Everything Claude Code のハーネスエンジニアリング

症状・対象

エージェントが「完了」と報告しても、ビルド・テスト・型・セキュリティの確認が抜ける、または毎回違う基準で成果物を評価している場合が対象です。ECC のハーネス監査と検証コマンドを、リポジトリ固有の品質ゲートへ接続します。

最短解決

1. 未導入なら ECC を追加し、既存導入なら /plugin update ecc で更新します。
2. /harness-audit で設定、検証経路、リスクを監査します。
3. リポジトリの正しいテスト・型・lint コマンドを完了条件にします。
4. 変更後に /verify、統合前に /quality-gate を明示的に実行します。

コピペ例

未導入の場合は Claude Code 内で次を実行します。

> /plugin marketplace add https://github.com/affaan-m/ECC
> /plugin install ecc@ecc

導入後、次の順で監査と検証を依頼します。

> /harness-audit

このリポジトリの検証ハーネスを監査して。
- package.json と CI 設定から実在するコマンドを特定
- Secret の値は読まず、設定名だけ確認
- 自動修正はせず、欠落・重複・実行順を報告

> /verify

今回の差分に対して、特定したビルド・テスト・型・lint を実行し、
各コマンド、終了コード、失敗箇所を省略せず報告して。

> /quality-gate

期待結果

監査では「何を、どのコマンドで、どの順に確認するか」と不足しているゲートが分かります。検証では実行したコマンドごとの成功・失敗が示され、失敗した項目は完了扱いになりません。

検証

ECC の報告に書かれたコマンドを親セッションでも再実行します。たとえばこのリポジトリのスクリプトが存在する場合は、次のように確認します。

pnpm test
pnpm typecheck
pnpm lint
git diff --check

package.json にないコマンドを推測して追加実行しないでください。CI とローカルで環境差がある場合は、同じランタイム・ロックファイル・環境変数名を使って再現します。

落とし穴

• /verify と /code-review は必要な時点で明示的に呼び出します。自動実行を前提にしません。
• eval の評価点は、実際のテスト成功や利用者の受け入れ条件の代わりにはなりません。
• 自動修正を有効にする前に、対象範囲と差分を限定します。
• Secret スキャンでも値をプロンプトやログへ貼らないでください。
• カタログ数やカバレッジ率はバージョンで変わります。品質判断を固定の件数・割合に依存させません。

次の一手

実装順序にも規律を入れるなら TDD ワークフロー、セッションをまたいで有効なパターンを育てるなら ECC の継続学習 へ進みます。