confidence

確信度の評価

現在の作業が、提示された要件を完全に満たしているという確信度を評価してください。

複数シグナルによる評価。 単一の LLM 確信度の数値は、単独の判定基準としては信頼できません（トークン確率 ≠ 正しさ）。このスキルでは、LLM による多次元スコアリングと、エージェントが併せて実行する必要のある決定論的なルールチェックを組み合わせます。最終スコアは、両方に合格した場合にのみ認められます。

目次

• モードの検出
• 評価項目
  • plan モードの場合 — 複数シグナル：LLM スコアリング + ルールチェック（不合格の場合は上限 89%）
  • code モードの場合
  • analysis モードの場合
• 出力形式
• スコアのしきい値
• 反復プロトコル（plan モード）
• 自動修正（Fix モードのみ）

---

モードの検出

引数を確認します：$ARGUMENTS

引数	デフォルト	検証対象	使用するタイミング
plan		実装計画の完全性	フェーズ 1 の計画後、自律実行の前
code	yes	コード実装の正確性	コードの記述後、PR の前
analysis		分析の正確性（根本原因、リファクタリングの根拠、またはスキルの不足）	調査中、修正やリファクタリング、スキルソースの差分を提案する前
bug-analysis		analysis の非推奨エイリアス — 同じように動作します	後方互換性のため。レポートヘッダーに 1 行の非推奨メモを記載してください

引数が指定されていない場合は、デフォルトで code を使用します。

エイリアスの処理。 bug-analysis は非推奨のエイリアスとして受け付けられ、同一の評価項目、重み、しきい値、Fix モードの動作で analysis に解決されます。このエイリアスを指定して実行した場合は、レポートヘッダーの先頭に次の 1 行を追加してください：> Note: \bug-analysis` is a deprecated alias for `analysis`. Update the caller when convenient.` このエイリアスにより、移行期間中も進行中のワークフローや既存のトランスクリプトが引き続き機能します。呼び出し元の移行後に削除してください。

引数に 「fix」 が含まれる場合（例：code fix、plan fix、analysis fix）、Fix モードで実行し、レビュー後に見つかった懸念点を自動的に修正してください。

---

評価項目

plan モードの場合

Plan モードでは複数シグナルを用います：LLM による多次元スコアリング + 決定論的なルールチェック。 判定を通過するには、両方に合格する必要があります。

ステップ 1 — LLM による次元別スコアリング

次元	重み	評価内容
完全性	40%	Phase 0 の要件はすべて盛り込まれていますか？Core セクションは記入されていますか（タスクで必要な場合、Extended セクションも含まれていますか）？新しいセッションで、この計画だけをもとに実行できますか？Include when のトリガー条件が該当しないために Extended セクションが正当に省略されている場合（例：変更のみの計画に Existing Code Survey がない場合）は、減点しないでください。「Searched for」列が曖昧（「ざっと見た」など）な Existing Code Survey や、検索を行っていないことを示す BUILD NEW 判定は減点してください。ルール #10 は記載の有無を確認し、この次元では検索の質を確認します。
実現可能性	30%	技術的なアプローチは妥当ですか？パターンはコードベースと一貫していますか？該当する場合、リスクは特定されていますか？
曖昧さのなさ	30%	実装手順は、解釈を加えずに実行できるほど具体的ですか？該当する場合、エッジケースに対応していますか？

ステップ 2 — 決定論的なルールチェック（Bash で実行）

プランモードでは、以下のチェックすべてに合格する必要があります。ルールに 1 つでも不合格があると、LLM のスコアにかかわらずゲートの上限は 89% となります。エージェントは不合格となったルールを提示し、計画を修正するかユーザーにエスカレーションする必要があります。ルール #10 と #11 は条件付きで適用されます（トリガー条件はルールに含まれます）。条件に該当しない場合は、記録された注記とともに適用対象外として合格となります。暗黙にスキップされることはありません。

