Introduction

When working with AI coding tools like DSH, the most common approach is to throw requirements directly at an AI and have it write from start to finish. It’s quick to get started, but the flaws are obvious: the process is invisible, and correctness depends entirely on manual post-checking; if something goes wrong at one step and you want to revert, you can only sift through chat history; switching sessions breaks progress.

OpenSpec (Fission-AI/OpenSpec, openspec.sh) solves the first half: writing specifications before code, organizing requirements into proposals, designs, tasks, and specs. But what happens after the specs are written? Implementation, verification, review, and merging still require the user to oversee the AI step-by-step. openspec-agents fills this gap: it orchestrates the implementation and quality control of OpenSpec changes into a fixed process, entrusted to a group of clearly defined agents.

What is This

openspec-agents is a workflow plugin created by ifrankwang, licensed under MIT, with the npm package name @ifrankwang/openspec-agents and current version 0.133.1. Built on OpenSpec, it focuses on completing the implementation and quality control aspects of OpenSpec changes.

One-sentence positioning: enabling multiple AI agents to collaborate according to the specification workflow, turning OpenSpec change specifications into high-quality, reviewed code.

The plugin supports native integration with multiple AI coding tools: Claude Code, Codex, ZCode, DeepSeek Harness (DSH), and OpenCode. The following introduction uses DSH as an example.

Core Capabilities

Spec-Driven and Agent Division of Labor

The plugin directly consumes OpenSpec change specifications within the project: proposal (change description), design, tasks (task list), and specs (acceptance criteria). The process corresponds one-to-one with these specifications.

During execution, instead of a single AI writing from start to finish, a main agent handles scheduling, while specialized agents collaborate in a division of labor—the implementer writes code, the reviewer performs checks, and the quality gatekeeper conducts multi-dimensional verification.

Quality Gates and Task Verification

After implementation is complete, it must pass three checks in sequence: tool checks, task verification, and multi-dimensional quality review. If issues are found, the system automatically reverts to the implementation phase for fixes; issues that comply with rules may also be exempted, and these exemptions are recorded.

Task verification is a mandatory gate: when the review conclusion is submitted as passed, every declared task must be confirmed item-by-item, ensuring verified_tasks are fully covered. If this blocks progress, the reviewer can submit confirmation results to clear the block.

In simple mode, verification is filtered by nature: deterministic checks are performed and declared by the developer, while the reviewer performs tiered re-verification, focusing their energy on adversarial judgment.

Isolated Execution and Audit Trail

Each change is implemented in an isolated environment, preventing interference; upon completion, the environment is merged and cleaned up.

The entire process is auditable and recoverable: progress, conclusions, exemptions, and recovery points are recorded throughout; after an interruption, work can continue from the last progress. Tasks that require manual execution or cannot be verified by the environment are reported via blocker. After the user confirms and leaves a trace (blocker_updates), completion is declared based on the records. The recovery parameter reset_steps validates its value range according to the workflow mode (full / simple) before taking effect.

Independent Review Session

Besides the orchestration workflow bound to OpenSpec changes, the plugin also supports independent code review not bound to any specific changes: performing a complete review on the PR change interval (review_scope=pr) or the entire codebase (review_scope=full). review_scope is mutually exclusive with change_id / task_group_id; you must choose one.

When initializing, you can configure granularity and fix strategy:
1. Granularity: thorough (divided into three layers, the second layer is regression verification) or simple (a single reviewer completes all checks);
2. Fix Strategy: fix (automatically fixes issues found and re-reviews) or none (review only, no fixes).

For thorough regression verification, builds must pass and existing tests must not introduce new failures. If a service can be started, smoke and existing API tests are also performed.

Review is conducted within an independent worktree. In fix mode, after all checks pass, the working branch is merged back to the target branch and the environment is cleaned up. In none mode, no merge occurs, and the working environment is destroyed directly.

Installation and Activation

The environment requires two things: Node.js ≥ 23.6 (or Bun) and git.

DSH’s philosophy is “everything is a plugin”; adding openspec-agents requires only one command:

dsh plugin --profile web add @ifrankwang/openspec-agents

After installation, simply restart dsh web to finish.

Typical Usage

One-Sentence Integration

After installation (or even before installing), simply send this prompt to DSH:

请帮我安装并启用 openspec-agents 插件，然后基于当前项目的 OpenSpec 变更规范，执行完整的变更实施编排流程。

English version:

Please install and enable the openspec-agents plugin for my current AI coding tool, then run the OpenSpec change orchestration workflow on this repository.

If the plugin is already installed, saying “Please run the openspec-agents orchestration workflow” is enough to get started. Installation, initialization, task assignment, and quality control are all handled by the AI.

Initiating Independent Review

Initiating an independent review requires specifying three things during initialization:
1. Review Scope: review_scope is set to pr (the change interval between two local branches) or full (the entire codebase), and is mutually exclusive with change_id / task_group_id;
2. Granularity: thorough or simple;
3. Fix Strategy: fix or none.

The tool derives a session ID based on the review scope and informs you of it in the return result; subsequent steps use this session ID.

Applicable Scenarios and Notes

First, the cost: this orchestration workflow is slower than having a single AI modify directly, and it consumes more API credits. However, it provides a stable, reproducible, and auditable implementation process—every step has a gate, allowing for rollback if issues arise and recovery if interrupted.

Therefore, it is suitable for teams and projects that require high code quality and process controllability. If the task is just a small job changing a few lines of code, letting the AI modify directly might be more convenient.

A security reminder: the plugin runs with the permissions of the current DSH process; it is recommended to check the source code and license before installing. The source code for openspec-agents is public on GitHub under the MIT license; confirm it is correct before installing.

Conclusion

In summary: OpenSpec is responsible for turning requirements into specifications, while openspec-agents is responsible for turning those specifications into code that has passed gate reviews and has a full audit trail, eliminating the need for manual process monitoring. If your team is already using OpenSpec to manage changes, it is worth adding it to your toolchain.