Establishes SDD methodology - workflow routing, process discipline, spec-first principle, and skill discovery. Use when starting any SDD conversation to determine which workflow skill to invoke.
Routes tasks to the appropriate SDD workflow skill (brainstorm, implement, or evolve) based on whether you're starting from a rough idea, clear requirements, or handling spec/code mismatches.
/plugin marketplace add rhuss/cc-superpowers-sdd/plugin install sdd@sdd-plugin-developmentThis skill inherits all available tools. When active, it can use any tool Claude has access to.
IF A SKILL APPLIES TO YOUR TASK, YOU DO NOT HAVE A CHOICE. YOU MUST USE IT.
This is not negotiable. This is not optional. You cannot rationalize your way out of this. </EXTREMELY-IMPORTANT>
SDD = Specification-Driven Development
A development methodology where specifications are the single source of truth:
This plugin combines:
NOTE: The spec-kit skill handles all technical setup automatically.
Every SDD workflow skill calls {Skill: spec-kit} first, which:
You don't need to worry about setup. Focus on choosing the right workflow.
Before responding to ANY user message, you MUST complete this checklist:
Responding WITHOUT completing this checklist = automatic failure.
CRITICAL RULE: Specs are the source of truth. Everything flows from and validates against specs.
Before ANY implementation work:
You CANNOT write code without a spec. Period.
These work as-is with spec context:
User request arrives
↓
Is this a new feature/project?
Yes → Is it a rough idea?
Yes → sdd:brainstorm
No → Create spec using spec-kit tools
No → Does spec exist for this area?
Yes → Is there spec/code mismatch?
Yes → sdd:evolve
No → sdd:implement
No → Create spec first using spec-kit tools
User: "I want to add authentication to my app"
→ Use sdd:brainstorm
Brainstorm will:
User: "Add a POST /api/users endpoint that validates email and returns 422 on invalid format"
→ Create spec directly using spec-kit tools
Direct spec creation:
WHAT vs HOW principle: Specs define WHAT and WHY, not HOW.
If you catch yourself thinking ANY of these thoughts, STOP. You are rationalizing. Check for and use the skill.
Spec-avoidance rationalizations:
Skill-avoidance rationalizations:
Why: Specs prevent drift. Skills enforce discipline. Both save time by preventing mistakes.
If a skill for your task exists, you must use it or you will fail at your task.
If a skill has a checklist, YOU MUST create TodoWrite todos for EACH item.
Don't:
Why: Checklists without TodoWrite tracking = steps get skipped. Every time.
Before using a skill, announce that you are using it.
"I'm using [Skill Name] to [what you're doing]."
Examples:
Why: Transparency helps your human partner understand your process and catch errors early.
Specs WILL diverge from code. This is expected and healthy.
When mismatch detected:
Remember: Specs are source of truth, but truth can evolve based on reality.
Consider creating a constitution for your project:
What is it?
When to create:
How to create:
Use /sdd:constitution skill.
Your human partner's specific instructions describe WHAT to do, not HOW.
"Add X", "Fix Y" = the goal, NOT permission to skip spec-first or verification.
Red flags: "Instruction was specific" • "Seems simple" • "Workflow is overkill"
Why: Specific instructions mean clear requirements, which is when specs matter MOST.
Starting any task:
The methodology is:
The tools are:
The goal is: High-quality software with specs that remain the living source of truth.
User: "I want to add notifications to my app"
1. Recognize: Rough idea
2. Route to: sdd:brainstorm
3. Brainstorm will:
- Call spec-kit (auto-setup)
- Explore idea collaboratively
- Create formal spec
- Hand off to sdd:implement
User: "Add GET /api/stats endpoint returning JSON with user_count and post_count"
1. Recognize: Clear requirements
2. Create spec using spec-kit tools
3. Route to: sdd:implement
4. Implement will:
- Call spec-kit (auto-setup)
- Generate plan from spec
- Use TDD
- Verify spec compliance
User: "Document what this auth module does"
1. Recognize: Code without spec
2. Create spec by analyzing code
3. Route to: sdd:evolve (to reconcile)
User: "The login endpoint returns different errors than the spec says"
1. Recognize: Spec/code mismatch
2. Route to: sdd:evolve
3. Evolve will:
- Call spec-kit (auto-setup)
- Analyze mismatch
- Recommend update spec vs. fix code
- User decides or auto-update
You are the methodology enforcer.
You are NOT:
Your job: Ensure the right skill gets used for the right task, and that SDD principles are followed.
The goal: Specs that stay current. Code that matches intent. Quality through discipline.
This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
This skill should be used when the user asks to "create a slash command", "add a command", "write a custom command", "define command arguments", "use command frontmatter", "organize commands", "create command with file references", "interactive command", "use AskUserQuestion in command", or needs guidance on slash command structure, YAML frontmatter fields, dynamic arguments, bash execution in commands, user interaction patterns, or command development best practices for Claude Code.
This skill should be used when the user asks to "create a hook", "add a PreToolUse/PostToolUse/Stop hook", "validate tool use", "implement prompt-based hooks", "use ${CLAUDE_PLUGIN_ROOT}", "set up event-driven automation", "block dangerous commands", or mentions hook events (PreToolUse, PostToolUse, Stop, SubagentStop, SessionStart, SessionEnd, UserPromptSubmit, PreCompact, Notification). Provides comprehensive guidance for creating and implementing Claude Code plugin hooks with focus on advanced prompt-based hooks API.