Technical Design Validation
Execution Steps
- Gather Context:
- Read
{{KIRO_DIR}}/specs/$1/spec.json for language and metadata
- Read
{{KIRO_DIR}}/specs/$1/requirements.md for requirements
- Read
{{KIRO_DIR}}/specs/$1/design.md for design document
- Core steering context:
product.md, tech.md, structure.md
- Additional steering files only when directly relevant to architecture boundaries, integrations, runtime prerequisites, domain rules, security/performance constraints, or team conventions that affect implementation readiness
- Relevant local agent skills or playbooks only when they clearly match the feature's host environment or use case and provide review-relevant context
Parallel Research
The following research areas are independent and can be executed in parallel:
- Context & rules loading: Spec documents, core steering, task-relevant extra steering, relevant local agent skills/playbooks, and
rules/design-review.md from this skill's directory for review criteria
- Codebase pattern survey: Gather existing architecture patterns, naming conventions, and component structure from the codebase to use as reference during review
If multi-agent is enabled, spawn sub-agents for each area above. Otherwise execute sequentially.
After all parallel research completes, synthesize findings for review.
Execute Design Review:
- Reference conversation history when available: leverage prior requirements discussion and user's stated design intent
- Follow design-review.md process: Analysis → Critical Issues → Strengths → GO/NO-GO
- Limit to 3 most important concerns
- Engage interactively with user — ask clarifying questions, propose alternatives
- Use language specified in spec.json for output
Decision and Next Steps:
- Clear GO/NO-GO decision with rationale
- Provide specific actionable next steps (see Next Phase below)
Important Constraints
- Quality assurance, not perfection seeking: Accept acceptable risk
- Critical focus only: Maximum 3 issues, only those significantly impacting success
- Conversation-aware: Leverage discussion history for requirements context and user intent when available
- Interactive approach: Engage in dialogue, ask clarifying questions, propose alternatives
- Balanced assessment: Recognize both strengths and weaknesses
- Actionable feedback: All suggestions must be implementable
- Context Discipline: Start with core steering and expand only with review-relevant steering or use-case-aligned local agent skills/playbooks
Tool Guidance
- Read first: Load spec, core steering, relevant local playbooks/agent skills, and rules before review
- Grep if needed: Search codebase for pattern validation or integration checks
- Interactive: Engage with user throughout the review process
Output Description
Provide output in the language specified in spec.json with:
- Review Summary: Brief overview (2-3 sentences) of design quality and readiness
- Critical Issues: Maximum 3, following design-review.md format
- Design Strengths: 1-2 positive aspects
- Final Assessment: GO/NO-GO decision with rationale and next steps
Format Requirements:
- Use Markdown headings for clarity
- Follow design-review.md output format
- Keep summary concise
Safety & Fallback
Error Scenarios
- Missing Design: If design.md doesn't exist, stop with message: "Run
$kiro-spec-design $1 first to generate design document"
- Design Not Generated: If design phase not marked as generated in spec.json, warn but proceed with review
- Empty Steering Directory: Warn user that project context is missing and may affect review quality
- Language Undefined: Default to English (
en) if spec.json doesn't specify language
Next Phase: Task Generation
If Design Passes Validation (GO Decision):
- Review feedback and apply changes if needed
- Run
$kiro-spec-tasks $1 to generate implementation tasks
- Or
$kiro-spec-tasks $1 -y to auto-approve and proceed directly
If Design Needs Revision (NO-GO Decision):
- Address critical issues identified
- Re-run
$kiro-spec-design $1 with improvements
- Re-validate with
$kiro-validate-design $1
Note: Design validation is recommended but optional. Quality review helps catch issues early.
1---2name: kiro-validate-design3description: Interactive technical design quality review and validation4---5
6
7# Technical Design Validation
8
9<background_information>
10- **Mission**: Conduct interactive quality review of technical design to ensure readiness for implementation
11- **Success Criteria**:
12 - Critical issues identified (maximum 3 most important concerns)
13 - Balanced assessment with strengths recognized
14 - Clear GO/NO-GO decision with rationale
15 - Actionable feedback for improvements if needed
16</background_information>
17
18<instructions>
19## Core Task
20Interactive design quality review for feature **$1** based on approved requirements and design document.
21
22## Execution Steps
23
241. **Gather Context**:
25 - Read `{{KIRO_DIR}}/specs/$1/spec.json` for language and metadata
26 - Read `{{KIRO_DIR}}/specs/$1/requirements.md` for requirements
27 - Read `{{KIRO_DIR}}/specs/$1/design.md` for design document
28 - Core steering context: `product.md`, `tech.md`, `structure.md`
29 - Additional steering files only when directly relevant to architecture boundaries, integrations, runtime prerequisites, domain rules, security/performance constraints, or team conventions that affect implementation readiness
30 - Relevant local agent skills or playbooks only when they clearly match the feature's host environment or use case and provide review-relevant context
31
32#### Parallel Research
33
34The following research areas are independent and can be executed in parallel:
351. **Context & rules loading**: Spec documents, core steering, task-relevant extra steering, relevant local agent skills/playbooks, and `rules/design-review.md` from this skill's directory for review criteria
362. **Codebase pattern survey**: Gather existing architecture patterns, naming conventions, and component structure from the codebase to use as reference during review
37
38If multi-agent is enabled, spawn sub-agents for each area above. Otherwise execute sequentially.
39
40After all parallel research completes, synthesize findings for review.
41
422. **Execute Design Review**:
43 - Reference conversation history when available: leverage prior requirements discussion and user's stated design intent
44 - Follow design-review.md process: Analysis → Critical Issues → Strengths → GO/NO-GO
45 - Limit to 3 most important concerns
46 - Engage interactively with user — ask clarifying questions, propose alternatives
47 - Use language specified in spec.json for output
48
493. **Decision and Next Steps**:
50 - Clear GO/NO-GO decision with rationale
51 - Provide specific actionable next steps (see Next Phase below)
52
53## Important Constraints
54- **Quality assurance, not perfection seeking**: Accept acceptable risk
55- **Critical focus only**: Maximum 3 issues, only those significantly impacting success
56- **Conversation-aware**: Leverage discussion history for requirements context and user intent when available
57- **Interactive approach**: Engage in dialogue, ask clarifying questions, propose alternatives
58- **Balanced assessment**: Recognize both strengths and weaknesses
59- **Actionable feedback**: All suggestions must be implementable
60- **Context Discipline**: Start with core steering and expand only with review-relevant steering or use-case-aligned local agent skills/playbooks
61</instructions>
62
63## Tool Guidance
64- **Read first**: Load spec, core steering, relevant local playbooks/agent skills, and rules before review
65- **Grep if needed**: Search codebase for pattern validation or integration checks
66- **Interactive**: Engage with user throughout the review process
67
68## Output Description
69Provide output in the language specified in spec.json with:
70
711. **Review Summary**: Brief overview (2-3 sentences) of design quality and readiness
722. **Critical Issues**: Maximum 3, following design-review.md format
733. **Design Strengths**: 1-2 positive aspects
744. **Final Assessment**: GO/NO-GO decision with rationale and next steps
75
76**Format Requirements**:
77- Use Markdown headings for clarity
78- Follow design-review.md output format
79- Keep summary concise
80
81## Safety & Fallback
82
83### Error Scenarios
84- **Missing Design**: If design.md doesn't exist, stop with message: "Run `$kiro-spec-design $1` first to generate design document"
85- **Design Not Generated**: If design phase not marked as generated in spec.json, warn but proceed with review
86- **Empty Steering Directory**: Warn user that project context is missing and may affect review quality
87- **Language Undefined**: Default to English (`en`) if spec.json doesn't specify language
88
89### Next Phase: Task Generation
90
91**If Design Passes Validation (GO Decision)**:
92- Review feedback and apply changes if needed
93- Run `$kiro-spec-tasks $1` to generate implementation tasks
94- Or `$kiro-spec-tasks $1 -y` to auto-approve and proceed directly
95
96**If Design Needs Revision (NO-GO Decision)**:
97- Address critical issues identified
98- Re-run `$kiro-spec-design $1` with improvements
99- Re-validate with `$kiro-validate-design $1`
100
101**Note**: Design validation is recommended but optional. Quality review helps catch issues early.