Claude Code Harness：/harness-planから/harness-releaseまで
Claude Code 専用開発ハーネス - 自律的な計画作業レビュー サイクルを通じて高品質な開発を実現します。
ひと目でわかる
- これは何？
- Chachamaru127/claude-code-harnessのGoガードレール、R01-R15、bin/harness session list、v5.13.1、MITをREADME事実で整理します。
- 誰に向いている？
- Claude Code/Codex/Cursor/GrokでAgentコーディング手順を固定したいチーム向き。README主張はCIゲートで機械検証されますが独立セキュリティ監査はありません。
- 商用利用できる？
- できます。MIT は寛容なライセンスで、著作権表示とライセンス表示を残せば、使用・改変・販売が可能です。
- 今もメンテナンスされている？
- されています。最後のコミットは 2 日前です。
- 何の言語で書かれている？
- 主に Shell です（GitHub の言語統計による）。
回答はプロジェクトの GitHub データ（最終同期：2026年9月14日）と当サイトの分析に基づくもので、法的助言ではありません。
オープンソース詳細解説
Plan.Work.Review.Shipの手順固定
Claude Code HarnessはREADMEで、Agent coding drifts（計画がチャットから消え、テストが任意化、レビューがマージ後、リリース証拠が記憶再構成）を解くと説明しています。置き換え経路は「write spec → implement approved slice → verify → review independently → package evidence」です。モデルを賢くするのではなく手順と境界を固定し、モデル変更時も継続動作させる、とREADMEは述べます。
READMEは記載主張がCIゲートで機械検証され、コンポーネント配線・タスク台帳一貫性・出荷バイナリ再ビルドが証明された後にのみ機能がREADMEへ現れると明言しています。Written is not working、がREADMEの立場です。Install in 30 seconds節は`claude`起動後に`/plugin marketplace add Chachamaru127/claude-code-harness`、続けて`/plugin install claude-code-harness@claude-code-harness-marketplace`、最後に`/harness-setup`という順を示します。README冒頭はEnglishとREADME_ja.mdへの切替リンク、Releases latestバッジ、LICENSE.md、docs/CLAUDE_CODE_COMPATIBILITY.mdへのリンクを並べています。言語メタデータはShell、MIT、取得時点スター約3072です。
評価の最初の入力はREADMEが示す`/harness-plan Improve the README onboarding flow`で足り、生成物spec.mdとPlans.mdがリポジトリに残るか、承認せずに/harness-workへ進まないかを記録してください。plugin marketplace名claude-code-harness-marketplaceとリポジトリChachamaru127/claude-code-harnessの対応も採用記録に書きます。
/harness-planとspec.md/Plans.md
5動詞スキルはplan/work/review/sync/releaseで、/harness-setupはインストール時一度です。/harness-planは意図をscope、acceptance criteria、dependencies、unknowns、stop conditions含むspec.md+Plans.mdへ変換します。ゲートは生成契約のユーザー承認または修正です。READMEは「Your job is not to write the plan, it is to approve or correct it」と書き、計画下書きを人間が最終確定する前提です。/harness-workは承認1タスク実装、/harness-work allは全計画実行（TDD required when task says so）。
/harness-reviewは実装と分離レビュー、major findingsは完了ブロックで、PR-ready is not release-readyとREADME表は区別します。/harness-syncは計画と実装差分報告。/harness-releaseは検証済み証拠のみCHANGELOG/tag/releaseへ、Release preflight must passがゲートです。Agent未確認データはunknownのまま、とREADMEは述べます。評価では小さなREADME改善を`/harness-plan Improve the README onboarding flow`に渡し、生成されたspec.mdのscope行とPlans.mdのstop conditions行を固定入力として保存してください。各段階が次段階の材料を残す、というのがThe loop節の設計です。
Go Runtime floorとR01-R15ガードレール
全ツール呼び出しはGoエンジンが実行前裁定し、事後diffではネットワーク送信や削除を見逃さない、とREADMEは説明しています。Runtime floor 5カテゴリ（billing、network egress、secret reads、production deploys、task worktree外destruction）は完全denyで、config/env/permission modeで上書き不可、disable switchなし、とREADMEは明記しています。isolated code path上にあり、自律実行が自分で無効化できない、というのがThe safety layer節の主張です。
Guardrails R01-R15はdeny/confirm/warn判定を持ち一部project configで調整可能です。対象例としてmainへのdirect push、protected pathへの書き込み、forced push、history rewriteがREADMEに挙がります。確認はplan timeへ移動し、risky operationsを事前収集して一度だけ尋ね、approvalはexpiry・task scope・use limit付き、とREADMEは述べます。全停止はJSONL logへrule id/category/verdict記録、command textはhash+lengthのみ（secret-read/billingはそれも無し）です。隔離repoで/harness-work実行し、JSONL logのrule id列を確認してください。Go native guardrailsでNode.js不要、とREADMEは別節で述べます。
bin/harness session listとinbox send
READMEはCooperBench引用（2 Agent同一ファイル編集成功率約半分、63%失敗が相手変更誤認）を根拠に、ローカルセッション間roster/message pathを提供すると説明しています。`bin/harness session list`はgit --git-common-dir解決で他worktree含むlive session一覧、各行にteamとagentが載ります。`bin/harness inbox send --team <t> --from <a> --to <b> --subject <s> "<body>"`またはsession-send skillで送信、受信はturn boundaryでnon-instruction envelope包装、peer messageはverify対象で命令ではない、とREADMEは述べます。
送信はデフォルトunfilteredです。[livemsg] verification=onでmentioned files/commits/worktree claimを検証しfalse claimはsenderへ理由返却、offではgate未呼び出し、とREADMEは説明しています。harness-mem併設時はroster entry保持、local-onlyでharness-mem非依存、とREADMEは明記しています。2 sessionで同一file pathを編集し、inbox send後のgit status突合を記録してください。Open three agents on one repo and they normally work blind to each other、がSessions that can see each other節の問題設定です。
Plan Brief/Progress/Acceptance HTML
非エンジニアスポンサー向け3 HTML view：Plan Brief（plan finalized時にunderstanding/options/risks/acceptance criteria）、Progress（WIP/未完了/done countsとdrift alerts自動再生成）、Acceptance（release前per-criterion pass/failとship/wait/reject）がREADMEに表があります。コード未読判断サーフェスとして文書化され、正確性保証ではない、とREADMEは位置づけています。
検証では/harness-plan完了後Plan Brief HTMLを開き、Plans.md acceptance criteria行と表示内容の一致を目視確認してください。Progressは作業中にWIP/未完了/done件数とdrift alertが自動再生成される前提なので、/harness-work実行中に件数変化があるかも併せて記録します。Acceptanceはrelease前のship/wait/reject判断面であり、/harness-releaseのpreflight合格とは別レイヤです。Decision surfaces for non-engineers節はsingle-screen HTMLと書いており、CLI JSONLログとは読者層が違います。
setup-codex.shとsupported tier
4 install routeは同一保証ではない、setup scriptはentry pathのみ、とREADMEは明示しています。Claude Codeはsupported tierでplugin marketplace→/harness-setup。Codex CLIはscripts/setup-codex.sh --user（Harness更新後再実行+Codex再起動、codex/README.md Option 1）。Cursorはscripts/setup-cursor.sh。Grokはscripts/setup-grok.sh。Codex app/OpenCode/Hermes/Copilot CLIはcandidate、Antigravity CLIはfuture/unsupported tierです。READMEは階層が厳格で、ホストは独自H1-H8チェックに合格した場合のみ昇格すると述べます。
bin/harness doctor --migration-reportは既存キャッシュ/状態を削除せずinventory、とREADMEは説明しています。Breezing、Codex companion review、experimental auto-approval flags（default off）、harness-mem、OpenCode bootstrapもREADME advanced節にあります。Claude Code v2.1+と書込repoアクセスがsupported path要件です。異なるツールで同じ保証を期待せず、まずClaude Code supported経路で1サイクル通し、Codexはsetup-codex.sh再実行後にrestartしたかログに残してください。
Cursorのsetup-cursor.shはcontainmentがHarness側、というREADME途中までの記述があり、スクリプト再実行タイミングはCodexと同様にHarness更新後です。Grokはscripts/setup-grok.shがsupported経路です。candidate扱いのCodex app、OpenCode、Hermes Agent、GitHub Copilot CLIでは同じRuntime floorを期待せず、まず`bin/harness doctor --migration-report`でキャッシュinventoryだけ取り、supported経路へ寄せる判断材料にしてください。experimental auto-approval flagsはdefault offのまま評価し、本番repoでは立てないことがREADMEの実験フラグ位置づけに沿います。
MIT LICENSE.mdとv5.13.1タグ
プロジェクトはMIT LICENSE.mdで、使用/複製/改変/merge/公開/配布/sublicense/販売を許可し、ライセンス記載外保証・責任なしです。本番結果や独立セキュリティ監査はREADMEに確立されていません。docs/CLAUDE_CODE_COMPATIBILITY.mdはClaude Code互換の入口で、v2.1+要件と併せて読む対象です。README_ja.mdは日本語READMEであり、英語READMEとコマンド表が一致するか確認する材料になります。
最新リリースv5.13.1（2026-08-25）がGitHub Releasesにあり、同日のv5.13.0、前日のv5.12.0とタグが続いています。評価ではv5.13.1固定で/harness-setup→/harness-plan→/harness-reviewまで1サイクル実行し、release preflight失敗時のログを保存してください。MITは社内フォークと再配布を妨げませんが、JSONLに残るrule idやPlans.mdを監査証跡として扱うかは運用側の判断であり、READMEはそこまで規定していません。
GitHub Releasesのv5.13.1（2026-08-25T18:36:00Z）とv5.13.0（同日04:09）、v5.12.0（2026-08-24）を並べ、評価クローンはv5.13.1タグをcheckoutしてください。LICENSE.mdのMITは保証なし条項が本文にあり、Goエンジンが遮断した操作を監査ログとして使う場合でも、READMEは法的保証を付けていません。README_ja.mdと英語READMEでコマンド名（/harness-plan、/harness-work all、/harness-release）が一致するかも確認対象です。docs/CLAUDE_CODE_COMPATIBILITY.mdはClaude Code v2.1+要件の詳細入口です。
編集部の結論
Claude Code/Codex/Cursor/GrokでAgentコーディング手順を固定したいチーム向き。README主張はCIゲートで機械検証されますが独立セキュリティ監査はありません。評価では`/plugin install claude-code-harness@claude-code-harness-marketplace`と`/harness-setup`後、`/harness-plan Improve the README onboarding flow`でspec.md/Plans.md生成を確認し、bin/harness doctor --migration-reportで既存キャッシュ影響を把握してから本番repoへ適用してください。
コミュニティノート