---
description: Interactive technical design quality review and validation
allowed-tools: Read, Glob, Grep
argument-hint: <feature-name>
---

# Technical Design Validation

<background_information>
- **Role**: Conduct an interactive, structured quality review of the technical design to determine whether it is ready for implementation at an acceptable level of risk.
- **Success Criteria**:
  - The three most significant concerns are identified and articulated with precision
  - Design strengths are acknowledged to maintain a balanced assessment
  - A clear GO or NO-GO decision is issued with rationale the team can act on
  - All feedback is constructive and immediately actionable
</background_information>

<instructions>
## Core Task
Perform an interactive design quality review for feature **$1** against its approved requirements and design document.

## Execution Steps

1. **Load Context**:
   - Read `{{SDD_DIR}}/specs/$1/spec.json` for language and metadata
   - Read `{{SDD_DIR}}/specs/$1/requirements.md` for the approved requirement set
   - Read `{{SDD_DIR}}/specs/$1/design.md` for the design document under review
   - Read the entire `{{SDD_DIR}}/steering/` directory (core + all custom files) for full project memory — design alignment is assessed against these conventions

2. **Load Review Guidelines**:
   - Read `{{SDD_DIR}}/settings/rules/design-review.md` for the review criteria, assessment process, and output format

3. **Execute the Review**:
   - Follow the `design-review.md` process: Analysis → Critical Issues → Strengths → GO/NO-GO
   - Enforce the three-issue maximum — only concerns that materially threaten implementation success qualify
   - Engage interactively with the user; this is a dialogue, not a one-way audit
   - Produce all output in the language specified in `spec.json`

4. **Deliver Decision and Guidance**:
   - Issue a clear GO or NO-GO with a one-to-two sentence rationale
   - Specify concrete next steps tailored to the decision outcome

## Important Constraints
- **Quality assurance, not perfectionism**: Accept reasonable risk — perfection is not the goal
- **Critical focus only**: Limit identified issues to the three most impactful concerns
- **Dialogue over monologue**: Invite the designer's perspective on each issue
- **Balanced view**: Recognize genuine strengths alongside weaknesses
- **Actionable feedback**: Every suggested improvement must be specific and implementable
</instructions>

## Tool Guidance
- **Read first**: Load all spec files, steering, and review rules before beginning
- **Grep if needed**: Validate pattern claims or check integration feasibility against the actual codebase
- **Stay interactive**: Pause for user input when a concern needs clarification rather than assuming

## Output Description

Report in the language specified in `spec.json`:

1. **Review Summary**: 2–3 sentences on overall design quality and readiness
2. **Critical Issues**: Up to 3, each following the format defined in `design-review.md`
3. **Design Strengths**: 1–2 aspects that demonstrate sound architectural thinking
4. **Final Assessment**: GO / NO-GO decision with rationale and concrete next steps

**Formatting Rules**:
- Apply Markdown headings for each section
- Follow the output format in `design-review.md` exactly
- Keep total review output concise (guideline: ~400 words)

## Safety & Fallback

### Error Scenarios
- **Design Document Missing**: Halt with — "No `design.md` found. Run `/sdd:spec-design $1` to generate the design document first"
- **Design Phase Not Recorded**: If `spec.json` does not reflect that design was generated, warn the user but proceed with the review
- **Empty Steering Directory**: Warn that project context is missing and alignment checks may be incomplete
- **Language Not Set**: Default to English (`en`) if `spec.json` omits a language value

### Next Phase: Task Generation

**When Design Passes Review (GO)**:
- Apply any recommended improvements if warranted
- Run `/sdd:spec-tasks $1` to generate implementation tasks
- Or run `/sdd:spec-tasks $1 -y` to auto-approve and proceed immediately

**When Design Needs Revision (NO-GO)**:
- Address each critical issue identified in the review
- Regenerate the design with `/sdd:spec-design $1`
- Rerun this validation with `/sdd:validate-design $1`

**Note**: Design validation is recommended but not mandatory. Running it before task generation helps catch expensive misalignments early.
