kasiopeiya
@kasiopeiya
Public Skills
cdk-imp
by kasiopeiya
AWS CDK実装専用コマンド。GitHub IssueからCDK実装・テスト・CDK合成まで自動実行する。CDKインフラの実装を依頼されたときに使用すること。
restore-toggles
by kasiopeiya
編集ツールに剥がされた トグルを、git 差分を見て消えたタグだけ戻す。本文の文字は変えない。「restore-toggles」「トグルを復元して」と指示されたとき。
devil
by kasiopeiya
意見を出す前に、切り離した反論エージェントに主張を潰させ、返ってきた反証条件を確認してから答える。後戻りコストの高い相談（設計・技術選定・方針決め）で使う。「devil」「反論して」「この意見を潰して」と指示されたとき。
code-dev
by kasiopeiya
'アプリケーション実装の一気通貫ワークフロー。実装→コードレビュー→CI→設計書整合性チェックまでを人間への確認なしに自律実行する。Issue番号を引数に指定すること（例: /code-dev 15）。CDKには使用しない。'
handoff
by kasiopeiya
このセッションの要点を tmp/handoff/ に markdown 1枚で書き出し、別セッションが続きから着手できるようにする。文脈が長くなったが、まだ Issue にはできない段階の退避に使う。「handoff」「引き継ぎファイルを作って」「別セッションに引き継いで」と指示されたとき。
requirements-review
by kasiopeiya
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
design
by kasiopeiya
'GitHub Issue をもとに設計書（docs/design/）を更新し、レビューと修正まで自律実行する。Issue番号を引数に指定すること（例: /design 15）'
doc-review
by kasiopeiya
Markdownドキュメントの品質をレビューする。種別を自動判定し、種別に応じた観点で評価する。「doc-review」「ドキュメントをレビューして」と指示されたとき。要件定義書は /requirements-review、実装との整合性は /validate-design を使う。
arch-review
by kasiopeiya
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
cdk-review
by kasiopeiya
infra/ 配下の AWS CDK インフラコードをレビューする。併せてインフラ設計書・IaC 設計書の内容の妥当性も見る。「cdk-review」「CDKコードをレビューして」と指示されたとき。
code-review
by kasiopeiya
TypeScript / React アプリケーションコードをレビューする。「code-review」「コードをレビューして」と指示されたとき。
brief
by kasiopeiya
対話中の回答を、常時の文体規定より一段平易にする。論点が2つ以上あれば冒頭に結論付きの論点マップを置き、専門用語には一行の言い換えを、抽象的な説明には具体例を必ず添える。「brief」「平易に説明して」「分かりやすく説明して」「論点を整理して」と指示されたとき。
sre-prr
by kasiopeiya
本番投入レディネスレビュー（PRR）。リリース直前に、組み上がったシステム全体が本番運用に耐えるかをSRE観点で審査し、go/条件付きgo/no-go を助言する。/sre-prr が呼ばれたとき、またはユーザーがリリース前の本番投入審査・PRRを依頼したときに使用する。個別のコード品質（/code-review）・アーキ品質（/arch-review）・設計整合（/validate-design）とは責務が異なり、「本番で安全に・低コストで運用し続けられるか」という全体の本番耐性だけを見る。
tdd
by kasiopeiya
GitHub IssueからTDD（Test-Driven Development）サイクルを実行し、テストと実装を段階的に作成。アプリケーションコードの実装にTDDを適用する際に使用。
pr-check
by kasiopeiya
PR がレビューを受け付けてよい前提条件（差分サイズ）を満たすかを判定し、結果を PR にコメントする。「pr-check」「PRをチェックして」と指示されたとき。
design-doc-mermaid
by kasiopeiya
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", 「図を描く」「図にする」「アーキテクチャ図」。
cdk-dev
by kasiopeiya
'CDK実装の一気通貫ワークフロー。実装→コードレビュー→CI までを人間への確認なしに自律実行する。Issue番号を引数に指定すること（例: /cdk-dev 15）。アプリケーションコードには使用しない。'
elicit-requirements
by kasiopeiya
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
unit-test
by kasiopeiya
各npmワークスペースの単体テストを実行し、失敗を分析して詳細レポートを提供する。コード変更後のテスト実行やテスト結果の確認を依頼されたときに使用すること。修正は行わない。
issue-regroup
by kasiopeiya
open な子が全部ブロッカー待ちで止まった親 Issue を、子を他の親へ移して close する。「issue-regroup」「親issueを閉じられるようにして」「子を付け替えて」と指示されたとき。
issue-deps
by kasiopeiya
open Issue の依存を棚卸しし、ブロッカー節と段番号を直して、着手できる Issue の一覧を出す。「issue-deps」「issueの依存を棚卸しして」「着手順を振り直して」と指示されたとき。
origin-search
by kasiopeiya
発信元の原典（一次資料）だけを根拠に web を調べ、主張ごとに出典URLを付けて答える。原典で確かめられなければ答えず「確認できなかった」と返す。「origin-search」「一次資料で調べて」「出典付きで調べて」「原典に当たって」と指示されたとき。
validate-design
by kasiopeiya
設計書と実装コードの整合性（ドリフト）を検証する。「validate-design」「設計書と実装の整合性チェック」と指示されたとき。
code-ci
by kasiopeiya
各npmワークスペースの静的解析・単体テストを実行する（CIパイプラインシミュレーション）。CIチェックやコミット・PR前のコード品質検証を依頼されたときに使用すること。