SpecOps

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

SpecOps is a lightweight OpenCode plugin for running software changes through a structured OpenSpec workflow.

Give it a goal:

/specops add a health endpoint with tests

SpecOps coordinates specialist agents to investigate the repository, define the requirements, design the solution, plan the implementation, write the code, and independently review the result.

Each role can use a different model, while OpenSpec remains the durable source of truth for the change.

Install

Install SpecOps through OpenCode:

opencode plugin @jrpbuilds/specops-opencode -g

Install the OpenSpec CLI:

npm install -g @fission-ai/openspec

Then restart OpenCode.

Check the installation:

/specops-doctor

/specops-doctor checks the installed OpenSpec CLI before trusting its JSON responses. SpecOps targets the latest OpenSpec version and probes the required read-only command capabilities with --help. Older versions whose capability probes still pass work too — only a genuine capability gap (a probe that fails) is reported as an incompatible-install state with remediation. If you upgrade the CLI later, just run /specops-doctor again.

SpecOps also validates the active change with the positional command openspec validate <change> --strict --json before planning artifacts are authored or a review can pass. Validation is scoped to the active change, so unrelated changes do not block the workflow.

Getting started

Open a project and give SpecOps a goal:

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

SpecOps automatically initialises OpenSpec on first use.

You can also initialise it explicitly:

/specops-onboard

How it works

The default spec-driven schema typically routes a change through these roles; custom schemas may declare a different artifact graph.

/specops <goal>
      │
      ▼
  Coordinator
      │
      ├── Explorer      repository investigation
      ├── Planner       proposal + specifications
      ├── Designer      technical design
      ├── Planner       implementation tasks
      ├── Implementer   source + tests
      └── Reviewer      independent verification

In the default spec-driven schema, a typical change produces normal OpenSpec artifacts:

openspec/changes/<change>/
├── proposal.md
├── specs/
├── design.md
└── tasks.md

SpecOps maintains no parallel state machine because the coordinator derives the next step from OpenSpec's own artifact graph via the specops_status tool plus task checkbox state, so custom schemas and interrupted changes resume naturally.

The plugin itself stays deliberately small:

• Models handle reasoning and orchestration.
• OpenSpec owns durable change state.
• TypeScript handles deterministic plugin operations.
• Specialist agents stay focused on their assigned role.

Internal agents

The specops-* specialist agents (specops-explorer, specops-planner, specops-designer, specops-implementer, specops-reviewer, and, when enabled, specops-frontier) are internal to the SpecOps workflow. Only the SpecOps and SpecOps Auto coordinators may dispatch them; other OpenCode agents cannot invoke them, and they are hidden from the @ autocomplete menu. They cannot themselves delegate to further subagents.

Coordinator agents have native edit tools disabled and may use the shell only for openspec --help lookups. Ordinary OpenCode primary agents can use the user-facing specops_doctor and specops_onboard tools, while OpenSpec context, change creation, and archive operations remain Coordinator-owned.

Model configuration

Open the OpenCode command palette with Ctrl+P and select:

SpecOps Configure

Models and reasoning variants can be configured independently for:

• Coordinator
• Explorer
• Planner
• Designer
• Implementer
• Reviewer
• Frontier

Configuration is stored at:

~/.config/opencode/specops.json

or the equivalent $XDG_CONFIG_HOME/opencode/specops.json.

Example:

{
    "frontierEscalation": false,
    "agents": {
        "specops-coordinator": {
            "model": "opencode-go/deepseek-v4-flash",
            "variant": "high"
        },
        "specops-explorer": {
            "model": "openference/Qwen3.7 Plus",
            "variant": "medium"
        },
        "specops-planner": {
            "model": "openai/gpt-5.6-terra",
            "variant": "high"
        },
        "specops-designer": {
            "model": "openference/GLM-5.2",
            "variant": "max"
        },
        "specops-implementer": {
            "model": "openference/Kimi K2.7 Code",
            "variant": "thinking"
        },
        "specops-reviewer": {
            "model": "openference/DeepSeek-V4-Pro",
            "variant": "high"
        },
        "specops-frontier": {
            "model": "openai/gpt-5.6-sol",
            "variant": "high"
        }
    }
}

Leave a role unset to inherit OpenCode's default model.

frontierEscalation controls whether the Frontier agent is registered. Changing it requires restarting OpenCode.

Commands

/specops <goal>

Starts or resumes a SpecOps change.

/specops stop the background animation when the game is over

/specops-auto <goal>

Runs the workflow autonomously without human checkpoints and finishes with a terminal COMPLETED or BLOCKED report.

Useful for headless runs:

opencode run --auto --command specops-auto "<goal>"

/specops-update <revision>

Revises an active change in place from a goal:

/specops-update <revision>

The workflow resumes the active change, determines the owning artifact, dispatches the owning specialist with feedback verbatim, reconciles the revision, and re-presents the plan checkpoint if the effective plan changed. (issue #11)

/specops-sync

Synchronizes an active change's delta specs into the main specs without archiving it. Use it when a parallel change needs to build on newly defined specs, or when you want to review the merged main spec before archive. Archive remains the right path once the change is finished and ready to be finalized.

/specops-onboard

Initialises OpenSpec in the current project.

/specops-doctor

Checks the SpecOps installation, OpenSpec availability, project state, configuration, and configured models.

Engram (optional)

SpecOps works without Engram.

For cross-session project memory, you can optionally use the Engram MCP server. SpecOps agents may use it for historical architectural decisions, conventions, previous discoveries, and project-specific context.

Engram is contextual memory only. Current user instructions, OpenSpec artifacts, repository state, and executed evidence always take precedence.

Install Engram using its installation guide, then follow its OpenCode setup.

Example

• Galaxy Shooter — a browser arcade game generated through the SpecOps workflow.

Development

bun install
bun run check

Build the plugin with:

bun run build

SpecOps uses Bun and TypeScript throughout.

Status

SpecOps v1.0.0 is released and being dogfooded against real software changes. The v1.0.0 milestone delivers schema-aware planning specialists, status-routed coordinator orchestration, and the specops_status lifecycle tool. Post-1.0 work is tracked in the issue tracker.

Make structured multi-model software development useful without building another workflow engine.

Community

• Contributing
• Security
• Code of conduct

License

MIT — built by @jrpbuilds.