docs/user-guide/commands.md
Complete SuperClaude Framework Command Reference
This file serves two purposes: quick navigation for Claude Code and learning resource for humans.
Last Updated: 2026-01-18
This reference contains sections for different audiences:
| Section | Purpose |
|---|---|
π File Map | File paths for navigation in new sessions |
π§ MCP Server Reference | Technical integration details |
π Notes for Future Sessions | Session start instructions |
| Section | Purpose |
|---|---|
ποΈ Command Categories | Overview of all 30 commands by category |
π Detailed Descriptions | Syntax, examples, when to use each command |
π Visual Map | Decision tree: which command to use |
β‘ Key Differences | spawn vs task vs implement, etc. |
π Typical Workflows | Real-world usage patterns with examples |
π‘ Recommendation: Start with
ποΈ Command Categoriesfor overview, then readπ Typical Workflowsfor practical examples.
π€ For Claude Code: This section helps navigate the codebase in new sessions.
This section is for quick lookups in future sessions (new context).
PROJECT_INDEX.md # Project quick start (3K tokens)
src/superclaude/commands/
βββ pm.md # /sc:pm - Project Manager Agent (593 lines, most detailed)
βββ task.md # /sc:task - Task Management
βββ workflow.md # /sc:workflow - Workflow Generator
βββ spawn.md # /sc:spawn - Meta-System Orchestration
βββ brainstorm.md # /sc:brainstorm - Requirements Discovery
βββ implement.md # /sc:implement - Feature Implementation
βββ design.md # /sc:design - System Design
βββ research.md # /sc:research - Web Research
βββ analyze.md # /sc:analyze - Code Analysis
βββ troubleshoot.md # /sc:troubleshoot - Issue Diagnosis
βββ improve.md # /sc:improve - Code Improvement
βββ cleanup.md # /sc:cleanup - Dead Code Removal
βββ test.md # /sc:test - Testing
βββ build.md # /sc:build - Building
βββ explain.md # /sc:explain - Code Explanation
βββ document.md # /sc:document - Documentation
βββ git.md # /sc:git - Git Operations
βββ estimate.md # /sc:estimate - Development Estimation
βββ reflect.md # /sc:reflect - Task Reflection
βββ spec-panel.md # /sc:spec-panel - Expert Spec Review (414 lines)
βββ business-panel.md # /sc:business-panel - Business Analysis
βββ index-repo.md # /sc:index-repo - Repository Indexing
βββ index.md # /sc:index - Project Documentation
βββ load.md # /sc:load - Session Load
βββ save.md # /sc:save - Session Save
βββ select-tool.md # /sc:select-tool - MCP Tool Selection
βββ recommend.md # /sc:recommend - Command Recommendation
βββ help.md # /sc:help - Help
βββ sc.md # /sc - Main dispatcher
βββ agent.md # /sc:agent - Custom agents
plugins/superclaude/commands/ # Copy for plugin distribution
src/superclaude/pm_agent/
βββ confidence.py # ConfidenceChecker (pre-execution)
βββ self_check.py # SelfCheckProtocol (post-implementation)
βββ reflexion.py # ReflexionPattern (error learning)
src/superclaude/execution/
βββ parallel.py # Wave β Checkpoint β Wave pattern
βββ reflection.py # Session reflection
βββ self_correction.py # Error correction
src/superclaude/pytest_plugin.py # Fixtures: confidence_checker, self_check_protocol, etc.
CLAUDE.md # Project setup, commands overview
PLANNING.md # Architecture, design decisions
KNOWLEDGE.md # Best practices, troubleshooting
TASK.md # Current tasks
src/superclaude/skills/confidence-check/SKILL.md # Confidence check skill
| Command | Purpose | File |
|---|---|---|
/sc:pm | Project Manager (always active) | pm.md |
/sc:spawn | Decomposition Epic β Task | spawn.md |
/sc:task | Execution with MCP coordination | task.md |
/sc:workflow | Generate plan from PRD | workflow.md |
| Command | Purpose | File |
|---|---|---|
/sc:brainstorm | Clarify requirements (Socratic) | brainstorm.md |
/sc:research | Web research via Tavily | research.md |
| Command | Purpose | File |
|---|---|---|
/sc:implement | Write code | implement.md |
/sc:design | Architecture, API, schemas | design.md |
| Command | Purpose | File |
|---|---|---|
/sc:analyze | Code analysis (quality/security/perf) | analyze.md |
/sc:troubleshoot | Root cause analysis | troubleshoot.md |
/sc:test | Tests + coverage | test.md |
/sc:build | Build project | build.md |
| Command | Purpose | File |
|---|---|---|
/sc:improve | Refactoring, optimization | improve.md |
/sc:cleanup | Dead code, unused imports | cleanup.md |
| Command | Purpose | File |
|---|---|---|
/sc:explain | Code explanation | explain.md |
/sc:document | Generate documentation | document.md |
/sc:index-repo | Repository indexing | index-repo.md |
| Command | Purpose | File |
|---|---|---|
/sc:spec-panel | Specification review (Wiegers, Fowler...) | spec-panel.md |
/sc:business-panel | Business analysis (Porter, Drucker...) | business-panel.md |
| Command | Purpose | File |
|---|---|---|
/sc:git | Git + smart commits | git.md |
/sc:estimate | Time/complexity estimation | estimate.md |
/sc:reflect | Progress validation | reflect.md |
/sc:load | Load session | load.md |
/sc:save | Save session | save.md |
These commands produce documents/reports and DO NOT implement:
/sc:brainstorm β Requirements specification/sc:workflow β Implementation plan/sc:spawn β Task hierarchy/sc:research β Research report/sc:estimate β Estimation report/sc:design β Architecture documents/sc:analyze β Analysis report/sc:spec-panel β Expert review document/sc:business-panel β Business analysis document/sc:troubleshoot β Diagnostic report (fixes require --fix flag + confirmation)These commands execute changes:
/sc:implement β Writes code/sc:improve β Applies improvements (auto-fix for style, approval for architecture)/sc:cleanup β Removes dead code (auto-fix for unused imports, approval for referenced code)/sc:task β Discrete task execution (stops when complete)/sc:test β Runs tests/sc:build β Builds project/sc:git β Git operations/sc:troubleshoot is diagnose-first by default; use --fix flag to apply fixes/sc:improve and /sc:cleanup auto-fix safe changes, prompt for risky ones/sc:pm - Project Manager AgentStatus: Always active automatically. This is a background layer, not a command.
When to use: No need to call explicitly β always running.
What it does:
Workflow:
User: "I want to add authentication"
PM Agent:
1. Activates Brainstorming Mode (if request is vague)
2. Delegates to requirements-analyst
3. Delegates to system-architect
4. Delegates to security-engineer
5. Delegates to backend-architect
6. Delegates to quality-engineer
7. Documents in CLAUDE.md
MCP servers: sequential, context7, magic, playwright, morphllm, serena, tavily, chrome-devtools
Key patterns:
docs/pdca/[feature]/)/sc:spawn - Meta-System Task OrchestrationWhen to use: Complex task that requires breaking down into many subtasks with dependencies.
What it does:
Syntax:
/sc:spawn [complex-task] [--strategy sequential|parallel|adaptive] [--depth normal|deep]
Examples:
# Monolith migration
/sc:spawn "migrate legacy monolith to microservices" --strategy adaptive --depth deep
# Creates: Database design β Backend API β Frontend β Testing
# Feature with dependencies
/sc:spawn "implement user authentication system"
# Breakdown: Database design β Backend API β Frontend UI β Testing
Difference from /sc:task:
/sc:task - Enhanced Task ManagementWhen to use: Need to execute a specific complex task with MCP server coordination.
What it does:
Syntax:
/sc:task [action] [target] [--strategy systematic|agile|enterprise] [--parallel] [--delegate]
Examples:
# Enterprise-level feature
/sc:task create "enterprise authentication system" --strategy systematic --parallel
# Activates architect + security + backend + frontend
# Agile sprint
/sc:task execute "feature backlog" --strategy agile --delegate
# Iterative execution with delegation
MCP servers: sequential, context7, magic, playwright, morphllm, serena
/sc:workflow - Implementation Workflow GeneratorWhen to use: Have a PRD/specification and need a step-by-step implementation plan.
What it does:
Syntax:
/sc:workflow [prd-file|feature-description] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel]
Examples:
# From PRD file
/sc:workflow docs/PRD/auth-feature.md --strategy systematic --depth deep
# Result: "1. DB schema β 2. API β 3. UI β 4. Tests"
# From description
/sc:workflow "user authentication system" --strategy agile --parallel
Difference from /sc:task:
/sc:brainstorm - Interactive Requirements DiscoveryWhen to use: Idea is vague, need to understand requirements through dialogue.
What it does:
Syntax:
/sc:brainstorm [topic/idea] [--strategy systematic|agile|enterprise] [--depth shallow|normal|deep] [--parallel]
Examples:
# New product
/sc:brainstorm "AI-powered project management tool" --strategy systematic --depth deep
# Claude: What problems should it solve? For what team? Integrations?
# Result: Clear requirements document
# Feature
/sc:brainstorm "real-time collaboration features" --strategy agile --parallel
MCP servers: sequential, context7, magic, playwright, morphllm, serena
/sc:research - Deep Web ResearchWhen to use: Need up-to-date information from the internet.
What it does:
claudedocs/research_*.mdSyntax:
/sc:research "[query]" [--depth quick|standard|deep|exhaustive] [--strategy planning|intent|unified]
Examples:
/sc:research "latest developments in quantum computing 2024" --depth deep
/sc:research "competitive analysis of AI coding assistants" --depth exhaustive
MCP servers: tavily, sequential, playwright, serena
/sc:implement - Feature ImplementationWhen to use: Know exactly what to do, need to write code.
What it does:
Syntax:
/sc:implement [feature-description] [--type component|api|service|feature] [--framework react|vue|express] [--safe] [--with-tests]
Examples:
# React component
/sc:implement user profile component --type component --framework react --with-tests
# API with security
/sc:implement user authentication API --type api --safe --with-tests
# Full-stack feature
/sc:implement payment processing system --type feature --with-tests
MCP servers: context7, sequential, magic, playwright
/sc:design - System and Component DesignWhen to use: Need to design, but not implement.
What it does:
Syntax:
/sc:design [target] [--type architecture|api|component|database] [--format diagram|spec|code]
Examples:
/sc:design user-management-system --type architecture --format diagram
/sc:design payment-api --type api --format spec
/sc:design e-commerce-db --type database --format diagram
Difference from /sc:implement:
/sc:analyze - Code AnalysisWhen to use: Need a code audit.
What it does:
Syntax:
/sc:analyze [target] [--focus quality|security|performance|architecture] [--depth quick|deep] [--format text|json|report]
Examples:
/sc:analyze src/auth --focus security --depth deep
/sc:analyze --focus performance --format report
/sc:analyze src/components --focus quality --depth quick
/sc:troubleshoot - Issue DiagnosisWhen to use: Something is broken, need to find the cause.
What it does:
Syntax:
/sc:troubleshoot [issue] [--type bug|build|performance|deployment] [--trace] [--fix]
Examples:
/sc:troubleshoot "Null pointer exception in user service" --type bug --trace --fix
/sc:troubleshoot "TypeScript compilation errors" --type build --fix
/sc:troubleshoot "API response times degraded" --type performance
/sc:improve - Code ImprovementWhen to use: Code works, but want to make it better.
What it does:
Syntax:
/sc:improve [target] [--type quality|performance|maintainability|style] [--safe] [--interactive]
Examples:
/sc:improve src/ --type quality --safe
/sc:improve api-endpoints --type performance --interactive
/sc:improve auth-service --type security --validate
MCP servers: sequential, context7
/sc:cleanup - Code CleanupWhen to use: Need to remove garbage: dead code, unused imports.
What it does:
Syntax:
/sc:cleanup [target] [--type code|imports|files|all] [--safe|--aggressive] [--interactive]
Examples:
/sc:cleanup src/ --type code --safe
/sc:cleanup --type imports --preview
/sc:cleanup --type all --interactive
MCP servers: sequential, context7
/sc:test - TestingWhen to use: Need to run tests.
What it does:
Syntax:
/sc:test [target] [--type unit|integration|e2e|all] [--coverage] [--watch] [--fix]
Examples:
/sc:test
/sc:test src/components --type unit --coverage
/sc:test --type e2e # Activates Playwright MCP
/sc:test --watch --fix
MCP servers: playwright
/sc:build - Project BuildingWhen to use: Need to build the project.
What it does:
Syntax:
/sc:build [target] [--type dev|prod|test] [--clean] [--optimize] [--verbose]
Examples:
/sc:build
/sc:build --type prod --clean --optimize
/sc:build frontend --verbose
MCP servers: playwright
/sc:explain - Code ExplanationWhen to use: Need to understand how code works.
What it does:
Syntax:
/sc:explain [target] [--level basic|intermediate|advanced] [--format text|examples|interactive] [--context domain]
Examples:
/sc:explain authentication.js --level basic
/sc:explain react-hooks --level intermediate --context react
/sc:explain microservices-system --level advanced --format interactive
MCP servers: sequential, context7
/sc:document - Documentation GenerationWhen to use: Need to create documentation.
What it does:
Syntax:
/sc:document [target] [--type inline|external|api|guide] [--style brief|detailed]
Examples:
/sc:document src/auth/login.js --type inline
/sc:document src/api --type api --style detailed
/sc:document payment-module --type guide --style brief
/sc:index-repo - Repository IndexingWhen to use: Starting work with a large repository.
What it does:
PROJECT_INDEX.md (3KB instead of 58KB)Syntax:
/sc:index-repo [mode=update|quick]
Examples:
/sc:index-repo # Full indexing
/sc:index-repo mode=update # Update existing
/sc:index-repo mode=quick # Quick (without tests)
/sc:spec-panel - Expert Specification ReviewWhen to use: Need specification, API, or requirements review from "experts".
What it does: Simulates a panel discussion of renowned software engineering experts.
Expert Panel (10 personas):
| Expert | Specialization | Typical Question/Critique |
|---|---|---|
| Karl Wiegers | Requirements Engineering | "Requirement lacks measurable criteria" |
| Gojko Adzic | Specification by Example | "Can you provide Given/When/Then?" |
| Alistair Cockburn | Use Cases | "Who is the primary stakeholder?" |
| Martin Fowler | Architecture & Design | "This violates single responsibility" |
| Michael Nygard | Production Systems | "What happens when this fails?" |
| Sam Newman | Microservices | "How handle backward compatibility?" |
| Gregor Hohpe | Enterprise Integration | "What's the message exchange pattern?" |
| Lisa Crispin | Agile Testing | "How would QA validate this?" |
| Janet Gregory | Collaborative Testing | "Did whole team participate?" |
| Kelsey Hightower | Cloud Native | "How handle cloud deployment?" |
Three Operating Modes:
| Mode | What Happens |
|---|---|
--mode discussion | Experts build on each other's ideas (collaborative) |
--mode critique | Systematic review with severity and priorities |
--mode socratic | Questions for deep understanding (learning) |
Focus Areas:
| Focus | Lead Expert | Analyzes |
|---|---|---|
--focus requirements | Wiegers | Clarity, testability, acceptance criteria |
--focus architecture | Fowler | Interfaces, boundaries, patterns |
--focus testing | Crispin | Test strategy, edge cases, coverage |
--focus compliance | Wiegers + Nygard | Security, audit, regulatory |
Syntax:
/sc:spec-panel [spec|@file] [--mode discussion|critique|socratic] [--experts "name1,name2"] [--focus requirements|architecture|testing|compliance] [--iterations N]
Examples:
# API specification review
/sc:spec-panel @auth_api.spec.yml --mode critique --focus requirements,architecture
# Requirements workshop
/sc:spec-panel "user story content" --mode discussion --experts "wiegers,adzic,cockburn"
# Learning through questions
/sc:spec-panel @my_first_spec.yml --mode socratic --iterations 2
# Iterative improvement (3 rounds)
/sc:spec-panel @complex_system.spec.yml --iterations 3 --format detailed
Example output (critique mode):
KARL WIEGERS - Requirements Quality:
β CRITICAL: Requirement R-001 lacks acceptance criteria
π RECOMMENDATION: Replace "handle gracefully" with "open circuit after 5 failures"
π― PRIORITY: High
π QUALITY IMPACT: +40% testability
MARTIN FOWLER - Interface Design:
β οΈ MINOR: CircuitBreaker couples state with execution
π RECOMMENDATION: Separate CircuitBreakerState from Executor
MCP servers: sequential, context7
/sc:business-panel - Business Analysis PanelWhen to use: Need business analysis of strategy, plan, or idea.
What it does: Simulates a panel discussion of legendary business thinkers.
Expert Panel (9 personas):
| Expert | Framework | Typical Question |
|---|---|---|
| Clayton Christensen | Disruption, Jobs-to-be-Done | "What job is customer hiring this for?" |
| Michael Porter | Five Forces, Competitive Strategy | "What's your sustainable advantage?" |
| Peter Drucker | Management by Objectives | "What results are you measuring?" |
| Seth Godin | Tribe Building, Permission Marketing | "Who is your tribe? What story?" |
| Kim & Mauborgne | Blue Ocean Strategy | "Competing or creating new market?" |
| Jim Collins | Good to Great, Flywheel | "What's your hedgehog concept?" |
| Nassim Taleb | Antifragility, Black Swan | "Does this benefit from volatility?" |
| Donella Meadows | Systems Thinking | "Where are the leverage points?" |
| Jean-luc Doumont | Structured Communication | "Is the message clear and actionable?" |
Three Operating Modes:
| Mode | What Happens |
|---|---|
--mode discussion | Collaborative β experts build on each other's ideas |
--mode debate | Adversarial β experts argue, stress-test ideas |
--mode socratic | Question-driven β deep questions for understanding |
Syntax:
/sc:business-panel [content|@file] [--experts "porter,christensen"] [--mode discussion|debate|socratic] [--focus domain] [--synthesis-only]
Examples:
# Business plan analysis
/sc:business-panel @business_plan.md
# Competitive analysis
/sc:business-panel @market_analysis.md --experts "porter,christensen" --focus "competitive-analysis"
# Strategy debate (stress-test)
/sc:business-panel @strategy.md --mode debate
# Synthesis only (without detailed analysis)
/sc:business-panel @pitch_deck.md --synthesis-only
Example output (discussion mode):
PORTER: "The competitive position relies on cost leadership..."
CHRISTENSEN: "But cost leadership is vulnerable to disruption from below..."
KIM/MAUBORGNE: "Consider creating new market space instead..."
TALEB: "The real question: does this benefit from uncertainty?"
MCP servers: sequential, context7
| Document | Panel |
|---|---|
| API specification | /sc:spec-panel |
| User stories / Requirements | /sc:spec-panel |
| Architecture Decision Record | /sc:spec-panel |
| Business plan | /sc:business-panel |
| Go-to-market strategy | /sc:business-panel |
| Pitch deck | /sc:business-panel |
| PRD (Product Requirements) | Both β spec for technical, business for strategy |
/sc:git - Git OperationsWhen to use: Git operations with smart commit messages.
Syntax:
/sc:git [operation] [args] [--smart-commit] [--interactive]
Examples:
/sc:git status
/sc:git commit --smart-commit # Generates conventional commit message
/sc:git merge feature-branch --interactive
/sc:estimate - Development EstimationWhen to use: Need time/complexity estimation.
Syntax:
/sc:estimate [target] [--type time|effort|complexity] [--unit hours|days|weeks] [--breakdown]
Examples:
/sc:estimate "user authentication system" --type time --unit days --breakdown
# Database design: 2 days
# Backend API: 3 days
# Frontend UI: 2 days
# Testing: 1 day
# Total: 8 days (85% confidence)
/sc:estimate "migrate to microservices" --type complexity --breakdown
MCP servers: sequential, context7
/sc:reflect - Task ReflectionWhen to use: Need to check progress and validate work.
Syntax:
/sc:reflect [--type task|session|completion] [--analyze] [--validate]
Examples:
/sc:reflect --type task --analyze # Current approach validation
/sc:reflect --type session --validate # Session analysis
/sc:reflect --type completion # Readiness check
MCP servers: serena
VAGUE IDEA?
βββ /sc:brainstorm (clarify requirements)
β
βΌ
NEED RESEARCH?
βββ /sc:research (search the web)
β
βΌ
PRD READY?
βββ /sc:workflow (generate plan)
β
βΌ
COMPLEX DECOMPOSITION?
βββ /sc:spawn (Epic β Story β Task)
β
βΌ
NEED DESIGN?
βββ /sc:design (architecture, API, schemas)
β
βΌ
READY TO CODE?
βββ /sc:implement (write code)
β
βΌ
NEED TESTS?
βββ /sc:test (run tests)
β
βΌ
NEED BUILD?
βββ /sc:build (build project)
β
βΌ
SOMETHING BROKEN?
βββ /sc:troubleshoot (find the cause)
β
βΌ
WANT IT BETTER?
βββ /sc:improve or /sc:cleanup
β
βΌ
NEED DOCUMENTATION?
βββ /sc:document
β
βΌ
NEED REVIEW?
βββ /sc:analyze (code) or /sc:spec-panel (specs)
| Command | Purpose | Result |
|---|---|---|
/sc:spawn | Decompose large task | Task hierarchy |
/sc:task | Execute task with coordination | Finished result |
/sc:workflow | Plan implementation | Roadmap/plan |
/sc:design | Design | Diagrams, specs |
/sc:implement | Write code | Finished code |
/sc:brainstorm | Clarify requirements | Concrete specs |
| Command | Role | Writes code? |
|---|---|---|
/sc:spawn | Project Manager | β No β only breaks down into tasks |
/sc:task | Tech Lead | β οΈ Can β through delegation |
/sc:implement | Developer | β Yes β directly |
/sc:spawn β Decomposition (planner)What it does: Takes a large task and breaks it into a hierarchy of subtasks.
Result: Document/task structure, NOT code.
/sc:spawn "build e-commerce platform"
Result (structure only!):
Epic: E-commerce Platform
βββ Story: User Authentication
β βββ Task: Database schema for users
β βββ Task: Auth API endpoints
β βββ Task: Login UI
βββ Story: Product Catalog
β βββ Task: Product model
β βββ Task: Search functionality
βββ Story: Checkout
βββ Task: Cart logic
βββ Task: Payment integration
When to use: Don't know where to start, task is huge, need to break into AI-friendly parts.
/sc:task β Execution Coordination (Tech Lead)What it does: Takes a specific task and executes with MCP server and persona orchestration.
Result: Can be code, but through delegation (activates needed tools).
/sc:task create "user authentication" --strategy systematic --parallel
Workflow:
1. Activates architect persona β designs
2. Activates security persona β reviews
3. Activates backend persona β writes code (calls implement internally)
4. Activates qa persona β tests
When to use: Complex task requiring coordination across domains (security + backend + frontend simultaneously).
/sc:implement β Code Writing (Developer)What it does: Directly writes code.
Result: Finished code.
/sc:implement user login form --type component --framework react --with-tests
Result:
- src/components/LoginForm.tsx (created)
- src/components/LoginForm.test.tsx (created)
When to use: Know exactly what's needed, just need to write it.
/sc:spawn "build auth system" β Breaks into tasks
β
βββ Creates Task: "Design auth architecture"
β βββ Can execute via /sc:design
β
βββ Creates Task: "Implement auth API"
β βββ Can execute via /sc:task or /sc:implement
β
βββ Creates Task: "Build login UI"
βββ Can execute via /sc:implement
Or /sc:task can call /sc:implement internally:
/sc:task execute "auth system" --parallel
β
βββ Delegates backend β calls /sc:implement auth API
βββ Delegates frontend β calls /sc:implement login form
βββ Delegates security β calls /sc:analyze --focus security
| Situation | Command |
|---|---|
| "Want to do X, but don't know how to break it down" | /sc:spawn |
| "Need to do X, requires backend + security + tests" | /sc:task |
| "Write me component Y" | /sc:implement |
| "Need implementation plan from PRD" | /sc:workflow |
| Situation | Better |
|---|---|
| Feature spans multiple domains (API + UI + security) | /sc:task |
| Need architectural review before coding | /sc:task |
| Working in unfamiliar codebase | /sc:task |
| Critical feature (auth, payments) | /sc:task |
| Situation | Better |
|---|---|
| Single component / single function | /sc:implement |
| Know exactly what and how to do | /sc:implement |
| Simple CRUD | /sc:implement |
| Already did design/architecture | /sc:implement |
Coordination overhead β task spends tokens on "meetings":
/sc:task "add logout button"
task thinks:
1. Activate architect? β overkill for a button
2. Activate security? β logout is simple
3. Activate frontend? β ok
4. Activate qa? β for a button?
Result: spent tokens on coordination for a single button
vs
/sc:implement logout button --type component --framework react
implement:
1. Reads existing code
2. Writes button
3. Done
For complex tasks, meetings are needed. For "add a button" β no.
Task concerns 1 domain (only frontend OR only backend)?
β /sc:implement
Task concerns 2+ domains (frontend + backend + security)?
β /sc:task
Unsure about architecture?
β /sc:task (or first /sc:design)
Critical code (auth, payments, data)?
β /sc:task (extra checks don't hurt)
| Command | Question | Result |
|---|---|---|
/sc:design | WHAT to build? | Architecture, schemas, specifications |
/sc:workflow | IN WHAT ORDER to do it? | Work plan, roadmap, steps |
/sc:design β Architecture (blueprint)Answers: How is the system structured? What components? How are they connected?
/sc:design payment-system --type architecture
Result:
βββββββββββββββ βββββββββββββββ βββββββββββββββ
β Client ββββββΆβ API Gateway ββββββΆβ Payment β
β (React) β β (Express) β β Service β
βββββββββββββββ βββββββββββββββ βββββββββββββββ
β
βΌ
βββββββββββββββ
β Stripe β
β Webhook β
βββββββββββββββ
+ API contracts
+ Database schema
+ Security requirements
/sc:workflow β Work Plan (roadmap)Answers: In what order to do it? What dependencies? What's parallel?
/sc:workflow payment-system --strategy systematic
Result:
Phase 1: Foundation (Week 1)
βββ Task 1.1: Setup database schema
βββ Task 1.2: Create Payment model
βββ Task 1.3: Configure Stripe SDK
Phase 2: Backend (Week 2)
βββ Task 2.1: Implement payment endpoints β depends on 1.1, 1.2
βββ Task 2.2: Add webhook handler β depends on 1.3
βββ Task 2.3: Write unit tests
Phase 3: Frontend (Week 2-3) β can start parallel with 2.2
βββ Task 3.1: Payment form component
βββ Task 3.2: Confirmation page
Phase 4: Integration (Week 3)
βββ Task 4.1: E2E tests β depends on all above
| Stage | Command | What you get |
|---|---|---|
| House blueprint | /sc:design | Where walls go, where windows, what materials |
| Construction plan | /sc:workflow | First foundation β walls β roof β finishing |
1. /sc:brainstorm "payment system" β Requirements (WHAT we want)
β
βΌ
2. /sc:design payment-system β Architecture (HOW it's structured)
β
βΌ
3. /sc:workflow payment-system β Plan (IN WHAT ORDER)
β
βΌ
4. /sc:implement ... (following plan) β Code
| Situation | Command |
|---|---|
| "How should system X be structured?" | /sc:design |
| "In what order to implement feature Y?" | /sc:workflow |
| "Need API spec for service Z" | /sc:design --type api |
| "Break PRD into tasks with dependencies" | /sc:workflow |
| "What database schema is needed?" | /sc:design --type database |
| "How many phases in implementation?" | /sc:workflow --depth deep |
| Tool | Creates files | Where stored |
|---|---|---|
/sc:index-repo | PROJECT_INDEX.md (3KB) | Project root |
| Serena MCP | .serena/project.yml + .serena/memories/*.md | .serena/ folder in project |
.serena/
βββ project.yml # Configuration (languages, encoding, LSP settings)
βββ .gitignore # Git ignore
βββ memories/
βββ project_overview.md # About the project, tech stack
βββ suggested_commands.md # Development commands
βββ style_conventions.md # Code styles and conventions
βββ task_completion.md # Task completion checklist
| Aspect | /sc:index-repo | Serena MCP |
|---|---|---|
| Type | Static file | Live LSP server + memories |
| Main goal | Quick start (token savings) | Semantic code understanding |
| What it understands | File structure | Symbols (functions, classes, types) |
| Updates | Manual (mode=update) | Memories β manual, LSP β automatic |
| Persistence | File in project | Files in .serena/memories/ |
| LSP operations | β No | β rename, find references, go to definition |
| Cross-session | β Read file | β Memories are persistent |
| Tokens at start | ~3K (reading INDEX) | On demand (reading needed memories) |
/sc:index-repo β for quick session start:
Serena MCP β for deep code work:
find_symbol β find class/function by namefind_referencing_symbols β where symbol is usedrename_symbol β rename everywhere safely via LSPget_symbols_overview β file structure (class methods etc.)Either one is sufficient to start working:
| If you chose | What you get | Each session |
|---|---|---|
| Serena (recommended) | Memories + LSP + symbols | No need to read anything |
| index-repo | PROJECT_INDEX.md | Can read for context |
| Both | Maximum information | Optional |
# Initial setup (once)
serena activate_project . # Activate project
serena onboarding # Create memories
# and/or
/sc:index-repo # Create PROJECT_INDEX.md
# On structural changes
/sc:index-repo mode=update # Update INDEX (if using)
serena edit_memory ... # Update memories (if needed)
Important: SuperClaude commands automatically use Serena for code work.
Explicitly reading PROJECT_INDEX.md or calling serena read_memory each session is not required.
| What | Auto-updates? | How to update |
|---|---|---|
PROJECT_INDEX.md | β No | /sc:index-repo mode=update |
| Serena memories | β No | write_memory / edit_memory |
| Serena LSP understanding | β Yes | Automatically sees file changes |
| Event | index-repo | Serena memories |
|---|---|---|
| Added new module/folder | β Update | β‘ Optional |
| Renamed module | β Update | β‘ Optional |
| Fixed bug in file | β Not needed | β Not needed |
| Added dependency | β Update | β Not needed |
| Changed code conventions | β Not needed | β Update |
| Before PR/release | β‘ Good practice | β Not needed |
# Option A: Via Serena (recommended)
1. serena activate_project . # Activate project
2. serena onboarding # Create memories (project_overview, commands, etc.)
# Option B: Via index-repo
1. /sc:index-repo # Create PROJECT_INDEX.md
# Can use both β they complement each other
Important: Add Serena auto-activation instruction to project CLAUDE.md:
mcp__serena__activate_project project="."Then Claude will activate Serena automatically at the start of each session.
1. /sc:brainstorm "feature idea" # Requirements gathering
2. /sc:design feature --type api # Architecture design
3. /sc:workflow feature # Implementation plan
4. /sc:implement step1 # Step-by-step implementation
5. /sc:test --coverage # Testing
β See: /sc:brainstorm, /sc:design, /sc:workflow, /sc:implement, /sc:test
1. /sc:troubleshoot "error" --trace # Diagnosis (finds code via Serena)
2. /sc:implement fix # Fix
3. /sc:test # Verification
β See: /sc:troubleshoot, /sc:implement, /sc:test
1. /sc:analyze code --type quality # Problem analysis (uses Serena)
2. /sc:improve code --focus X # Improvement
3. /sc:cleanup --scope module # Cleanup
4. /sc:test # Verification
β See: /sc:analyze, /sc:improve, /sc:cleanup, /sc:test
1. /sc:analyze PR --type quality # Code quality
2. /sc:analyze PR --type security # Security
3. /sc:test --type integration # Integration tests
β See: /sc:analyze, /sc:test
1. /sc:brainstorm "idea" # Clarify requirements through dialogue
2. /sc:research "market + competitors" # Market research
3. /sc:business-panel @idea.md --mode discussion # Expert analysis (Porter, Christensen...)
# β Get strategic insights
4. /sc:business-panel @idea.md --mode debate # Stress-test idea (optional)
5. /sc:design system --type architecture # Technical architecture
6. /sc:spec-panel @design.md --mode critique # Specification review (Fowler, Wiegers...)
# β Get technical recommendations
β See: /sc:brainstorm, /sc:research, /sc:business-panel, /sc:design, /sc:spec-panel
1. /sc:spec-panel @spec.md --mode socratic # Questions to understand gaps
# β Experts ask: "Who is primary stakeholder?"
2. Answer questions, expand spec
3. /sc:spec-panel @spec.md --mode critique # Critical review
# β Get: β CRITICAL, β οΈ MAJOR, priorities
4. /sc:spec-panel @spec.md --iterations 2 # Iterative improvement
β See: /sc:spec-panel
1. /sc:design system --type architecture # Create architecture
2. /sc:spec-panel @architecture.md --focus architecture --experts "fowler,newman,nygard"
# β Fowler: "This violates single responsibility"
# β Newman: "How handle service evolution?"
# β Nygard: "What happens when this fails?"
3. Fix based on recommendations
4. /sc:workflow system # Implementation plan
5. /sc:implement ... # Implementation
β See: /sc:design, /sc:spec-panel, /sc:workflow, /sc:implement
1. /sc:business-panel @pitch.md --mode discussion
# β Porter: competitive advantage
# β Christensen: disruption potential
# β Godin: tribe and story
2. /sc:business-panel @pitch.md --mode debate # Stress-test arguments
3. /sc:business-panel @pitch.md --synthesis-only # Final synthesis
β See: /sc:business-panel
1. /sc:brainstorm "enterprise feature" # Requirements
2. /sc:business-panel @requirements.md # Business validation
3. /sc:design feature --type architecture # Architecture
4. /sc:spec-panel @design.md --focus architecture,testing # Technical validation
5. /sc:workflow feature --depth deep # Detailed plan
6. /sc:spawn "feature" --strategy adaptive # Decompose into tasks
7. /sc:task execute task1 --parallel # Execution with coordination
8. /sc:analyze feature --focus security # Security review
9. /sc:test --type all --coverage # Full testing
β See: /sc:brainstorm, /sc:business-panel, /sc:design, /sc:spec-panel, /sc:workflow, /sc:spawn, /sc:task, /sc:analyze, /sc:test
Note: SuperClaude commands automatically use Serena for symbol search, dependency analysis, and code structure understanding. No need to explicitly call
serena find_symboletc.
π€ For Claude Code: Technical integration details for MCP routing.
| MCP Server | Purpose | Used in |
|---|---|---|
sequential | Multi-step reasoning | pm, task, workflow, brainstorm, spec-panel |
context7 | Official docs lookup | implement, improve, explain, design |
magic | UI component generation | implement, task, workflow |
playwright | E2E testing, browser | test, build, research |
serena | Session persistence | pm, task, reflect |
tavily | Web search | research, pm |
morphllm | Large-scale transforms | task, workflow, brainstorm |
chrome-devtools | Browser debugging | pm |
π€ For Claude Code: Session start protocol and context restoration instructions.
When starting a new session:
PROJECT_INDEX.md (3K tokens)SC_COMMANDS_REFERENCE.md)src/superclaude/commands/{name}.mdsrc/superclaude/pm_agent/ and src/superclaude/execution/src/superclaude/pytest_plugin.pyKNOWLEDGE.mdTASK.mdPLANNING.md# Activate project
serena activate_project /path/to/SuperClaude_Framework
# Check memories
serena list_memories
# Read needed memory
serena read_memory project_overview.md
serena read_memory suggested_commands.md
Available memories:
project_overview.md β about the project, tech stack, architecturesuggested_commands.md β development commands (UV, pytest, make)style_conventions.md β code styles and conventionstask_completion.md β task completion checklistThis document is updated as the project evolves.