$npx -y skills add himself65/finance-skills --skill skill-creatorCreate 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 quali
| 1 | # Skill Creator |
| 2 | |
| 3 | 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. |
| 4 | |
| 5 | **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. |
| 6 | |
| 7 | **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. |
| 8 | |
| 9 | --- |
| 10 | |
| 11 | ## Step 1: Understand What the User Wants |
| 12 | |
| 13 | Classify the request into one of these modes: |
| 14 | |
| 15 | | User Intent | Mode | Jump To | |
| 16 | |---|---|---| |
| 17 | | Create a brand-new skill | **Create** | Step 2 | |
| 18 | | Improve / fix an existing skill | **Improve** | Step 6 | |
| 19 | | Evaluate / score a skill's quality | **Evaluate** | Step 7 | |
| 20 | |
| 21 | If ambiguous, ask: "Do you want to create a new skill, improve an existing one, or evaluate one?" |
| 22 | |
| 23 | ### Gather Requirements (for Create mode) |
| 24 | |
| 25 | Before writing anything, answer these questions (ask the user if unclear): |
| 26 | |
| 27 | | Question | Why it matters | |
| 28 | |---|---| |
| 29 | | What task does the skill automate? | Defines the core workflow | |
| 30 | | Who is the target user? | Determines complexity and terminology level | |
| 31 | | What tools/APIs/CLIs does it use? | Determines dependencies and platform restrictions | |
| 32 | | What does the user provide as input? | Defines parameters and defaults | |
| 33 | | What should the output look like? | Defines the response template | |
| 34 | | Does it need API keys or credentials? | Determines `required_environment_variables` | |
| 35 | | Should it work on Claude.ai or only CLI? | Determines platform field and dynamic commands | |
| 36 | |
| 37 | --- |
| 38 | |
| 39 | ## Step 2: Plan the Skill Architecture |
| 40 | |
| 41 | Before writing SKILL.md, plan the structure. Read `references/architecture-patterns.md` for detailed guidance on each pattern. |
| 42 | |
| 43 | ### Choose a Structural Pattern |
| 44 | |
| 45 | | Pattern | When to use | Steps | Example | |
| 46 | |---|---|---|---| |
| 47 | | **Linear** | Single workflow, no branching | 5-7 | earnings-preview, etf-premium | |
| 48 | | **Router** | Multiple sub-tasks under one umbrella | 3 + sub-skills | stock-correlation (4 sub-skills) | |
| 49 | | **Methodology** | Complex domain framework with sequential gates | 7-9 | sepa-strategy (9-step trading methodology) | |
| 50 | | **Widget** | Generates interactive UI output | 4-5 | options-payoff (extract + compute + render) | |
| 51 | | **API Wrapper** | Wraps an external API with many endpoints | 3-5 + heavy references | funda-data (5 steps, 8 reference files) | |
| 52 | |
| 53 | ### Plan the Step Outline |
| 54 | |
| 55 | Write out the step names before writing content. Every skill should have: |
| 56 | |
| 57 | 1. **Detection flow** (Step 1) -- dynamically detect available tools, auth state, and runtime environment; build a decision tree for which method to use |
| 58 | 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 |
| 59 | 3. **Respond to user** (Final step) -- structured output template |
| 60 | |
| 61 | Target **5-9 steps** total. More than 9 means the skill should be split or use a router pattern. |
| 62 | |
| 63 | ### Plan the Detection Flow |
| 64 | |
| 65 | 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: |
| 66 | |
| 67 | | Question | How to detect | Decision | |
| 68 | |---|---|---| |
| 69 | | Is the CLI tool installed? | `command -v tool` | CLI path vs Python fallback | |
| 70 | | Is the user authenticated? | `tool auth status` / `echo $API_KEY` | Skip auth setup vs guide through it | |
| 71 | | Which runtime has the library? | `import lib` in terminal vs execute_code | Route to correct runtime | |
| 72 | | Is a richer tool available? | `gh --version` vs `git --version` | Rich path vs minimal path | |
| 73 | | Is live data re |