buildpad-validate-design
Skill1 starsChanged 27 days agoMITView on GitHub
Interactive technical design quality review and validation. Use when reviewing design before implementation.
In this repository66 other files it gives its agents.
- add-ai-chatSkill
- add-buildpadSkill
- add-commentsSkill
- add-cronSkill
- add-external-oauthSkill
- add-filesSkill
- add-i18nSkill
- add-mcp-serverSkill
- add-microappSkill
- add-microfrontendSkill
- add-microfrontend-zonesSkill
- add-mobile-appSkill
- add-multitenancySkill
- add-usersSkill
- add-workflowsSkill
- amplify-env-varsSkill
- authentication-proxySkill
- buildpad-debugSkill
- buildpad-discoverySkill
- buildpad-implSkill
- buildpad-referenceSkill
- buildpad-reviewSkill
- buildpad-spec-batchSkill
- buildpad-spec-designSkill
- buildpad-spec-initSkill
- buildpad-spec-quickSkill
- buildpad-spec-requirementsSkill
- buildpad-spec-statusSkill
- buildpad-spec-tasksSkill
- buildpad-steering-customSkill
- buildpad-steeringSkill
- buildpad-validate-gapSkill
- buildpad-validate-implSkill
- buildpad-verify-completionSkill
- code-simplificationSkill
- context-engineeringSkill
- create-api-routeSkill
- create-collectionSkill
- create-componentSkill
- create-cronSkill
- create-featureSkill
- create-form-builderSkill
- create-migrationSkill
- create-projectSkill
- create-rbacSkill
- create-serviceSkill
- create-testsSkill
- create-workflowSkill
- daas-platformSkill
- debugging-and-error-recoverySkill
- generate-docsSkill
- git-workflow-and-versioningSkill
- grant-module-accessSkill
- hooks-extensionsSkill
- idea-refineSkill
- incremental-implementationSkill
- manage-scopeSkill
- migrate-to-engineSkill
- performance-optimizationSkill
- planning-and-task-breakdownSkill
- The first 60 shown.
The file
Show its rules and text
We split this skill into the rules it gives an agent
16 rules. About 0 are common, 7 are distinctive, and 9 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈7
Distinctive · estimate
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
- Distinctive: line 27
If steering/spec context is already available from conversation, skip redundant file reads.
- Very specific: line 29
Read .kiro/specs/{feature}/spec.json for language and metadata
- Very specific: line 30
Read .kiro/specs/{feature}/requirements.md for requirements
- Very specific: line 31
Read .kiro/specs/{feature}/design.md for design document
- Distinctive: line 42
After all parallel research completes, synthesize findings for review.
- Distinctive: line 46
Follow design-review.md process: Analysis → Critical Issues → Strengths → GO/NO-GO
- Very specific: line 49
Use language specified in spec.json for output
- Distinctive: line 61
Actionable feedback: All suggestions must be implementable
- Very specific: line 62
Context Discipline: Start with core steering and expand only with review-relevant steering or use-case-aligned local agent skills/playbooks
- Distinctive: line 66
Grep if needed: Search codebase for pattern validation or integration checks
- Distinctive: line 78
Use Markdown headings for clarity
- Distinctive: line 79
Follow design-review.md output format
- Very specific: line 85
Missing Design: If design.md doesn't exist, stop with message: "Run /buildpad-spec-design {feature} first to generate design document"
- Very specific: line 86
Design Not Generated: If design phase not marked as generated in spec.json, warn but proceed with review
- Very specific: line 88
Language Undefined: Default to English (en) if spec.json doesn't specify language
- Very specific: line 94
Run /buildpad-spec-tasks {feature} to generate implementation tasks
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
buildpad-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
/buildpad-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
/buildpad-spec-tasks {feature}to generate implementation tasks - Or
/buildpad-spec-tasks {feature} -yto auto-approve and proceed directly
If Design Needs Revision (NO-GO Decision):
- Address critical issues identified in review
- Re-run
/buildpad-spec-design {feature}with improvements - Re-validate with
/buildpad-validate-design {feature}
Note: Design validation is recommended but optional. Quality review helps catch issues early.
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
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.

