design

Topics in the source

• Design Workflow
• Steps
• Step 1: Define the technical solution
• Step 2: Define contracts
• Step 3: Split into tasks
• Step 4: Anticipate risks
• Step 5: Produce design output
• Step 6: Publish the annotatable plan

CANARY: design-loaded-2026-05-19-e08675ccb0a5c932 Owns sections 5–6 of status/specification.md (contracts, risks) and creates status/plan.md (task split). Reads sections 1–4 of status/specification.md to understand what the spec already covers. Before Step 1 — the spec must be approved. The specify skill's validator answers it: validatespec.py --input status/specification.md --require-approved (in that skill's scripts/). Anything but exit 0 means stop and hand the spec back for approval, because a plan written before approval is built on a draft. Translate the chosen option into a concrete technical design. Architecture overview: how the change fits into the existing system Data flow: how data moves through affected services (request/response, events, jobs) State changes: what data is created, updated, or deleted and where Technology choices: any new libraries, tools, or patterns (justify each) What is NOT changing: explicit boundaries to prevent scope creep For every interaction between components: API contracts: request/response schemas, status codes, error formats Event contracts: message schemas, routing keys, retry policies Database changes: schema modifications, migration app

This is an excerpt. Refer to the complete source and its current requirements.