実行標準（すべてのスキルに適用）

• フェーズ: すべてのスキルで4～5つの異なるフェーズでサブエージェントを作成します。
• 自動実行: ユーザーを待たないでください。自動的に進めます。「実行しますか?」「承認しますか?」はありません。実行して報告します。一時停止しても実行を保証しません。

Evidence-Proof スキル

目的: 証拠を体系的に収集し、信頼度をスコアリングし、未検証項目を文書化します。

使用時期: 機能実装後、バグ修正後、または変更を加えた後。

ルール: 完了を主張する前に npm test を実行します。「動作するはず」と主張しないでください — 実際のテスト出力をキャプチャします。数値やカバレッジを作り出さないでください。

サポートファイル: 出力は .claude/CONFIDENCE_SCORE.md に出力されます。SKILL.md は500行以下に保ちます。

---

フェーズ 1: 発見

サブエージェント: EvidenceScout (model: haiku)

• ツール: Glob、Grep、Bash
• プロンプト: 変更されたファイル (git diff --name-only HEAD~1) を検出します。対応するテストファイルを検出します。カバレッジレポートが存在するかを確認します。手動テストが必要な場合はサーバーステータスを確認します。
• 出力: { changed_files[], test_files[], coverage_exists: boolean, server_needed: boolean }
• ゲート: 変更されたファイルが識別されている

フェーズ 2: 計画

サブエージェント: ProofPlanner (model: sonnet)

• プロンプト: 変更されたファイルごとに必要な証拠をマッピングします：実行するテスト、検証するフロー、確認するエンドポイント。以下のスコアリングテンプレートを使用します。
• 出力: { proof_plan[{file, test_cmd, flow, expected_result}] }
• ゲート: 証拠計画が変更されたすべてのファイルをカバーしている

フェーズ 3: 実装

サブエージェント: TestRunner (model: haiku)

• ツール: Bash、Read
• プロンプト: npm test を実行します。出力をそのままキャプチャします。テスト数、合格数、失敗数、カバレッジ % を抽出します。サーバーが必要な場合 → ヘルスチェックを実行します。証拠計画から特定のテストファイルを実行します。
• 出力: { test_output_summary, test_count, pass_count, fail_count, coverage_pct, duration }
• ゲート: テストが実際に実行された（出力は実在するもので、作られたものではない）

フェーズ 4: 検証

サブエージェント: ConfidenceScorer (model: haiku)

• プロンプト: 以下のルーブリックを使用して信頼度をスコアリングします。未検証項目を列挙します。残存リスクを列挙します。スコアリングテンプレートで .claude/CONFIDENCE_SCORE.md を更新します。
• 出力: { confidence, evidence[], unknowns[], residual_risks[], rollback_path }
• ゲート: 信頼度は実際のテスト出力に基づく数値である

フェーズ 5: 納品

サブエージェント: EvidenceArchiver (model: haiku)

• プロンプト: スコアリングテンプレートを .claude/CONFIDENCE_SCORE.md に書き込みます。ユーザーに信頼度スコア、サーバーステータス、および残存する未検証項目を通知します。
• 出力: { confidence_score_updated, server_status, user_message }
• ゲート: CONFIDENCE_SCORE.md が更新されている

---

偶発性への対応

npm test が失敗した場合: → 信頼度を任意に低下させないでください — 実際の失敗を報告してください → 偶発性 L1 を起動（失敗したテストを修正） → 2回の試行後も失敗している場合 → 偶発性 L2（簡略化）

サーバーが必要だが起動しない場合: → server-lifecycle を起動 → まだダウンしている場合 → 手動テストを [UNKNOWN] としてマーク、信頼度を低下させる

テスト実行中にレート制限された場合: → ここまでに収集した証拠を保存 → 偶発性 L5（一時停止、状態を保存）

---

プロセス: 証拠を収集（6ステップ）

1. テストを実行

npm test                    # カバレッジ付きすべてのテスト
npm run test:ci             # CI モード (GitHub Actions シミュレーション)
npm run test:watch          # 開発ウォッチモード

キャプチャする証拠:

• テスト数: 「319 合格、合計 973」
• カバレッジ: 「89.87% 行」
• 失敗: 「e2e-business-website.test.js で 2 件失敗」
• 実行時間: 「54.74 秒」

2. 手動テスト

npm start
# http://localhost:3000 にアクセス
# 重要なワークフローをテスト:
#  - フォーム送信と成功
#  - 入力値の検証エラー
#  - ネットワークエラー復旧
#  - 権限拒否の処理

キャプチャする証拠:

• ✅ フォームがエラーなく読み込まれる
• ✅ 送信ボタンがローディング状態をトリガーする
• ✅ 結果が 4 つのステージをすべて表示する
• ✅ エラーメッセージが無効な入力に対して表示される
• ✅ 再試行ボタンがエラー後に機能する

3. コードレビュー

git diff HEAD~1              # 変更内容を表示
git log --oneline -5         # 最近のコミット

キャプチャする証拠:

• 変更されたファイル: [パスを列挙]
• 追加/削除行数: [数値]
• 重要なパスが変更されたか: [はい/いいえ]
• テストが更新されたか: [はい/いいえ]

4. カバレッジギャップを確認

npm test 2>&1 | grep "uncovered"
# または coverage/lcov-report/index.html を開く

キャプチャする証拠:

• ファイル別のカバレッジ
• カバレッジされていない行
• カバレッジトレンド（改善/低下）

5. 重要なフローを検証

CLAUDE.md の重要なワークフローごと:

• ✅ フローが端から端まで機能する
• ✅ エラーケースが処理される
• ✅ 復旧パスがテストされる
• ✅ 状態遷移が有効である

6. 未検証項目を文書化

