Open_Ultra_SAST/.agents/skills/kiro-spec-design/SKILL.md

name, description, metadata

name	description	metadata
kiro-spec-design	Create comprehensive technical design for a specification; optionally run the implementation gap analysis first (--gap) or an interactive design review of an existing design (--review)	shared-rules design-principles.md, design-discovery-full.md, design-discovery-light.md, design-synthesis.md, design-review-gate.md, gap-analysis.md, design-review.md

Technical Design Generator

Arguments: $1 is the feature. $2 may be -y (auto-approve requirements), --gap (run the optional gap analysis of Step 1b before designing) or --review (run only the optional interactive design review of Step 7 on an existing design.md). The design review gate of Step 5 always runs when a design is generated; the optional steps never replace it.

<background_information>

• Success Criteria:
  • All requirements mapped to technical components with clear interfaces
  • The design makes responsibility boundaries explicit enough to guide task generation and review
  • Appropriate architecture discovery and research completed
  • Design aligns with steering context and existing patterns
  • Visual diagrams included for complex architectures </background_information>

## Execution Steps

Step 1: Load Context

Read all necessary context:

• .kiro/specs/$1/spec.json, requirements.md, design.md (if exists)
• .kiro/specs/$1/research.md (if exists, contains the gap analysis from Step 1b or an earlier run)
• Core steering context: overview.md, roadmap.md, safety-net.md (this repository's core steering; custom steering files may also exist in .kiro/steering/)
• Additional steering files only when directly relevant to requirement coverage, architecture boundaries, integrations, runtime prerequisites, security/performance constraints, or team conventions that affect implementation readiness
• .kiro/settings/templates/specs/design.md for document structure
• Read rules/design-principles.md from this skill's directory for design principles
• .kiro/settings/templates/specs/research.md for discovery log structure

Validate requirements approval:

• If -y flag provided ($2 == "-y"): Auto-approve requirements in spec.json
• Otherwise: Verify approval status (stop if unapproved, see Safety & Fallback)

Step 1b (optional, --gap): Implementation Gap Analysis

Recommended for brownfield features; skip for greenfield. Analyze the gap between the approved requirements and the existing codebase to inform the design, following rules/gap-analysis.md from this skill's directory.

1. Read rules/gap-analysis.md for the analysis framework.
2. Research in parallel where possible (sub-agents if available, otherwise sequentially): existing implementations, architecture patterns, integration points and extension possibilities; external dependency compatibility and version constraints when needed; the requirements, core steering, task-relevant extra steering and relevant local agent skills or playbooks.
3. Execute the gap analysis: Grep and Read the codebase, use WebSearch/WebFetch for external dependencies if needed, evaluate multiple implementation approaches (extend / new / hybrid) with trade-offs, flag areas needing further research. Provide information and options, not final implementation choices.
4. Write the analysis to .kiro/specs/$1/research.md (append after a --- rule if the file exists; never overwrite earlier research) and read it back to verify the write. Use the language specified in spec.json.
5. Unapproved requirements are a warning here, not a stop: gap analysis can inform requirement revisions. Then continue with Step 2, or stop and report if the user asked for the gap analysis alone.

Step 2: Discovery & Analysis

Critical: This phase ensures design is based on complete, accurate information.

1. Classify Feature Type:

   • New Feature (greenfield) → Full discovery required
   • Extension (existing system) → Integration-focused discovery
   • Simple Addition (CRUD/UI) → Minimal or no discovery
   • Complex Integration → Comprehensive analysis required

2. Execute Appropriate Discovery Process:

   For Complex/New Features:

   • Read and execute rules/design-discovery-full.md from this skill's directory
   • Conduct thorough research using WebSearch/WebFetch:
     • Latest architectural patterns and best practices
     • External dependency verification (APIs, libraries, versions, compatibility)
     • Official documentation, migration guides, known issues
     • Performance benchmarks and security considerations

   For Extensions:

   • Read and execute rules/design-discovery-light.md from this skill's directory
   • Focus on integration points, existing patterns, compatibility
   • Use Grep to analyze existing codebase patterns

   For Simple Additions:

   • Skip formal discovery, quick pattern check only

Parallel Research (sub-agent dispatch)

The following research areas are independent and can be dispatched as sub-agents. The agent should decide the optimal decomposition based on feature complexity — split, merge, add, or skip sub-agents as needed. Each sub-agent returns a findings summary (not raw data) to keep the main context clean for synthesis.

Typical research areas (adjust as appropriate):

• Codebase analysis: Existing architecture patterns, integration points, code conventions
• External research: Dependencies, APIs, latest best practices
• Context loading (usually main context): Steering files, design principles, discovery rules, templates

For simple additions, skip sub-agent dispatch entirely and do a quick pattern check in main context.

After all findings return, synthesize in main context before proceeding.

3. Retain Discovery Findings for Step 3:

   • External API contracts and constraints
   • Technology decisions with rationale
   • Existing patterns to follow or extend
   • Integration points and dependencies
   • Identified risks and mitigation strategies
   • Boundary candidates, out-of-boundary decisions, and likely revalidation triggers

4. Persist Findings to Research Log:

   • Create or update .kiro/specs/$1/research.md using the shared template
   • Summarize discovery scope and key findings (Summary section)
   • Record investigations in Research Log topics with sources and implications
   • Document architecture pattern evaluation, design decisions, and risks using the template sections
   • Use the language specified in spec.json when writing or updating research.md

Step 3: Synthesis

Apply design synthesis to discovery findings before writing.

• Read and apply rules/design-synthesis.md from this skill's directory
• This step requires the full picture from discovery — do not parallelize or delegate to sub-agents
• Record synthesis outcomes (generalizations found, build-vs-adopt decisions, simplifications) in research.md

Step 4: Generate Design Draft

1. Load Design Template and Rules:

   • Read .kiro/settings/templates/specs/design.md for structure
   • Read rules/design-principles.md from this skill's directory for principles

2. Generate Design Draft:

   • Follow specs/design.md template structure and generation instructions strictly
   • Boundary-first requirement: Before expanding supporting sections, make the boundary explicit. The draft must clearly define what this spec owns, what it does not own, which dependencies are allowed, and what changes would require downstream revalidation.
   • Integrate all discovery findings and synthesis outcomes: Use researched information (APIs, patterns, technologies) and synthesis decisions (generalizations, build-vs-adopt, simplifications) throughout component definitions, architecture decisions, and integration points
   • File Structure Plan (required): Populate the File Structure Plan section with concrete file paths and responsibilities. Analyze the codebase to determine which files need to be created vs. modified. Each file must have one clear responsibility. This section directly drives task _Boundary:_ annotations and implementation Task Briefs — vague file structures produce vague implementations.
   • Testing Strategy: Derive test items from requirements' acceptance criteria, not generic patterns. Each test item should reference specific components and behaviors from this design. E2E paths must map to the critical user flows identified in requirements. Avoid vague entries like "test login works" -- instead specify what is being verified and why it matters.
   • If existing design.md found in Step 1, use it as reference context (merge mode)
   • Apply design rules: Type Safety, Visual Communication, Formal Tone
   • Use language specified in spec.json
   • Keep this as a draft until the review gate passes; do not write design.md yet

Step 5: Review Design Draft

• Read and apply rules/design-review-gate.md from this skill's directory
• Verify requirements coverage, architecture readiness, and implementation executability before finalizing the design
• If issues are local to the draft, repair the design and review again
• Keep the review bounded to at most 2 repair passes
• If the draft exposes a real requirements/design gap, stop and return to requirements clarification instead of papering over it in design.md

Step 6: Finalize Design Document

1. Write Final Design and Research Log:

   • Write .kiro/specs/$1/design.md only after the design review gate passes
   • Write research.md with discovery findings and synthesis outcomes (if not already written)
   • Persist any research.md updates that support the finalized design

2. Update Metadata in spec.json:

   • Set phase: "design-generated"
   • Set approvals.design.generated: true, approved: false
   • Set approvals.requirements.approved: true
   • Update updated_at timestamp

Step 7 (optional, --review): Interactive Design Review

A human-paced quality review of an existing .kiro/specs/$1/design.md, in addition to the automatic gate of Step 5. Follow rules/design-review.md from this skill's directory.

1. Gather context: spec.json, requirements.md, design.md, core steering, review-relevant extra steering and local playbooks; survey existing codebase patterns, naming conventions and component structure for reference (parallel sub-agents if available).
2. Review: Analysis -> Critical Issues -> Strengths -> GO/NO-GO. Limit to the 3 most important concerns; recognize 1-2 strengths; engage interactively (clarifying questions, alternatives); leverage conversation history for requirements context and user intent. Quality assurance, not perfection seeking; accept acceptable risk; every suggestion must be implementable.
3. Decide: a clear GO/NO-GO with rationale. GO: /kiro-spec-tasks $1 (or -y). NO-GO: address the critical issues, re-run /kiro-spec-design $1, then /kiro-spec-design $1 --review again.
4. If design.md does not exist, stop: "Run /kiro-spec-design $1 first to generate design document". If the design phase is not marked generated in spec.json, warn but proceed.

Critical Constraints

• Type Safety:
  • Enforce strong typing aligned with the project's technology stack.
  • For statically typed languages, define explicit types/interfaces and avoid unsafe casts.
  • For TypeScript, never use any; prefer precise types and generics.
  • For dynamically typed languages, provide type hints/annotations where available (e.g., Python type hints) and validate inputs at boundaries.
  • Document public interfaces and contracts clearly to ensure cross-component type safety.
• Requirements Traceability IDs: Use numeric requirement IDs only (e.g. "1.1", "1.2", "3.1", "3.3") exactly as defined in requirements.md. Do not invent new IDs or use alphabetic labels.

Output Description

Command execution output (separate from design.md content):

Provide brief summary in the language specified in spec.json:

1. Status: Confirm design document generated at .kiro/specs/$1/design.md
2. Discovery Type: Which discovery process was executed (full/light/minimal)
3. Key Findings: 2-3 critical insights from research.md that shaped the design
4. Review Gate: Confirm the design review gate passed
5. Next Action: Approval workflow guidance (see Safety & Fallback)
6. Research Log: Confirm research.md updated with latest decisions

Format: Concise Markdown (under 200 words) - this is the command output, NOT the design document itself

Note: The actual design document follows .kiro/settings/templates/specs/design.md structure.

Safety & Fallback

Error Scenarios

Requirements Not Approved:

• Stop Execution: Cannot proceed without approved requirements
• User Message: "Requirements not yet approved. Approval required before design generation."
• Suggested Action: "Run /kiro-spec-design $1 -y to auto-approve requirements and proceed"

Missing Requirements:

• Stop Execution: Requirements document must exist
• User Message: "No requirements.md found at .kiro/specs/$1/requirements.md"
• Suggested Action: "Run /kiro-spec-requirements $1 to generate requirements first"

Template Missing:

• User Message: "Template file missing at .kiro/settings/templates/specs/design.md"
• Suggested Action: "Check repository setup or restore template file"
• Fallback: Use inline basic structure with warning

Steering Context Missing:

• Warning: "Steering directory empty or missing - design may not align with project standards"
• Proceed: Continue with generation but note limitation in output

Invalid Requirement IDs:

• Stop Execution: If requirements.md is missing numeric IDs or uses non-numeric headings (for example, "Requirement A"), stop and instruct the user to fix requirements.md before continuing.

Spec Gap Found During Design Review:

• Stop Execution: Do not write a patched-over design.md
• User Message: "Design review found a real spec gap or ambiguity that must be resolved before design can be finalized."
• Suggested Action: Clarify or fix requirements.md, then re-run /kiro-spec-design $1

Next Phase: Task Generation

If Design Approved:

• Review generated design at .kiro/specs/$1/design.md
• Optional: Run /kiro-spec-design $1 --review for the interactive quality review (Step 7)
• Then /kiro-spec-tasks $1 -y to generate implementation tasks

If Modifications Needed:

• Provide feedback and re-run /kiro-spec-design $1
• Existing design used as reference (merge mode)