atmos-specs-test-planlisted

Author the scenario-level test plan for an Atmos spec at `specs/<ZONE>/<ZONE>-NNN_.../TEST.md`. Use whenever the user wants to define WHAT to verify for a feature — Given/When/Then scenarios, acceptance criteria, regression checklist, performance budgets, Playwright/E2E coverage, agent-browser exploratory checks, or manual steps. Trigger on "test plan", "测试方案", "acceptance criteria", "验收标准", "how do we verify", "QA checklist", or after PRD/TECH has stabilized and you need to pin down what "done" looks like. This skill only writes the plan document; actually writing and running test code lives in the `atmos-specs-test-run` skill. Cover happy path, edge cases, and failure recovery at the scenario level — not individual unit tests. Only touch `TEST.md`.
AruNi-01/atmos · ★ 3 · Testing & QA · score 70

Install: claude install-skill AruNi-01/atmos

# Atmos Specs · Test Plan Define observable, executable proof that a feature is done. The audience is the engineer who will later implement the tests (via `atmos-specs-test-run`) and the reviewer checking the feature before merge. ## What this skill owns — and what it does not - **Owns**: `TEST.md` in one spec directory — the scenario-level plan. - **Does not own**: actual test code (Rust `#[cfg(test)]`, `bun test` specs, Playwright specs). That belongs to `atmos-specs-test-run`. - **Does not own**: running `just test` / `cargo test` / `bun test`, Playwright, or agent-browser. Also `atmos-specs-test-run` or a manual/browser verification pass. - **Does not own**: BRAINSTORM, PRD, TECH. Why: TEST.md is a scenario-level contract, not a test harness. A stable plan lets implementation churn (new helpers, refactored imports, renamed symbols) without invalidating the "what we promise to verify" section. Keeping authoring and execution in separate skills prevents the planner from prematurely committing to brittle assertions tied to today's internals. ## Read these before you write 1. `specs/AGENTS.md`. 2. The spec's `PRD.md` — every Must Have must have at least one scenario that would fail if it regressed. 3. The spec's `TECH.md` — gives you the failure surfaces (new WS messages, new tables, new endpoints, new frontend components). 4. If the plan includes web E2E, read `e2e/README.md` and `e2e/AGENTS.md` for the committed Playwright harness, commands, file placement, and fixtur