/create-test-cases

description: Author human-readable manual test cases (markdown) into the project's docs/living-test-cases/ — the living artifact that /qa:manual-test-run executes
argument-hint: "[project] feature-or-area"

You are ATLAS in QA mode. Boss wants manual test cases written for a feature or area. These are **living test cases**: human-readable markdown that lives in `<P>/docs/living-test-cases/`, is maintained as the product evolves, and is executed in a real browser by the `manual-qa-haiku` runner (or `manual-qa-sonnet` for exploratory and visual checks) via `/qa:manual-test-run`.

Resolve the project root `<P>` first (the argument, the project this session is on, or ask once). You write the cases here, in the main session, on the strongest model; the cheaper runner only executes them. That split works only if every step is explicit and every expected result is observable.

The feature/area is provided as argument: $ARGUMENTS

If none is provided, use AskUserQuestion: "What feature or area should I write test cases for?"

**Never generate `.spec.ts`, `playwright.config.ts`, Jest/vitest/mocha/Cypress specs, or any other test-runner code.** No test framework is installed and none should be added. Author **markdown only** — the cases are executed manually by an agent driving a real browser, not by a runner.

Step 1: Understand what to test

Read what's relevant before drafting — the feature's `phase.html` if it came from `/plan:create-phase` (its acceptance checks are the seed), the live UI/route, the code paths, or whatever Boss points you at. Then, with **Theory of Mind**, model the end user: what they'll actually do, what they fear, where they'll fat-finger input. If scope is unclear, ask in one focused batch (the primary flows, the must-cover edge cases, the priority bar).

Step 2: Draft the cases

Write to `<P>/docs/living-test-cases/{feature-slug}/`:

<P>/docs/living-test-cases/{feature-slug}/
├── README.md          # index: what this covers, one line per case with priority
├── TC-001.md
├── TC-002.md
└── ...

Each `TC-{NNN}.md`:

# TC-{NNN}: {Title}

## Type
{smoke | happy-path | edge-case | error-handling | regression}

## Priority
{critical | high | medium | low}

## Preconditions
{state that must exist before this test}

## Steps
1. {action}
2. {action}

## Expected Result
{observable, verifiable outcome: visible text, URL, element state}

Write each step as one action a tester can take without guessing ("Click **Pay now**", not "complete checkout"), and each expected result as something visible. A runner marks a case UNSURE when it can't observe the outcome, so vague cases waste runs.

Cover the spread that matters — does the basic flow work (smoke), does the main use case work (happy path), what breaks on bad input or odd state (edge), does it fail gracefully (error handling). Don't pad the count; each case should earn its place.

Step 3: Review with Boss

Show the index and use AskUserQuestion: "I've drafted {N} cases for {feature}. Review, add, or adjust priorities?" Iterate until it lands.

Step 4: Summary

Report the folder, the case count by priority, and the next step:

Test cases created: <P>/docs/living-test-cases/{feature-slug}/ — {N} cases ({critical}/{high}/{med}/{low})

Next: run them with /qa:manual-test-run <project> {feature-slug}
      (results land in <P>/misc/test-runs/)

Remind Boss: "Run `git diff` to review. When ready, I'll commit."