メニュー
アプリケーション実装の一気通貫オーケストレーションワークフロー。実装（テスト変更を含む場合はTDD、含まない場合は直接実装）→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正→設計書整合性チェック→設計書修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 6（frontend/backend実装）で使用。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
| name | code-dev |
| description | アプリケーション実装の一気通貫オーケストレーションワークフロー。実装（テスト変更を含む場合はTDD、含まない場合は直接実装）→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正→設計書整合性チェック→設計書修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 6（frontend/backend実装）で使用。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。 |
| argument-hint | <Issue番号> |
Issue番号: $ARGUMENTS
実装 → コードレビュー → レビュー指摘修正 → CI実行 → CI指摘修正 → 設計書整合性チェック → 設計書修正 を順次自律実行する。 全フェーズを人間への確認なしに自律実行すること。
code-reviewer-agent を Task ツールで起動し、完了を待つcode-ci-runner-agent を Task ツールで起動し、完了を待つdesign-validator-agent を Task ツールで起動し、完了を待つTDD はテストを起点に実装を駆動する手法であり、テストの新規作成・変更を伴うタスクでこそ価値を発揮する。逆に、テスト変更を伴わないタスク（設定値変更・型定義の調整・ログ追加・既存テストを壊さない軽微な修正など）に TDD を適用すると、無意味な Red フェーズを挟むだけで非効率になる。そのため、まずタスク内容からテスト変更の要否を判定し、方式を分岐する。
gh issue view $ARGUMENTS --json title,body,labels で Issue を取得し、タスク一覧（## タスク一覧 のチェックリスト）のうち アプリケーションコード（backend/frontend）に関するタスク を対象に、テストの新規作成・変更を伴うかを判定する。
| 判定 | 該当するタスクの例 | 実装方式 |
|---|---|---|
| テスト変更あり | 新規関数・ハンドラーの実装、新しい振る舞いの追加、テストコード作成が明記されている | ステップ 1-2A（TDD） |
| テスト変更なし | 設定値・定数の変更、型定義の調整、ログ追加、リネーム、コメント修正など既存テストに影響しない変更のみ | ステップ 1-2B（直接実装） |
判定が曖昧な場合（新しい振る舞いが加わる可能性がある）は、安全側に倒して TDD（1-2A） を選択する。
判定結果と根拠を明示してから、対応するステップへ進む。
tdd スキルを Skill ツールで Issue番号 $ARGUMENTS を渡して起動し、TDDサイクル（Red-Green-Refactor）をこの場（インライン）で実行する。AskUserQuestion が必要な箇所は全て最初の選択肢（デフォルト）で自動選択し、人間への確認なしに最後まで自律実行すること。完了後、Phase 2 へ進む。
tdd スキルは起動しない。Issue のタスク一覧（アプリケーションコードタスクのみ）を1つずつ実装する。
backend/・frontend/ 配下のみ。cdk/ 配下は変更しないdocs/policy/code-comment-policy.md に従う（実装コメントは WHY、doc comment は契約を書く。コードが語る WHAT/HOW は書かない）gh issue edit $ARGUMENTS でチェックリストを更新するunit-test-runner を Task ツールで起動して回帰確認する（既存テストが存在しない場合はスキップ）完了後、Phase 2 へ進む。
/tdd $ARGUMENTS で個別実行を案内する/code-review で個別実行を案内する/code-ci で個別実行を案内する/validate-design で個別実行を案内するいま進行中のセッションの会話の流れを5項目で要約し、コンテキストスイッチから戻った人間が状況を思い出すのを助ける。「catchup」「ここまで要約して」「どこまでやったか」「文脈を思い出したい」と指示されたときに使う。
CDK実装の一気通貫オーケストレーションワークフロー。CDK実装→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 7（CDK実装）で使用。Issue番号を引数に指定すること（例: /cdk-dev 15）。frontend/backend実装には使用しない。
統合設計ワークフロー。GitHub IssueをもとにIssueを読み込み設計書（docs/design/）を更新し、自動レビューと修正まで実行する。仕様駆動開発のStep 4で使用。Issue番号を引数に指定すること（例: /design 15）
AWS CDK実装専用コマンド。GitHub IssueからCDK実装・テスト・CDK合成まで自動実行する。CDKインフラの実装を依頼されたときに使用すること。
AWS CDK インフラコードを詳細にレビュー。/cdk-review コマンドが呼ばれたとき、またはユーザーが CDK コードのレビューを依頼したときに使用する。cdk/ ディレクトリ内の TypeScript ファイルを対象に、型安全性・CDK ベストプラクティス・プロジェクトルール準拠を自動チェックする。
Plan ファイルを早期監査する（シフトレフト）。必須セクションの充足と、コードベース・ドキュメントへの影響範囲の網羅を Issue 化前にチェックする。「check-plan」「plan をチェック」と指示されたとき、または /to-plan から自動で呼ばれる。Plan の不足を指摘し、修正してから次工程へ進めるようにする。