메뉴
既存コードに対してテストが不足している箇所を体系的に洗い出し、優先度付きリストにする。コード複雑度・変更頻度・障害リスクを軸に評価する。「テスト不足どこ？」「テストギャップ調べて」「カバレッジ穴探して」などで起動。
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | backend-test-gap-finder |
| description | 既存コードに対してテストが不足している箇所を体系的に洗い出し、優先度付きリストにする。コード複雑度・変更頻度・障害リスクを軸に評価する。「テスト不足どこ？」「テストギャップ調べて」「カバレッジ穴探して」などで起動。 |
既存コードのテスト不足箇所を特定し、どこから埋めるべきか を優先度付きで提示する。
ユーザーに確認:
<impl>.go → <impl>_test.go が存在するか
src/foo.ts → src/foo.test.ts / __tests__/foo.test.ts が存在するか
ファイルの存在だけでは不十分（テストがあっても中身が薄いことも）。可能なら中身を一瞥する。
各ファイル / 関数について以下を評価:
| 軸 | 評価方法 |
|---|---|
| 複雑度 | 分岐・ループ・ネストの多さ、LOC |
| 変更頻度 | git log --oneline -- <path> の頻度 |
| 依存の広さ | 呼び出し元の数（Grep で参照検索） |
| 境界性 | 外部 I/O（DB、API、ファイル、時刻）を跨ぐか |
| 歴史的障害 | コミットメッセージに fix, bug, hotfix が多いか |
高リスク 低リスク
┌──────────────┬──────────────┐
高変更│ P1 │ P2 │
頻度 │ 最優先で書く │ 書く │
├──────────────┼──────────────┤
低変更│ P3 │ P4 │
頻度 │ 次に書く │ 書かなくて可 │
└──────────────┴──────────────┘
リスク = 複雑度 + 依存の広さ + 境界性 + 歴史的障害 の合成。
# テストギャップ分析: <スコープ>
## 優先度 P1（最優先）
| ファイル / 関数 | 複雑度 | 変更頻度 | 依存元 | 境界 | 障害歴 | 提案 |
| --- | --- | --- | --- | --- | --- | --- |
| `<path>::<func>` | 高 | 高 | 15 箇所 | DB | 3 件 | Unit + Integration |
### 補足
- `<path>::<func>` は <理由>。特に <条件> のテストがない。
## 優先度 P2
...
## 優先度 P3
...
## 今回は対象外（P4）
- <path> — <理由: 削除予定 / 自動生成 / 十分にカバーされている>
## 推奨ステップ
1. P1 のうち `<top>` から着手（工数目安: X 時間）
2. `backend-test-planner` で詳細ケース設計
3. `backend-test-writer` で実装
ギャップ検出時は unit / integration の両面を見ること。単体テストだけ充実して integration がないと DB マッピング・エラー変換・トランザクション境界のバグを拾えない。
docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。
差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。
未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。
未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。
バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。
汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。