specops-cc

SPECOPS

A meta-prompting, context engineering and spec-driven development system for Claude Code and OpenCode.

Solves context rot — the quality degradation that happens as Claude fills its context window.

npx specops-cc

Works on Mac, Windows, and Linux.

How It Works · Commands · Why It Works · Getting Started

What is SpecOps?

SpecOps is a context engineering layer that makes Claude Code reliable for real projects.

Vibecoding has a bad reputation — you describe what you want, AI generates code, and you get inconsistent garbage that falls apart at scale. SpecOps fixes that by giving Claude everything it needs: structured context, phased execution, fresh subagent windows, and automated verification.

Describe your idea, let the system extract everything it needs to know, and let Claude Code get to work.

— Hardik Desai

Who This Is For

Developers who want to describe what they want and have it built correctly — without the overhead of enterprise project management tools.

Getting Started

npx specops-cc

The installer prompts you to choose:

• Runtime — Claude Code, OpenCode, or both
• Location — Global (all projects) or local (current project only)

Verify with /so:help inside your Claude Code or OpenCode interface.

Staying Updated

SpecOps evolves fast. Check for updates periodically:

/so:whats-new

Update with:

npx specops-cc@latest

Non-interactive Install (Docker, CI, Scripts)

# Claude Code
npx specops-cc --claude --global   # Install to ~/.claude/
npx specops-cc --claude --local    # Install to ./.claude/

# OpenCode (open source, free models)
npx specops-cc --opencode --global # Install to ~/.opencode/

# Both runtimes
npx specops-cc --both --global     # Install to both directories

Use --global (-g) or --local (-l) to skip the location prompt. Use --claude, --opencode, or --both to skip the runtime prompt.

Development Installation

Clone the repository and run the installer locally:

git clone https://github.com/hardik874/specops.git
cd specops
node bin/install.js --claude --local

Installs to ./.claude/ for testing modifications before contributing.

Recommended: Skip Permissions Mode

SpecOps is designed for frictionless automation. Run Claude Code with:

claude --dangerously-skip-permissions

[!TIP] This is how SpecOps is intended to be used — stopping to approve date and git commit 50 times defeats the purpose.

Alternative: Granular Permissions

If you prefer not to use that flag, add this to your project's .claude/settings.json:

{
  "permissions": {
    "allow": [
      "Bash(date:*)",
      "Bash(echo:*)",
      "Bash(cat:*)",
      "Bash(ls:*)",
      "Bash(mkdir:*)",
      "Bash(wc:*)",
      "Bash(head:*)",
      "Bash(tail:*)",
      "Bash(sort:*)",
      "Bash(grep:*)",
      "Bash(tr:*)",
      "Bash(git add:*)",
      "Bash(git commit:*)",
      "Bash(git status:*)",
      "Bash(git log:*)",
      "Bash(git diff:*)",
      "Bash(git tag:*)"
    ]
  }
}

How It Works

Already have code? Run /so:map-codebase first. It spawns parallel agents to analyze your stack, architecture, conventions, and concerns. Then /so:new-project knows your codebase — questions focus on what you're adding, and planning automatically loads your patterns.

1. Initialize Project

/so:new-project

One command, one flow. The system:

• Questions — Asks until it understands your idea completely (goals, constraints, tech preferences, edge cases)
• Research — Spawns parallel agents to investigate the domain (optional but recommended)
• Requirements — Extracts what's v1, v2, and out of scope
• Roadmap — Creates phases mapped to requirements

You approve the roadmap. Now you're ready to build.

Creates: PROJECT.md, REQUIREMENTS.md, ROADMAP.md, STATE.md, .planning/research/

2. Discuss Phase

/so:discuss-phase 1

This is where you shape the implementation.

Your roadmap has a sentence or two per phase. That's not enough context to build something the way you imagine it. This step captures your preferences before anything gets researched or planned.

The system analyzes the phase and identifies gray areas based on what's being built:

• Visual features → Layout, density, interactions, empty states
• APIs/CLIs → Response format, flags, error handling, verbosity
• Content systems → Structure, tone, depth, flow
• Organization tasks → Grouping criteria, naming, duplicates, exceptions

For each area you select, it asks until you're satisfied. The output — CONTEXT.md — feeds directly into the next two steps:

• Researcher reads it — Knows what patterns to investigate ("user wants card layout" → research card component libraries)
• Planner reads it — Knows what decisions are locked ("infinite scroll decided" → plan includes scroll handling)

The deeper you go here, the more the system builds what you actually want. Skip it and you get reasonable defaults. Use it and you get your vision.

Creates: {phase}-CONTEXT.md

3. Plan Phase

/so:plan-phase 1

The system:

