{
  "markdown": "# Claude Code Harness\n\n<p align=\"center\">\n  <img src=\"docs/images/claude-harness-logo-with-text.png\" alt=\"Claude Harness\" width=\"400\">\n</p>\n\n<p align=\"center\">\n  <strong>Plan. Work. Review. Ship.</strong><br>\n  <em>A disciplined delivery loop for Claude Code, Codex CLI, Cursor, and Grok.</em>\n</p>\n\n<p align=\"center\">\n  <a href=\"https://github.com/Chachamaru127/claude-code-harness/releases/latest\"><img src=\"https://img.shields.io/github/v/release/Chachamaru127/claude-code-harness?display_name=tag&sort=semver\" alt=\"Latest Release\"></a>\n  <a href=\"LICENSE.md\"><img src=\"https://img.shields.io/badge/License-MIT-green.svg\" alt=\"License\"></a>\n  <a href=\"docs/CLAUDE_CODE_COMPATIBILITY.md\"><img src=\"https://img.shields.io/badge/Claude_Code-v2.1+-purple.svg\" alt=\"Claude Code\"></a>\n  <img src=\"https://img.shields.io/badge/Skills-5_core_%2F_23_total-orange.svg\" alt=\"Skills: 5 core verbs / 23 total\">\n  <img src=\"https://img.shields.io/badge/Guardrails-R01%E2%80%93R16_%2B_5_floors-B5462F.svg\" alt=\"Guardrails: R01-R16 plus 5 runtime floor categories\">\n  <img src=\"https://img.shields.io/badge/Core-Go_Native-00ADD8.svg\" alt=\"Go Core\">\n</p>\n\n<p align=\"center\">\n  English | <a href=\"README_ja.md\">日本語</a>\n</p>\n\n<p align=\"center\">\n  <img src=\"docs/images/readme/loop-en.svg\" alt=\"Operating loop: Plan, Work, Review, Release — with every command checked before it runs\" width=\"880\">\n</p>\n\n## The problem\n\nClaude Code Harness (CCH) is a development plugin for delegating planning,\nimplementation, validation, and review to Claude Code or Codex. Provide the\nintended outcome and completion criteria; the assigned agents inspect the\nexisting code and organize the work.\n\n**You decide what to build, what counts as complete, and which actions are\nauthorized.** Agents choose the method within that scope and continue the\nnecessary fixes and checks. They return changes, verification results, and\nunknowns so you can judge the result against the criteria.\n\n## Install in 30 seconds\n\n```bash\nclaude\n/plugin marketplace add Chachamaru127/claude-code-harness\n/plugin install claude-code-harness@claude-code-harness-marketplace\n/harness-setup\n```\n\nThen hand it something small:\n\n```bash\n/harness-plan Improve the README onboarding flow\n```\n\nHarness drafts `spec.md` and `Plans.md` for you. **Your job is not to write the\nplan — it is to approve or correct it** before execution continues.\n\nUsing a different tool? See [install by tool](#install-by-tool) below.\n\n## The loop\n\nThe 5 verb skills keep that surface small: plan, work, review, sync, release.\n(`/harness-setup` runs once at install time, above.) Each stage leaves the\nmaterial the next stage needs, and each has its own gate.\n\n| Command | What happens | Gate |\n|---|---|---|\n| `/harness-plan` | Turns intent into `spec.md` + `Plans.md`: scope, acceptance criteria, dependencies, unknowns, stop conditions. | You approve or correct the generated contract. |\n| `/harness-work` | Executes the selected scope, choosing solo or team execution by task count. | Clarifies scope only when it is unresolved; runs required checks and review. |\n| `/harness-work 3` | Implements task 3 only. | TDD required when the task says so. |\n| `/harness-work all` | Runs the whole approved plan. Use once the plan is clear and the repo baseline is known. | Same TDD gate, applied task by task. |\n| `/harness-review` | Reviews the result **separately from implementation**. | Major findings block completion. PR-ready is not release-ready. |\n| `/harness-sync` | Compares the plan against what is actually implemented and reports drift. | Reconciles status using observed evidence. |\n| `/harness-release` | Packages only verified evidence into CHANGELOG, tag, and release. | Release preflight must pass. |\n\nData the agent has not seen stays `unknown` instead of being quietly invented.\n\n## What happens after a request\n\nFor example, an order duplication bug can start with:\n\n```text\n/harness-plan Fix duplicate orders. The completion criterion is that the same order is stored once.\n```\n\nReview and approve the scope and completion criteria, then run\n`/harness-work all`. In Codex, invoke the skills as `$harness-plan` and\n`$harness-work all`.\n\n1. **Plan.** Inspect the existing specification and code, then capture reproduction steps, scope, and completion criteria in `spec.md` and `Plans.md`.\n2. **Implement.** Pass the original request, criteria, and observed evidence to the assigned worker. Independent work can run concurrently with separate file ownership.\n3. **Verify and fix.** Run required tests and reproduction steps. Send review findings back to the worker for correction within the configured iteration limit.\n4. **Report.** Return criterion-level results, changed files, checks actually performed, and remaining issues.\n\nAgents first recover missing inputs from the specification and relevant code.\nReversible work inside the authorized scope continues with stated assumptions.\nA new authorization or material specification decision blocks the dependent\naction; independent authorized work can continue. Major findings or an\nexhausted correction limit produce an incomplete result with evidence for\nthe next decision.\n\n## Model roles and your choices\n\nCCH assigns models by role. Reasoning effort controls how much processing a\nmodel allocates to thinking. These are role defaults; the main conversation\nalso uses its session selection and the active skill's settings.\n\n| Role | Model | Effort |\n|---|---|---|\n| Claude difficult decisions and advice (`deep` / `advisor`) | Fable 5.1 (`claude-fable-5-1`) | `high` |\n| Ordinary Claude implementation | Sonnet 5 (`claude-sonnet-5`) | `medium` |\n| Dedicated independent Claude Reviewer | Sonnet 5 (`claude-sonnet-5`) | `xhigh` |\n| Codex standard work, difficult decisions, review, and advice | GPT-6 astra (`gpt-6-astra`) | `xhigh` |\n| Codex Breezing implementation Worker | GPT-5.6 luna (`gpt-5.6-luna`) | `max` |\n\nThe general Claude review route uses Fable 5.1 / `high`; the dedicated\nReviewer above uses a separate Sonnet 5 definition. Lightweight research has\nits own routes. See the [full role table](docs/model-routing-policy.md).\n\n**Manual model and effort choices remain authoritative.** Per-call selections\nand role settings apply to their respective execution paths. Changing the\nparent conversation does not retune every child role. Explicit Codex `ultra`\nis preserved; stronger wording in a request does not authorize effort changes.\n\n## The safety layer\n\nOperations connected to CCH's checks are inspected by a Go engine before\nexecution. Network sends and deletions also need command-level checks because\na file diff cannot establish those effects. Coverage depends on the host;\nsee [safety differences between hosts](docs/hardening-parity.md).\n\n**Two layers, deliberately different in strength.**\n\n| Layer | Decides | Configuration |\n|---|---|---|\n| **Runtime floor** — 5 categories | Allows or denies under category-specific rules | No global disable switch; limited allowlists exist for destinations, read targets, and other defined operations |\n| **Guardrails** — R01–R16 | Deny / confirm / warn | Partly, by project config |\n\nThe floor covers billing, network egress, secret reads, production deploys, and\ndestruction outside the task worktree. Allowed targets and release-operation\nsettings are protected, operator-managed configuration. Agents must not rewrite\nthem to make their own work pass.\n\nGuardrails are the layer you tune. Direct pushes to `main`, writes to protected\npaths, forced pushes, history rewrites — each has a defined verdict, and some\nare configurable per project.\n\n**Known approvals can be collected at plan time.** Operations that support\npreapproval can be scoped and approved with the plan. A newly discovered\napproval requirement is checked before that operation runs. Approvals carry\nan expiry, a task scope, and a use limit.\n\n**Stop reasons are recorded.** Rule identifiers, categories, and verdicts in\nthe decision log let you inspect what blocked an operation.\n\n## Sessions that can see each other\n\nWhen several conversations work on the same repository, CCH's roster shows\nthe active agents. A local message path can carry information to agents\nworking in other worktrees.\n\n| Piece | What it does |\n|---|---|\n| Roster | `bin/harness session list` shows live sessions registered across worktrees of the same repository. The store resolves from `git --git-common-dir`. Each row carries the `team` and `agent` a sender needs. |\n| Send | `bin/harness inbox send --team <t> --from <a> --to <b> --subject <s> \"<body>\"`, or the `session-send` skill, which also documents what is worth sending. |\n| Receive | Messages arrive at the receiving session's turn boundary, wrapped as data with an explicit non-instruction envelope. A peer's message is a report to verify, never an order to follow. |\n\nMessage content checks are off by default. Setting\n`[livemsg] verification = \"on\"` checks whether mentioned files and commits\nexist and whether a \"clean worktree\" claim matches the current state.\nMessages that fail the check are withheld, with the reason returned to the sender.\n\nThis is local-only and does not depend on harness-mem. If harness-mem is\ninstalled alongside, its roster entries are preserved untouched.\n\n## Decision surfaces for non-engineers\n\nThree single-screen HTML views let a non-engineer sponsor judge without reading\ncode.\n\n| Surface | When | Shows |\n|---|---|---|\n| **Plan Brief** | Plan finalized | Understanding, options, risks, acceptance criteria |\n| **Progress** | During work | WIP/TODO/done counts recorded in `Plans.md` and pending decisions |\n| **Acceptance** | Before release | Per-criterion pass/fail with ship / wait / reject |\n\nUse `/harness-progress` to inspect the current state. A status request alone\ndoes not mark work complete or save a memory. Work handoffs carry completed\nwork, unresolved issues, verification results, and the next action to try.\nClaude Code regenerates the page after editing or command execution, at most\nonce every 60 seconds. The completion percentage is a task-count ratio, not\nan acceptance pass rate or an automatically detected implementation state.\n\n## Install by tool\n\nFour install routes are **not** four identical guarantees. A setup script means\na tool has an *entry path*, not a shared product promise.\n\n| Tool | Tier | Route |\n|---|---|---|\n| Claude Code | `supported` | Plugin marketplace, then `/harness-setup` |\n| Codex CLI | `supported` | [`scripts/setup-codex.sh --user`](codex/README.md#option-1-script-recommended-user-based); rerun after Harness updates, then restart Codex |\n| Cursor | `supported` | `scripts/setup-cursor.sh` — containment is harness-side, see [notes](docs/CURSOR_INTEGRATION.md) |\n| Grok | `supported` | `scripts/setup-grok.sh` |\n| Codex app | `candidate` | Candidate smoke only; CLI proof is not reused |\n| OpenCode | `internal-compatible` | `scripts/setup-opencode.sh`; runtime parity not claimed |\n| Hermes Agent | `candidate` | Manual symlink research route. `harness gen` now writes its turn-delivery hook when `~/.hermes` exists; guardrail enforcement is still not wired, so the tier is unchanged |\n| GitHub Copilot CLI | `candidate` | Manual profile research |\n| Antigravity CLI | `future/unsupported` | No end-user install route yet |\n\n<details>\n<summary><strong>What the tiers mean, and why we are strict about them</strong></summary>\n\n<br>\n\n| EN tier | Japanese public wording |\n|---|---|\n| `supported` | 正式対応 |\n| `internal-compatible` | 互換利用可 / 制限付き対応 |\n| `candidate` | 試験対応 / プレビュー |\n| `future/unsupported` | 非対応 / 将来検討 |\n\nClaude Code, Codex CLI, Cursor, and Grok passed H1–H8 on their verified claim\npaths (live H4 2026-07-17; H7 release-preflight fail-closed wiring 2026-07-19).\nEvery other row stays at its listed tier until it passes its own H1–H8\n(`docs/spec/planning-and-host-adapter.md`, Phase 111).\n\nHarness does not inherit support claims from Superpowers, Hermes Agent, or any\nother project. A host moves up only when Harness has its own bootstrap, trigger,\nruntime, and release evidence.\n\n`not_observed != absent` — missing local proof means \"not proven here\". It does\nnot mean impossible, and it does not mean supported.\n\n</details>\n\n<details>\n<summary><strong>Already using Harness? Run the migration report first</strong></summary>\n\n<br>\n\n```bash\nbin/harness doctor --migration-report\n```\n\nIt inventories stale Claude plugin caches, duplicate Codex skills, old symlinks,\nOpenCode backup paths, and harness-mem state — **without deleting anything**.\n\n</details>\n\n<details>\n<summary><strong>Advanced capabilities</strong></summary>\n\n<br>\n\nReach for these after the basic path is working.\n\n| Capability | What it adds | Boundary |\n|---|---|---|\n| **Breezing** | Planner / Critic / Worker team execution for larger task lists | Still gated by plan quality and review |\n| **harness-loop** | Repeats execution within a chosen limit, consulting an advisor when needed and retaining stop reasons and restart information | Reaching the limit or finding no runnable work is distinct from completing every task |\n| **Codex companion review** | Schema-backed second opinion via `scripts/codex-companion.sh` | Raw `codex exec` is not the companion path |\n| **harness-mem** | Project-scoped memory and recall across sessions | Optional; purge stays explicit |\n| **OpenCode bootstrap** | Mirrors guidance into OpenCode-compatible surfaces | Runtime parity not claimed |\n| auto-approve *(experimental)* | `HARNESS_AUTO_APPROVE=on` records the gate result in the orchestration ledger | Default OFF. Approval prompts are **not** skipped yet |\n\n`/harness-loop` defaults to a limit of eight cycles. Claude Code normally\nhandles one task per wake-up; Codex runs a batch whose dependencies are met.\nUse `/harness-loop status` to inspect the loop and `/harness-loop stop` to stop further execution.\nResume work with `/harness-work --resume latest`, recovering the plan, diff,\nverification results, and remaining completion criteria.\n\n**Codex Breezing role routing.** After setup is rerun and Codex is restarted,\nCodex-native `$breezing` selects the managed Worker profile. `$breezing --codex`\nuses the companion Worker route. Both implementation Workers use\n`gpt-5.6-luna` / `max`; the routed Codex review route uses `gpt-6-astra` /\n`xhigh`. The main Codex session model stays unpinned, and explicit backends such\nas Cursor keep their own routing. See [activation and\nboundaries](codex/README.md#codex-breezing-role-routing).\n\nNative Codex children can inherit the parent's execution permissions. The\nReviewer profile alone is not filesystem isolation. CCH's read-only review\nuses the companion path, which explicitly selects read-only execution.\n\n</details>\n\n## Requirements\n\n- **Claude Code v2.1+** for the supported Claude path\n- A repository with write access\n- No Node.js is required for the Go-native guardrail engine\n- Optional: [harness-mem](https://github.com/Chachamaru127/harness-mem) for\n  cross-session memory\n\n## Documentation\n\n| Resource | Description |\n|---|---|\n| [Tool-first onboarding](docs/onboarding/index.md) | Where to start, by host tool |\n| [Install routes](docs/onboarding/install.md) | Per-tool setup and tier boundaries |\n| [Migration check](docs/onboarding/migration.md) | Existing-user impact and rollback |\n| [Skill trigger gate](docs/onboarding/skill-trigger-acceptance.md) | How install success is verified |\n| [Capability matrix](docs/tool-capability-matrix.md) | Full host claim table |\n| [Distribution scope](docs/distribution-scope.md) | Included vs compatibility vs dev-only |\n| [Hardening parity](docs/hardening-parity.md) | Safety differences between hosts |\n| [Work All evidence pack](docs/evidence/work-all.md) | Verification contract for full-plan runs |\n| [Model roles](docs/model-routing-policy.md) | Role models, reasoning effort, and override priority |\n| [Task requests and handoffs](docs/prompt-calibration.md) | Completion criteria, evidence, correction instructions, and restart context |\n| [Language / i18n](docs/i18n.md) | Switching output language |\n| [Changelog](CHANGELOG.md) | User-facing version history |\n\n## Contributing\n\nIssues and PRs welcome. See [CONTRIBUTING.md](CONTRIBUTING.md).\n\n## Acknowledgments\n\n- [AI Masao](https://note.com/masa_wunder) — hierarchical skill design\n- [Beagle](https://github.com/beagleworks) — test tampering prevention patterns\n\n## License\n\nMIT. See [LICENSE.md](LICENSE.md).\n",
  "bytes": 16396,
  "sha": "d274ee01f719b812e49f995c1deddf25f8878a51cffb4b49259d8f23eee1f9ca",
  "repo_slug": "chachamaru127/claude-code-harness",
  "fonte": "repo",
  "truncated": false,
  "api": "https://agentalog.com/api/listings/skl_chachamaru127_claude_code_harness_skills_28190749/readme"
}