菜单
本番投入レディネスレビュー（PRR）。リリース直前に、組み上がったシステム全体が本番運用に耐えるかをSRE観点で審査し、go/条件付きgo/no-go を助言する。/sre-prr が呼ばれたとき、またはユーザーがリリース前の本番投入審査・PRRを依頼したときに使用する。個別のコード品質（/code-review）・アーキ品質（/arch-review）・設計整合（/validate-design）とは責務が異なり、「本番で安全に・低コストで運用し続けられるか」という全体の本番耐性だけを見る。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/kasiopeiya/claude-dev-template --skill sre-prr命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
RFC等の入力資料をもとに対話しながら要求を引き出し、requirements.md（PRD）を作成する。顧客が書いた「解決策」を「目的」に還元し、「制約」とされた事項が本当に制約かを疑いながら、目的の認識を合わせて要件を確定する。要求分析・要件定義・requirements.md作成を依頼されたとき、または「elicit-requirements」と指示されたときに使う。
要件定義書（docs/requirements.md）を requirements-doc-policy の基準でレビューし、凍結してよい品質かを合否判定する。「requirements-review」「要件定義書をレビューして」と指示されたとき。
アプリの設計・アーキテクチャの「質」をレビューする。UI/DB/外部サービス/言語などの詳細を差し替え可能に保てているかを検査する。「arch-review」「設計をレビューして」「アーキテクチャをレビューして」と指示されたとき。
正在显示 SKILL.md
| name | sre-prr |
| description | 本番投入レディネスレビュー（PRR）。リリース直前に、組み上がったシステム全体が本番運用に耐えるかをSRE観点で審査し、go/条件付きgo/no-go を助言する。/sre-prr が呼ばれたとき、またはユーザーがリリース前の本番投入審査・PRRを依頼したときに使用する。個別のコード品質（/code-review）・アーキ品質（/arch-review）・設計整合（/validate-design）とは責務が異なり、「本番で安全に・低コストで運用し続けられるか」という全体の本番耐性だけを見る。 |
| argument-hint | [リリース対象/スコープ。省略時はシステム全体] |
| disable-model-invocation | true |
| context | fork |
| agent | sre-prr-reviewer-agent |
本番投入レディネスレビュー（PRR）を実施してください。これはリリース直前の最終防衛線です。見るのは組み上がったシステム全体が本番運用に耐えるかという一点だけです——仕様どおり動くか（リリース判定）・プログラム単体の品質（/code-review）・アーキの質（/arch-review）・設計と実装の整合（/validate-design）には踏み込まないでください（それぞれ別スキルの責務）。
中核の問い：このシステムを本番に入れて、安全に・低コストで運用し続けられるか。 リリース後の重大障害と運用トイルの爆発を未然に防ぐのが目的です。
PRR はゲート＋参照集約型です。既存の資産と重複させないため、次を厳守してください。
docs/policy/monitoring-policy.md、手順書→docs/policy/runbook-policy.md、依存→docs/policy/dependency-policy.md。references/readiness-rubric.md に自己完結で持つ。/code-review・/cdk-review・/arch-review・CI は再実行せず「実施済みか」を確認する（下記「証拠モデル」）。/security-review は差分ベースで PRR の全体スコープと粒度が違う。PRR は依存スキャン・秘密の直書き・security-review の実施状況を自分で確認し、/security-review は「古ければ実行を推奨する補助」に留める。PRR はコード・ドキュメント・CI/GitHub 状態を静的に読みます。ライブ AWS 環境は照会しません（手動スキルに認証・コンテキストが無く、.claude/rules/cdk.md も実行時 SDK を抑制）。「コードにアラーム定義があるか」は検査できますが、「実際にデプロイされ発報するか」は検査できません（結合テスト・実運用の領域）。この限界をレポートに必ず注記してください。
monitoring-policy・性能/SLO と依存限界。/code-review・/cdk-review・/arch-review の実施有無は検証できないため、AskUserQuestion で一度だけ確認し、回答をレポートに記録する。判定基準（各領域・pass/warn/fail/N-A の定義・総合 go/no-go の集約）は references/readiness-rubric.md、レポート様式は references/report-format.md に従ってください。design-hub.md・requirements.md が未作成の環境（テンプレート段階）でも破綻せず、該当領域を N-A（前提未整備）として報告してください。
レポートを出力したら、続けて gh issue create で GitHub Issue を起票してください。ユーザーへの確認は行いません（CLAUDE.md の boy-scout ルール）。全領域が pass（総合 go）なら起票しません。
| 起票対象 | 粒度 | タイトル | なぜ |
|---|---|---|---|
| fail | 1件ごとに1 Issue | [fail] 本番投入: <解消すべき点> | リリースを止める条件は1件ずつ解消・クローズされる。束ねると一部だけ直った状態が残る |
| warn | 全件まとめて1 Issue | [warn] PRR 指摘まとめ（リスク受容） | リスクを受容するかの判断は並べて見た方がぶれない。件数分に割ると fail の Issue が埋もれる |
タイトルの先頭ラベルは省略しないでください——本文を開かないと指摘の重さが分からない状態を避けるためです。
本文の書き方・ラベル・起票前セルフチェックは .claude/skills/quick-issue/SKILL.md が正典です。Read して従ってください。
Issue 本文の「現状」には、レポートの審査領域・判断理由・解消すべき点を書き写してください（レポートを読み返さずに着手できるように）。ライブ AWS 環境を照会していない限界も併記してください。
引数: $ARGUMENTS