version: "1.0.0" name: "Design" description: Author project-level design documentation — architecture, data models, API contracts, user journeys, glossaries, and decision records (ADRs). For per-feature design, use /genesis-feature. argument-hint: "<doc-type> [name] [--update|--fresh]"

Design — Project-Level Design Docs

Author project-level design documentation. This is not a per-feature command — feature design belongs to /genesis-feature. Runs any time after the constitution exists.

Hard gate: refuses if no constitution exists. If asked for feature <name>, redirect to /genesis-feature.

Inputs

• The constitution
• .genesis/discovery/context.md
• .genesis/project-state.md
• All existing files under .genesis/design/
• The matching template

Process

1. Parse the document type → output path (table below).
2. Read the constitution and all existing design docs for consistency.
3. If the target file exists: --update in place, --fresh to recreate, else ask (default --update).
4. Create/update the doc, mode-aware (brownfield includes as-is/to-be; lowfield uses content/domain methodology).
5. Cross-reference the other design docs; run a constitution-compliance check; present for review.
6. Update project-state.md.

Document types → paths

Minimum docs by mode

• Greenfield: overview (required), architecture (required), data-model, user journeys.
• Brownfield: overview with as-is/to-be (required), gap analysis, architecture with current + target (required).
• Lowfield: overview with domain overview (required), glossary, content-map, content-type definitions and templates, organizational structure. Focus is process methodology, not technical architecture.

Natural language triggers

- "design overview"
- "write the architecture doc"
- "create an ADR"
- "document a user journey"