Converge goals, constraints, and key trade-offs that are not yet clear into a design sufficient to guide implementation. Follow the user's existing decisions and do not re-approve already-accepted approaches.
Scope and Completion Conditions
- When the user asks to discuss first, review the approach first, or not implement yet, treat design delivery as the endpoint; do not write implementation code or set up scaffolding without approval.
- When the user has already asked for implementation, only clarify open questions that would materially change scope, cost, or outcome; follow project conventions for ordinary, reversible choices and state assumptions, without inserting an additional full design approval.
- Once the design is clear and implementation is authorized, continue through implementation and corresponding verification, and do not hand back early when the first version of the code or plan is complete.
Converge the Design
First read the code and documentation related to the current design, and do not ask the user about facts you can look up. Only trace back through commits when a historical decision affects the current trade-off.
Focus on purpose, constraints, and success criteria, and prioritize asking the one question that most affects the design. When real alternatives exist, compare the trade-offs and give a recommendation; when the path is clear, do not offer multiple options just to pad the list.
Design depth scales with complexity: a simple tool can be a few sentences; a complex system explains the relevant boundaries, data flow, failure handling, and verification approach. When multiple subsystems require phases, explain the dependencies and build order, and do not unilaterally shrink the complete delivery the user asked for into the first sub-project.
When a persistent spec is needed, write it to docs/specs/YYYY-MM-DD-<主题>-design.md, preferring the location specified by the user. A short, one-off design can be given directly in the reply, without forcing the creation of a file. Only create a Git commit when the user explicitly requests it.
Before delivery, eliminate gaps, contradictions, and ambiguities that would affect implementation. For complex specs, use spec-document-reviewer-prompt.md for review; only delegate an independent review when it is authorized and the current environment supports it.
Keep the constraints and trade-offs that explain the design, and avoid unrequested features, abstractions, or opportunistic refactoring.
Visual Companion
Propose using the browser companion only when layout, wireframes, or spatial relationships are better suited to visual discussion. After the user agrees, read visual-companion.md and start it; if they decline, continue with plain text. The topic involving UI itself does not constitute a reason to start it.