#	ルールの確認	検証
1	plan.md が想定されるパスに存在する	test -f .agent/$(git branch --show-current)/plan.md
2	すべての Core セクションが存在する	grep -E '^## (TL;DR|Requirements|Decisions|Acceptance Criteria|Implementation Order|File Changes|Verification|Progress Log)' plan.md | wc -l ≥ 8 — これらは常に必須の Core 層です。拡張セクション（Background、Technical Approach、Patterns、Edge Cases、API、Tests、Dependencies、Risks）は必要に応じて含めるものであり、ここではカウントしません。
3	Acceptance Criteria セクションが空ではない	awk '/^## Acceptance Criteria/{f=1;next} /^###? /{f=0} f' plan.md | grep -c '^- |^[0-9]' ≥ 1
4	## File Changes のすべてのファイルが解決できるか、create である	modify/delete の各行について、git ls-files <path> がそのパスを返します。create の行はこの確認をスキップします。
5	すべての要件に [user-stated] または [inferred] のタグが付いている	awk '/^## Requirements/{f=1;next} /^###? /{f=0} !f{next} /^[-0-9]/{n++} /\[user-stated\]/{t++} /\[inferred\]/{t++} END{exit n!=t}' plan.md は 0 で終了します — タグ数が要件数と一致する必要があります（範囲は ### Out of Scope で終了するため、除外項目はカウントされません）。シェルのパイプを使わない単一の awk コマンドなので、表の行はそのまま実行できます。
6	すべての決定行で Rationale 列に値が入力されている	awk -F'[|]' '/^## Decisions/{f=1;next} /^###? /{f=0} !f{next} !/^[|]/{next} {r++} r<3{next} NF<5{bad=1} $4 ~ /^[ \t]*$/{bad=1} END{exit bad}' plan.md は 0 で終了します — Decisions テーブルの Rationale（第 3 列）に空欄や未入力のセルがありません。フィールド区切り文字と行の照合には角括弧クラス [|] を使っているため、コマンドにシェルのパイプは不要で、そのまま実行できます。
7	すべてのタイムスタンプが時刻部分を含む ISO 8601 形式である	awk '/^## Progress Log/{f=1;next} /^###? /{f=0} !f{next} /^- /{n++} /^- \[20[0-9][0-9]-[0-9][0-9]-[0-9][0-9]T[0-9][0-9]:[0-9][0-9]:[0-9][0-9]Z\]/{t++} END{exit n!=t}' plan.md は 0 で終了します — Progress Log のすべての項目は [YYYY-MM-DDTHH:MM:SSZ] タイムスタンプで始まります。シェルのパイプを使わない単一の awk コマンドなので、表の行はそのまま実行できます。
8	検証コマンドがテンプレートではない	「編集後」と「PR 前」の行に { または } のプレースホルダー用の波括弧が含まれていません
9	すべての [user-stated] 要件が Acceptance Criterion でカバーされている	awk '/^## Requirements/ {rs=1; as=0; next} /^## Acceptance Criteria/ {as=1; rs=0; next} /^###? / {rs=0; as=0} rs && /^[-0-9]/ {n++; if (index($0,"[user-stated]")) us[n]=1} as {s=$0; while (match(s, /covers:[^)]*/)) {seg=substr(s,RSTART,RLENGTH); s=substr(s,RSTART+RLENGTH); while (match(seg,/R[0-9]+/)) {cov[substr(seg,RSTART+1,RLENGTH-1)]=1; seg=substr(seg,RSTART+RLENGTH)}}} END {for (i in us) if (!(i in cov)) exit 1; exit 0}' plan.md は 0 で終了します — 要件はリストの位置で番号付けされます（最初の項目 = R1。### によるリセットで Out of Scope 項目は除外）。[user-stated] タグが付いた各位置は、Acceptance Criteria 内の (covers: R…) アノテーションに含まれている必要があります。これは要件から基準へのトレーサビリティを確認するゲートです。計画でユーザーが明示した要件を暗黙に落とすことはできません。シェルのパイプを使わない単一の awk コマンドなので、表の行はそのまま実行できます。
10	予定されているすべての create に Existing Code Survey の判定がある	awk -F'[|]' '/^## File Changes/ {fc=1; es=0; next} /^## Existing Code Survey/ {es=1; fc=0; next} /^###? / {fc=0; es=0} fc && /^[|]/ && $2 ~ /create/ {creates++} es && /^[|]/ {if (index($0,"EXTEND") + index($0,"WRAP") + index($0,"BUILD NEW") > 0) rows++} END {if (creates == 0) exit 0; exit (rows < 1)}' plan.md は 0 で終了します — File Changes テーブルに create の行が 1 つ以上ある場合、## Existing Code Survey セクションに判定行（EXTEND / WRAP / BUILD NEW）が 1 つ以上必要です。変更のみの計画は常に合格します（このセクションは正当に省略できます）。これは再発明を防ぐゲートです。再利用を検索した記録なしに新しい単位を作ることはできません。フィールド区切り文字には角括弧クラス [|] を使い、判定の照合にはパイプを含まない index() の合計を使うため、コマンドにシェルのパイプは不要で、そのまま実行できます。
11	checks.yaml が存在し、その ID が計画と同期している	Acceptance Criteria に AC-{n} ID が付いている場合のみ適用されます（例：/fix-bug のファストレーンなど、ID のない計画はログに注記を残してスキップします）。確認方法：test -f .agent/$(git branch --show-current)/checks.yaml を実行し、次に計画の Acceptance Criteria セクション内の各 AC-{n} について、grep -c "^- id: AC-{n}$" checks.yaml が 1 以上を返すことを確認します。また、checks.yaml のすべての id: が計画内の AC に対応している必要があります。どちらかの方向に孤立した項目があれば失敗します。
各チェックを実行し、出力テーブルに合格／不合格を記載します。ルール違反は、LLM の次元別スコアが高くてもゲートが検出しなければならないブロッカーです。

Step 3 — 統合ゲート

overall_score = min(weighted_LLM_score, max_allowed_by_rule_checks)
where max_allowed_by_rule_checks = 100% if all rules pass, else 89%

意図：LLM の判定で 95% のスコアを獲得した計画でも、ルールチェック #4（存在しないファイルパスを参照している）に失敗した場合は 89% が上限となり、ゲートも不合格になります。これにより、モデルが確信していても、計画が幻覚によるパスに基づいているという失敗パターンを検出できます。