• Researches — Investigates how to implement this phase, guided by your CONTEXT.md decisions
• Plans — Creates 2-3 atomic task plans with XML structure
• Verifies — Checks plans against requirements, loops until they pass

Each plan is small enough to execute in a fresh context window. No degradation, no "I'll be more concise now."

Creates: {phase}-RESEARCH.md, {phase}-{N}-PLAN.md

4. Execute Phase

/so:execute-phase 1

The system:

• Runs plans in waves — Parallel where possible, sequential when dependent
• Fresh context per plan — 200k tokens purely for implementation, zero accumulated garbage
• Commits per task — Every task gets its own atomic commit
• Verifies against goals — Checks the codebase delivers what the phase promised

Walk away, come back to completed work with clean git history.

Creates: {phase}-{N}-SUMMARY.md, {phase}-VERIFICATION.md

5. Verify Work

/so:verify-work 1

This is where you confirm it actually works.

Automated verification checks that code exists and tests pass. But does the feature work the way you expected? This is your chance to use it.

The system:

• Extracts testable deliverables — What you should be able to do now
• Walks you through one at a time — "Can you log in with email?" Yes/no, or describe what's wrong
• Diagnoses failures automatically — Spawns debug agents to find root causes
• Creates verified fix plans — Ready for immediate re-execution

If everything passes, you move on. If something's broken, you don't manually debug — you just run /so:execute-phase again with the fix plans it created.

Creates: {phase}-UAT.md, fix plans if issues found

6. Repeat → Complete → Next Milestone

/so:discuss-phase 2
/so:plan-phase 2
/so:execute-phase 2
/so:verify-work 2
...
/so:complete-milestone
/so:new-milestone

Loop discuss → plan → execute → verify until milestone complete.

Each phase gets your input (discuss), proper research (plan), clean execution (execute), and human verification (verify). Context stays fresh. Quality stays high.

When all phases are done, /so:complete-milestone archives the milestone and tags the release.

Then /so:new-milestone starts the next version — same flow as new-project but for your existing codebase. You describe what you want to build next, the system researches the domain, you scope requirements, and it creates a fresh roadmap. Each milestone is a clean cycle: define → build → ship.

Quick Mode

/so:quick

For ad-hoc tasks that don't need full planning.

Quick mode gives you SpecOps guarantees (atomic commits, state tracking) with a faster path:

• Same agents — Planner + executor, same quality
• Skips optional steps — No research, no plan checker, no verifier
• Separate tracking — Lives in .planning/quick/, not phases

Use for: bug fixes, small features, config changes, one-off tasks.

/so:quick
> What do you want to do? "Add dark mode toggle to settings"

Creates: .planning/quick/001-add-dark-mode-toggle/PLAN.md, SUMMARY.md

Why It Works

Context Engineering

Claude Code is incredibly powerful if you give it the context it needs. Most people don't.

SpecOps handles it for you:

File	What it does
PROJECT.md	Project vision, always loaded
research/	Ecosystem knowledge (stack, features, architecture, pitfalls)
REQUIREMENTS.md	Scoped v1/v2 requirements with phase traceability
ROADMAP.md	Where you're going, what's done
STATE.md	Decisions, blockers, position — memory across sessions
PLAN.md	Atomic task with XML structure, verification steps
SUMMARY.md	What happened, what changed, committed to history
todos/	Captured ideas and tasks for later work

Size limits based on where Claude's quality degrades. Stay under, get consistent excellence.

XML Prompt Formatting

Every plan is structured XML optimized for Claude:

<task type="auto">
  <name>Create login endpoint</name>
  <files>src/app/api/auth/login/route.ts</files>
  <action>
    Use jose for JWT (not jsonwebtoken - CommonJS issues).
    Validate credentials against users table.
    Return httpOnly cookie on success.
  </action>
  <verify>curl -X POST localhost:3000/api/auth/login returns 200 + Set-Cookie</verify>
  <done>Valid credentials return cookie, invalid return 401</done>
</task>

Precise instructions. No guessing. Verification built in.

Multi-Agent Orchestration

Every stage uses the same pattern: a thin orchestrator spawns specialized agents, collects results, and routes to the next step.

Stage	Orchestrator does	Agents do
Research	Coordinates, presents findings	4 parallel researchers investigate stack, features, architecture, pitfalls
Planning	Validates, manages iteration	Planner creates plans, checker verifies, loop until pass
Execution	Groups into waves, tracks progress	Executors implement in parallel, each with fresh 200k context
Verification	Presents results, routes next	Verifier checks codebase against goals, debuggers diagnose failures

The orchestrator never does heavy lifting. It spawns agents, waits, integrates results.

The result: You can run an entire phase — deep research, multiple plans created and verified, thousands of lines of code written across parallel executors, automated verification against goals — and your main context window stays at 30-40%. The work happens in fresh subagent contexts. Your session stays fast and responsive.