まだ証明されていないことをリストアップします:

• [UNKNOWN] 高負荷下での API 動作
• [UNKNOWN] 本番ネットワークでのレスポンスタイムアウト
• [UNKNOWN] モバイル ≤768px でのユーザー動作

信頼度スコアリングルーブリック

95-100: 検証完了 ✅

• すべてのテストが合格（テストスイートの 100%）
• 重要なワークフローをローカルで検証
• 最新コミットで GitHub Actions が合格
• 重要なモジュールのカバレッジ ≥ 85%
• すべての未検証項目が文書化されている
• ロールバックパスがテストされている
• 手作業や「動作するはず」がない

80-94: 強力な証拠

• コードが計画と正確に一致
• テストが合格（テストスイートの ≥95%）
• カバレッジ ≥ 75%
• 重要なワークフローが手動またはE2E で検証されている
• 軽微な未検証項目が文書化されている
• ロールバックパスが特定されている

60-79: 部分実装

• コード変更が行われている
• テストが合格（≥90%）
• カバレッジ 60-75%
• いくつかの重要なフローがテストされていない
• 仮定が存在する
• 未検証項目リストが増えている

40-59: 不完全

• 実装が進行中
• ハッピーパスのみのテストが合格
• カバレッジ <60%
• 主要なフローがテストされていない
• main にマージしないでください

0-39: 証拠なし

• テストが実行されていない
• 検証なしの変更
• 本番環境で使用しないでください

スコアリングテンプレート

## [機能名/修正名]

**観察**:
- テスト結果: npm test 出力
- GitHub Actions: ワークフロー #XYZ 合格/失敗
- 手動テスト: フォーム送信が動作する ✅
- コードレビュー: X ファイル、Y 行変更

**実行したテスト**:
- npm test: 319 合格、合計 973
- npm run test:ci: 合格（Node 18、20）
- カバレッジ: 89.87% 行

**検証した重要なフロー**:
- ✅ [フロー 1]: localhost:3000 での手動テスト
- ✅ [フロー 2]: 統合テスト「should X」
- ❌ [フロー 3]: まだテストされていない

**エッジケース**:
- ✅ 無効な入力: 検証が機能する
- ✅ ネットワークエラー: 再試行成功
- ❌ タイムアウト: テストされていない

**エラーハンドリング**:
- ✅ ハッピーパス: 動作する
- ✅ 検証: エラーを表示
- ✅ ネットワーク: 自動的に再試行
- ❌ 権限: まだテストされていない

**未検証項目**:
- [UNKNOWN] 負荷下での動作
- [UNKNOWN] 本番環境でのレスポンス時間

**残存リスク**:
- 複数のユーザーが同時に送信した場合のレースコンディション
- 非常に遅いネットワークでもタイムアウトが発生する可能性

**ロールバック**:
- git revert [commit]（安全、変更は分離されている）
- 検証: npm test が合格、UI が読み込まれる

**信頼度**: 87/100
- 理由: 強力なテスト証拠、手動検証完了、軽微な未検証項目が文書化されている

アンチパターン（❌ しないでください）

❌ 「動作するはず」 - 必須: テストを実行して検証する ❌ 「正しく見える」 - 必須: テストを実行する ❌ 「テストはおそらく合格」 - 必須: 実際のテスト出力を表示する ❌ 「100% の信頼度」 - すべての重要なフローが検証されている場合のみ ❌ 「未検証項目なし」 - 必須: 少なくとも残存リスクをリストアップする ❌ 文書化されていない仮定 - 必須: 未検証項目をリストアップする

良いパターン（✅ こうしてください）

✅ 「npm test は 319 合格を表示」 ✅ 「GitHub Actions ワークフロー #451 が合格」 ✅ 「localhost:3000 での手動テストがフォーム送信を検証」 ✅ 「カバレッジ 89.87%（閾値: 60%）」 ✅ 「[UNKNOWN] ロードテストはまだ実施されていない」 ✅ 「ロールバック: git revert abc123def - 安全性確認済み」

学んだ教訓（ステークホルダーのフィードバックより）

1. すべてのリネーム後にテストを実行します。 ファイル名の変更と移動はインポートパスを変更します。git mv 後すぐに npm test を実行して、破損を早期にキャッチします。
2. サンドボックスの制限を主張しないでください — 回避策を提供してください。 コマンドが現在の環境で実行できない場合は、ユーザーがローカルでプレースホルダーなしで実行できる正確なコマンドを提供します。
3. 変更が見えることを確認します。 UI ファイルを編集した後、localhost:3000 で変更が表示されることを確認します。ブラウザが自動更新されるか、サーバーが自動リロードされるかを仮定しないでください。
4. 従来のコミットは証拠です。 type(scope): description 形式を使用します。コミットログは監査証跡です — 雑なメッセージは信頼を損なわせます。
5. 冪等チェックはトークンを節約します。 編集する前に、その作業がすでに完了しているかを確認します。CHANGELOG.md と git log を読んで、完了したタスクの再実行を避けます。
6. テスト結果を作り出さないでください。 実際の npm test 出力からのみ数値を報告します。「1117 合格」はコマンドを実行してその数字を見たことを意味します。

ブロックされた場合

証拠を収集できない場合:

1. [UNKNOWN] としてマークする
2. 信頼度スコアをそれに応じて低下させる
3. それを証明するものが何かを説明する
4. 他の証拠で続ける
5. 理由を説明する .claude/CONFIDENCE_SCORE.md を更新する

例:

信頼度: 65/100 - コードはローカルで動作しますが、本番環境
はテストされていません。承認なしに本番 API に対してE2E を実行できません。
[UNKNOWN] 本番環境の動作がローカルホストと異なります。