Claude Code Harness

Plan. Work. Review. Ship.
A disciplined delivery loop for Claude Code, Codex CLI, Cursor, and Grok.

English | 日本語

The problem

Claude Code Harness (CCH) is a development plugin for delegating planning,
implementation, validation, and review to Claude Code or Codex. Provide the
intended outcome and completion criteria; the assigned agents inspect the
existing code and organize the work.

You decide what to build, what counts as complete, and which actions are
authorized. Agents choose the method within that scope and continue the
necessary fixes and checks. They return changes, verification results, and
unknowns so you can judge the result against the criteria.

Install in 30 seconds

claude
/plugin marketplace add Chachamaru127/claude-code-harness
/plugin install claude-code-harness@claude-code-harness-marketplace
/harness-setup

Then hand it something small:

/harness-plan Improve the README onboarding flow

Harness drafts spec.md and Plans.md for you. Your job is not to write the
plan — it is to approve or correct it before execution continues.

Using a different tool? See install by tool below.

The loop

The 5 verb skills keep that surface small: plan, work, review, sync, release.
(/harness-setup runs once at install time, above.) Each stage leaves the
material the next stage needs, and each has its own gate.

Data the agent has not seen stays unknown instead of being quietly invented.

What happens after a request

For example, an order duplication bug can start with:

/harness-plan Fix duplicate orders. The completion criterion is that the same order is stored once.

Review and approve the scope and completion criteria, then run
/harness-work all. In Codex, invoke the skills as $harness-plan and
$harness-work all.

1. Plan. Inspect the existing specification and code, then capture reproduction steps, scope, and completion criteria in spec.md and Plans.md.
2. Implement. Pass the original request, criteria, and observed evidence to the assigned worker. Independent work can run concurrently with separate file ownership.
3. Verify and fix. Run required tests and reproduction steps. Send review findings back to the worker for correction within the configured iteration limit.
4. Report. Return criterion-level results, changed files, checks actually performed, and remaining issues.

Agents first recover missing inputs from the specification and relevant code.
Reversible work inside the authorized scope continues with stated assumptions.
A new authorization or material specification decision blocks the dependent
action; independent authorized work can continue. Major findings or an
exhausted correction limit produce an incomplete result with evidence for
the next decision.

Model roles and your choices

CCH assigns models by role. Reasoning effort controls how much processing a
model allocates to thinking. These are role defaults; the main conversation
also uses its session selection and the active skill's settings.

The general Claude review route uses Fable 5.1 / high; the dedicated
Reviewer above uses a separate Sonnet 5 definition. Lightweight research has
its own routes. See the full role table.

Manual model and effort choices remain authoritative. Per-call selections
and role settings apply to their respective execution paths. Changing the
parent conversation does not retune every child role. Explicit Codex ultra
is preserved; stronger wording in a request does not authorize effort changes.

The safety layer

Operations connected to CCH's checks are inspected by a Go engine before
execution. Network sends and deletions also need command-level checks because
a file diff cannot establish those effects. Coverage depends on the host;
see safety differences between hosts.

Two layers, deliberately different in strength.

The floor covers billing, network egress, secret reads, production deploys, and
destruction outside the task worktree. Allowed targets and release-operation
settings are protected, operator-managed configuration. Agents must not rewrite
them to make their own work pass.

Guardrails are the layer you tune. Direct pushes to main, writes to protected
paths, forced pushes, history rewrites — each has a defined verdict, and some
are configurable per project.

Known approvals can be collected at plan time. Operations that support
preapproval can be scoped and approved with the plan. A newly discovered
approval requirement is checked before that operation runs. Approvals carry
an expiry, a task scope, and a use limit.

Stop reasons are recorded. Rule identifiers, categories, and verdicts in
the decision log let you inspect what blocked an operation.

Sessions that can see each other

When several conversations work on the same repository, CCH's roster shows
the active agents. A local message path can carry information to agents
working in other worktrees.

Message content checks are off by default. Setting
[livemsg] verification = "on" checks whether mentioned files and commits
exist and whether a "clean worktree" claim matches the current state.
Messages that fail the check are withheld, with the reason returned to the sender.

This is local-only and does not depend on harness-mem. If harness-mem is
installed alongside, its roster entries are preserved untouched.

Decision surfaces for non-engineers

Three single-screen HTML views let a non-engineer sponsor judge without reading
code.

Use /harness-progress to inspect the current state. A status request alone
does not mark work complete or save a memory. Work handoffs carry completed
work, unresolved issues, verification results, and the next action to try.
Claude Code regenerates the page after editing or command execution, at most
once every 60 seconds. The completion percentage is a task-count ratio, not
an acceptance pass rate or an automatically detected implementation state.

Install by tool

Four install routes are not four identical guarantees. A setup script means
a tool has an entry path, not a shared product promise.

bin/harness doctor --migration-report

Requirements

• Claude Code v2.1+ for the supported Claude path
• A repository with write access
• No Node.js is required for the Go-native guardrail engine
• Optional: harness-mem for
  cross-session memory

Documentation

Contributing

Issues and PRs welcome. See CONTRIBUTING.md.

Acknowledgments

• AI Masao — hierarchical skill design
• Beagle — test tampering prevention patterns

License

MIT. See LICENSE.md.

{
  "name": "claude-code-harness-marketplace",
  "metadata": {
    "version": "5.15.0",
    "description": "Marketplace entry for distributing and installing claude-code-harness as a single plugin."
  },
  "owner": {
    "name": "Chachamaru"
  },
  "plugins": [
    {
      "name": "claude-code-harness",
      "version": "5.15.0",
      "source": "./",
      "description": "A harness for solo developers (Vibecoders) to handle full-cycle contract development.",
      "author": {
        "name": "Chachamaru",
        "url": "https://github.com/Chachamaru127"
      },
      "homepage": "https://github.com/Chachamaru127/claude-code-harness",
      "repository": "https://github.com/Chachamaru127/claude-code-harness",
      "license": "MIT",
      "keywords": [
        "claude-code",
        "plugin",
        "vibecoder",
        "workflow",
        "plan-work-review"
      ],
      "category": "productivity",
      "strict": true
    }
  ]
}