claude-dev-template

いま進行中のセッションの会話の流れを5項目で要約し、コンテキストスイッチから戻った人間が状況を思い出すのを助ける。「catchup」「ここまで要約して」「どこまでやったか」「文脈を思い出したい」と指示されたときに使う。

CDK実装の一気通貫オーケストレーションワークフロー。CDK実装→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 7（CDK実装）で使用。Issue番号を引数に指定すること（例: /cdk-dev 15）。frontend/backend実装には使用しない。

アプリケーション実装の一気通貫オーケストレーションワークフロー。実装（テスト変更を含む場合はTDD、含まない場合は直接実装）→コードレビュー→レビュー指摘修正→CI実行→CI指摘修正→設計書整合性チェック→設計書修正を人間への確認なしに自律実行する。CLAUDE.md の開発フロー Step 6（frontend/backend実装）で使用。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。

統合設計ワークフロー。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 の不足を指摘し、修正してから次工程へ進めるようにする。

TypeScript アプリケーションコードをレビュー。/code-review コマンドが呼ばれたとき、またはユーザーが TypeScript/React コードのレビューを依頼したときに使用する。型安全性・設計原則・セキュリティ・プロジェクトルール準拠を自動チェックする。

GitHub IssueからTDD（Test-Driven Development）サイクルを実行し、テストと実装を段階的に作成。backendまたはfrontendの実装にTDDを適用する際に使用。

Break a plan, spec, or PRD into independently-grabbable issues on the project issue tracker using tracer-bullet vertical slices. Use when user wants to convert a plan into issues, create implementation tickets, or break down work into issues.

grill-me での対話や事前調査の結果を Plan ファイルに構造化して書き出す。Plan モードでの調査結果や grill-me の議論を Plan 化したいとき、「to-plan」「plan ファイルにして」と指示されたときに使用する。必須セクション（設計書への影響・設計書更新タスク）を満たした Plan を ~/.claude/plans/ に保存し、続けて /check-plan による監査まで自動で行う。

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use when user wants to stress-test a plan, get grilled on their design, or mentions "grill me".

確認不要で手早く GitHub Issue を起票する。grill-me/to-plan/to-issues の正式フローを経由せず、思いついた要望・課題・バグをその場で軽量に Issue 化したいときに使う。「quick-issue」「issueを起票して」「issueを作って」と指示されたとき。

CDKコードを解析してAWSリソース構成図・Stack依存関係図・Constructツリーを生成し、cdk.out/visualization/に出力する。CDKプロジェクトの可視化を依頼されたときに使用すること。

docs/ 配下のドキュメントを横断的に走査し、文書間の重複（DRY違反）と矛盾（同じ事柄の食い違い）を検出する。単一ドキュメントの品質レビュー（/doc-review）とは別物で、文書群全体の整合性を監査したいときに使う。引数なしで docs/ 全体、'hub' で design-hub 配下、ファイルパスでそのファイルを起点に他文書と突合する。

git差分を分析し、フォーマットに従ったコミットを自動作成する。

backendとfrontendの単体テストを実行し、失敗を分析して詳細レポートを提供する。コード変更後のテスト実行、テスト結果の確認、失敗テストの修正を依頼されたときに使用すること。

指定したIssueを元に設計書を自律的に更新する仕様駆動開発サポートコマンド。Issue番号を引数で指定可能（例: /update-design 15）

ドキュメントファイルのレビューを実行し、品質・完全性・設計の妥当性に関する詳細なフィードバックを提供する。docs/ 配下の設計書（*-design.md）、PRD（requirements.md）、提案書（docs/idea/）、開発ガイドライン（.claude/rules/）など、あらゆる種別のMarkdownドキュメントに対応。ドキュメント種別を自動判定し、種別に応じたレビュー観点で評価する。ドキュメントのレビュー・品質チェックを依頼されたときに使用すること。実装コードとの整合性チェックは対象外（/validate-design で実施）。