AI駆動開発ワークフローの「実装準備」フェーズ(ステップ3)を実行する。 「/dev-impl-prep <issue番号>」で呼び出す。issue番号は必須引数。 GitHubのissueを起点に以下を自動で行う: (1) 要件定義フェーズで確定したアウトプットの把握、 (2) Exploreエージェントによる既存テストパターン調査、(3) テストケースの箇条書き作成、 (4) 人間との合意形成とissueへの記録、(5) 合意済みテストの実装。 以下の場面で必ずこのskillを使うこと: - 「/dev-impl-prep <番号>」と呼び出されたとき - 「issue #NNの実装準備をして」「テスト計画を立てて」「実装準備フェーズを始めて」と言われたとき - 要件定義フェーズ完了後、実装前にテストを先に書きたい場面
AI駆動開発ワークフロー(docs/workflow/ai-dev-workflow.md)のステップ3「実装準備」を実行する。
要件定義フェーズで確定したアウトプット(API仕様・UI仕様・DBスキーマ等)を守るためのテストを、
まず箇条書きで計画し、人間の承認を得てから実装することがゴール。
<issue番号>(必須): 実装準備を行うGitHub issueの番号メインスキル(オーケストレーター)
├── Step1: Issue確認(メイン)
├── Step2: コードベース調査 → Explore エージェント
│ ↓ 調査サマリーを受け取る
├── Step3: テスト計画(箇条書き)(メイン)
├── Step4: 人間確認・合意(メイン)
└── Step5: テスト実装 → general-purpose エージェント
gh issue view <番号> --comments でissueの内容とコメントを取得する
docs/specs/api-list.md, openapi.yaml, screen-list.md, er-diagram.md以下を調査させ、調査サマリーをメインに返させる:
__tests__ ディレクトリ、.test.ts サフィックス等)Exploreエージェントへの指示例:
以下を調査してサマリーを返してください:
1. 既存テストファイルのディレクトリ構造と命名規則
2. 使用しているテストフレームワーク(package.json, requirements.txt等から判断)
3. 既存テストファイルの書き方のパターン(describe/it/test の構成)
4. テストファイルの保存場所の規則
Step1・Step2の情報をもとに、テストケースを箇条書きで列挙する。コードは書かない。
以下のカテゴリでテストケースを整理する:
APIテスト(APIエンドポイントの追加・変更がある場合):
UIコンポーネントテスト(画面の追加・変更がある場合):
その他(DB変更がある場合など):
gh issue comment でissueに記録するStep4で承認されたテスト計画と、Step2のコードベース調査サマリーをコンテキストとして渡し、 テストコードを実装させる。
general-purposeエージェントへの指示例:
以下の調査サマリーと承認済みテスト計画をもとに、テストコードを実装してください。
[調査サマリー]
[承認済みテスト計画]
- ビジネスロジックは実装しない(テストコードのみ)
- 既存テストのパターン・命名規則に従う
- 実装したテストファイルの一覧を返してください
完了後:
gh issue comment で実装完了をissueに記録するgh コマンドが使えない場合はエラーをそのままユーザーに伝える