atmos-specs-impllisted

Implement an Atmos spec — turn the four spec docs (BRAINSTORM / PRD / TECH / TEST) at `specs/<ZONE>/<ZONE>-NNN_.../` into real production code changes in `crates/`, `apps/`, `packages/`. Use whenever the user says "implement APP-NNN", "ship this spec", "按照 spec 实现", "start coding the PRD", or otherwise transitions from spec authoring to actual engineering. Read all four files first, plan along TECH's rollout, respect Atmos's layered architecture (infra → core-engine → core-service → api → apps) and WebSocket-first transport. Keep existing tests green (regression gate) and run lint+compile on every chunk; delegate authoring new scenario-level tests to the `atmos-specs-test-run` skill. Writes production code (not specs, not new scenario tests); updates specs only when reality forces TECH to change.
AruNi-01/atmos · ★ 3 · Code & Development · score 70

Install: claude install-skill AruNi-01/atmos

# Atmos Specs · Implementation This skill is the bridge from specs to shipped production code. You execute what TECH.md designed, you keep the regression gate green, and you do it in the layer order Atmos expects. Comprehensive test authoring for the spec (turning TEST.md scenarios into runnable tests) belongs to the sibling skill `atmos-specs-test-run`, which should run immediately after implementation for complete spec work unless the user explicitly asks to stop after production code. ## What this skill owns — and what it does not - **Owns**: real production code in `crates/`, `apps/`, `packages/`, plus schema/migration/feature-flag files TECH.md names. - **Owns**: compile + lint + existing-test regression gate on every chunk (`cargo check`, `cargo clippy`, `bun run typecheck`, `just lint`, targeted `cargo test` / `bun test` for pre-existing suites near the change). - **May touch `TECH.md`**: only when implementation reveals a decision in TECH that is wrong or ambiguous. When that happens, update TECH alongside the code and call it out. - **Does not own** authoring the scenario-level test suite described in TEST.md. Hand that off to `atmos-specs-test-run` after production code. In-line "smoke" tests that are *the cheapest way to prove the code you just wrote compiles and runs* are fine (and encouraged), but the systematic TEST.md coverage pass is not this skill's job. - **Does not touch `PRD.md` / `BRAINSTORM.md`** — if PRD is wrong, stop and tell the user. Why: separa