kasiopeiya

sre-prr

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

kasiopeiya 0 Updated 4w ago

Resources

1
GitHub

Install

npx skillscat add kasiopeiya/claude-dev-template/sre-prr

Install via the SkillsCat registry.

SKILL.md

本番投入レディネスレビュー(PRR)を実施してください。これはリリース直前の最終防衛線です。見るのは組み上がったシステム全体が本番運用に耐えるかという一点だけです——仕様どおり動くか(リリース判定)・プログラム単体の品質(/code-review)・アーキの質(/arch-review)・設計と実装の整合(/validate-design)には踏み込まないでください(それぞれ別スキルの責務)。

中核の問い:このシステムを本番に入れて、安全に・低コストで運用し続けられるか。 リリース後の重大障害と運用トイルの爆発を未然に防ぐのが目的です。

このスキルの立ち位置(重複を作らない)

PRR はゲート+参照集約型です。既存の資産と重複させないため、次を厳守してください。

  • 判定基準は既存ポリシーを SSOT として参照し、転記しない。 監視→docs/policy/monitoring-policy.md、手順書→docs/policy/runbook-policy.md、依存→docs/policy/dependency-policy.md。
  • 既存ポリシーが無いギャップ領域(リリース/ロールバック・性能/SLO・回復性/DR)の基準だけ、references/readiness-rubric.md に自己完結で持つ。
  • 開発フローで issue 単位に済んだ検査は再実行しない。 /code-review・/cdk-review・/arch-review・CI は再実行せず「実施済みか」を確認する(下記「証拠モデル」)。
  • セキュリティは丸投げしない。 /security-review は差分ベースで PRR の全体スコープと粒度が違う。PRR は依存スキャン・秘密の直書き・security-review の実施状況を自分で確認し、/security-review は「古ければ実行を推奨する補助」に留める。

審査は静的(限界を明記する)

PRR はコード・ドキュメント・CI/GitHub 状態を静的に読みます。ライブ AWS 環境は照会しません(手動スキルに認証・コンテキストが無く、.claude/rules/cdk.md も実行時 SDK を抑制)。「コードにアラーム定義があるか」は検査できますが、「実際にデプロイされ発報するか」は検査できません(結合テスト・実運用の領域)。この限界をレポートに必ず注記してください。

証拠モデル

  • 直接検査(PRR が自分で見る):リリース/ロールバック経路・回復性/DR・監視 vs monitoring-policy・性能/SLO と依存限界。
  • 機械確認(検証可能な信号):CI green(静的解析・単体テスト)・結合テスト pass・期待される PR ラベル。
  • 人間 attest(永続証跡が残らないもの):/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 が埋もれる

タイトルの先頭ラベルは省略しないでください——本文を開かないと指摘の重さが分からない状態を避けるためです。タイトルの先頭には段番号を付けてください(例:1. [fail] …)。振り方は Issueの階層ガイド(docs/reference/issue-hierarchy.md)の「段番号(着手順)」に従います。

本文の書き方・ラベル・起票前セルフチェックは .claude/skills/quick-issue/SKILL.md が正典です。Read して従ってください。

Issue 本文の「現状」には、レポートの審査領域・判断理由・解消すべき点を書き写してください(レポートを読み返さずに着手できるように)。ライブ AWS 環境を照会していない限界も併記してください。

引数: $ARGUMENTS