agentleFS
buildpad-aibuildpad-ai/skills/buildpad-validate-design/SKILL.md

buildpad-validate-design

Skill1 starsChanged 27 days agoMITView on GitHub

Interactive technical design quality review and validation. Use when reviewing design before implementation.

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
  1. Distinctive:

    If steering/spec context is already available from conversation, skip redundant file reads.

    line 27
  2. Very specific:

    Read .kiro/specs/{feature}/spec.json for language and metadata

    line 29
  3. Very specific:

    Read .kiro/specs/{feature}/requirements.md for requirements

    line 30
  4. Very specific:

    Read .kiro/specs/{feature}/design.md for design document

    line 31
  5. Distinctive:

    After all parallel research completes, synthesize findings for review.

    line 42
  6. Distinctive:

    Follow design-review.md process: Analysis → Critical Issues → Strengths → GO/NO-GO

    line 46
  7. Very specific:

    Use language specified in spec.json for output

    line 49
  8. Distinctive:

    Actionable feedback: All suggestions must be implementable

    line 61
  9. 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
  10. Distinctive:

    Grep if needed: Search codebase for pattern validation or integration checks

    line 66
  11. Distinctive:

    Use Markdown headings for clarity

    line 78
  12. Distinctive:

    Follow design-review.md output format

    line 79
  13. Very specific:

    Missing Design: If design.md doesn't exist, stop with message: "Run /buildpad-spec-design {feature} first to generate design document"

    line 85
  14. Very specific:

    Design Not Generated: If design phase not marked as generated in spec.json, warn but proceed with review

    line 86
  15. Very specific:

    Language Undefined: Default to English (en) if spec.json doesn't specify language

    line 88
  16. Very specific:

    Run /buildpad-spec-tasks {feature} to generate implementation tasks

    line 94

≈ “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.

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

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.json for language and metadata
  • Read .kiro/specs/{feature}/requirements.md for requirements
  • Read .kiro/specs/{feature}/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:

  1. 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
  2. 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:

  1. Review Summary: Brief overview (2-3 sentences) of design quality and readiness
  2. Critical Issues: Maximum 3, following design-review.md format
  3. Design Strengths: 1-2 positive aspects
  4. 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} -y to 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.

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.