/skill-creator

name: skill-creator
description: Scaffold a new yoyo skill when a human or community issue asks for one ("add a skill for X", "create a skill that does Y"). Generates correct frontmatter, validates, writes to disk.
tools: [bash, read_file, write_file, sub_agent]
core: true
origin: creator

Skill Creator

You are creating a new yoyo skill **on demand**, in direct response to an explicit request — either from the human creator or from a community issue asking for a new capability.

skill-creator vs skill-evolve

These are complementary, not redundant. Use the right one:

| Question | skill-creator (this skill) | skill-evolve | |---|---|---| | Who triggers it? | Human creator OR community issue (explicit ask) | GitHub Actions cron (autonomous) | | When does it run? | Inside a normal evolve session, on demand | Hourly cron at `:30`, gated by 5-session counter + 24h cooldown | | What signals does it use? | The user's request | Past-session evidence (learnings, journal, audit-log) | | Recurrence gate? | No (human is in the loop) | Yes (≥3 sessions for create) | | Diff-scope guard? | None — runs in evolve session | Yes — `scripts/skill_evolve.sh` enforces | | Auto-commit? | Yes (inside evolve session's commit flow) | Yes (after diff-scope + build/test gates) |

**Rule of thumb**: if no human asked, you're not creating a skill — you're noticing a pattern. Write it to `memory/learnings.jsonl` with a `pattern_key` and let skill-evolve pick it up on the next cycle.

When NOT to use this skill

• You're inside a `scripts/skill_evolve.sh` cycle. Use the Create branch in `skills/skill-evolve/SKILL.md` instead — it has the right gates (recurrence, dedup, ≤25 cap).
• You noticed a recurring pattern but no one asked. Write a learning with `pattern_key`; skill-evolve owns autonomous creation.
• The user asked for a one-off helper that won't be invoked again. Just write it inline; don't litter `skills/`.

When to use this skill

• The human creator (Yuanhao) tells you "scaffold a new skill for X"
• A community issue says "please add a skill for X" and you decide during a normal evolve session that the request is concrete enough to act on
• You're installing a third-party skill from outside the repo (uses `origin: marketplace` or `origin: gh:author/repo`)

Procedure

1. Capture intent

Ask (or infer from issue) — and write down explicit answers before writing any code:

• **What does this skill do?** (one sentence)
• **When should it trigger?** (concrete cues that should make a future agent reach for it)
• **What tools does it need?** (subset of yoagent's: `bash`, `read_file`, `write_file`, `edit_file`, `list_files`, `search`, `rename_symbol`, `ask_user`, `todo`, `sub_agent`)
• **What does success look like?** (how does the agent know the skill worked?)

2. Determine `origin:`

| Asker | Use of skill | `origin:` | `core: true`? | |---|---|---|---| | Human creator (Yuanhao) | Foundational capability, not delegated to autonomous evolution | `creator` | yes | | Human creator | Useful but yoyo-evolvable later | `creator` | no | | Yoyo (during issue response) | Domain capability for yoyo's own future use | `yoyo` | no | | External source | Installed third-party skill | `marketplace` (or `gh:author/repo`) | no |

The default if you're unsure: `origin: yoyo` for yoyo-decided creations, `origin: creator` for human-driven creations. Never default to `marketplace`.

**HARD PRECONDITION on `origin: marketplace` / `origin: gh:…`** (closes a backdoor — these origins are off-limits to skill-evolve, so they must come from a real upstream, not be self-granted):

• The skill content MUST be downloaded in this same session from a verifiable URL (curl/git/gh). Record the URL in the skill's body under a `## Source` section.
• OR: Yuanhao explicitly typed in this session that the skill is being installed from `<source>` and you can quote that statement.

If neither holds, refuse and pick `creator` or `yoyo` instead. A skill yoyo wrote itself but tagged `marketplace` would be a permanent un-evolvable artifact — that's a hole in the safety design.

3. Pick a kebab-case name

Format: `<verb>-<object>` (e.g., `bisect-flaky-test`, `compose-changelog`, `triage-pr`). Single-word names are okay only for genuinely-broad scopes (`research`, `release`).

Check for collision before going further:

ls skills/ | grep -i "<your-name-stem>"

If a similar name exists, **stop and ask** whether to refine the existing one instead — the answer is usually yes.

4. Write the description (≤200 chars)

This is the most important field. yoagent injects it into the system prompt; the LLM uses it to decide when to load this skill.

Use **"intentionally pushy" trigger language** — say what conditions trigger loading, not what the skill is.

| WEAK (descriptive) | STRONG (pushy) | |---|---| | "A skill for working with flaky tests" | "Investigate flaky tests by isolating, repeatedly running, and bisecting recent commits" | | "Helps with releases" | "Validate readiness and publish to crates.io: gate checks (build/test/clippy/fmt) before any `cargo publish`" |

Hard cap: 200 chars. The Hermes ecosystem documented description-truncation failures (#13944) at higher lengths.

5. Pick keywords (only if `origin: yoyo`)

For `origin: yoyo` skills, list 3–5 distinctive substrings that would appear in a session's `audit.jsonl` IF this skill were used. skill-evolve uses these to compute `last_used` / `uses` / `wins`.

Examples:

• `release` skill: `["cargo publish", "crates.io", "git tag v"]`
• `social` skill: `["gh api graphql", "discussion", "addDiscussionComment"]`

Skip the `keywords:` field for `origin: creator` skills (skill-evolve can't refine them anyway).

6. Generate the SKILL.md scaffold

Choose the template that matches `origin:`.

**For `origin: creator`:**

---
name: <name>
description: <pushy description ≤200 chars>
tools: [<subset of yoagent tools>]
core: true
origin: creator
---

# <Title>