michi-scenario-test-builder

The scenario test builder generates rich, story-driven test scenarios and structured test plans. It is based on Cem Kaner’s scenario testing methodology (2003), adapted for AI-assisted and autonomous development workflows. This skill produces test plans and scenarios as markdown documents — it does not write test code.

When to use

• Discovering what to test before writing any test code
• Building structured test plans with prioritized scenarios and coverage notes
• Defining verification scenarios for autonomous agent work (Michi sessions)
• Exploring how a system could fail through creative, adversarial thinking
• Surfacing requirements gaps — finding disagreements, edge cases, and unstated assumptions
• When someone asks “what should I test?” or “how do I validate this works end-to-end?”

What it does

Understand the system. Before generating scenarios, the agent gathers context — what the system does, who uses it, key benefits, riskiest areas, known problems, external interactions, and existing test coverage. If given a codebase, it reads key files to build understanding before generating anything.

Generate scenarios using Kaner’s techniques. The agent applies relevant techniques from Kaner’s twelve scenario generation methods (life histories, disfavored users, tours through a system, interoperability, and others). Each generated scenario is a story — a person doing something for a reason, with context about why it matters. Every scenario is evaluated against five quality criteria: it must be motivating, credible, complex (involving multiple features or data flows), and easy to evaluate despite that complexity.

Build the test plan. Scenarios are organized by priority (likelihood times impact) into a structured plan with coverage notes and identified gaps. The plan shows what’s well-covered and where other testing approaches are needed.

Generate acceptance criteria (optional). Selected scenarios can be converted into structured acceptance criteria with must-pass, should-pass, and edge-case tiers — suitable for agent consumption in Michi sessions.

For autonomous agent verification, the skill emphasizes easy-to-evaluate criteria (pass/fail must be unambiguous and automatable), considers the agent as a “disfavored user” who might take shortcuts, and separates scenarios by verification level (A: autonomous, B: judgment needed, C: human evaluates).

What it produces

• Scenario catalog — narrative test scenarios with motivation, credibility assessment, complexity notes, verification level, Given-When-Then steps, and priority. In Michi projects, these live in verification/scenarios.md.
• Test plan — prioritized, structured document referencing scenarios with coverage notes and risk assessment. Informs verification/test-plan.md.
• Acceptance criteria (optional) — per-feature criteria in must-pass/should-pass/edge-case tiers, suitable for plan docs.

Key things to know

• This skill produces documents, not test code. Use TDD or test-generation skills for implementation.
• A good scenario is a story, not a checklist. “A user syncs their chats and finds them searchable” rather than “POST /api/chat returns 200.”
• Scenario testing complements other approaches — it does not replace unit testing, domain testing, or stress testing. Kaner himself emphasized that scenario testing is one approach among many.
• The skill includes specific adaptations for Michi workflows, including designing scenarios that catch agent shortcuts like writing return true to pass tests.

For the full agent instructions, see the SKILL.md source.