atmos-specs-techlisted

# Atmos Specs · TECH Translate a PRD into an engineering plan concrete enough that another engineer could implement it without a meeting. Output: one `TECH.md` file. ## What this skill owns — and what it does not - **Owns**: `TECH.md` in one spec directory. - **Does not own**: BRAINSTORM, PRD, TEST, and — importantly — actual code. If you find yourself wanting to edit `crates/` or `apps/`, stop and hand off to the `atmos-specs-impl` skill. Why: TECH is a design artifact. It should be reviewable without running the code. Editing code mid-design flow contaminates the spec with premature details. ## Read these before you write 1. `specs/AGENTS.md` — conventions. 2. The spec's own `PRD.md` — this is your contract. Every Must Have (M1, M2, …) should be addressed here. 3. The spec's `BRAINSTORM.md` for context on rejected options. 4. Root `AGENTS.md` — specifically the **Transport Rules** (WebSocket-first) and the **Backend Change Flow** (infra → core-engine → core-service → api). 5. Package-level `AGENTS.md` files for any crate/app you plan to touch: - `crates/infra/AGENTS.md` — DB, WebSocket, jobs. - `crates/core-engine/AGENTS.md` — PTY, Git, FS. - `crates/core-service/AGENTS.md` — business rules. - `crates/agent/AGENTS.md` — ACP integration. - `apps/api/AGENTS.md` — handlers and DTOs. - `apps/web/AGENTS.md` — Next.js app. - `packages/ui/AGENTS.md` — shared UI. 6. A comparable existing `TECH.md` for tone and depth: - API/WebSocket-style: `specs/APP/A