This skill should be used when users want guidance on Spec-Driven Development methodology using GitHub's Spec-Kit. Guide users through executable specification workflows for both new projects (greenfield) and existing codebases (brownfield). After any SDD command generates artifacts, automatically provide structured 10-point summaries with feature status tracking, enabling natural language feature management and keeping users engaged throughout the process.
Instrucciones de origen · Vista previa de solo lectura
name
sdd
description
This skill should be used when users want guidance on Spec-Driven Development methodology using GitHub's Spec-Kit. Guide users through executable specification workflows for both new projects (greenfield) and existing codebases (brownfield). After any SDD command generates artifacts, automatically provide structured 10-point summaries with feature status tracking, enabling natural language feature management and keeping users engaged throughout the process.
Guide users through GitHub's Spec-Kit for Spec-Driven Development - a methodology that flips traditional software development by making specifications executable and directly generating working implementations.
Core Philosophy
Spec-Driven Development emphasizes:
Intent-driven development: Define the "what" before the "how"
Rich specification creation: Use guardrails and organizational principles
Multi-step refinement: Not one-shot code generation
AI-native: Heavy reliance on advanced AI capabilities
Remember: This is AI-native development. Specifications aren't just documentation - they're executable artifacts that directly drive implementation. The AI agent uses them to generate working code that matches the intent defined in the specs.
Highlight the most important decisions with rationale
Include quality indicators and watch-outs
Keep summary focused and actionable
Use clear headings for each section
Include Feature Status (Hybrid Approach)
Brief status line in every summary
Detailed status on demand with /speckit.status
See "Feature Status Tracking" section below
Offer Feedback Options
Option A: "Looks good, proceed to next step"
Option B: "I'd like to modify [specific section]"
Option C: "Regenerate with these changes: [user input]"
Option D: "Explain why [specific decision] was made"
10-Point Summary Template
Use this structured format after ANY SDD command completes:
## ✅ [Command Name] Completed - Here's What Just Happened
### 🎯 Key Decisions Made (Top 3)
1. [Decision] - **Rationale:** [Why this was chosen]
2. [Decision] - **Rationale:** [Why this was chosen]
3. [Decision] - **Rationale:** [Why this was chosen]
### 📋 What Was Generated
- [Artifact 1]: [Brief description of content]
- [Artifact 2]: [Brief description of content]
### 🔍 Important Items to Review (Top 3)
1. [Critical item to check and why it matters]
2. [Important detail to verify and potential impact]
3. [Edge case to consider and how it affects the design]
### ⚠️ Watch Out For (Top 2)
- [Potential issue or gotcha] - **How to avoid:** [Guidance]
- [Common mistake] - **How to avoid:** [Guidance]
### 🔄 What This Enables Next (2 Options)
- **Option 1:** [Next step] - Best if: [Condition]
- **Option 2:** [Alternative step] - Best if: [Condition]
📊 **Feature Status:** [Current Feature Name] ([Stage]) → Next: [Next Feature]
Progress: [●●●○○] [X]% | Completed: [N] of [Total] features | Dependencies: [Status]
**Your options:** [A] Proceed [B] Modify [C] Explain more [D] Show full status
Example: Enhanced Summarization After `/speckit.specify`
```
✅ Specify Completed - Here's What Just Happened
🎯 Key Decisions Made
Authentication: JWT tokens - Rationale: Stateless architecture, horizontally scalable, industry standard
Password requirements: 12+ characters with complexity - Rationale: Balances security (NIST guidelines) with usability
Session timeout: 24 hours - Rationale: Standard for web apps, balances security vs user convenience
📋 What Was Generated
`.speckit/features/user-auth/specify.md`: Complete requirements with 5 user stories, 8 success criteria, 3 edge cases
🔍 Important Items to Review
Password reset flow - Verify email requirements match your infrastructure (SMTP server, templates)
Multi-factor authentication - Currently marked as "future enhancement"; may need to be in MVP
Rate limiting - Set at 5 login attempts per 15 min; consider if this fits your security policy
⚠️ Watch Out For
Email service dependency not specified - How to avoid: Add email service to plan.md dependencies
GDPR compliance for user data - How to avoid: Review data retention and user deletion requirements
🔄 What This Enables Next
Option 1: Run `/speckit.plan` to design technical implementation - Best if: Requirements look good
Option 2: Modify specify.md - Best if: You need to adjust requirements or add features
When user requests full status (option D) or runs /speckit.status, show:
📊 Project Feature Status Dashboard
🎯 CURRENT FEATURE
├─ [feature-name] ([Stage] - [X]% complete)
│ ├─ ✅ Requirements specified
│ ├─ 🔄 Implementation plan in progress
│ ├─ ⏸️ Tasks not started
│ └─ ⏸️ Implementation not started
│ Blockers: [None | Description]
│ Dependencies: [feature-name] ✅
✅ COMPLETED FEATURES ([N])
├─ [feature-1] (100% complete)
└─ [feature-2] (100% complete)
📋 UPCOMING FEATURES ([N])
├─ [feature-3] (depends on: [current-feature])
└─ [feature-4] (depends on: [feature-3])
⚠️ BLOCKED FEATURES ([N])
[List any features that are blocked with reasons]
Natural Language Feature Management
Claude should automatically detect and handle natural language feature management requests:
User says: "Move feature XYZ before ABC"
Claude does:
Reads current feature list from .speckit/features/
Shows current order with numbers
Proposes new order
Asks for confirmation
Updates feature priority/order in constitution or plan
Shows updated status dashboard
User says: "Add a new feature for email notifications"
Claude does:
User says: "Let's do profile-management first"
Claude does:
Identifies current feature order
Proposes moving profile-management to top priority
Adjusts dependencies if needed
Updates artifacts
Shows updated status
Detection patterns:
"Move [feature] before/after [other]" → Reorder
"Add [feature]" → New feature
"Let's do [feature] first" → Move to top priority
"Skip [feature] for now" → Mark as deferred
"We finished [feature]" → Update status to complete
"What features depend on [feature]?" → Show dependency tree
"Show feature status" → Display full dashboard
Quick Feature Operations
Guide users through these operations when requested:
Add Feature:
User: "Add a feature for admin dashboard"
Claude:
1. What's the priority? (High/Medium/Low)
2. What features does this depend on? (user-auth, profile-management, etc.)
3. Brief description?
[Creates outline, shows updated status]
Reorder Features:
User: "Reorder features"
Claude:
Current order:
1. user-authentication
2. profile-management
3. admin-dashboard
4. email-notifications
5. reporting
How would you like to reorder? (provide new numbers or describe changes)
[Updates order, shows new status]
Remove Feature:
User: "Remove the reporting feature"
Claude:
⚠️ Warning: This will remove 'reporting' feature.
Dependencies affected: None
Are you sure? (yes/no)
[If yes: removes, updates status]
Progress Calculation
Automatically calculate progress based on SDD workflow completion:
📊 Can we start profile-management?
Checking dependencies...
✅ user-authentication (complete)
✅ database-setup (complete)
All dependencies satisfied! Ready to proceed.
Detect circular dependencies:
⚠️ Warning: Circular dependency detected
feature-A depends on feature-B
feature-B depends on feature-C
feature-C depends on feature-A
Please resolve this before proceeding.
Integration with Workflows
For Greenfield Projects:
After /speckit.specify, ask if there are multiple features
If yes, list them and track progress through each
Show status after each command
For Brownfield Projects:
After /speckit.reverse-engineer, create feature list from discovered functionality
Track new features separately from existing documented features
Add features iteratively to existing codebases, modernize legacy systems, adapt processes for evolving requirements, reverse-engineer existing code into SDD format.
