Expand edge cases with ak:scenario

Use ak:scenario to turn a feature description or code path into concrete edge cases, failure paths, and test targets. Run one pass for a fast review, a fixed iteration count for a hard ceiling, or saturation mode to continue until two consecutive iterations add no new scenarios.

Choose ak:scenario for pre-implementation coverage

Use ak:scenario when

• A complex or stateful feature needs edge cases before implementation.
• You are planning regression tests, reviewing an API contract, or preparing a release risk audit.
• Timing, scale, authorization, data integrity, integrations, or partial failure could change expected behavior.
• You want each scenario classified and linked to an expected outcome.

Choose another workflow when

• The change is trivial, cosmetic, or has no meaningful logic branch.
• The target is mature and already has current evidence for the same risks.
• You need to execute tests rather than generate targets. Use ak:test.
• You need a five-perspective verdict on a proposed design. Use ak:predict.
• You need implementation. Feed approved scenarios into ak:plan or ak:cook.

Prepare the target and bound

Before you start:

• Complete Onboarding, and confirm Engineer Kit is installed for the current runtime and scope.
• Provide a feature description or narrow file path and the behavior it should preserve.
• Name actors, state, data, integrations, constraints, and known failure modes.
• Choose one-shot, --iterations N, or --saturation deliberately.
• Prefer --iterations N when you require a hard count ceiling. Saturation mode has a novelty stop but no separate numeric maximum in the shipped contract.
• Exclude secrets and unrelated files from the evidence scope.

Run a bounded exploration

/ak:scenario "Account recovery with expiring email links, active sessions, and organization SSO" --iterations 25 --domain security --focus failures --format test-scenarios

/ak:scenario "Account recovery with expiring email links, active sessions, and organization SSO" --iterations 25 --domain security --focus failures --format test-scenarios

$ak:scenario "Account recovery with expiring email links, active sessions, and organization SSO" --iterations 25 --domain security --focus failures --format test-scenarios

Use one-shot mode by omitting both --iterations and --saturation:

/ak:scenario src/api/account-recovery.ts

For Codex, use $ak:scenario src/api/account-recovery.ts.

Choose the exploration controls

Do not combine a claim of exhaustive coverage with either mode. A fixed count is a budget, and saturation is a novelty heuristic—not proof that all behavior has been discovered.

Understand the twelve dimensions

The Skill first filters for relevance rather than filling every category mechanically:

Irrelevant dimensions should be listed with both a reason and the assumption behind the skip, not silently counted as covered. If that assumption could stop being true during the feature's life, treat its failure as a scenario instead of skipping the dimension.

Observe the scenario loop

1. The Skill reads the target. It identifies actors, components, preconditions, state, and expected behavior.
2. The Skill filters dimensions. Relevant dimensions become the exploration plan; skipped dimensions remain visible with their assumptions. A breakable skip assumption becomes a failure scenario.
3. The Skill proposes one situation per iteration. A trigger, flow, and expected outcome make the scenario testable.
4. The Skill classifies novelty. New and useful Variant scenarios stay; Duplicate, out-of-scope, and low-value cases are discarded with reasons.
5. The Skill expands kept cases. Boundaries, interruptions, ordering, and stale or missing data expose derived edge cases.
6. The Skill rotates exploration. After three same-dimension iterations, it moves through dimensions, combinations, negation, amplification, personas, and temporal shifts.
7. The Skill checkpoints progress. Every five iterations it summarizes kept and discarded cases, dimensions, severity, and gaps.
8. The Skill stops and synthesizes. The selected count or novelty condition ends the run, followed by a grouped report and coverage matrix.

Keep the analysis within its authority

The workflow reads authorized evidence and may write scenario-results.tsv in iterative mode. It should not change product code, create test files, contact external systems, or execute attack payloads as part of scenario generation.

Keep sensitive source and customer data out of the prompt and report. If a scenario implies a destructive test, credential use, production traffic, or an external cost, record it as a gated follow-up rather than running it.

Verify the scenario evidence

A complete report should contain:

• Target, assumptions, evidence scope, and selected mode.
• Dimensions analyzed and dimensions skipped with reasons and assumptions.
• Scenarios with trigger, flow, expected behavior, severity, and dimension.
• In iterative mode, scenario-results.tsv with novelty classification and discard reasons.
• Progress checkpoints for longer runs.
• A coverage matrix and explicit gaps.
• The halt reason: one-shot, fixed count, or two no-new iterations.
• Follow-on test, plan, prediction, or security-review recommendations.

The bundled composite score weights generated scenarios, edge cases, dimensions, actors, and severity. Treat it as an internal prioritization heuristic, not a coverage percentage or release threshold.

Troubleshoot or continue

Pass testable rows to ak:test, Critical and High risks to ak:plan, or the most consequential proposal to ak:predict.

Know the current limits

• Scenario generation does not prove runtime behavior or complete coverage.
• Novelty classification and severity include model judgment and can be wrong.
• --saturation has a two-iteration novelty stop but no source-defined maximum iteration count; use --iterations N for a strict resource ceiling.
• Composite score is heuristic and must not be presented as test coverage.
• Runtime access controls what files and context the Skill can inspect.