← ClaudeAtlas

swarm-implementlisted

Implementation phase — turn a validated design into dependency-ordered tickets, then work them as one of N parallel agents with atomic claims, model tiering, and tests-in-ticket definition of done. Use to plan tickets from a design, pick up/continue implementation work, coordinate parallel agents, or check what to build next.
AnmarHani/SwarmVault · ★ 5 · AI & Automation · score 72
Install: claude install-skill AnmarHani/SwarmVault
# swarm-implement — implementation phase Two roles. Check flow-state: no tickets yet → you're the **planner**; tickets exist → you're a **worker**. ## Planner (strong model, once per milestone batch) **Gate:** validated design. Read `docs/design.md` and the milestone's FR specs. 1. Emit tickets to `30 Plans/<P>/tickets/TK-NNN-<slug>.md` (template: `90 Templates/ticket.md`, machine lane): FR-ID trace, `requires:` edges (tracer-bullet order: thinnest end-to-end slice first), suggested `tier` (size) and `kind` (`design`/`planning`/`coding`/`review`/`docs` — lets orchestration route the right model), DoD checklist, and CONTEXT — the exact notes/design sections a worker needs (nothing more). **Also name the layers.** `requires:` orders tickets that exist; it cannot say whether the thing being ordered exists at all. Two tickets were once written as if a persistence layer were there — the engine belonged to one ticket, the tables to another, and the carrier between them to nobody, so both DoDs were unreachable as written and the gap was findable only by grepping for a repository and finding none. So every ticket carries: - `provides:` — the layers this ticket makes exist (`ledger repository`, `recurrence tables`) - `needs:` — the layers it builds on, in the same words Every `needs:` must match some ticket's `provides:`. `board` prints a **PLANNING GAPS** section and `doctor` fails the `ticket coverage` check when one does not, when a `requi