kiro-validate-design
GitHub用于在代码实现前对技术设计文档进行交互式质量审查,确保实施就绪。通过并行收集上下文、执行平衡评估并识别关键问题,最终给出明确的 GO/NO-GO 决策及可操作的改进建议。
触发场景
安装
npx skills add growilabs/growi --skill kiro-validate-design -g -y
SKILL.md
Frontmatter
{
"name": "kiro-validate-design",
"metadata": {
"shared-rules": "design-review.md"
},
"description": "Interactive technical design quality review and validation. Use when reviewing design before implementation.",
"allowed-tools": "Read, Grep, Glob, AskUserQuestion",
"argument-hint": "<feature-name>"
}
kiro-validate-design Skill
Role
You are a specialized skill for conducting interactive quality review of technical design to ensure readiness for implementation.
Core Mission
- Mission: Conduct interactive quality review of technical design to ensure readiness for implementation
- Success Criteria:
- Critical issues identified (maximum 3 most important concerns)
- Balanced assessment with strengths recognized
- Clear GO/NO-GO decision with rationale
- Actionable feedback for improvements if needed
Execution Steps
Step 1: Gather Context
If steering/spec context is already available from conversation, skip redundant file reads. Otherwise, load all necessary context:
- Read
.kiro/specs/{feature}/spec.jsonfor language and metadata - Read
.kiro/specs/{feature}/requirements.mdfor requirements - Read
.kiro/specs/{feature}/design.mdfor 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.mdfrom 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
After all parallel research completes, synthesize findings for review.
Step 2: Execute Design Review
- Reference conversation history: 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
Step 3: 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
- 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 {feature}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):
- Apply any suggested improvements if agreed
- Run
/kiro-spec-tasks {feature}to generate implementation tasks - Or
/kiro-spec-tasks {feature} -yto auto-approve and proceed directly
If Design Needs Revision (NO-GO Decision):
- Address critical issues identified in review
- Re-run
/kiro-spec-design {feature}with improvements - Re-validate with
/kiro-validate-design {feature}
Note: Design validation is recommended but optional. Quality review helps catch issues early.
版本历史
- 0dc62d2 当前 2026-08-20 19:46


