Skills Frameworks
Methodologies and skill collections for effective AI-assisted development.
What Are Skills Frameworks?
Skills frameworks provide structured methodologies for working with Claude Code. Rather than using Claude Code ad-hoc, these frameworks enforce specific workflows, planning phases, and quality gates.
The key insight behind skills frameworks: AI agents perform better when they follow consistent, well-defined patterns rather than improvising each time. By encoding best practices into "skills" (markdown files that Claude reads), you get more reliable, disciplined results.
This page covers two complementary approaches:
- superpowers — Strict TDD-enforced methodology for production software
- get-shit-done — Context-engineered spec-driven development for solo developers
superpowers
An agentic skills framework & software development methodology.
GitHub | 32k+ stars | TDD-enforced | Disciplined development
Overview
superpowers provides a structured approach to AI-assisted development that makes Claude Code more reliable, disciplined, and autonomous. Created by Jesse Vincent (obra), it enables Claude to work "autonomously for a couple hours at a time without deviating from the plan."
The core insight: AI agents can learn reusable capabilities by reading markdown "SKILL.md" files that document specific workflows. These become mandatory patterns rather than optional suggestions.
The Iron Law — The non-negotiable principle that defines superpowers:
"NO PRODUCTION CODE WITHOUT A FAILING TEST FIRST"
This means Claude will refuse to write implementation code until you have a failing test. This enforcement is what makes superpowers different from simply asking Claude to "use TDD."
Key Features
Each feature addresses a specific challenge in AI-assisted development:
| Feature | Description |
|---|---|
| 21 Built-in Skills | Development, planning, debugging, review, docs, git, and more |
| Mandatory TDD | Enforced RED-GREEN-REFACTOR cycles |
| Subagent Architecture | Fresh subagents per task with two-stage review |
| Parallel Agent Dispatch | Coordinate multiple agents simultaneously |
| Git Worktrees | Isolated development branches for parallel work |
| Marketplace Support | Install additional skills from community |
Available Skills
Skills are organized by category. Each skill is a self-contained workflow that Claude follows when invoked:
| Category | Skills |
|---|---|
| Development | tdd, implement-feature, refactor, code-review |
| Planning | brainstorm, write-plan, execute-plan, break-down-task |
| Debugging | debug, investigate-issue, fix-bug |
| Documentation | document, update-readme, generate-api-docs |
| Git | commit, create-pr, review-changes |
| Testing | write-tests, increase-coverage, fix-failing-tests |
| Analysis | analyze-codebase, find-patterns, security-review |
Core Commands
These are the primary slash commands you'll use. Each one triggers a specific workflow:
| Command | Purpose |
|---|---|
/superpowers:brainstorm | Socratic questioning to refine design |
/superpowers:write-plan | Create detailed implementation plans |
/superpowers:execute-plan | Execute in batches with oversight |
/superpowers:tdd | Strict RED-GREEN-REFACTOR cycle |
Typical Workflow
This diagram shows the recommended progression through superpowers. Each phase has a specific purpose and output:
┌─────────────────────────────────────────────────────────────────┐
│ 1. BRAINSTORM │
│ /superpowers:brainstorm "Add user authentication" │
│ → Claude asks clarifying questions (OAuth? JWT? Sessions?) │
│ → You refine requirements through dialogue │
│ → Output: Clear understanding of what to build │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. PLAN │
│ /superpowers:write-plan │
│ → Creates git worktree for isolated work │
│ → Breaks work into 2-5 minute tasks │
│ → Output: PLAN.md with exact file paths and test cases │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. EXECUTE (with mandatory TDD) │
│ /superpowers:execute-plan │
│ For each task: │
│ → RED: Write failing test first │
│ → GREEN: Write minimal code to pass │
│ → REFACTOR: Clean up while tests stay green │
│ → Checkpoint: Review batch before continuing │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. REVIEW & MERGE │
│ → Code review against original plan │
│ → All tests must pass │
│ → Merge worktree back to main branch │
└─────────────────────────────────────────────────────────────────┘
Quick TDD cycle — For single features where you want to skip the full planning process:
/superpowers:tdd "Add password reset functionality"
# Claude will enforce RED → GREEN → REFACTOR for each piece
The Seven-Phase Workflow
Understanding the full workflow helps you know where you are in the process and what comes next:
- Design Refinement — Agent asks clarifying questions before coding
- Environment Setup — Isolated branches, dependency verification
- Planning — Break work into 2-5 minute tasks with exact file paths
- Implementation — Subagent-driven or batch execution
- TDD — Mandatory RED-GREEN-REFACTOR cycles
- Code Review — Work evaluated against original plan
- Finalization — Verify tests, present merge options, cleanup
TDD Enforcement
The RED-GREEN-REFACTOR cycle is the heart of superpowers. Understanding this pattern is essential:
1. RED: Write one failing test (must watch it fail)
→ This proves the test is actually testing something
2. GREEN: Write minimal code to pass
→ Only what's needed, nothing more
3. REFACTOR: Clean up while keeping tests green
→ Now you can improve the code safely
The key insight: by watching the test fail first, you prove it's actually testing the right thing. This prevents false confidence from tests that pass for the wrong reasons.
Installation
superpowers is installed through the plugin marketplace:
# Register the marketplace
/plugin marketplace add obra/superpowers-marketplace
# Install the plugin
# (Follow marketplace prompts)
When to Use
superpowers shines in these scenarios:
- Production-quality software requiring discipline
- Projects with existing test infrastructure
- Teams wanting consistent development standards
- Extended autonomous operation needs
Considerations
Be aware of these tradeoffs before adopting superpowers:
- Strict methodology — Skills are MANDATORY, not optional
- Learning curve — Requires adjustment to structured workflow
- Test infrastructure required — TDD enforcement needs testable architecture
- Time investment upfront — Brainstorm-plan-execute takes more initial time
get-shit-done
A lightweight meta-prompting, context engineering and spec-driven development system.
GitHub | 5.7k stars | Solo developers | Context engineering
Overview
While superpowers focuses on TDD discipline, get-shit-done (GSD) tackles a different problem: context rot — the quality degradation that occurs as Claude fills its context window during development sessions. It uses strategic file management to keep main context at 30-40% utilization while spawning parallel subagents with fresh 200k-token contexts.
The Core Problem:
Claude starts hallucinating and making bad decisions when context fills up. GSD keeps you in the "smart zone."
Target User: Solo developers who rely on Claude Code to write their code.
Adoption: Trusted by engineers at Amazon, Google, Shopify, and Webflow.
Key Features
Each feature addresses a specific aspect of context management or development workflow:
| Feature | Description |
|---|---|
| Context Engineering | Strategic file management at 30-40% context utilization |
| XML Prompt Formatting | Precise task structure for unambiguous execution |
| Multi-Agent Orchestration | Parallel subagents for research, planning, execution |
| Atomic Git Commits | One commit per task for clean history |
| Session Persistence | STATE.md maintains context across sessions |
| Codebase Learning | Hooks index exports/imports and detect naming conventions |
Workflow Modes
GSD provides different modes for different situations. Choose based on your task size and needs:
| Mode | Command | Purpose |
|---|---|---|
| Full Planning | /gsd:new-project | Complete spec-driven development |
| Quick Mode | /gsd:quick | Fast ad-hoc tasks with same guarantees |
| Debug Mode | /gsd:debug | Systematic debugging with persistent state |
| Resume | /gsd:resume | Continue from STATE.md |
| Checkpoint | /gsd:checkpoint | Save progress for later |
Typical Workflow
This diagram shows the full GSD cycle. Each phase has specific inputs and outputs, creating a clear progression from idea to implementation:
┌─────────────────────────────────────────────────────────────────┐
│ 1. INITIALIZE │
│ /gsd:new-project │
│ "I want to build a task management API with auth" │
│ → Claude asks questions until it fully understands │
│ → Parallel agents research domain (auth patterns, etc.) │
│ → Creates: PROJECT.md, REQUIREMENTS.md, ROADMAP.md │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 2. DISCUSS (per phase) │
│ /gsd:discuss-phase 1 │
│ → "Should we use JWT or sessions?" │
│ → "REST or GraphQL?" │
│ → Captures your preferences before planning │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 3. PLAN │
│ /gsd:plan-phase 1 │
│ → Research implementation approach │
│ → Creates 2-3 atomic task plans in XML format │
│ → Verification: plans checked against requirements │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 4. EXECUTE │
│ /gsd:execute-phase 1 │
│ → Fresh 200k-token subagents for each task │
│ → Tasks run in parallel waves │
│ → Atomic git commit after each task │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 5. VERIFY │
│ /gsd:verify-work 1 │
│ → Manual verification walkthrough │
│ → Test deliverables against requirements │
│ → Failures trigger /gsd:debug automatically │
└─────────────────────────────────────────────────────────────────┘
↓
┌─────────────────────────────────────────────────────────────────┐
│ 6. COMPLETE or CONTINUE │
│ /gsd:complete-milestone → Archive and tag release │
│ /gsd:new-milestone → Start next version │
│ /gsd:discuss-phase 2 → Continue to next phase │
└─────────────────────────────────────────────────────────────────┘
Quick mode — For small tasks where full planning is overkill:
/gsd:quick "Add a health check endpoint at /api/health"
# Skips full planning, uses same context engineering
Resume after break — GSD tracks state so you can pick up where you left off:
/gsd:resume
# Loads STATE.md and continues where you left off
The Six-Step Cycle
Understanding the cycle helps you know what phase you're in and what comes next. Here's what each step accomplishes:
1. INITIALIZE → 2. DISCUSS → 3. PLAN → 4. EXECUTE → 5. VERIFY → 6. COMPLETE
Step 1: Initialize (/gsd:new-project)
- Asks clarifying questions until complete understanding
- Spawns parallel agents for domain research
- Creates: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md
Step 2: Discuss (/gsd:discuss-phase N)
- Captures implementation preferences before planning
- Identifies gray areas (layout choices, API formats, architecture)
Step 3: Plan (/gsd:plan-phase N)
- Research implementation approach
- Creates 2-3 atomic task plans with XML structure
- Verification loop until plans pass requirements check
Step 4: Execute (/gsd:execute-phase N)
- Plans run in parallel waves with fresh 200k-token contexts
- Each task gets atomic commit immediately upon completion
Step 5: Verify (/gsd:verify-work N)
- Extracts testable deliverables
- Manual verification walkthrough
- Failures trigger automatic debugging
Step 6: Complete (/gsd:complete-milestone)
- Archives and tags release
/gsd:new-milestonestarts next version
XML Task Structure
GSD uses XML to structure tasks. This format ensures Claude understands exactly what to do, what files to touch, and how to verify success. Here's an example:
<task type="auto">
<name>Create login endpoint</name>
<files>src/app/api/auth/login/route.ts</files>
<action>
Use jose for JWT (not jsonwebtoken).
Validate credentials against users table.
Return httpOnly cookie on success.
</action>
<verify>curl -X POST localhost:3000/api/auth/login returns 200</verify>
<done>Valid credentials return cookie, invalid return 401</done>
</task>
The XML structure prevents ambiguity — each field has a specific purpose:
name: What we're buildingfiles: Which files will be created or modifiedaction: Specific implementation instructionsverify: How to test it worksdone: Success criteria
Installation
GSD is installed via npx:
npx get-shit-done-cc
# Options
npx get-shit-done-cc --global # Install to ~/.claude/
npx get-shit-done-cc --local # Install to ./.claude/
Configuration
GSD's behavior is customizable. Settings in .planning/config.json:
- mode:
yolo(auto-approve) orinteractive(confirm each step) - depth:
quick,standard, orcomprehensive - Model Profiles: quality (Opus), balanced (Sonnet/Opus mix), budget
When to Use
GSD is designed for these scenarios:
- Solo development with Claude Code
- Projects needing clear specifications
- Long sessions where context rot is a concern
- Rapid iteration with quality guarantees
Considerations
Be aware of these aspects before adopting GSD:
- Optimized for solo developers — Not designed for team collaboration
- Claude Code specific — Built specifically for Claude Code
- Requires permission bypasses — Best with
--dangerously-skip-permissions - Learning curve — Multiple slash commands to learn
Comparison
This table highlights the key differences to help you choose the right framework for your needs:
| Aspect | superpowers | get-shit-done |
|---|---|---|
| Philosophy | Disciplined, structured | Context engineering + specs |
| Core Problem | Agent reliability & drift | Context rot (quality degradation) |
| Workflow Phases | 7 phases | 6 steps |
| TDD Approach | Mandatory RED-GREEN-REFACTOR | Optional |
| Planning Style | 2-5 minute tasks | XML-structured atomic tasks |
| Agent Usage | Subagent with dual-stage review | Parallel subagents, fresh contexts |
| Human Oversight | Batch checkpoints | Interactive or YOLO mode |
| Strictness | "Skills are MANDATORY" | Flexible with quick mode |
| Best For | Production software, teams | Solo developers, rapid iteration |
Decision Guide: When to Use Each
Use superpowers when:
- Building production-quality software
- You want enforced TDD discipline
- Extended autonomous operation is needed
- Team consistency is important
Use get-shit-done when:
- You're a solo developer
- Context rot is affecting quality
- You want spec-driven development
- Rapid iteration is the priority
Combining Approaches
You don't have to choose one exclusively. These frameworks can complement each other by using each for what it does best:
1. /gsd:new-project → Create clear specification
2. /superpowers:plan → Design implementation with TDD
3. /gsd:execute-phase → Execute with fresh context agents