Design Doc

Write a lightweight architecture design doc for a decision that deserves thinking before code. Use this when the problem has real ambiguity, tradeoffs, cross-cutting concerns, or future maintenance risk. If the solution is obvious and the doc would only become an implementation manual, say so and recommend spec or implement instead.

Workflow

1. Ground

• Treat the full argument as the design brief unless the user names a feature or path.
• Derive a kebab-case slug if no name is given.
• Read referenced docs, code, specs, plans, and architecture notes so the design fits the system as it exists.
• Identify stakeholders, goals, non-goals, constraints, cross-cutting concerns, and decisions that need human review.
• Ask only when a missing fact would materially change the design. Ask one question at a time with your recommended answer.

2. Write

Write docs/<design-slug>/design.md using the sections below. Keep solo-developer docs short: prefer 1-3 pages unless the architecture genuinely needs more.