design-ruleslisted

# Design Rules ## Purpose Guidelines for the /designer command to produce high-quality design specs that reduce plan-review iterations. ## Instructions ### Step 1: Load at /designer startup Read this SKILL.md for overview. Supporting files loaded on-demand per phase. ### Step 2: Use phase-driven loading - Phase 3 (PROPOSE) → read [Spec Quality](spec-quality.md) for approach evaluation criteria - Phase 4 (WRITE SPEC) → read [Design Checklist](design-checklist.md) for self-verification - Phase 5 (USER GATE) → verify checklist before presenting to user ## Spec Quality Criteria | Criterion | Required | Check | |-----------|----------|-------| | Context describes current state | Yes | Not just "add X" but "currently Y exists, need X because Z" | | Scope has IN and OUT | Yes | OUT items have explicit reasons | | At least 2 approaches compared | Yes | With pros/cons for each | | Selected approach has rationale | Yes | References constraints from requirements | | Key decisions are numbered | Yes | Each has rationale and impact | | Risks have severity and mitigation | Yes | HIGH risks must have concrete mitigation | | Acceptance criteria are verifiable | Yes | Each can be checked as pass/fail | ## Anti-Patterns | Anti-Pattern | Why Bad | Fix | |---|---|---| | "The obvious approach is..." | Skips exploration, may miss better options | Always compare at least 2 | | Spec without OUT scope | Scope creep during planning | Explicitly list what's excluded | | Vague acceptance criteri