atmos-specs-test-runlisted

Implement and execute the real tests for an Atmos spec — turn the scenarios in `specs/<ZONE>/<ZONE>-NNN_.../TEST.md` into actual Rust `#[cfg(test)]` modules, `bun test` specs, and (where warranted) Playwright/E2E tests, then run them and report. Use whenever the user says "write the tests", "实现测试", "跑测试", "run the tests for APP-NNN", "make TEST.md actually executable", or asks to verify that an implemented spec still works. Respect the project's test stack (`just test` = `bun test` + `cargo test --workspace`; per-crate/app filters via `cargo test --package <c>` and `bun run --filter <pkg> test`). Writes code in `tests/` or `#[cfg(test)]` mods and in `apps/**/*.test.ts[x]`; may append short status lines to `TEST.md` per scenario. Does not write production code — that's the `atmos-specs-impl` skill.
AruNi-01/atmos · ★ 2 · Testing & QA · score 69

Install: claude install-skill AruNi-01/atmos

# Atmos Specs · Test Run This skill is the execution side of the TEST lifecycle. The `atmos-specs-test-plan` skill writes scenarios in `TEST.md`; this skill turns those scenarios into real executable tests and runs them against the implementation. ## What this skill owns — and what it does not - **Owns**: test code — Rust `#[cfg(test)]` modules, integration tests under `crates/**/tests/`, Bun test specs under `apps/**/*.test.ts[x]` or `packages/**/*.test.ts[x]`, Playwright specs if they exist. - **Owns**: running the relevant test commands (`cargo test`, `bun test`, `just test`, etc.) and triaging failures. - **May touch `TEST.md`** — only to append a short status line per scenario, e.g. `S1 — ✅ covered by crates/core-engine/tests/github.rs::lists_open_prs`. Never rewrite plan sections here; that's the plan skill's job. - **Does not own** production code changes in `crates/` / `apps/` / `packages/`. If the scenario fails because production code is missing or broken, stop and hand off to `atmos-specs-impl`. - **Does not own** BRAINSTORM / PRD / TECH. Why: separating planning from execution lets TEST.md stay stable while the suite evolves with the code. Separating test-writing from production-code-writing forces an honest check — the tester cannot silently "fix" a failure by relaxing the production contract. ## Read these before you write tests 1. `specs/AGENTS.md` — conventions. 2. The spec's own `TEST.md` — your source of truth. Every Must Have has scenarios here; your