Atomic Git Commits

Each task gets its own commit immediately after completion:

abc123f docs(08-02): complete user registration plan
def456g feat(08-02): add email confirmation flow
hij789k feat(08-02): implement password hashing
lmn012o feat(08-02): create registration endpoint

[!NOTE] Benefits: Git bisect finds exact failing task. Each task independently revertable. Clear history for Claude in future sessions. Better observability in AI-automated workflow.

Every commit is surgical, traceable, and meaningful.

Modular by Design

• Add phases to current milestone
• Insert urgent work between phases
• Complete milestones and start fresh
• Adjust plans without rebuilding everything

You're never locked in. The system adapts.

Commands

Core Workflow

Command	What it does
/so:new-project	Full initialization: questions → research → requirements → roadmap
/so:discuss-phase [N]	Capture implementation decisions before planning
/so:plan-phase [N]	Research + plan + verify for a phase
/so:execute-phase <N>	Execute all plans in parallel waves, verify when complete
/so:verify-work [N]	Manual user acceptance testing
/so:audit-milestone	Verify milestone achieved its definition of done
/so:complete-milestone	Archive milestone, tag release
/so:new-milestone [name]	Start next version: questions → research → requirements → roadmap

Navigation

Command	What it does
/so:progress	Where am I? What's next?
/so:help	Show all commands and usage guide
/so:whats-new	See what changed since your installed version
/so:update	Update SpecOps with changelog preview

Brownfield

Command	What it does
/so:map-codebase	Analyze existing codebase before new-project

Phase Management

Command	What it does
/so:add-phase	Append phase to roadmap
/so:insert-phase [N]	Insert urgent work between phases
/so:remove-phase [N]	Remove future phase, renumber
/so:list-phase-assumptions [N]	See Claude's intended approach before planning
/so:plan-milestone-gaps	Create phases to close gaps from audit

Session

Command	What it does
/so:pause-work	Create handoff when stopping mid-phase
/so:resume-work	Restore from last session

Utilities

Command	What it does
/so:settings	Configure model profile and workflow agents
/so:set-profile <profile>	Switch model profile (quality/balanced/budget)
/so:add-todo [desc]	Capture idea for later
/so:check-todos	List pending todos
/so:debug [desc]	Systematic debugging with persistent state
/so:quick	Execute ad-hoc task with SpecOps guarantees

Configuration

SpecOps stores project settings in .planning/config.json. Configure during /so:new-project or update later with /so:settings.

Core Settings

Setting	Options	Default	What it controls
mode	yolo, interactive	interactive	Auto-approve vs confirm at each step
depth	quick, standard, comprehensive	standard	Planning thoroughness (phases × plans)

Model Profiles

Control which Claude model each agent uses. Balance quality vs token spend.

Profile	Planning	Execution	Verification
quality	Opus	Opus	Sonnet
balanced (default)	Opus	Sonnet	Sonnet
budget	Sonnet	Sonnet	Haiku

Switch profiles:

/so:set-profile budget

Or configure via /so:settings.

Workflow Agents

These spawn additional agents during planning/execution. They improve quality but add tokens and time.

Setting	Default	What it does
workflow.research	true	Researches domain before planning each phase
workflow.plan_check	true	Verifies plans achieve phase goals before execution
workflow.verifier	true	Confirms must-haves were delivered after execution

Use /so:settings to toggle these, or override per-invocation:

• /so:plan-phase --skip-research
• /so:plan-phase --skip-verify

Execution

Setting	Default	What it controls
parallelization.enabled	true	Run independent plans simultaneously
planning.commit_docs	true	Track .planning/ in git

Troubleshooting

Commands not found after install?

• Restart Claude Code to reload slash commands
• Verify files exist in ~/.claude/commands/so/ (global) or ./.claude/commands/so/ (local)

Commands not working as expected?

• Run /so:help to verify installation
• Re-run npx specops-cc to reinstall

Updating to the latest version?

npx specops-cc@latest

Using Docker or containerized environments?

If file reads fail with tilde paths (~/.claude/...), set CLAUDE_CONFIG_DIR before installing:

CLAUDE_CONFIG_DIR=/home/youruser/.claude npx specops-cc --global

This ensures absolute paths are used instead of ~ which may not expand correctly in containers.

Uninstalling

To remove SpecOps completely:

# Global installs
npx specops-cc --claude --global --uninstall
npx specops-cc --opencode --global --uninstall

# Local installs (current project)
npx specops-cc --claude --local --uninstall
npx specops-cc --opencode --local --uninstall

This removes all SpecOps commands, agents, hooks, and settings while preserving your other configurations.

License

MIT License. See LICENSE for details.

Claude Code is powerful. SpecOps makes it reliable.