kasiopeiya/claude-dev-template

brief

対話中の回答を、常時の文体規定より一段平易にする。論点が2つ以上あれば冒頭に結論付きの論点マップを置き、専門用語には一行の言い換えを、抽象的な説明には具体例を必ず添える。「brief」「平易に説明して」「分かりやすく説明して」「論点を整理して」と指示されたとき。

Source text: Japanese

cdk-imp

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

Source text: Japanese

check-plan

Plan ファイルを Issue 化前に監査し、必須セクションの充足と影響範囲の網羅をチェックする。「check-plan」「plan をチェック」と指示されたとき。

Source text: Japanese

code-review

TypeScript / React アプリケーションコードをレビューする。「code-review」「コードをレビューして」と指示されたとき。

Source text: Japanese

create-adr

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

Source text: Japanese

decide-tech-stack

新規開発の立ち上げで、requirements.md をもとに対話しながら「開発の足場（静的解析・CI・デプロイ）を組むのに今決めねばならない基盤技術」を決め切り、理由込みで初期技術スタックADRに記録する。使用言語・クラウド・IaC・CI/CD などを確定し、FW・DB等の詳細はあえて保留する。技術スタック選定・初期技術スタックADR作成を依頼されたとき、または「decide-tech-stack」と指示されたときに使う。

Source text: Japanese

design-doc-mermaid

Create Mermaid diagrams from text or source code, selecting the diagram type from the shape of the information (flowchart is the last resort). Use for "create a diagram", "generate mermaid", "code to diagram", 「図を描く」「図にする」「アーキテクチャ図」。

devil

意見を出す前に、切り離した反論エージェントに主張を潰させ、返ってきた反証条件を確認してから答える。後戻りコストの高い相談（設計・技術選定・方針決め）で使う。「devil」「反論して」「この意見を潰して」と指示されたとき。

Source text: Japanese

doc-review

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

Source text: Japanese

git-commit

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

Source text: Japanese

grill-me

Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Agrees the interview's scope in one sentence first and refuses to walk outside it. Use for "grill me",…

handoff

このセッションの要点を tmp/handoff/ に markdown 1枚で書き出し、別セッションが続きから着手できるようにする。文脈が長くなったが、まだ Issue にはできない段階の退避に使う。「handoff」「引き継ぎファイルを作って」「別セッションに引き継いで」と指示されたとき。

Source text: Japanese

issue-check

boy-scout ラベルの open Issue を「やる価値があるか」「対応方針がポリシーに合っているか」で判定し、本文とラベルを直す。/sweep で着手する前に人間が打つ。「issue-check」「issueを検査して」と指示されたとき。

Source text: Japanese

issue-decide

issue:needs-human-decision が付いた boy-scout Issue の論点を1件ずつ人間に示し、決まった方針を本文へ書き戻して ai-fixable に変換する。/sweep の前処理として人間が打つ。「issue-decide」「人間判断待ちのissueを片付けて」と指示されたとき。

Source text: Japanese

issue-deps

open Issue の依存を棚卸しし、ブロッカー節と段番号を直して、着手できる Issue の一覧を出す。「issue-deps」「issueの依存を棚卸しして」「着手順を振り直して」と指示されたとき。

Source text: Japanese

issue-regroup

open な子が全部ブロッカー待ちで止まった親 Issue を、子を他の親へ移して close する。「issue-regroup」「親issueを閉じられるようにして」「子を付け替えて」と指示されたとき。

Source text: Japanese

issue-split

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

Source text: Japanese

origin-search

発信元の原典（一次資料）だけを根拠に web を調べ、主張ごとに出典URLを付けて答える。原典で確かめられなければ答えず「確認できなかった」と返す。「origin-search」「一次資料で調べて」「出典付きで調べて」「原典に当たって」と指示されたとき。

Source text: Japanese

pr-check

PR がレビューを受け付けてよい前提条件を満たすかを判定し、結果を PR にコメントする。「pr-check」「PRをチェックして」と指示されたとき。

Source text: Japanese

pr-viz

指定したPRを図中心のHTML1枚にまとめて tmp/visual/ に出力する。差分を開く前に全体像と重点を掴むために使う。「pr-viz」「PRを可視化して」「PRを図にして」と指示されたとき。

Source text: Japanese

quick-doc-review

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

Source text: Japanese

quick-issue

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

Source text: Japanese

requirements-review

要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。

Source text: Japanese

restore-toggles

編集ツールに剥がされた `<details>` トグルを、git 差分を見て消えたタグだけ戻す。本文の文字は変えない。「restore-toggles」「トグルを復元して」と指示されたとき。

Source text: Japanese

sre-prr

本番投入レディネスレビュー（PRR）。リリース直前に、組み上がったシステム全体が本番運用に耐えるかをSRE観点で審査し、go/条件付きgo/no-go を助言する。/sre-prr が呼ばれたとき、またはユーザーがリリース前の本番投入審査・PRRを依頼したときに使用する。個別のコード品質（/code-review）・アーキ品質（/arch-review）・設計整合（/validate-design）とは責務が異なり、「本番で安全に・低コストで運用し続けられるか」という全体の本番耐性だけを見る。

Source text: Japanese

sweep

ai-fixable が付いた open Issue を1件ずつ片付け、コミットして close する。人間が `/sweep` と打ったときだけ起動する。

Source text: Japanese

tdd

GitHub IssueからTDD（Test-Driven Development）サイクルを実行し、テストと実装を段階的に作成。アプリケーションコードの実装にTDDを適用する際に使用。

Source text: Japanese

to-issues

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

Source text: Japanese

to-plan

grill-me の対話や事前調査の結果を Plan ファイルに構造化して書き出し、続けて /check-plan で監査する。「to-plan」「plan ファイルにして」と指示されたとき。

Source text: Japanese

update-design

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

Source text: Japanese

vis

会話で扱った内容や指定されたテーマを、図中心のHTML1枚にまとめて tmp/visual/ に出力する。複雑な話を可視化して掴みやすくするために使う。「vis」「図にして」「可視化して」「HTMLにまとめて」と指示されたとき。

Source text: Japanese

elicit-requirements

RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。

Source text: Japanese

cdk-review

infra/ 配下の AWS CDK インフラコードをレビューする。併せてインフラ設計書・IaC 設計書の内容の妥当性も見る。「cdk-review」「CDKコードをレビューして」と指示されたとき。

Source text: Japanese

design

GitHub Issue をもとに設計書（docs/design/）を更新し、レビューと修正まで自律実行する。Issue番号を引数に指定すること（例: /design 15）

Source text: Japanese

cdk-dev

CDK実装の一気通貫ワークフロー。実装→コードレビュー→CI までを人間への確認なしに自律実行する。Issue番号を引数に指定すること（例: /cdk-dev 15）。アプリケーションコードには使用しない。

Source text: Japanese

code-dev

アプリケーション実装の一気通貫ワークフロー。実装→コードレビュー→CI→設計書整合性チェックまでを人間への確認なしに自律実行する。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。

Source text: Japanese

arch-review

アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。

Source text: Japanese

doc-consistency

docs/ 配下を横断的に走査し、文書間の重複（DRY違反）と矛盾を検出する。「doc-consistency」「ドキュメントの整合性を見て」と指示されたとき。単一文書の品質レビューは /doc-review。

Source text: Japanese

pr-label

PR に「変更の種類」ラベルと、人間レビューの要否を示すラベルを付ける。「pr-label」「PRにラベルを付けて」と指示されたとき。

Source text: Japanese

code-ci

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

Source text: Japanese