Use OpenSpec to Separate Coding, Review, and Verification

fluentdb-dev — Mon, 24 Aug 2026 05:42:18 +0000

ithyno combines a desktop app or VS Code extension with OpenSpec Skills and ithyno Skills. OpenSpec Skills define the change. ithyno Skills assign implementation, review, and verification to separate AI sessions. The app visualizes their progress.

When one coding session is no longer enough

This article is for developers who use coding agents for real feature work. It is not about autocomplete or one-off questions. It focuses on work that no longer fits in one agent session.

You may recognize some of these situations:

The agent starts coding before the expected behavior is clear.
Requirements are scattered across chat history.
The same session writes the code and approves its own work.
A second session reviews the wrong branch or an old diff.
Active changes become a collection of terminals and mental notes.
A process exits, but you do not know if the requested work is complete.

You may want one session to implement a change. Another session can review it. A third session can verify it. These sessions can use the same tool and model. They can also use different ones. The important distinction is the role, not the vendor.

I built ithyno for this workflow.

Start with an agreed specification

Before choosing an agent, first decide what should change.

This is the idea behind spec-driven development.

A chat prompt should not be the only source of requirements. Spec-driven development records the expected behavior before coding starts. The specification becomes a shared agreement. The developer and every agent role can read it.

That changes the workflow from:

prompt → code → hope that the result matches the intent

to:

agree on behavior → plan the change → implement → review → verify

The goal is not documentation for its own sake. The goal is to preserve the original intent. Implementation details should not replace requirements. Agents should not silently add new scope.

What OpenSpec provides

OpenSpec is a lightweight framework for spec-driven development. It is designed for AI coding assistants. The developer and the assistant agree on the change before coding starts.

OpenSpec keeps the current system behavior and proposed changes as files in the repository.

openspec/specs/ describes the current agreed behavior.
openspec/changes/<change-id>/ contains one proposed change.
A change can include a proposal, spec updates, design notes, and tasks.
Completed changes can be archived into the living specifications.

The main files of a change are easy to inspect:

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

proposal.md explains why the change is needed. tasks.md tracks the work. The specs/ directory records the behavior added or changed. design.md is used when implementation decisions need a separate explanation.

These artifacts are ordinary project files. They are not tied to one chat session. A later session can read the same intent. It does not need to rebuild the context from chat history.

For a closer look at how these files map to the project workflow, see OpenSpec and the ithyno Kanban model.

Turn one OpenSpec change into role-based work

OpenSpec defines the change. ithyno gives that change to separate roles.

OpenSpec change
    │
    ├── code role   → implement the tasks
    ├── review role → compare the result with the proposal and specs
    └── verify role → run the applicable project checks

Each role receives the same change. Each role has a different responsibility.

Code

The code worker reads the proposal, spec changes, and tasks. It implements the requested behavior. It also updates task progress.

Review

The review worker does not continue implementation. It compares the result with the agreed scope. It records whether the change passes or needs rework.

Verify

The verify worker runs the checks that apply to the project. It then records the result. A missing optional script is different from a failed required test. The role evaluates the available evidence. It does not blindly run a fixed command list.

Implementation, review, and verification require different judgments. One long session carries its implementation assumptions into the review. Separate roles reduce that problem.

Assign multiple agents

“Multiple agents” can sound like a mix of competing products. Role-based execution does not require that mix.

All of the following are valid arrangements:

Claude Sonnet for code and Claude Fable for review.
Codex GPT-5.6-Sol for code and GPT-5.6-Terra for review.
AGY calling Claude Sonnet 4.6 for code and Gemini 3.1 Pro for review.
Claude Sonnet for code and Codex GPT-5.6-Terra for review.

The same model can also handle both roles when code and review run in separate sessions. Model names and availability may change as each CLI evolves.

An agent entry defines a worker and its responsibility. A project can reuse the same CLI and model. It can also mix them. ithyno selects a supported route for the chosen Manager and worker.

The current setup guide documents role configuration and verified routes: Configure role-based agent workers.

Dispatch the roles in sequence

A Manager coordinates the change through its required stages.

proposed → code → review → verify → merge and archive

The app creates the dispatch command for the selected Manager. It can enter the command into the terminal it started. You can also copy the command and paste it into that terminal yourself.

The Manager CLI then invokes the installed ithyno dispatch Skill. The command format depends on the CLI. A slash-command client and a skill-name client may use these forms:

/ithy-opsx:dispatch add-session-timeout
ithy-opsx-dispatch add-session-timeout

The stages of one change stay in order. Review starts after the implementation it needs to inspect. Verification does not replace review. Different changes can run at the same time when isolated execution is enabled.

Each active change can use its own Git worktree and branch. This keeps uncommitted files separate. The developer can still inspect every result with normal Git commands.

Worktrees are optional. They are not required to start using ithyno. See OpenSpec worktrees for details.

Completion must leave evidence

Agent CLIs report success in different ways. A worker may exit with code 0 without producing the requested result.

ithyno does not rely only on terminal output or process status. Review and verification roles write structured results into the change. The Manager reads those results. It then continues, requests rework, or stops.

A review worker can write a review.md file like this:

---
verdict: needs-rework
summary: "The implementation is missing a required edge case."
findings:
  - severity: high
    file: src/auth.ts
    line: 42
    message: "Token expiry validation is missing."
---

This creates a shared chain of evidence:

specification → implementation diff → review result → verification result

The developer and later agent sessions inspect the same files.

Where ithyno fits

ithyno does not replace OpenSpec, Git, or the agent CLIs.

OpenSpec defines the agreed change.
Agent sessions perform role-specific work.
Git branches and worktrees isolate implementation.
Review and verification artifacts record outcomes.
ithyno coordinates these parts as one project workflow.

ithyno is available as a VS Code extension and an Electron app. Both use the same repository files.

Current status

ithyno is currently an alpha project. Agent CLIs change quickly. Permissions, command arguments, and child-agent features can change between releases. The documentation lists supported settings and verified routes.

Try the workflow

Read the installation guide.
Follow Start a simple project.
Configure role-based agent workers.
View the source and releases on GitHub.

You do not need another vendor to separate these responsibilities. Start with one shared specification. Then give planning, implementation, review, and verification their own roles.

See the architecture overview for more detail.

Feedback from real projects is welcome. If a CLI route fails or the workflow does not fit your project, open an issue. If ithyno is useful to you, consider starring the repository.

Disclosure: This article was edited with AI assistance and reviewed by the author.

DEV Community: fluentdb-dev