Design First — The Design Gate

Overview

Projects fail at execution when design questions surface mid-implementation. This skill forces the design conversation BEFORE the specialist writes code — and gives the approved design authority to revise decisions made at scaffold time, when knowledge was thinnest.

Core principle: the scaffold is an informed draft; the first operational design is where the rules truly settle.

When the gate triggers (called by Cortex Step 3b)

The Design Dialogue

1. Context read: CLAUDE.md (including Working Agreements), docs/phases/PHASE-{N}-execution.md, the design spec, relevant wiki pages. Never ask what these already answer.
2. Questions — ONE at a time, max 5. Prefer multiple choice. Mode-aware: Normal asks all; Autopilot only the critical ones (irreversible choices, cost, genuinely missing requirements); Autonomous skips to step 3 and tags assumptions [HYPOTHESIS].
3. 2-3 approaches with trade-offs and an explicit recommendation, recommended option first.
4. Sectioned design: architecture of the change, data flow, error handling, verification plan. Ask after each section whether it looks right.
5. Approval → write docs/design/TASK-{id}-design.md (compact, ≤80 lines) → execution proceeds with the design as the specialist's primary context.

Rule-Revision Authority (the key power)

The approved design MAY amend scaffold-era artifacts — with full traceability:

Never rewrite history: revisions add, supersede, and cite — they never erase.

Outputs

• docs/design/TASK-{id}-design.md — the approved design; specialist, QA, and phase verification all check against it
• Updated artifacts per the table above
• Log entry in logs/pipeline/: gate trigger, questions asked, approach chosen, revisions made

Anti-Patterns