kasiopeiya

大きすぎる／複数の関心事を含む既存 GitHub Issue を sub-issue に割り、親を umbrella に作り替える。「issue-split」「issueを分割して」「issueをsub-issueに割って」と指示されたとき。

Plan・仕様・PRD を曳光弾（縦スライス）に分け、それぞれ独立して着手できる Issue にする。「issue化して」「issueに分割して」と指示されたとき。

Markdownドキュメントの品質をレビューする。種別を自動判定し、種別に応じた観点で評価する。「doc-review」「ドキュメントをレビューして」と指示されたとき。要件定義書は /requirements-review、実装との整合性は /validate-design を使う。

ドキュメント編集直後の軽量レビュー。よく指摘される項目だけを高速にチェックし、その場で修正する。「quick-doc-review」「軽くdocチェックして」と指示されたとき。大掛かりなレビューは /doc-review。

指定したIssueを元に設計書を自律的に更新する。Issue番号を引数で指定可能（例: /update-design 15）

ADR（Architecture Decision Record）を作成、またはADR対象かどうかを判定する。意思決定の文書化・ADRの要否確認を依頼されたときに使う。

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

確認不要で手早く GitHub Issue を起票する。思いついた要望・課題・バグ・割れ窓の起票に使う。「quick-issue」「issueを起票して」「issueを作って」と指示されたとき。

AWS CDK インフラコードを詳細にレビュー。/cdk-review コマンドが呼ばれたとき、またはユーザーが CDK コードのレビューを依頼したときに使用する。cdk/ ディレクトリ内の TypeScript ファイルを対象に、型安全性・CDK ベストプラクティス・プロジェクトルール準拠を自動チェックする。

CDKインフラコードの静的解析・スナップショットテスト・cdk synthを実行する。インフラコードのCDK CIチェックを依頼されたときに使用すること。

cdk diffを実行し、変更内容をMarkdownテーブルで整形して表示する。インフラ変更のレビューやデプロイ前確認に使用する。

backendとfrontendの静的解析・単体テストを実行する（CIパイプラインシミュレーション）。CIチェックやコミット・PR前のコード品質検証を依頼されたときに使用すること。

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

設計書（docs/design/）とアプリケーションコード（backend/、frontend/）の整合性を検証する。 「/validate-design」「設計書と実装の整合性チェック」と指示されたときに使用する。

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

AWS CDK実装専用コマンド。GitHub IssueからCDK実装・テスト・CDK合成まで自動実行する。CDKインフラの実装を依頼されたときに使用すること。

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

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