Evidence-backed repository context before planning begins.
One goal in.
A reviewed change out.
$
opencode plugin @jrpbuilds/specops-opencode -gThe pipeline
A disciplined route through non-deterministic work.
The coordinator orchestrates. Specialist agents do the work. OpenSpec artifacts decide what exists, what is complete, and what comes next, so interrupted changes resume from durable state instead of model memory.
Proposal, specifications and tasks from the active schema.
Technical design when the schema declares one.
Source code, tests and task completion by the implementer.
Correctness, risk and quality critics run independently.
One final reviewer owns PASS or FAIL and lifecycle handoff.
Schema-driven: custom OpenSpec artifact graphs are routed as declared, not forced into a hardcoded checklist.Strict validation: OpenSpec validation gates planning and review.
The gauntlet
Three critics. One authority. No committee theatre.
The review specialists do not vote. Each produces an isolated critique, and the final reviewer receives all three reports as evidence before making the only PASS or FAIL decision.
Correctness
Does the implementation actually satisfy the requirements? Are edge cases, tests, behaviour and evidence aligned with the intended change?
Risk
What could break, leak, regress or surprise production? This pass looks for operational, security and change-surface risk.
Quality
Is the result maintainable, coherent and appropriately simple? Good code should survive the change after the change.
FAIL goes to the earliest incorrect layer.
Source problem? Back to implementation. Design flaw? Fix the design first. Requirement problem? Repair planning before touching downstream work. Then the complete review gauntlet runs again.
Control surface
Different models where they matter. Boring machinery underneath.
SpecOps is deliberately small around the models. The plugin routes work, enforces boundaries and reads durable state; it does not try to become a second project-management system inside your repository.
Map the right model to the right job.
Coordinator, explorer, planner, designer, implementer, final reviewer, three review specialists and optional frontier escalation can all use different models and reasoning variants.
OpenSpec is the source of truth.
Artifacts and task checkboxes live under the change itself. Resume a run and SpecOps re-reads the real state instead of reconstructing it from chat history.
Concurrency without chaos.
Planning routes and the review fan-out can run concurrently up to your configured subagent limit while the coordinator keeps lifecycle ownership.
Auto can correct itself, finitely.
Autonomous runs can remediate review failures and re-run the full gauntlet within a configured correction budget, then stop BLOCKED rather than looping forever.
Keep expensive models in reserve.
Optional Frontier escalation lets normal routes stay economical while a stronger model is available for blockers the regular path cannot resolve.
Orchestration is not implementation.
Internal specialists are hidden from normal dispatch, coordinators do not edit files, and review agents are isolated from mutating the work they are judging.
Two operating modes
Keep the checkpoints. Or hand over the keys.
Standard and Auto use the same underlying pipeline. The difference is lifecycle policy: whether decisions and checkpoints come back to you or are handled autonomously inside explicit bounds.
Standard
You remain in the loop at the meaningful boundaries.
- Approve planning before implementation begins.
- Answer specialist decisions as native questions.
- Choose what happens after PASS or FAIL.
- Resume naturally from the same OpenSpec change.
Auto
The same gauntlet, with bounded autonomous lifecycle decisions.
- Auto-approves completed planning.
- Chooses defensible specialist options itself.
- Corrects and re-reviews within the configured budget.
- Ends explicitly as COMPLETED or BLOCKED.
Command deck
Small interface. Serious workflow.
Start, automate, revise, sync, onboard or diagnose. The surface area stays compact so the workflow is easy to reach without teaching OpenCode a second language.
/specops <goal>Start or resume a change in Standard mode./specops-auto <goal>Run autonomously to a terminal COMPLETED or BLOCKED result./specops-update <feedback>Revise the active change in place./specops-sync [<change>]Merge delta specs into the main specs without archiving the change./specops-onboardInitialise OpenSpec in the current project./specops-doctorDiagnose installation, OpenSpec, configuration and model availability.Make the models specialise.
Make the process answerable.
SpecOps is actively developed and dogfooded against real software changes. It is open source, MIT licensed, and intentionally focused on one job: making structured multi-model development useful without building another workflow engine.