code モードの場合

次元	重み	評価内容
正確性	40%	ロジックは、説明されている問題に実際に対処していますか？
完全性	30%	すべてのケース、エッジケース、要件を網羅していますか？
リグレッションなし	30%	既存の動作を壊したり、副作用を引き起こしたりする可能性はありますか？

analysis モードの場合

評価対象の成果物が分析である場合は、必ずこのモードを使用してください。対象には、根本原因の分析文書、リファクタリングの根拠、/create-skill diagnose の提案、ループが停滞した後の包括的な再分析、または変更の提案に先立つその他の推論成果物が含まれます。

次元	重み	評価内容
証拠の強さ	40%	分析は具体的な証拠（ログ、トレース、コードパス、ファイル名と行番号の参照、再現された動作）に裏付けられていますか？
根本原因の確実性	30%	これは根本原因ですか、それとも単なる症状ですか？調査はどこまで深く行われていますか？リファクタリング／診断の分析では、「根本原因」は文字どおりのバグの原因ではなく、「実際の構造的な理由」として解釈してください。
結果への確信度	30%	提案された対応（修正、リファクタリング、スキルソースの差分）は、新たな問題を引き起こさずに状況を解決しますか？

---

出力形式

必ず次の形式で出力してください。

## Confidence: X%

### LLM dimensional scoring

| Dimension | Score | Notes |
|-----------|-------|-------|
| <dim 1>   | X%    | ...   |
| <dim 2>   | X%    | ...   |
| <dim 3>   | X%    | ...   |

### Deterministic rule checks (plan mode only — omit for code/analysis)

| # | Rule                | Status      | Evidence                  |
|---|---------------------|-------------|---------------------------|
| 1 | <rule description>  | ✓ pass / ✗ fail | <command output snippet> |
| ... |                   |             |                           |

### Combined gate

- Weighted LLM score: X%
- Rule checks: <N pass> / <total> (cap: 100% if all pass, else 89%)
- **Final: X%**

次元の重みを使った加重平均として、LLM の加重スコアを計算します。plan モードでは、最終スコアは min(weighted_LLM_score, rule_check_cap) です。code モードと analysis モード（非推奨の bug-analysis エイリアスによる呼び出しを含む）では、ルールチェックのセクションを省略し、Final = weighted_LLM_score とします。

誠実かつ批判的に評価してください。スコアを水増ししてはいけません。明確な根拠を伴う低いスコアのほうが、誤った 95% よりも価値があります。ルールチェックの失敗は妥協できません。LLM のスコアが高くても、必ず明示してください。

---

スコアのしきい値

スコア	対応
90-100%	続行 — 作業の準備ができています
70-89%	具体的な懸念事項と、確信度を高めるために必要なことを列挙します。修正モードの場合は、修正を適用します。
70% 未満	検証または修正のための具体的な次の手順を提案します。自律実行を続行してはいけません。

---

反復プロトコル（plan モード）

自律実行前の品質ゲートとして使用する場合：

確信度が 90% 未満の場合は、スコアを高めるために追加調査、分析、証拠収集を最大 2 回行います。 各反復の後に、確信度評価を再実行します。 2 回の反復後も 90% 未満の場合は、調査結果をユーザーに提示し、続行するか、さらに改善するかを尋ねます。

---

自動修正（修正モードのみ）

修正モードでない場合は、このセクション全体を省略してください。

修正モード（plan fix、code fix、analysis fix、または非推奨の bug-analysis fix エイリアス）で実行する場合は、スコアを下げた懸念事項をすべて自動的に解消します：

簡単な修正（すぐに適用）

リスクが低く、機械的に対応できる以下の修正は、確認せずに適用してください。

• 明らかな実装方法があるエッジケースの処理漏れ
• null／undefined チェックの不足
• オフバイワンエラーまたは不正な境界条件
• 文字列、コメント、変数名の誤字
• 型が明らかな場合の戻り値の型または型注釈の不足
• 修正方法が明確な小さなロジックエラー
• （計画モード）セクションの不足、不完全な要件、曖昧な実装手順

各修正を適用した後、変更内容を簡潔に記録してください（修正ごとに1行）。

複雑な修正（計画してから適用）

より慎重な検討が必要な問題については、以下を実施してください。

• 未対応のパスに対するテストカバレッジの不足
• 不完全な実装（ケースの不足、未処理の状態）
• アーキテクチャ上の懸念または不適切な抽象化
• （計画モード）根本的なアプローチの問題、技術設計の不足

それぞれについて、次を出力してください。

### [Issue title]
**Why:** [1-sentence explanation]
**Fix plan:**
1. [Step 1]
2. [Step 2]
**Files involved:** [list]

その後、計画を実行してください。

修正後の再評価

すべての修正を適用した後、次を実施してください。

1. 更新したスコアで確信度を再評価する
2. 修正内容と、各修正がスコアをどのように改善したかを列挙する
3. 確信度が90％未満の場合、自動修正できなかった懸念事項を列挙する