$npx -y skills add avibebuilder/claude-prime --skill skill-creatorUse when the user wants to work on a Claude Code skill file (SKILL.md): writing one from scratch, testing whether an existing one works well, running evals or benchmarks, improving its instructions, or fixing why it isn't triggering. Triggers on: 'make a skill for X', 'test this
| 1 | # Skill Creator |
| 2 | |
| 3 | Default operating mode: autonomous — create or update the skill, run evals, improve it, optimize the description, and return with a final report. Only pause for human review if the user explicitly requests it or you hit an ambiguity that can't be resolved from the evidence alone. |
| 4 | |
| 5 | At a high level, the process of creating a skill goes like this: |
| 6 | |
| 7 | - Decide what you want the skill to do and roughly how it should do it |
| 8 | - Write a draft of the skill |
| 9 | - Create a few test prompts and run claude-with-access-to-the-skill on them |
| 10 | - Evaluate the results both qualitatively and quantitatively |
| 11 | - While the runs happen in the background, draft some quantitative evals if there aren't any (if there are some, you can either use as is or modify if you feel something needs to change about them) |
| 12 | - Use the `eval-viewer/generate_review.py` script to show the results if the user wants to review |
| 13 | - Rewrite the skill based on eval results, benchmark data, and user feedback (if review was requested) |
| 14 | - Repeat until quality thresholds are met or the user is satisfied |
| 15 | - Optimize the description for triggering accuracy parallel |
| 16 | |
| 17 | Figure out where the user is in this process and then jump in and help them progress through these stages. Route based on what they need. Of course, you should always be flexible and if the user is like "I don't need to run a bunch of evaluations, just vibe with me", you can do that instead. |
| 18 | |
| 19 | **Workspace convention**: All eval artifacts go in `tmp/<skill-name>-workspace/` under the project root (the directory containing `.claude/`). This directory is gitignored. Within the workspace, organize by iteration (`iteration-1/`, `iteration-2/`, etc.). |
| 20 | |
| 21 | **Nested invocation**: When invoked as a subagent with an explicit `outputs` directory, use that `outputs/` directory as the root for all inner workspaces — not `tmp/<skill-name>-workspace/`. |
| 22 | |
| 23 | Track your progress with tasks/todos — without them, description optimization and the judge step are commonly skipped. |
| 24 | |
| 25 | ## Communicating with the user |
| 26 | |
| 27 | The skill creator is liable to be used by people across a wide range of familiarity with coding jargon. If you haven't heard (and how could you, it's only very recently that it started), there's a trend now where the power of Claude is inspiring plumbers to open up their terminals, parents and grandparents to google "how to install npm". On the other hand, the bulk of users are probably fairly computer-literate. |
| 28 | |
| 29 | So please pay attention to context cues to understand how to phrase your communication! In the default case, just to give you some idea: |
| 30 | |
| 31 | - "evaluation" and "benchmark" are borderline, but OK |
| 32 | - for "JSON" and "assertion" you want to see serious cues from the user that they know what those things are before using them without explaining them |
| 33 | |
| 34 | It's OK to briefly explain terms if you're in doubt, and feel free to clarify terms with a short definition if you're unsure if the user will get it. |
| 35 | |
| 36 | --- |
| 37 | |
| 38 | ## Creating a skill |
| 39 | |
| 40 | ### Capture Intent |
| 41 | |
| 42 | Start by understanding the user's intent. The current conversation might already contain a workflow the user wants to capture (e.g., they say "turn this into a skill"). If so, extract answers from the conversation history first — the tools used, the sequence of steps, corrections the user made, input/output formats observed. |
| 43 | **Skip if in autonomous mode**: The user may need to fill the gaps, and should confirm before proceeding to the next step. |
| 44 | |
| 45 | 1. What should this skill enable Claude to do? |
| 46 | 2. When should this skill trigger? (what user phrases/contexts) |
| 47 | 3. What's the expected output format? |
| 48 | 4. What evaluation strategy fits? Objectively verifiable outputs (file transforms, code generation) → expectations and baselines. Subjective outputs (writing style, art) → qualitative analysis. |
| 49 | |
| 50 | **Skip if in autonomous mode**: If a gap is genuinely irresolvable from context and would materially change the skill's correctness, pause and ask. Otherwise infer, state it, and proceed. |
| 51 | |
| 52 | ### Interview and Research |
| 53 | |
| 54 | Proactively ask questions about edge cases, input/output formats, example files, success criteria, and dependencies. Wait to write test prompts until you've got this part ironed out. SKIP this interview in autonomous mode, let make decisions yourself |
| 55 | |
| 56 | **Research existing skills** — MUST read `references/available-skill-resources.md` for curated skill repositories, then fetch the READM |