メニュー
Use when generating operational runbooks from code and infrastructure — produces runbooks that work at 3 AM, covering common failure scenarios with specific diagnosis and resolution steps, copy-pasteable commands, and clear escalation paths.
Codex または Claude でインストール この Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。
SOC 職業分類に基づく
| name | sbp-runbook-author |
| description | Use when generating operational runbooks from code and infrastructure — produces runbooks that work at 3 AM, covering common failure scenarios with specific diagnosis and resolution steps, copy-pasteable commands, and clear escalation paths. |
| metadata | {"domain":"platform","lifecycle":"run"} |
Generate a runbook for the system under review by reading the actual codebase: configs, deployment files, monitoring setup, error handling patterns, and dependency declarations. The runbook must be usable by an on-call engineer at 3 AM under pressure — no vague instructions, no assumptions about tribal knowledge.
Start with what matters when you get paged.
Source this from: README files, deployment configs (Kubernetes manifests, Terraform, CloudFormation), service mesh configs, dependency declarations (package.json, requirements.txt, go.mod).
Document how to tell if the system is healthy right now.
Source this from: health check implementations in code, monitoring configs (Prometheus rules, Datadog monitors, Grafana dashboards), logging configuration, alerting rules.
For each scenario below, provide the full incident response flow. Only include scenarios that are relevant to the system — skip what does not apply, add system-specific scenarios found in the code.
For each scenario, document:
Source scenario details from: error handling code, retry logic, circuit breaker configs, fallback implementations, health check failure modes, known issues in commit history.
On-call needs to know what changed recently because changes cause incidents.
Source this from: CI/CD configs (GitHub Actions, GitLab CI, Jenkins, ArgoCD), deployment scripts, release processes.
Produce a single structured markdown document with:
A runbook that cannot be followed under pressure at 3 AM is useless. Optimize for clarity and actionability over completeness.
Use when building any UI, HTML component, slide, document, or design asset that will represent SBP visually — applies the Schuberg Philis visual brand identity (colors, typography, logo, stylization, grids, photography, iconography) to ensure brand-consistent output without manual reminders.
Use when conducting a security review, reducing dependency surface, or when dependencies may pose supply-chain, bloat, or maintainability risks.
Use when deploying to production — verifies rollback readiness, monitoring, and change communication against mission-critical criteria and produces a go/no-go decision.
Use when a production incident has occurred — structured blameless post-incident analysis that reconstructs timeline, assesses impact, finds root causes, and produces concrete action items.
Use when verifying monitoring, alerting, and logging coverage — checks the four pillars (metrics, logs, traces, alerts), produces a coverage matrix with gaps, severity ratings, and recommended actions, and applies the 3 AM test to every component.
Use when existing code needs to change shape before a feature, or when code drift is making further work expensive — improves structure and readability without changing observable behavior.
