Anthropic's skill-creator helps create, revise, and evaluate reusable skills. It turns a vague request for a long prompt into concrete decisions: when the skill should activate, which inputs it needs, what it should produce, and how to judge improvement. It works best when you already understand the repeated task you want to capture.
Install and first invocation
This guide covers skill-creator in Anthropic's anthropics/skills repository. For Claude Code, Anthropic's current documentation recommends installing its standalone official skill-creator plugin; the plugin's SKILL.md currently matches the same-named file in that repository. Start Claude Code in your project, then enter this in the Claude Code prompt:
/plugin install skill-creator@claude-plugins-official
The command opens the plugin details. Check the name, choose an install scope, and complete the installation; it is not a shell command. If Claude Code says it cannot find the claude-plugins-official marketplace, enter /plugin marketplace add anthropics/claude-plugins-official in the same prompt, then retry the install command. Follow any reload instruction in the install summary. Once active, type / and check that the plugin's skill-creator skill appears in the list. If you already have example-skills@anthropic-agent-skills, check whether it already supplies the same skill before installing another copy.
Then, in the same project conversation, ask Claude to “use skill-creator” and provide the task or files. The prompt below is an editable starting example. Installing supplies instructions and resources; it does not supply your source material or guarantee that your local environment can run the full evaluation workflow. If the skill is missing, check the install summary, whether the plugin is enabled, and whether the current session loaded it before troubleshooting the requested output.
Bring a task with inspectable outputs
Use skill-creator to turn customer interview notes into an action-list workflow.
Inputs are Markdown interviews. Outputs need problems, supporting excerpts, owners, and open questions.
Do not present customer guesses as verified facts or invent owners.
Clarify the trigger boundary before drafting SKILL.md.
Test three different interviews, not just this example.
Provide examples of good and poor past results. Define the output format and unacceptable behavior. The skill starts with scope, then writes the name, description, and instructions. The description helps determine when the skill is discovered; the body explains the workflow, decisions, and supporting resources.
Put templates, references, and reusable scripts in appropriate resource directories, with clear pointers from the main file. Avoid turning every detail of one example into a permanent rule. A comprehensible structure is easier to maintain than a growing collection of unexplained absolute commands.
Compare the same tasks under different instructions
Start with two or three realistic prompts covering normal input, missing material, and inconsistent formatting. For a new skill, compare runs with and without it. For an existing skill, preserve the old version and compare both versions on the same inputs. Check objective properties such as required fields, accurate excerpts, and explicit unknowns; use human review for subjective writing quality.
The official workflow organizes outputs by iteration and test case, combining quantitative checks with feedback on the actual artifacts. Inspect individual failures and execution traces rather than only the average score. A weak result may indicate unclear instructions or an uninformative test. After revising, repeat the comparison and add unseen cases so the skill does not become a solution tailored to three files.
Trigger-description optimization comes later. It uses both queries that should activate the skill and nearby tasks that should not. Those boundary cases are more useful than obviously unrelated requests. The scripts need the relevant CLI and model environment; not every chat interface can run them. Without those capabilities, drafting and manual trials remain useful, but should not be described as independent baseline evaluation.
Deliver the skill directory, representative inputs, review feedback, and installation guidance. When updating an existing skill, preserve its identity and explain which behavior changed. That gives future maintainers a reasoned improvement rather than an unexplained replacement.
Test whether the skill activates at the right time
Do not test a new skill with only one ideal prompt. Prepare requests that clearly should trigger it, look similar but should not, and should trigger despite missing material. Save a baseline without the skill and compare it with the skilled run on the same input. Check whether essential steps were completed and whether missing facts were invented. That distinguishes attractive instructions from useful behavior.
If the skill never activates, improve the description's trigger and boundary. If it activates but performs badly, revise the workflow or supporting resources. Change one failure class at a time, rerun the same examples, and add fresh examples to guard against overfitting. Keep inputs, expected checks, and failure notes with the deliverable so later revisions can be evaluated.
Divide work between instructions and references
The description tells the agent when to enter; the main file should show the shortest reliable process. Put long lists, templates, and examples in adjacent references for use when needed. If every edge case is copied into the main file, essential steps become hard to notice. Read failure traces before editing: was a reference missed, was order misunderstood, or did two rules conflict? Restructuring the relevant material usually helps more than adding another undirected “must follow” line.
Inspect traces when trigger scores look wrong
Do not broaden a description immediately because an evaluator reports zero recall. In a published 20-query test, the harness could mark a run as failed when the model called Bash or Glob before the eventual Skill call. Inspect the event trace to see whether the skill actually loaded, then revise the trigger description and rerun the same positives and near-miss negatives.