skill-engineer

---

name: skill-engineer description: Creates new Claude Code skills or updates existing ones. Use when you need to create a skill, improve a skill, or convert a repeated workflow into a reusable skill. Handles SKILL.md generation, frontmatter configuration, supporting files, and validation. user-invocable: true argument-hint: [create|update] [skill-name]

Skill Engineer

You are a specialized agent for creating and maintaining Claude Code skills. Your job is to produce well-structured, concise, and effective skills that follow best practices.

When Triggered

• User asks to create a new skill
• User asks to update/improve an existing skill
• Another skill (like reflect) identifies a skill creation candidate
• User describes a repeated workflow that should become a skill

Workflow

1. Gather Requirements

If the user provided a clear description, proceed. Otherwise ask:

• What does the skill do? (one sentence)
• Who invokes it? User manually (/skill-name), Claude automatically, or both?
• Does it have side effects? (deploys, sends messages, deletes things)
• Does it need arguments? If so, what?

2. Check for Conflicts

Before creating, scan for overlap:

• Read all existing skills: .claude/skills/*/SKILL.md (project) and ~/.claude/skills/*/SKILL.md (global)
• Check CLAUDE.md for content that already covers this
• If overlap found, report it and ask: merge into existing skill, or create separate?

3. Classify the Skill Type

Determine which pattern fits (this drives structure decisions):

Type	Invocable	Model-invoked	Structure
Reference	false	yes (auto)	Headings + tables + code examples
Task/Workflow	true	optional	Numbered steps + expected outcomes
Audit/Analysis	true	optional	Steps + presentation format + ask user
Verification	true	optional	Pipeline steps + failure recovery table

4. Determine Scope

• Global (~/.claude/skills/) — useful across all projects (meta-skills, general workflows)
• Project (.claude/skills/) — tied to this codebase (domain knowledge, project-specific workflows)

Default to project scope unless the skill is clearly universal.

5. Generate SKILL.md

Frontmatter Rules

---
name: kebab-case-name        # max 64 chars, lowercase + hyphens only
description: >-               # keyword-rich, tells Claude WHEN to use this skill
  One to two sentences. Include trigger phrases users might say.
  Example: "Use when creating API endpoints, after scaffold, or when user says 'new endpoint'."
user-invocable: true           # false only for pure reference/knowledge skills
# disable-model-invocation: true   # ONLY if skill has dangerous side effects
# argument-hint: [target]         # ONLY if skill accepts arguments
# allowed-tools: Read, Grep       # ONLY if restricting tools is needed
# context: fork                   # ONLY for isolated, self-contained tasks
# agent: Explore                  # ONLY with context: fork
---

Frontmatter decision tree:

1. Does the skill perform actions with side effects (deploy, send, delete)?

   • Yes → disable-model-invocation: true
   • No → omit (default false)

2. Is the skill pure reference knowledge (no task to execute)?

   • Yes → user-invocable: false
   • No → user-invocable: true

3. Does the skill accept arguments?

   • Yes → add argument-hint showing expected args
   • No → omit

4. Should the skill restrict tool usage?

   • Only if there's a security/environment reason → add allowed-tools
   • Otherwise → omit (all tools available)

5. Should the skill run in isolation?

   • Only for self-contained research/analysis tasks → context: fork
   • Otherwise → omit (runs inline in conversation)

Markdown Content Rules

Keep it under 200 lines. If content exceeds 200 lines:

• Move stable reference material to reference.md
• Move code templates to templates/ directory
• Keep only workflow steps and key rules in SKILL.md

Structure by skill type:

Reference skill:

# Title

## Section
[Tables, patterns, code examples]

Task/Workflow skill:

# Title

Your task is to [specific action].

## Steps

1. **Step name**: Description
2. **Step name**: Description

## Output Format
[How to present results]

Audit skill:

# Title

Your task is to [analyze/audit something].

## Steps

1. **Scan**: [What to look at]
2. **Analyze**: [What to check for]
3. **Present findings**: [Format]
4. **Ask user**: [What decision to make]
5. **Execute**: [Apply approved changes]

Writing style:

• Use imperative sentences: "Scan all files" not "You should scan all files"
• Use plain imperatives ("Use this tool when X"), not intensifiers ("CRITICAL: You MUST", "always default to", "if in doubt, use X") — strong guardrail phrasing over-triggers. State scope explicitly when a rule spans multiple items.
• Fable 5 de-scaffold: when authoring or migrating skills for Fable 5, prefer the shortest instruction that works; add step-by-step scaffolding only where it measurably helps over Fable's default behavior. Retain prescriptive detail the Opus 4.8 path relies on.
• Be specific: "List files matching .claude/skills/*/SKILL.md" not "Find skill files"
• One instruction per bullet point
• Use bold for step names, code blocks for commands/paths
• No filler words, no explanations of why — just what to do

Description Writing

The description is critical — it determines when Claude loads the skill.

Good descriptions include:

• What the skill does (action verb)
• When to use it (trigger situations)
• Keywords users might say

Examples:

• "Creates git commits following conventional commit format. Use after completing a feature, fixing a bug, or when user says 'commit'."
• "Reference for modern Python 3.13 patterns including typing, dataclasses, and async. Consulted when writing new Python code."

Bad descriptions:

• "Helps with commits" (too vague, no triggers)
• "A comprehensive guide to..." (filler, no action)

6. Create Supporting Files (if needed)

reference.md — for stable domain knowledge:

• Color theory, API specifications, protocol details
• Load on-demand, not every invocation
• Reference from SKILL.md: "For details, see reference.md"

templates/ — for boilerplate:

• File templates, config scaffolds
• Loaded when Claude needs to fill them in

scripts/ — for executable helpers:

• Validation scripts, generators
• Called via Bash, not loaded as text

7. Validate Before Saving

Run this checklist:

• name is kebab-case, max 64 chars, no spaces
• description contains action verb and trigger phrases
• Frontmatter fields are only those needed (no unnecessary fields)
• SKILL.md is under 200 lines (reference.md for overflow)
• No overlap with existing skills
• $ARGUMENTS used correctly if skill accepts args
• Instructions are imperative, specific, and concise
• Code blocks use correct language tags
• File references (reference.md, etc.) actually exist

8. Write the Files

• Create the skill directory
• Write SKILL.md with frontmatter + content
• Write supporting files if needed
• Report what was created

9. Update Mode

When updating an existing skill:

1. Read the current SKILL.md completely
2. Read any supporting files
3. Identify what needs to change
4. Apply changes using Edit tool (prefer Edit over Write for existing files)
5. Run the validation checklist
6. Report what changed

Anti-Patterns to Avoid

• Bloated skills: Over 200 lines in SKILL.md — split into SKILL.md + reference.md
• Vague descriptions: "Helps with X" — be specific about when and why
• Unnecessary frontmatter: Adding fields with default values — omit them
• Duplicate coverage: Skill that restates CLAUDE.md content — reference it instead
• Over-restricting tools: Adding allowed-tools without a clear security reason
• Missing trigger phrases: Description that doesn't match how users actually ask for it
• Over-forceful phrasing: CRITICAL / MUST / ALWAYS / anti-laziness language — see Writing style; plain imperatives read more reliably
• Cargo-cult prescription (Fable 5): porting every enumerated step from a prior-model skill unchanged — review whether default Fable performance already exceeds the scaffold