Spec-driven development for OpenCode, with the right model for each job.

SpecOps is a lightweight OpenCode plugin that runs software changes through a structured OpenSpec workflow.

You give it a goal:

/specops add a health endpoint with tests

Specialist agents then investigate the repository, work out the requirements, design the solution, plan the implementation, and write the code. Before anything gets archived, the finished work goes through three independent reviews. Each role can run on its own model, and OpenSpec keeps the whole change on disk as the source of truth.

Documentation

Getting started	Install, first run, and your first completed change
How it works	The pipeline, the roles, Standard vs Auto
Configuration	The Configure screen and specops.json reference
Model recommendations	Which model classes suit which roles
Commands	Every command explained
Troubleshooting	Doctor output, BLOCKED runs, common fixes

Install

Install SpecOps through OpenCode:

opencode plugin @jrpbuilds/specops-opencode -g

Install the OpenSpec CLI:

npm install -g @fission-ai/openspec

Then restart OpenCode and check everything with:

/specops-doctor

Getting started

Open a project and give SpecOps a goal:

/specops improve the API error responses and add coverage for the new behaviour

SpecOps initialises OpenSpec on first use, so there's nothing to set up by hand (or run /specops-onboard yourself if you prefer).

You approve the plan before implementation starts, and you decide what happens after review. If you want a run with no checkpoints at all, that's /specops-auto.

How it works

The coordinator routes your change through specialist agents, then has the finished work reviewed from three independent perspectives before a final verdict:

flowchart TD
    A[PLAN] --> B[IMPLEMENT]
    B --> C1[review-correctness]
    B --> C2[review-risk]
    B --> C3[review-quality]
    C1 --> D[specops-reviewer<br/>FINAL AUTHORITY]
    C2 --> D
    C3 --> D
    D --> E{PASS / FAIL}
    E -->|PASS| F[Lifecycle]
    E -->|FAIL| G[Find earliest incorrect layer]
    G --> H[Planning]
    G --> I[Implementation]
    H --> J[Planner / Designer]
    I --> K[Implementer]
    J --> L[IMPLEMENT]
    K --> L
    L --> C1
    L --> C2
    L --> C3

Loading

When the Reviewer fails the work, the coordinator finds the earliest incorrect layer (implementation, design, or requirements), gets it corrected there, and runs the whole review pipeline again. How it works covers the details.

SpecOps keeps no state of its own: everything lives in OpenSpec artifacts under openspec/changes/<change>/. That's why custom schemas work, and why an interrupted change picks up where it left off.

The specialist agents (specops-explorer, specops-planner, specops-designer, specops-implementer, specops-reviewer, the three review specialists, and optionally specops-frontier) are internal to SpecOps. Only its coordinators can dispatch them, they don't show up in OpenCode's @ menu, and the coordinators themselves never edit files.

Model configuration

Open the command palette (Ctrl+P), choose SpecOps Configure, and map any of the ten roles — coordinator, explorer, planner, designer, implementer, reviewer, three review specialists, and frontier — to their own model and reasoning variant.

Configuration lives at ~/.config/opencode/specops.json and looks like this:

{
    "frontierEscalation": false,
    "maxSubagentConcurrency": 1,
    "maxAutoReviewIterations": 3,
    "agents": {
        "specops-coordinator": { "model": "opencode-go/deepseek-v4-flash", "variant": "high" },
        "specops-planner": { "model": "openai/gpt-5.6-terra", "variant": "high" },
        "specops-reviewer": { "model": "openference/DeepSeek-V4-Pro", "variant": "high" }
    }
}

Any role you leave out inherits OpenCode's default model. Review specialists without their own entry inherit the Reviewer's. Specialists run one at a time by default; raise maxSubagentConcurrency (Configure offers 1–8) to parallelise planning routes and the review fan-out. Auto's correction budget defaults to 3 cycles, and both settings accept larger finite values if you set them directly in the file. For the best parallel experience, launch OpenCode with OPENCODE_EXPERIMENTAL_BACKGROUND_SUBAGENTS=true so a new specialist starts the moment one finishes.

For the full specops.json with all ten roles mapped, see Configuration. For advice on which models go where, see Model recommendations.

Commands

Command	Purpose
/specops <goal>	Start or resume a change in Standard mode
/specops-auto <goal>	Fully autonomous run ending in COMPLETED or BLOCKED
/specops-update <feedback>	Revise the active change in place
/specops-sync [<change>]	Merge an active change's delta specs into main specs without archiving
/specops-onboard	Initialise OpenSpec in the current project
/specops-doctor	Diagnose installation, OpenSpec, configuration, and models

Headless example: opencode run --auto --command specops-auto "<goal>". Details in Commands.

Engram (optional)

SpecOps works fine without Engram. If you want agents to remember decisions and conventions across sessions, you can run the Engram MCP server alongside it.

Engram is contextual memory only. What's in front of the agents always wins: your current instructions, the OpenSpec artifacts, the state of the repository, and evidence from commands that actually ran. See Engram's installation guide and OpenCode setup.

Development

bun install
bun run check

bun run build builds the plugin. SpecOps uses Bun and TypeScript throughout.

Status

SpecOps is actively developed, and I dogfood it on real software changes. Roadmap and open work live in the issue tracker.

The idea behind the project: make structured multi-model software development useful without building another workflow engine.

Community

• Contributing
• Security
• Code of conduct

License

MIT — built by @jrpbuilds.