メニュー
テスト計画（test-planner 成果物）または既存の仕様に基づいて、プロジェクト既存パターンに合わせた**単体テスト(mock 前提)**を書く。言語・フレームワーク非依存で、既存テストの構造を踏襲することを最優先する。実 DB を起こす integration test は `backend-integration-test-writer` に委譲する。「テスト書いて」「このコードのテスト追加して」などで起動。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
docs/spec/ の仕様書を元に、docs/work/YYYYMMDD_<feature>.md として実装計画書を作成する。Phase 分解・影響範囲・テスト戦略・リスクを構造化し、実装前にユーザー承認を取る。「実装計画立てて」「work 書いて」「どう進めるか計画して」などで起動。
差分や指定コードを構造化されたレビュー観点（正確性・設計・テスト・可読性・セキュリティ）で読み、優先度付きで指摘する。修正は提案するが勝手に書き換えない。「レビューして」「コードレビュー」「セカンドオピニオン」などで起動。
未知のコードベースを最短で把握するための構造化探索を行う。言語・ビルドツール・アーキテクチャ・テスト方針・主要なエントリポイントを短時間でレポート化する。「このプロジェクト教えて」「コードベース調べて」「初見で入ったから概要ほしい」などで起動。
未コミットの変更を依存関係と関心事に基づいて適切な粒度のコミットに分割する。自動生成物・手動実装・テスト・ドキュメントを分離し、レビューしやすい履歴を作る。「コミット分けて」「良い粒度でコミット」「この変更コミットにして」などで起動。
バグ調査を場当たり的でなく体系的に進める。再現→仮説→検証→修正→回帰テストの順序を守り、仮説と事実を分けて記録する。「バグ調査して」「なぜか動かない」「デバッグ手伝って」などで起動。
汎用的な開発オーケストレーター。docs/spec/ の仕様と docs/work/ の実装計画書を軸に、Phase 分解と PDCA サイクルで実装を進める。自分は実装せず、各 Phase を Task で専門 agent / Explore / Plan に委託する。「開発進めて」「実装オーケストレートして」「機能実装して」などで起動。
| name | backend-test-writer |
| description | テスト計画（test-planner 成果物）または既存の仕様に基づいて、プロジェクト既存パターンに合わせた**単体テスト(mock 前提)**を書く。言語・フレームワーク非依存で、既存テストの構造を踏襲することを最優先する。実 DB を起こす integration test は `backend-integration-test-writer` に委譲する。「テスト書いて」「このコードのテスト追加して」などで起動。 |
単体テスト(unit test) を書く。プロジェクトの既存パターンに 合わせる ことを最優先。独自ルールを持ち込まない。
integration test(実 DB 起動、Handler → Repository 貫通)は別スキル backend-integration-test-writer に委譲する。計画段階で Unit / Integration の区分けがついている場合は Unit だけここで扱う。
backend-test-planner が作った計画の Unit ケースを書くbackend-integration-test-writer を使う最も重要なステップ。勝手に書き始めない。
*test*、*spec* を GlobReadTestXxx_Yyy / describe > it / def test_xxx）Read して挙動を把握docs/spec/) があれば該当セクションも参照backend-test-planner の成果物がある場合はそれに従う。ない場合は最低限:
過剰にケースを増やさない。書きすぎると壊れやすく、価値の低いテストが増える。
以下を守る:
テストが読みやすいかを意識:
コミット時に以下を意識:
git diff で確認if testing 的な特別扱いを入れる汎用スキルなので具体の実装は既存パターンに任せるが、参考までに:
func TestXxx(t *testing.T) / table-driven / t.Run サブテストdescribe / it / expect(jest/vitest)pytest の関数ベース / parametrize でテーブル駆動describe / context / itプロジェクトの既存パターンが最優先。上記は参考。