skill-test-design
Skill4 starsChanged 29 days agoMITView on GitHub
[METHODOLOGY] Design test scenarios for skills through user interview. Reads the target skill, interviews about scope and edge cases, saves scenario files for skill-testing to execute. Pure reference — invoked via slash command or explicit Skill tool call, not auto-triggered.
In this repository48 other files it gives its agents.
- skills/dev-methodology/references/agents.mdAGENTS.md
- skills/skill-authoring/references/agents.mdAGENTS.md
- acceptance-protocolSkill
- agency-intakeSkill
- ai-visibility-methodologySkill
- banner-design-guideSkill
- benchmark-researchSkill
- brand-methodologySkill
- code-reviewingSkill
- code-writingSkill
- codex-bridgeSkill
- deploy-pipelineSkill
- design-assets-guideSkill
- design-system-methodologySkill
- design-task-decompositionSkill
- dev-methodologySkill
- docs-pipelineSkill
- documentation-writingSkill
- engagement-contractSkill
- engagement-protocolSkill
- feature-researchSkill
- human-voiceSkill
- infrastructure-setupSkill
- marketing-task-decompositionSkill
- post-deploy-qaSkill
- pre-deploy-qaSkill
- presentation-designSkill
- project-planningSkill
- prompt-engineeringSkill
- security-auditingSkill
- semantic-drift-methodologySkill
- seo-auditingSkill
- skill-authoringSkill
- skill-testingSkill
- system-optimization-protocolSkill
- task-decompositionSkill
- tech-spec-planningSkill
- testing-methodologySkill
- ui-styling-guideSkill
- ui-ux-methodologySkill
- user-spec-planningSkill
- validation-pipelineSkill
- yandex-analytics-methodologySkill
- yandex-direct-guideSkill
- yandex-metrika-guideSkill
- yandex-search-guideSkill
- yandex-webmaster-guideSkill
- yandex-wordstat-guideSkill
The file
We split this skill into the rules it gives an agent
5 rules. About 0 are common, 4 are distinctive, and 1 is very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈4
Distinctive · estimate
This author's own choices. Worth a look.
1
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 19
Read the target skill's SKILL.md + ALL referenced files completely
- Distinctive: line 78
Persona: Keep the default persona from scenario-format.md as-is.
- Distinctive: line 86
Checkpoint: All scenarios have: task prompt, acceptance criteria, model choice.
- Distinctive: line 98
If the scenario needs supporting files (task files, mock data), create them in the same scenarios/ directory
- Distinctive: line 102
Checkpoint: All scenario files saved. Paths confirmed to user.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Skill Test Designer
Design test scenarios for skills. Interview the user to understand what to test, then create detailed scenario files for skill-testing to execute.
Phase 1: Understand the Skill
- User provides skill name or path
- Read the target skill's SKILL.md + ALL referenced files completely
- Map out:
- Skill type: procedural / informational / dialogue / one-shot
- Input: what does the skill expect? (user message, task file, structured data)
- Output: what should the skill produce? (files, messages, actions, decisions)
- Phases: list all phases/steps with their checkpoints
- References: list all files the skill tells agents to read
- Decision points: where does the skill branch based on input?
- Dialogue points: where does the skill ask the user questions?
- Present this map to the user: "Here's what I found in the skill: [summary]. What do you want to focus on?"
Checkpoint: Skill map presented to user. User confirmed focus area.
Phase 2: Interview the User
Discuss with the user to define the test scope:
- Scope: "Do you want to test the whole skill or specific parts?"
- Whole skill → test full workflow end-to-end
- Specific parts → focus scenarios on those areas
- Scenarios: Propose 1 happy-path + 2-3 edge cases based on skill analysis.
For each, explain WHY this scenario tests an important aspect.
- Happy path: the most common, standard use case
- Edge cases: where the skill might break or behave unexpectedly
Examples of edge cases:
- Ambiguous user input ("ну сделай что-нибудь")
- Missing context (no project-knowledge files available)
- Contradictory requirements mid-dialogue
- Unusually large or unusually small scope
- Input that triggers rarely-used branches in the skill Let the user adjust: add, remove, modify scenarios.
- Task prompts: For each scenario, draft the exact message the runner will
receive. Show to user. These must be natural — exactly what the user would
type in a real session.
- For coding skills: may need a task file (create it, show to user)
- For dialogue skills: just the opening message
- For one-shot skills: the full request
- Acceptance criteria: For each scenario, propose specific checks.
The number depends on skill complexity — simple skills may have 5,
complex procedural skills can have 15+. Show to user. Categories:
- [Process]: Did the agent follow the skill's workflow? Examples: "Asked about X before starting", "Loaded reference Y"
- [Outcome]: Is the result correct and complete? Examples: "File contains field Z", "Tests pass"
- [Compliance]: Did the agent obey all skill instructions? Examples: "Followed all phases in order", "Did self-review" Each criterion must be:
- Binary (pass/fail, no "partially")
- Observable (from agent's messages and created files)
- Specific (no "did a good job", no "output is correct")
- Skill-focused (testing skill behavior, not general agent quality)
- Model: "Which model should the runners use? Opus for complex tasks (coding, architecture), Sonnet for simpler ones (documentation, notes)."
- Persona: Keep the default persona from
scenario-format.md as-is. Modify only
when the user explicitly requests changes. For edge-case scenarios, add
modifications to the default persona:
- Brief/vague responses
- Contradictory requirements
- Changing mind mid-conversation
Checkpoint: All scenarios have: task prompt, acceptance criteria, model choice. User approved final set.
Phase 3: Save Scenarios
- Create directory:
~/.claude/skill-tests/{skill-name}/scenarios/ - Save each scenario as a separate .md file:
- happy-path.md
- edge-case-1.md, edge-case-2.md, etc.
- Format each scenario file using the template from scenario-format.md (structure, persona block, grading notes)
- If the scenario needs supporting files (task files, mock data), create them in the same scenarios/ directory
- Confirm to user: "Scenarios saved at [path]. Run skill-testing to execute."
Checkpoint: All scenario files saved. Paths confirmed to user.
Final Check
Before finishing, verify:
- Target skill fully read (SKILL.md + all references)
- Each scenario has task prompt, persona, acceptance criteria, grading notes
- Acceptance criteria are binary, observable, specific, skill-focused
- All scenario files saved to
~/.claude/skill-tests/{skill-name}/scenarios/ - User confirmed all scenarios
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

