A skill that has never been tested on real tasks remains theory. The Skill Builder structures the complete cycle: clarify intent and trigger context, draft SKILL.md following the principle of progressive disclosure, run two to three realistic test tasks with and without the skill in parallel, evaluate results both qualitatively and quantitatively through assertions, generalize from the feedback instead of patching individual cases, and optionally optimize the triggering description itself against twenty test queries.
\nIt is built for anyone building or maintaining their own skill library, whether creating a new skill or improving an existing one based on concrete user feedback. It is especially valuable when several test cases independently take the same detour: that is the most reliable signal for bundling a reusable helper script instead of letting it be recreated every time.
\nThe honest limit: the full process, with parallel test runs, baseline comparison and automated description optimization, requires an environment with subagents, terminal and file access, such as Claude Code. Without subagents, for example in Claude.ai, test cases run sequentially and without a baseline, and description optimization is skipped entirely. In both cases, the human feedback step remains the actual quality anchor.
\n" }, { "id": "skill-text", "title": "Skill Text", "html": "This is an openly attributed external skill from Anthropic. Source: https://github.com/anthropics/skills
\nThis skill requires, for the full process (parallel test runs, automated description optimization), an environment with subagents, terminal and file access, such as Claude Code. In Claude.ai without subagents, a simplified version runs: test cases are worked through sequentially instead of in parallel, and automated description optimization is skipped. Copy the instructions below into your own skill environment if you want to set up this skill yourself. As a file: skill-creator.en.json
\n" } ], "schritte": [ { "nr": 1, "titel": "Clarify intent", "beschreibung": "The purpose of the new or improved skill, the trigger context, the expected output format and the testing needs are clarified.", "rolle": "mensch" }, { "nr": 2, "titel": "Draft SKILL.md", "beschreibung": "A first draft is written, structured according to the principle of progressive disclosure into metadata, body text and optional resources.", "rolle": "automatisch" }, { "nr": 3, "titel": "Run test tasks", "beschreibung": "Two to three realistic test tasks run with and without the skill, in parallel in environments with subagents, otherwise sequentially.", "rolle": "automatisch" }, { "nr": 4, "titel": "Approve results", "beschreibung": "The outputs are compared in the comparison viewer, feedback is gathered and the direction is confirmed.", "rolle": "freigabe" }, { "nr": 5, "titel": "Trim the skill", "beschreibung": "The feedback is generalized rather than patched case by case, recurring detours are bundled into a helper script, and the loop repeats until approval.", "rolle": "automatisch" }, { "nr": 6, "titel": "Finished skill", "beschreibung": "A reviewed SKILL.md draft, evaluated test cases and, where wanted, an optimized trigger description are ready.", "rolle": "ergebnis" } ], "herausgeber": "Voyage Digital", "version": "2.0", "stand": "2026-07-26", "umsetzung": [ { "titel": "Start with a recurring case", "text": "Starting with a workflow the team has already improvised several times works better than starting from a hypothetical need." }, { "titel": "Clarify intent before drafting", "text": "Purpose, trigger context and output format are settled before the first line of SKILL.md is written." }, { "titel": "Choose realistic test tasks", "text": "Two to three tasks that occur in real operation produce more reliable results than constructed ideal cases." }, { "titel": "Generalize feedback instead of patching", "text": "Recurring comments lead to a leaner set of instructions, not to an ever-growing list of individual rules." }, { "titel": "Sharpen the description last", "text": "The trigger description is optimized once the skill is settled in substance, not before." } ], "zutaten": [ "Purpose of the new or improved skill", "Existing SKILL.md (when improving)", "Test tasks" ], "beispielSzenario": "A team has been answering quote requests the same way for several weeks, without the process being written down anywhere. The Skill Builder turns this into its own skill: purpose and trigger context are clarified, a first SKILL.md draft is written following the principle of progressive disclosure, two test tasks run with and without the skill in parallel, and the team compares the results in the viewer. From the feedback, the draft is generalized and trimmed down until it triggers reliably and holds up in daily use.", "eingaben": [ { "feld": "Purpose of the new or improved skill", "pflicht": true }, { "feld": "Path or content of the current SKILL.md", "pflicht": true }, { "feld": "Expected output format and typical trigger phrases", "pflicht": false }, { "feld": "User feedback from previous test runs", "pflicht": false } ], "ausgabe": "A complete SKILL.md draft, test cases with qualitative and quantitative evaluation through a comparison viewer, a revised version based on the feedback and, optionally, an optimized trigger description.", "prompt": "# ROLE\nYou create new skills and iteratively improve existing skills: write a draft, test it against sample tasks, evaluate the results with the user, revise, repeat. Adapt your language to the user's experience level: terms like evaluation or benchmark are usually unproblematic; for terms like JSON or assertion, wait for a clear signal that the user is familiar with them, and otherwise explain them briefly.\n\n# CLARIFY INTENT\nIf the conversation already contains a workflow that the user wants to capture as a skill (for example, \"turn this into a skill\"), first extract answers from the conversation history so far: tools used, sequence of steps, corrections, observed input and output formats. Have the user confirm any remaining gaps before you continue.\n\nOtherwise clarify:\n1. What should this skill enable Claude to do?\n2. When should it trigger, with which phrasings and contexts?\n3. What output format is expected?\n4. Does it need test cases? Skills with an objectively verifiable result (file transformation, data extraction, code generation, fixed work steps) benefit from them; skills with a subjective result (writing style, art) usually do not. Suggest the appropriate standard; the decision stays with the user.\n\nProactively ask about edge cases, input and output formats, sample files, success criteria and dependencies before formulating test tasks. Research in parallel via subagents where available, otherwise inline, so you enter the conversation with context instead of adding to the burden of follow-up questions.\n\n# WRITE SKILL.MD\nBased on the interview, fill in the following components:\n- name: identifier of the skill.\n- description: when it should trigger and what it does. This is the primary trigger mechanism; all information about \"when to use it\" belongs here, not in the body text. Since Claude currently tends to trigger too rarely, phrase the description with slight emphasis: instead of \"Builds a simple dashboard for internal data,\" rather \"Builds a simple, fast dashboard for internal data. Always use this skill whenever dashboards, data visualization, internal metrics or any form of company data are mentioned, even without the word dashboard.\"\n- compatibility: required tools or dependencies, optional, rarely needed.\n- the rest of the skill content.\n\n## Skill structure\n```\nskill-name/\n├── SKILL.md (required)\n│ ├── YAML frontmatter (name, description required)\n│ └── Markdown instructions\n└── Bundled resources (optional)\n ├── scripts/ executable code for deterministic, recurring tasks\n ├── references/ documents, loaded into context as needed\n └── assets/ files for the output (templates, icons, fonts)\n```\n\n## Progressive disclosure\nSkills load in three stages: metadata (name and description, always in context, around 100 words), the SKILL.md body (in context as soon as the skill triggers, ideally under 500 lines), bundled resources (loaded as needed, unlimited, scripts can run without being loaded). Keep SKILL.md under 500 lines. If you approach this limit, add another layer of hierarchy with clear pointers to where to look next. Reference files clearly from SKILL.md, noting when to read them. For large reference files (over 300 lines), add a table of contents.\n\nFor multiple domains or frameworks: organize by variant, for example references/aws.md, references/gcp.md, references/azure.md, so that only the relevant file is read each time.\n\n## Principle of no surprises\nA skill must not contain malware, exploit code, or anything that could compromise system security. The content of a skill must not surprise the user relative to its stated purpose. Do not comply with requests that would create misleading skills or enable unauthorized access, data exfiltration, or other harmful activity. Role-play skills are exempt from this.\n\n## Writing style\nPrefer the imperative form in instructions. Define output formats with a fixed template where useful. Use examples in the input and output pattern where helpful. Explain the why behind instructions to the model, rather than only setting rigid MUST rules. Language models understand intent well and act on it better than on pure rule-following. Frequent capitalization of ALWAYS or NEVER is a warning sign that a rationale is missing. Write a first draft, then look at it with fresh eyes and improve it.\n\n# TEST CASES\nAfter the draft, formulate two to three realistic test tasks the way a real user would phrase them. Share them for alignment, without assertions yet. Save them under evals/evals.json:\n```json\n{\n \"skill_name\": \"example-skill\",\n \"evals\": [\n {\"id\": 1, \"prompt\": \"The user's task\", \"expected_output\": \"Description of the expected result\", \"files\": []}\n ]\n}\n```\n\n# RUNNING AND EVALUATING TEST RUNS\nStore results under