harness-review operating model
ひとことで
harness-review は、軽い closeout から重い品質 gate までを 1 つの入口で扱う。 別の軽量 skill は作らない。
たとえると
病院の受付を 2 つに増やすのではなく、同じ受付で「通常診察」「精密検査」「救急」を振り分ける形にする。 入口を増やすと迷いやすい。 入口を 1 つにして、中で適切な検査の重さを選ぶ。
Why single entrypoint
| 判断 | 理由 |
|---|---|
| 別 skill を作らない | discovery noise が増える。ユーザーも agent も、どちらを呼ぶべきか迷う |
harness-review を dispatcher にする | contract drift を避けられる。APPROVE の意味が skill ごとにズレない |
| governance を reference に逃がす | 長い SKILL.md を毎回読む負担を減らしつつ、品質 gate は残せる |
| read-only default にする | review だけで commit / push まで進むと、release/work flow の責務が壊れる |
Mode table
| mode | 使う場面 | 重さ | 主な出力 |
|---|---|---|---|
quick | 小さな未コミット変更を閉じたい時 | 軽い | accepted/rejected findings と focused tests |
codex-closeout | Codex review を助言として使い、実コードで確認したい時 | 軽い | review command / tests / clean result |
code | 普通の実装差分レビュー | 中 | APPROVE / REQUEST_CHANGES |
plan | Plans.md の DoD / Depends / Status を見る時 | 中 | plan 修正点 |
scope | やりすぎ、漏れ、不要変更を見たい時 | 中 | scope 判定 |
security | 権限、入力、秘密情報などのリスクを見る時 | 重い | OWASP Top 10 観点の findings |
ui-rubric | 見た目、使いやすさ、完成度を点数化する時 | 中 | design quality score |
full | release 前や重要変更の最終 gate | 重い | TeamAgent Debate + governance gate |
Adopted from external codex-review
| 採用項目 | harness-review での扱い |
|---|---|
advisory | Codex の指摘は助言。実コード、diff、テストで確認してから採用する |
accepted/rejected | 指摘は accepted findings / rejected findings に分けて理由を書く |
stop-on-clean | clean result 後に、見栄えのためだけの追加 review をしない |
target selection | dirty / PR branch / branch range / single commit を最初に固定する |
no push just to review | Do not push just to review。review 目的だけで push しない |
dirty tree handling | untracked を含む未コミット変更を review scope に含める |
Not adopted
| 非採用 | 理由 |
|---|---|
| review skill の default auto-commit | review と work/release の責務が混ざる |
| 軽量専用の別 skill | discovery noise と contract drift が増える |
| AI 指摘の自動採用 | 実コード確認なしでは false positive / false negative が混ざる |
| clean 後の追加 review loop | 時間を使うだけで品質が上がりにくい |
Side-effect boundary
harness-review は原則 read-only。 APPROVE は「品質 gate を通った」という判定であり、「commit してよい」という操作命令ではない。
commit / push / release の責務:
| 操作 | 担当 |
|---|---|
| 修正 commit | harness-work またはユーザー明示依頼 |
| release commit / tag / publish | harness-release |
| review 結果の判定 | harness-review |
| push | ユーザー明示依頼または release flow |
Concrete example
小さな docs 修正を見たい時:
bash
/harness-review --quick
bash scripts/harness-review-closeout.sh --dry-run --uncommittedrelease 前の重い gate を通す時:
bash
/harness-review full --team-debate --dualWhy this approach
今の問題は、品質基準が弱いことではない。 入口の SKILL.md が重すぎて、軽い closeout でも毎回精密検査の説明書を読む形になっていること。
だから、品質基準を削らず、入口だけを薄くする。 これにより、通常時は速く、重要時は深く見られる。