Generate comprehensive implementation plans using Specification-Driven Development (SDD)
methodology. Use when creating technical design, implementation roadmap, or executing
the /plan command.
This skill orchestrates the plan-template.md execution flow, generating research, data
models, API contracts, and test scenarios. It validates constitutional compliance
(Library-First, Test-First, Contract-First) and prepares for task generation.
Triggered by: /plan command, user request for "implementation plan", "technical design",
"how to implement", or "design this feature".
aseesy0 Sterne12.11.2025
Beruf
Kategorien
CMS & Plattformen
Skill-Inhalt
When to Use
Activate this skill when:
User invokes /plan command
User requests implementation planning for a feature
User asks "how should we implement this?"
Specification is complete and ready for technical design
Need to generate data models, contracts, and test scenarios
Trigger Keywords: plan, implementation plan, technical design, how to implement, architecture, design, /plan
Prerequisites: Feature specification must exist (typically from /specify command)
Procedure
Step 1: Setup and Initialization
Run setup script to get feature paths:
.specify/scripts/bash/setup-plan.sh --json
Parse JSON output to extract:
Verwandte Skills
FEATURE_SPEC: Path to feature specification
IMPL_PLAN: Path to implementation plan (plan.md)
SPECS_DIR: Directory for all feature artifacts
BRANCH: Current feature branch name
IMPORTANT: All file paths must be absolute (from repository root)
Step 2: Analyze Specification
Read and understand the feature specification:
Read: $FEATURE_SPEC
Extract key information:
Feature requirements and user stories
Functional and non-functional requirements
Success criteria and acceptance criteria
Technical constraints and dependencies
Domain context
Step 3: Review Constitutional Requirements
Read the constitution to ensure compliance:
Read: .specify/memory/constitution.md
Focus on core principles:
Principle I: Library-First Architecture - Feature must start as standalone library
Principle II: Test-First Development - Tests written before implementation
Principle III: Contract-First Design - Define contracts before code
Principle IX: Dependency Management - All dependencies declared
Step 4: Execute Plan Template
Load the plan template:
Read: .specify/templates/plan-template.md
The plan template is self-executing - follow its 9-step Execution Flow:
Phase 0: Research & Analysis
Technical research for feature requirements
Technology evaluation and selection
Architecture patterns identification
Risk assessment
Generate: $SPECS_DIR/research.md
Phase 1: Design Artifacts
Data model definition (entities, relationships, schemas)
Generate: $SPECS_DIR/data-model.md
API contract definition (endpoints, request/response schemas)
Generate: $SPECS_DIR/contracts/*.md (one file per endpoint/contract)
Test scenario definition (from user stories)
Generate: $SPECS_DIR/quickstart.md
Phase 2: Execution Planning
Implementation roadmap
Task breakdown with dependencies
Note: tasks.md generation is deferred to /tasks command
Incorporate user-provided details:
Add any additional context from command arguments to Technical Context section
User may provide implementation preferences, technology choices, constraints
Update Progress Tracking as you complete each phase:
Mark phases as complete
Note any errors or blockers
Track generated artifacts
Step 5: Verify Execution
Check that all phases completed successfully:
Phase 0: research.md exists and is comprehensive
Phase 1: data-model.md exists with entities defined
Phase 1: contracts/ directory exists with contract files
Phase 1: quickstart.md exists with test scenarios
Phase 2: Implementation approach documented in plan.md
Use the Task tool to delegate to planning-agent:
- subagent_type: "planning-agent"
- description: "Execute /plan command"
- prompt: "Execute the /plan command for this feature"
Note: This skill provides procedural guidance for the planning workflow. For autonomous execution, always delegate to the planning-agent which has specialized tools and constitutional compliance built-in.
backend-architect
When to delegate: Multi-service architecture, complex backend systems (for specialized research during Phase 0)
What they handle: Backend system design, API architecture, service patterns
frontend-specialist
When to delegate: UI components, user interactions, client-side logic
What they handle: Component design, state management, UI patterns
database-specialist
When to delegate: Complex data models, query optimization, schema design
What they handle: Database schema, relationships, indexing, query patterns
task-orchestrator
When to delegate: Multi-domain feature (3+ domains detected)
What they handle: Coordinating multiple specialists during implementation
Validation
Verify the skill executed correctly:
setup-plan.sh executed and paths extracted
Feature specification read and analyzed
Constitution reviewed and applied
Plan template executed through all phases
research.md generated and comprehensive
data-model.md generated with entities
contracts/ directory has contract files
quickstart.md generated with test scenarios
Plan validation executed and reported
Domain detection executed and reported
Suggested agents reported to user
User notified about next step (/tasks)
Troubleshooting
Issue: setup-plan.sh fails with "No specification found"
Cause: Feature specification doesn't exist or is in wrong location
Solution:
Verify spec.md exists in current branch's specs/ directory
Run /specify first to create specification
Check branch name matches specs directory name
Issue: Validation score low (<12/16)
Cause: Plan missing required sections or artifacts not generated
Solution:
Review validation output for specific failures
Check that all Phase 0 and Phase 1 artifacts exist
Ensure plan.md includes all required sections
Re-run plan template phases that failed
Issue: No contracts generated
Cause: Feature doesn't define external interfaces or API contracts unclear
Solution:
Review specification for API endpoints or component interfaces
If truly no external contracts, document internal interfaces
Create at least one contract showing module public API
Update plan to clarify contract boundaries
Issue: Domain detection shows different domains than specification