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 · ★ 2 · Code & Development · score 69

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`. ## 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`. 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: separating production code from scenario-test authoring forces honesty. When the same skill writes both, it's tempting to weaken assertions to make green; having `a