code-dev

# /code-dev Issue番号: $ARGUMENTS 実装 → コードレビュー → レビュー指摘修正 → CI実行 → CI指摘修正 → 設計書整合性チェック → 設計書修正 を順次自律実行する。 **全フェーズを人間への確認なしに自律実行すること。** ## 実行手順 1. **Phase 1: 実装** - まず実装方式を判定し、判定結果に応じて TDD または直接実装を行う（詳細は下記「Phase 1: 実装方式の判定と実行」）。AskUserQuestion が必要な箇所は全て最初の選択肢（デフォルト）で自動選択し、人間への確認なしに最後まで自律実行すること 2. **Phase 2: コードレビュー** - Phase 1 完了後、`code-review` スキルを Skill ツールで起動し、完了を待つ 3. **Phase 3: レビュー指摘修正とループ** - 詳細は下記「Phase 2〜3: レビューと修正のループ」 4. **Phase 4: CI実行** - `code-ci` スキルを Skill ツールで起動し、完了を待つ 5. **Phase 5: CI指摘修正** - Phase 4 の結果にエラーがある場合、静的解析・テストエラーを修正する。エラーなしの場合はスキップ 6. **Phase 6: 設計書整合性チェック** - `validate-design` スキルを Skill ツールで起動し、完了を待つ 7. **Phase 7: 設計書修正** - Phase 6 の結果に指摘事項がある場合、実装を正として設計書を修正する。指摘なしの場合はスキップ 8. 各フェーズの出力を**そのまま全文表示**する（要約・加工・コメント追加は禁止） ## Phase 1: 実装方式の判定と実行 TDD はテストを起点に実装を駆動する手法であり、テストの新規作成・変更を伴うタスクでこそ価値を発揮する。逆に、テスト変更を伴わないタスク（設定値変更・型定義の調整・ログ追加・既存テストを壊さない軽微な修正など）に TDD を適用すると、無意味な Red フェーズを挟むだけで非効率になる。そのため、まずタスク内容からテスト変更の要否を判定し、方式を分岐する。 ### ステップ 1-1: テスト変更要否の判定 `gh issue view $ARGUMENTS --json title,body,labels` で Issue を取得し、タスク一覧（`## タスク一覧` のチェックリスト）のうち **アプリケーションコードに関するタスク** を対象に、テストの新規作成・変更を伴うかを判定する。 | 判定 | 該当するタスクの例 | 実装方式 | | -------------- | ---------------------------------------------------------------------------------------------------- | ------------------------- | | テスト変更あり | 新規関数・ハンドラーの実装、新しい振る舞いの追加、テストコード作成が明記されている | ステップ 1-2A（TDD） | | テスト変更なし | 設定値・定数の変更、型定義の調整、ログ追加、リネーム、コメント修正など既存テストに影響しない変更のみ | ステップ 1-2B（直接実装） | 上表「テスト変更なし」の例のいずれにも当てはまらないタスクは、既定で **TDD（1-2A）** を選択する。 判定結果と根拠を明示してから、対応するステップへ進む。 ### ステップ 1-2A: TDD 実装 `tdd` スキルを Skill ツールで Issue番号 `$ARGUMENTS` を渡して起動し、TDDサイクル（Red-Green-Refactor）をこの場（インライン）で実行する。AskUserQuestion が必要な箇所は全て最初の選択肢（デフォルト）で自動選択し、人間への確認なしに最後まで自律実行すること。完了後、Phase 2 へ進む。 ### ステップ 1-2B: 直接実装（TDD を使わない） `tdd` スキルは起動しない。Issue のタスク一覧（アプリケーションコードタスクのみ）を1つずつ実装する。 - 対象は `app/` 配下のみ。CDK/インフラのディレクトリ（`infra/`）は変更しない - 新規ファイルを書き起こす前に `samples/app/backend/` を Read する（構造・命名・テストの粒度の手本）。`samples/` 自体は変更しない - コメント・JSDoc は `docs/policy/code-comment-policy.md` に従う（実装コメントは WHY、doc comment は契約を書く。コードが語る WHAT/HOW は書かない） - 各タスク完了ごとに `gh issue edit $ARGUMENTS` でチェックリストを更新する - 既存テストがある場合、変更後も壊れていないことを確認するため `unit-test` スキルを Skill ツールで起動して回帰確認する（既存テストが存在しない場合はスキップ） 完了後、Phase 2 へ進む。 ## Phase 2〜3: レビューと修正のループ 合否・再レビューの回数・修正範囲は [ai-review-gate-policy](../../../docs/policy/ai-review-gate-policy.md) に従う（自律型ワークフロー）。 - 指摘があれば、severity にかかわらずすべて直す（例外は同ポリシー「直す範囲は毎回すべて」の残してよい例外だけ）。修正後 Phase 2 へ戻り `code-review` を再起動する。**再レビューには前回の指摘を渡さない** - レビューは最大2回（初回を含む）。残してよい例外以外の Critical が0件になった回で合格とし、その回に出た High・Medium もその場で直してから Phase 4 へ進む - 2回目のレビューで指摘が出たら、直したうえで再レビューせずに Phase 4 へ進む ## エラーハンドリング - Phase 1 失敗（TDD: ステップ 1-2A） → Phase 2 以降は実行しない。`/tdd $ARGUMENTS` で個別実行を案内する - Phase 1 失敗（直接実装: ステップ 1-2B） → Phase 2 以降は実行しない。エラー内容を表示し、手動での修正を案内する - Phase 2 失敗 → Phase 1 の実装は完了済み。`/code-review` で個別実行を案内する - Phase 3 修正不要（指摘なし）→ Phase 4 へスキップ - Phase 4 失敗 → エラー内容を表示し中断。`/code-ci` で個別実行を案内する - Phase 5 修正後も CI 失敗 → エラー内容を表示し、手動での修正を案内する - Phase 6 失敗 → CI まで完了済み。`/validate-design` で個別実行を案内する - Phase 7 修正不要（指摘なし）→ 完了