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, Linear tickets, knowledge notes, playbooks, and architecture notes so the design fits the system as it exists.
• Use Devin's codebase search, MCP integrations, and session context to understand the current state before proposing changes.
• 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 docs short: prefer 1-3 pages unless the architecture genuinely needs more. Compress context aggressively -- every word competes for attention.