RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
docs/ 配下を横断的に走査し、文書間の重複（DRY違反）と矛盾を検出する。「doc-consistency」「ドキュメントの整合性を見て」と指示されたとき。単一文書の品質レビューは /doc-review。
本番投入レディネスレビュー（PRR）。リリース直前に、組み上がったシステム全体が本番運用に耐えるかをSRE観点で審査し、go/条件付きgo/no-go を助言する。/sre-prr が呼ばれたとき、またはユーザーがリリース前の本番投入審査・PRRを依頼したときに使用する。個別のコード品質（/code-review）・アーキ品質（/arch-review）・設計整合（/validate-design）とは責務が異なり、「本番で安全に・低コストで運用し続けられるか」という全体の本番耐性だけを見る。
ドキュメント編集直後の軽量レビュー。よく指摘される項目だけを高速にチェックし、その場で修正する。「quick-doc-review」「軽くdocチェックして」と指示されたとき。大掛かりなレビューは /doc-review。
Interview the user relentlessly about a plan or design until reaching shared understanding, resolving each branch of the decision tree. Use for "grill me", 「仕様を詰めたい」「壁打ちして」。
grill-me の対話や事前調査の結果を Plan ファイルに構造化して書き出し、続けて /check-plan で監査する。「to-plan」「plan ファイルにして」と指示されたとき。