Claude Code 用のプラグイン。自律的にコードを生成しながら、完了したかどうかの判定を生成した本人にさせない構造で回す。
assay — 鉱石が主張どおりの品位を持つかを、決まった手順で試験すること。
タスクを渡すと、こういう単位に分かれて進む。
定義層 完了条件を「機械で判定できるもの」と「意味でしか判定できないもの」に振り分ける
生成層 実装する。判定権もテストを書く権限も持たない
機械検証 assertion を安い順に直列実行する。落ちたらここで止める
意味評価 4体が並列で読む。指摘を返すだけで、重大さも次の手も決めない
集約 次にどこへ行くかをコードが決める。モデルは関与しない
学習層 次回への制約を残す
各サイクルは git の ref に記録される。予算内に収束しなかった場合、 最後のサイクルではなく最良のサイクルをブランチとパッチで受け取れる。
判定の権限を、実行時の判断ではなく構造で固定する。
| 層 | 決めてよいこと | 決めてはいけないこと |
|---|---|---|
| 定義層 | 完了条件、機械/意味の振り分け | 実装の中身 |
| 生成層 | 実装 | 完了したかどうか |
| 意味評価層 | 条件を満たしていないという指摘 | 重大さ、次にどうするか |
| 集約 | 次にどこへ行くか | 指摘の妥当性 |
これは prose の約束ではなく権限で強制されている。生成層には Bash が渡らないので
テストを自分で走らせて「通りました」と自己申告する経路が存在しない。
意味評価層は自分の findings ファイル以外に書き込めないので、指摘を自分で直して
辻褄を合わせられない。
設計判断の理由は CLAUDE.md に、仕様は contract.md にある。
/plugin marketplace add uta-a/assay
/plugin install assay@assay
/assay:init プロジェクトを検出して設定を作る
/assay:run <タスク> 回す
/assay:calibrate 意味評価層の検出率と誤検出率を測る
/assay:init は検証コマンドの候補を集め、実際に起動して確認してから提案する。
存在しないコマンドや、設定がなく素通りするだけのリンタは config に到達しない。
採用するかどうかは人間が決める。
- Node.js 18 以上
- git（チェックポイント機能に必要。なくても動くが
discardはinheritに降格される） - テストランナー（強く推奨。ないと全ての完了条件が意味評価層に倒れ、この設計の前提が崩れる）
plugins/assay/
├── agents/ サブエージェント定義（役割ごとにツール権限を制限）
├── commands/ /assay:init と /assay:run
├── hooks/ 編集ごとの静的ゲート、findings の形式検証、書き込み権限の強制
├── scripts/
│ ├── detect-project.mjs 検証コマンドを検出し、実際に叩いて確認する
│ ├── run-assertions.mjs 機械検証層。落ちたら意味評価層を起動しない
│ ├── aggregate.mjs 集約。次の行き先をコードで決める
│ ├── checkpoint.mjs 隔離ワークツリーとサイクルごとの ref
│ ├── guard-criteria.mjs 誰がどのファイルに書けるかの強制
│ └── static-gate.mjs ファイル単位のリンタ
└── reference/ 契約とベースライン完了条件
評価器のプロンプトを変えたとき、良くなったのかノイズが増えたのかを区別できないと、 レビュアーを増やすほど「厚く」なって精度が下がる。
同梱の較正セット（欠陥入り6件＋対照4件）に対して評価器を走らせ、 検出率・位置精度・対照への誤検出率を測る。対照は欠陥版と対になるように作ってあり、 「何かに文句を言うか」ではなく「欠陥のあるものとないものを区別できるか」を測る。
評価器 検出率 位置精度 対照誤検出
spec-conformance 50% 100% 25%
adversarial-critic 83% 100% 100%
層として（和） 100% 100%
判定: 採用不可 — 対照への誤検出が増えました。
採否はコードが決める。層としての検出率が下がるか対照誤検出が増えれば、 その変更は採用されない。「厳しくしたので良くなったはず」を排除するための仕組みなので、 判定を解釈で覆さないこと。
コア（層の分離、機械検証、集約、チェックポイント、較正）は動作する。 評価器を差し替え可能にするプロファイル機構は未実装。
MIT