studiogadgetstudiogadget/skills/kiro-validate-design/SKILL.md

kiro-validate-design

Skill3 starsChanged 6 months agoApache-2.0View on GitHub

Interactive technical design quality review and validation

3 other projects use a version of this, 3 of them edited.

Adopted by

Most recently taken up by

aiproxer/aiproxeredited, first seen Nov 8, 2026
growilabs/growiedited, first seen Oct 8, 2026
kyuki3rain/cc-sdd-adredited, first seen Jul 27, 2026

Other versions3 projects use a version of this.
Word for word · 0
None found.
Edited · 3
growilabs/growi★ 1.5k77% same
aiproxer/aiproxer★ 2297% same
kyuki3rain/cc-sdd-adr★ 077% same
Wrote their own version · 0
None found.
How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.
In this repository34 other files it gives its agents.
- cc-sdd-restack-after-mergeSkill
- cc-sdd-review-slice-stackSkill
- ci-stable-log-testingSkill
- create-issueSkill
- docker-deployment-guideSkill
- hibernate-pcSkill
- kiro-debugSkill
- kiro-discoverySkill
- kiro-implSkill
- kiro-reviewSkill
- kiro-spec-batchSkill
- kiro-spec-designSkill
- kiro-spec-initSkill
- kiro-spec-quickSkill
- kiro-spec-requirementsSkill
- kiro-spec-statusSkill
- kiro-spec-tasksSkill
- kiro-steering-customSkill
- kiro-steeringSkill
- kiro-validate-gapSkill
- kiro-validate-implSkill
- kiro-verify-completionSkill
- notion-pdfSkill
- playwright-scraperSkill
- pptx-slides-creatorSkill
- pr-creatorSkill
- pytest-marksSkill
- python-readable-codeSkill
- resolve-pr-review-threadsSkill
- sec-diff-reviewSkill
- sec-full-scanSkill
- sec-runtime-scanSkill
- skill-creatorSkill
- storage-stateSkill

The file

Show its rules and text

We split this skill into the rules it gives an agent

16 rules. 6 are common, 1 is distinctive, and 9 are very specific to this project.

6
Common
Most of the 3 edited versions we read keep these.
1
Distinctive
This author's own choices. Worth a look.
9
Very specific
Tied to their project's names, files or tools. Probably skip.

Common
Distinctive
Very specific

Very specific:
Read docs/specs/$1/spec.json for language and metadata
line 27
Very specific:
Read docs/specs/$1/requirements.md for requirements
line 28
Very specific:
Read docs/specs/$1/design.md for design document
line 29
Distinctive:
If multi-agent is enabled, spawn sub-agents for each area above.
line 40
Common:
After all parallel research completes, synthesize findings for review.
line 42
Common:
Follow design-review.md process: Analysis → Critical Issues → Strengths → GO/NO-GO
line 46
Very specific:
Use language specified in spec.json for output
line 49
Common:
Actionable feedback: All suggestions must be implementable
line 61
Very specific:
Context Discipline: Start with core steering and expand only with review-relevant steering or use-case-aligned local agent skills/playbooks …
line 62
Common:
Grep if needed: Search codebase for pattern validation or integration checks
line 67
Common:
Use Markdown headings for clarity
line 79
Common:
Follow design-review.md output format
line 80
Very specific:
Missing Design: If design.md doesn't exist, stop with message: "Run /kiro-spec-design $1 first to generate design document"
line 86
Very specific:
Design Not Generated: If design phase not marked as generated in spec.json, warn but proceed with review
line 87
Very specific:
Language Undefined: Default to English (en) if spec.json doesn't specify language
line 89
Very specific:
Run /kiro-spec-tasks $1 to generate implementation tasks
line 95

“Common” is measured: kept by at least 6 in 10 of the 3 edited versions of this file we could read. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.

Files

SKILL.md

Technical Design Validation

<background_information>

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 </background_information>

<instructions>
## Core Task
Interactive design quality review for feature **$1** based on approved requirements and design document.

Execution Steps

Gather Context:
- Read docs/specs/$1/spec.json for language and metadata
- Read docs/specs/$1/requirements.md for requirements
- Read docs/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</instructions>

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.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

It worked
Partly
It didn't

What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free