/skill-creator

name: skill-creator
description: >
  Create new skills, modify and improve existing skills, and measure skill performance.
  Use when users want to create a skill from scratch, update or optimize an existing skill,
  run evals to test a skill, benchmark skill performance with variance analysis, or iterate
  on skill quality. Triggers: "create a skill", "make a new skill", "build a skill for",
  "write a skill that", "skill for doing X", "I want a skill to", "new skill", "design a skill",
  "scaffold a skill", "improve this skill", "optimize this skill", "this skill isn't working well",
  "evaluate this skill", "score this skill", "how good is this skill", "run evals on",
  "benchmark this skill", "test this skill's quality", "skill quality", "skill performance".
  Also triggers when a user describes a repeatable workflow they want to automate, says
  "I keep doing X manually", "can you remember how to do X", or "turn this into a skill".

Skill Creator

Create, evaluate, and iterate on high-quality agent skills. This skill guides the entire lifecycle: planning what the skill should do, writing SKILL.md and reference files, scoring quality against a rubric, and iterating until the skill meets production standards.

**Philosophy:** A great skill is not a long skill. It is a *precise* skill: exhaustive triggers, explicit defaults, clear steps with exit gates, deferred complexity via reference files, and a structured output template.

**Core rule — always dynamic, never static:** Skills MUST detect what tools, libraries, and auth are available at runtime and adapt their behavior accordingly. Never hardcode a single method. Always provide a detection flow with a decision tree and fallback paths. See `references/dynamic-calling.md` for the complete pattern catalog.

---

Step 1: Understand What the User Wants

Classify the request into one of these modes:

| User Intent | Mode | Jump To | |---|---|---| | Create a brand-new skill | **Create** | Step 2 | | Improve / fix an existing skill | **Improve** | Step 6 | | Evaluate / score a skill's quality | **Evaluate** | Step 7 |

If ambiguous, ask: "Do you want to create a new skill, improve an existing one, or evaluate one?"

Gather Requirements (for Create mode)

Before writing anything, answer these questions (ask the user if unclear):

| Question | Why it matters | |---|---| | What task does the skill automate? | Defines the core workflow | | Who is the target user? | Determines complexity and terminology level | | What tools/APIs/CLIs does it use? | Determines dependencies and platform restrictions | | What does the user provide as input? | Defines parameters and defaults | | What should the output look like? | Defines the response template | | Does it need API keys or credentials? | Determines `required_environment_variables` | | Should it work on Claude.ai or only CLI? | Determines platform field and dynamic commands |

---

Step 2: Plan the Skill Architecture

Before writing SKILL.md, plan the structure. Read `references/architecture-patterns.md` for detailed guidance on each pattern.

Choose a Structural Pattern

| Pattern | When to use | Steps | Example | |---|---|---|---| | **Linear** | Single workflow, no branching | 5-7 | earnings-preview, etf-premium | | **Router** | Multiple sub-tasks under one umbrella | 3 + sub-skills | stock-correlation (4 sub-skills) | | **Methodology** | Complex domain framework with sequential gates | 7-9 | sepa-strategy (9-step trading methodology) | | **Widget** | Generates interactive UI output | 4-5 | options-payoff (extract + compute + render) | | **API Wrapper** | Wraps an external API with many endpoints | 3-5 + heavy references | funda-data (5 steps, 8 reference files) |

Plan the Step Outline

Write out the step names before writing content. Every skill should have:

1. **Detection flow** (Step 1) -- dynamically detect available tools, auth state, and runtime environment; build a decision tree for which method to use 2. **Core methodology** (Steps 2-N) -- the actual work, with pass/fail gates; each step that calls an external tool should have method alternatives based on what Step 1 detected 3. **Respond to user** (Final step) -- structured output template

Target **5-9 steps** total. More than 9 means the skill should be split or use a router pattern.

Plan the Detection Flow

Every skill that touches external tools MUST start with a runtime detection flow. Read `references/dynamic-calling.md` for all patterns. The detection flow answers:

| Question | How to detect | Decision | |---|---|---| | Is the CLI tool installed? | `command -v tool` | CLI path vs Python fallback | | Is the user authenticated? | `tool auth status` / `echo $API_KEY` | Skip auth setup vs guide through it | | Which runtime has the library? | `import lib` in terminal vs execute_code | Route to correct runtime | | Is a richer tool available? | `gh --version` vs `git --version` | Rich path vs minimal path | | Is live data reachable? | `curl -s endpoint` | Live data vs cached/default |

The detection output feeds into a **decision tree** that the rest of the skill follows. Never assume — always check.

Plan Reference Files

Decide what goes in SKILL.md vs references/:

| In SKILL.md (under ~250 lines) | In references/ | |---|---| | Step-by-step workflow | Detailed API documentation | | Routing/decision tables | Code templates (>20 lines) | | Parameter defaults table | Formulas and edge cases | | Output format template | Troubleshooting database | | Quick examples (1-3) | Comprehensive examples (4+) |

---

Step 3: Write the SKILL.md

Read `references/writing-guide.md` for detailed instructions on writing each section. Read `references/frontmatter-guide.md` for the complete YAML field reference.

Key Rules

1. **Frontmatter first**: `name` (lowercase-hyphenated, max 64 chars) and `description` (exhaustive trigger list, max 1024 chars) are required. Description needs 5+ triggers including sideways