skill-creator

Generated source view for the actual executable productivity/skill-creator skill. The durable routing article is Agent Operations Skills. Source: skills/productivity/skill-creator/SKILL.md

Runtime Source

Bundled Resources

These files are part of the executable skill folder and must be preserved with the skill source.

Description

Create, test, prune, and iteratively improve agent skills with structured evaluation. Use when creating a new skill, turning a workflow into a skill, improving/tightening an existing skill, pruning no-op instructions, reducing skill token cost, or when the user says "create a skill", "make a skill", "turn this into a skill", "skill for X", "improve this skill", "tighten this skill", or "remove no-ops." Based on anthropics/skills plus Matt Pocock's writing-great-skills/no-op pruning guidance. Wiki-aware — always checks the wiki before creating skills and updates the wiki after.

Skill Source

---
name: skill-creator
description: Create, test, prune, and iteratively improve agent skills with structured evaluation. Use when creating a new skill, turning a workflow into a skill, improving/tightening an existing skill, pruning no-op instructions, reducing skill token cost, or when the user says "create a skill", "make a skill", "turn this into a skill", "skill for X", "improve this skill", "tighten this skill", or "remove no-ops." Based on anthropics/skills plus Matt Pocock's writing-great-skills/no-op pruning guidance. Wiki-aware — always checks the wiki before creating skills and updates the wiki after.
origin: personal
source_slug: skill-creator
---

# Skill Creator

Create new skills and iteratively improve them. Wiki-aware variant that integrates with Kevin's LLM Wiki.

## Wiki-First Protocol

Before creating any skill:

1. **Check the wiki.** Read `wiki/_index.md` and search for pages related to the skill's domain. Existing wiki pages contain Kevin's compiled knowledge and preferences.
2. **Check skills.sh.** Use the `find-skills` skill to search for existing upstream skills. Prefer adapting an upstream skill over building from scratch.
3. **Check installed skills.** Scan the category source folders under `skills/{engineering,productivity,personal,misc}/` plus drafts/retired folders for overlap. Don't create a skill that duplicates an existing one.

After creating a skill:

1. **Update `wiki/tools/skills-sh.md`** — Add the new skill to the installed skills table
2. **Update `AGENTS.md`** — Add to the installed skills table in the Skills section
3. **Update `wiki/log.md`** — Record what was created and why
4. **Cross-reference** — Update related wiki pages with links to the new skill
5. **Rebuild index** — Run `npx tsx scripts/build-index.ts`

## Skill Creation Process

### 1. Capture Intent

- What should this skill enable the agent to do?
- When should it trigger? (specific user phrases and contexts)
- What's the expected output format?
- Does an upstream skill on skills.sh already cover this? (check first)

### 2. Interview and Research

- Ask about edge cases, input/output formats, success criteria, dependencies
- Check wiki pages for existing knowledge on the topic
- Check skills.sh for similar skills that could be adapted

### 3. Write the SKILL.md

Install skills to the right category source folder, e.g. `skills/engineering/<name>/SKILL.md`, `skills/productivity/<name>/SKILL.md`, `skills/personal/<name>/SKILL.md`, or `skills/misc/<name>/SKILL.md`. Agent runtimes load the generated `skills/.runtime/all` index. Required structure:

```yaml
---
name: skill-name
description: What it does and when to trigger. Be pushy — include specific trigger phrases.
---
```

**Skill anatomy:**

```
skill-name/
├── SKILL.md (required)
│   ├── YAML frontmatter (name, description required)
│   └── Markdown instructions
└── Bundled Resources (optional)
    ├── scripts/     - Executable code for deterministic tasks
    ├── references/  - Docs loaded into context as needed
    └── assets/      - Templates, icons, fonts
```

### 4. Writing Guidelines

- Keep SKILL.md under 500 lines; use `references/` for overflow
- Explain the **why** behind instructions — LLMs respond better to reasoning than rigid MUSTs
- Include examples with concrete input/output
- Always include a "Related Skills" section at the bottom
- Always reference relevant wiki pages where applicable (e.g., "Read `wiki/design/design-system.md` for current tokens")

### 5. Skill Design Discipline

Use Matt Pocock's `writing-great-skills` vocabulary when shaping or pruning a skill:

- **Invocation load.** A model-invoked skill spends context every turn through its description; a user-invoked skill spends Kevin's memory. Keep model invocation only when the agent or another skill must discover it autonomously. Otherwise, prefer a router skill that names the lower-level commands.
- **Branches.** A description should state the skill's leading word and the distinct trigger branches. Synonyms for the same branch are duplication; delete them.
- **Completion criteria.** Every ordered step should end with a checkable done condition. If a fuzzy criterion makes the agent rush, sharpen it before splitting the skill.
- **Progressive disclosure.** Put material every branch needs in `SKILL.md`. Move branch-specific reference into `references/`, named for the context pointer that should load it.
- **Single source of truth.** Each meaning lives in one place. Delete sediment, no-op advice, and repeated explanations instead of adding another section.
- **Leading words.** Prefer compact terms the model can reason with consistently, like "red loop", "tracer bullet", "deep module", or "router", then use them consistently across descriptions, docs, and prompts.

### 6. No-Op Pruning Pass

Run this branch when improving an existing skill, especially if Kevin says it feels too long, vague, bloated, token-heavy, or padded with generic virtue advice.

Matt Pocock's test: an instruction is a no-op when removing it does not change the agent's behavior for this skill. No-op status is contextual; there is no universal banned phrase list.

For each candidate line or paragraph:

1. **Classify the job.** Is it routing, a required file/tool, an output contract, a stop condition, a domain invariant, or a concrete example? If not, it is suspect.
2. **Delete generic virtue words.** Remove instructions like "be thorough", "write readable code", "make a detailed commit message", or "use best practices" unless the skill defines a task-specific test for that virtue.
3. **Merge duplicates.** Keep the sharpest single statement when two lines constrain the same behavior.
4. **Behavior-test the deletion.** Ask: would a competent agent choose a different first action, file, tool, output shape, or verification step without this sentence? If no, delete it.
5. **Replace vague advice with checkable criteria.** If the idea matters, rewrite it as a branch, artifact, command, threshold, or done condition.
6. **Record the compression.** When pruning a material skill, note the source and approximate reduction in the wiki timeline so future agents know the intent was quality, not accidental deletion.

### 7. Description Optimization

The description field is the primary triggering mechanism. Include:
- What the skill does
- Specific contexts for when to use it
- Trigger phrases users might say
- Upstream source attribution if based on a skills.sh skill

For model-invoked skills, front-load the leading word and keep the description biased toward trigger branches. For user-invoked skills, set `disable-model-invocation: true` and keep the description human-facing.

### 8. Testing

After writing, create 2-3 realistic test prompts:
- Something a real user would actually type
- Include edge cases and near-misses
- Test trigger accuracy (should-trigger vs should-not-trigger)

### 9. Wiki Integration (Mandatory)

After creating the skill, always:

```bash
# Update the installed skills table in AGENTS.md
# Update wiki/tools/skills-sh.md
# Append to wiki/log.md
# Rebuild backlinks
npx tsx scripts/build-index.ts
```

## Key Principles

- **Upstream first** — Check skills.sh before building from scratch
- **Wiki-aware** — Reference wiki pages for domain context
- **Focused** — One skill per concern, under 500 lines
- **Explain why** — Reasoning over rigid rules
- **Trigger branches** — One distinct invocation branch per description clause
- **Progressive disclosure** — Keep common steps in `SKILL.md`; move branch-only reference behind context pointers
- **Prune sediment** — Delete duplication, no-ops, and stale advice aggressively; keep only behavior-changing guidance
- **Test** — Verify trigger accuracy with realistic prompts

## Related Skills

- `find-skills` — Search skills.sh for existing skills
- `mattpocock-skills` — Source repo for `writing-great-skills` and the engineering-flow imports
- `content-strategy` — Example of a personalized skill with upstream references
- `vercel-react-best-practices` — Example of an upstream skill adapted for local use

<!-- folded-skills:auto:start -->
## Folded Skill References

These former standalone skills are bundled here as references to keep the runtime list compact. Load only the reference that matches the user's exact product, framework, or failure mode.

| Former skill | Reference | Description |
| --- | --- | --- |
| `claude-skill-creator` | [`references/skills/claude-skill-creator/SKILL.md`](references/skills/claude-skill-creator/SKILL.md) | Create new skills, modify and improve existing skills, and measure skill performance. Use when users want to create a skill from scratch, edit, or optimize an existing skill, run evals to test a skill, benchmark skill performance with variance analysis, or optimize a skill's description for better triggering accuracy. |
<!-- folded-skills:auto:end -->

---

Timeline

• 2026-07-15 | Generated a browseable source page from the actual executable skill file. Source: skills/productivity/skill-creator/SKILL.md