Claude prompts that write your runbooks for you

You are a release engineer. <context> Your team ships to production multiple times a week and needs a standard runbook every deployer follows so releases are boring and predictable. </context> <inputs> - Deploy pipeline: [PLACEHOLDER, e.g. GitHub Actions to ECS via CodeDeploy] - Pre-deploy checks: [PLACEHOLDER, e.g. staging smoke tests, migration dry run] - Rollback mechanism: [PLACEHOLDER, e.g. redeploy previous image tag] - Deploy window policy: [PLACEHOLDER, e.g. no deploys after 4pm Friday] </inputs> <task> Write a production deploy runbook: pre-deploy checklist, the deploy sequence step by step, the health checks to run immediately after, the go/no-go decision point, and the rollback trigger criteria (what error rate or latency spike means "roll back now"). </task> <constraints> - Give numeric rollback trigger thresholds, not "if things look bad" - Include the exact command or button for both deploying and rolling back - Keep the checklist short enough that a deployer actually follows it every time </constraints> <format> A markdown runbook with a pre-deploy checklist, numbered deploy steps, and a rollback trigger table: Signal | Threshold | Action. </format>

You are a release engineer. <context> A deploy just caused a regression and the team needs the exact rollback runbook rather than improvising under pressure. </context> <inputs> - Deploy target: [PLACEHOLDER, e.g. Kubernetes deployment 'web' on EKS] - Versioning scheme: [PLACEHOLDER, e.g. Docker image tags, one per commit SHA] - Database migration state: [PLACEHOLDER, e.g. migrations are backward-compatible for 1 version] - Traffic management: [PLACEHOLDER, e.g. Argo Rollouts canary at 20%] </inputs> <task> Write a rollback runbook: how to identify the last known-good version, the exact rollback command, how to handle any database migrations that ran with the bad deploy, how to verify the rollback succeeded, and how to communicate the rollback to the team. </task> <constraints> - Address the database migration edge case explicitly, do not assume code-only rollback - Include a verification step with a concrete pass/fail signal - State the maximum safe time to decide (e.g. do not deliberate past 10 minutes) </constraints> <format> A markdown runbook with sections: Identify Last Good Version, Roll Back Code, Handle Migrations, Verify, Communicate. </format>

You are a platform engineer who owns feature flag infrastructure. <context> You are rolling out a new feature behind a flag and need a runbook for a staged, monitored rollout rather than a flip-the-switch launch. </context> <inputs> - Feature and flag name: [PLACEHOLDER, e.g. new-checkout-flow] - Flag platform: [PLACEHOLDER, e.g. LaunchDarkly] - Rollout stages: [PLACEHOLDER, e.g. internal, 5%, 25%, 100%] - Guardrail metrics: [PLACEHOLDER, e.g. checkout conversion rate, error rate] </inputs> <task> Write a rollout runbook: the percentage stages and dwell time at each, the guardrail metrics to watch and their kill thresholds, the exact flag change to make at each stage, and the kill-switch procedure if a guardrail trips. </task> <constraints> - Give a specific dwell time (e.g. 2 hours) at each stage before advancing, not "monitor for a while" - Kill-switch step must be a single flag flip, not a deploy - Include what to check before advancing to the next stage </constraints> <format> A markdown runbook with a rollout stage table: Stage | % | Dwell Time | Guardrail Check | Advance/Kill Criteria. </format>

You are a database reliability engineer. <context> You need to run a schema migration against a production database used by a live application, and want a runbook that avoids downtime or data loss. </context> <inputs> - Database and size: [PLACEHOLDER, e.g. PostgreSQL, 40M row 'orders' table] - Migration type: [PLACEHOLDER, e.g. add nullable column, backfill, add NOT NULL constraint] - Migration tool: [PLACEHOLDER, e.g. Prisma Migrate, Flyway] - Traffic pattern: [PLACEHOLDER, e.g. read-heavy, peak traffic 9am to 6pm] </inputs> <task> Write a migration runbook that sequences the change so old and new code both work during rollout (expand, backfill, contract), states which steps are safe to run during peak traffic and which are not, and includes a verification query after each phase plus a rollback path for each phase. </task> <constraints> - Never propose a single-step destructive change (drop column, add NOT NULL directly) on a populated table - Name the maintenance window only if truly required, and justify why - Include the exact verification query to run after each phase </constraints> <format> A markdown runbook with phases: Expand (additive), Backfill, Verify, Contract (cleanup), each with commands and a rollback note. </format>

You are a release engineer. <context> A critical bug needs a fix shipped to production outside the normal release cadence, and you need a runbook that moves fast without skipping the checks that matter. </context> <inputs> - Bug and severity: [PLACEHOLDER, e.g. payment retries duplicate charges, Sev1] - Normal release process being bypassed: [PLACEHOLDER, e.g. weekly Tuesday release train] - Test coverage on the fix: [PLACEHOLDER, e.g. unit test added, no full regression run] - Approval requirement: [PLACEHOLDER, e.g. one engineer + on-call lead sign-off] </inputs> <task> Write a hotfix runbook: the minimum checks that cannot be skipped even under time pressure, the fast-path deploy sequence, who must approve before it ships, and the follow-up required afterward (backfilling the skipped tests, notifying the team that a hotfix bypassed normal review). </task> <constraints> - Name the non-negotiable checks explicitly (e.g. "fix must have at least one automated test") and separate them from steps that can be skipped - Require a named approver, not "get approval" - Include the follow-up task to reconcile the hotfix with the normal release branch </constraints> <format> A markdown runbook with sections: Non-Negotiable Checks, Fast-Path Deploy Steps, Required Approval, Post-Hotfix Follow-Up. </format>

You are an engineering manager running an on-call rotation. <context> You need a standard handoff runbook so context does not get lost when on-call rotates between engineers each week. </context> <inputs> - Rotation schedule: [PLACEHOLDER, e.g. weekly, Monday 10am handoff] - Team and services covered: [PLACEHOLDER, e.g. payments team, 6 services] - Handoff tool: [PLACEHOLDER, e.g. shared doc + 15 min sync call] - Open issues tracker: [PLACEHOLDER, e.g. Jira label 'on-call-carryover'] </inputs> <task> Write a handoff runbook and a fillable handoff template: what the outgoing on-call must document (open incidents, flaky alerts, in-progress mitigations, anything watched but not acted on), and what the incoming on-call must confirm before the outgoing signs off. </task> <constraints> - Template must have specific fields, not a blank "notes" section - Include a sign-off step where both engineers confirm the handoff explicitly - Keep the handoff process under 20 minutes </constraints> <format> A markdown runbook plus a fillable handoff template with fields: Open Incidents, Watch List, Recent Changes, Known Flaky Alerts, Sign-Off. </format>

You are an engineering manager designing an incident escalation policy. <context> On-call engineers need a clear runbook for when and how to escalate an incident they cannot resolve alone. </context> <inputs> - Team structure: [PLACEHOLDER, e.g. primary on-call, secondary on-call, EM, VP Eng] - Escalation triggers: [PLACEHOLDER, e.g. no progress after 30 minutes, Sev1 confirmed] - Paging tool: [PLACEHOLDER, e.g. PagerDuty escalation policy] - Time-to-escalate targets: [PLACEHOLDER, e.g. 15 minutes for Sev1] </inputs> <task> Write an escalation runbook: the specific triggers that require escalating (not "when you feel stuck"), who gets paged at each level, the maximum time to wait before escalating further, and what information must accompany the escalation so the next person isn't starting cold. </task> <constraints> - Every trigger must be a concrete, observable condition - Give a specific time limit per escalation level - Require a standard handoff summary format when escalating, not a free-form ping </constraints> <format> A markdown runbook with an escalation ladder table: Level | Who | Trigger | Time Limit | Required Handoff Info. </format>

You are a site reliability engineer who owns the alerting system. <context> Your on-call rotation is getting paged for a mix of real and noisy alerts and needs a runbook for triaging each page consistently. </context> <inputs> - Alert examples: [PLACEHOLDER, e.g. high CPU, 5xx rate spike, queue depth] - Monitoring stack: [PLACEHOLDER, e.g. Prometheus + Alertmanager] - Known noisy alerts: [PLACEHOLDER, e.g. CPU alert fires on nightly batch job] - Runbook links per alert: [PLACEHOLDER, e.g. each alert has a linked wiki page] </inputs> <task> Build a triage runbook and matrix: for each alert type, the first check to run, whether it is actionable right now or can wait until business hours, the fix or the mitigation, and when to snooze vs when to never snooze it. </task> <constraints> - Explicitly flag known noisy alerts and state the fix (better threshold, not permanent snooze) - Every alert must map to one first action, not a list of maybes - Distinguish "page now" alerts from "ticket for morning" alerts clearly </constraints> <format> A markdown alert triage table: Alert | First Check | Actionable Now? | Fix/Mitigation | Snooze Policy. </format>

You are an engineering manager setting paging standards for a growing team. <context> As the team and service count grow, you need a written policy for what is allowed to page a human at 3am versus what becomes a ticket. </context> <inputs> - Team size and services: [PLACEHOLDER, e.g. 8 engineers, 12 services] - Current pain point: [PLACEHOLDER, e.g. 40% of pages are non-actionable] - SLA commitments: [PLACEHOLDER, e.g. 99.9% uptime, 15 min response for Sev1] - Paging tool: [PLACEHOLDER, e.g. PagerDuty] </inputs> <task> Write a paging policy runbook: the criteria an alert must meet to page a human (customer-impacting, actionable, urgent), the criteria that make it a ticket instead, a quarterly review process for pruning noisy alerts, and how the policy gets enforced when a new alert is added. </task> <constraints> - Give a concrete decision test (e.g. three yes/no questions) for "does this deserve a page" - Include an ongoing review cadence, not a one-time cleanup - Tie the policy to the stated SLA so severity mapping is defensible </constraints> <format> A markdown policy doc with a decision flowchart (as numbered questions) and a quarterly alert review checklist. </format>

You are an operations manager coordinating cross-team incident response. <context> An after-hours incident sometimes needs someone outside engineering (support lead, comms, an executive) and you need a runbook for reaching them without guesswork. </context> <inputs> - Roles that may need contacting: [PLACEHOLDER, e.g. Head of Support, VP Eng, Comms Lead] - Contact methods and order: [PLACEHOLDER, e.g. phone call first, then SMS, then email] - Trigger conditions per role: [PLACEHOLDER, e.g. VP Eng only for Sev1 lasting over 30 min] - Backup contacts: [PLACEHOLDER, e.g. deputy for each role] </inputs> <task> Build an after-hours contact runbook: which role to contact for which incident type, the trigger condition that justifies waking someone up, the contact order and backup if unreachable, and a template message to send that gives them what they need in one read. </task> <constraints> - Every contact must have a stated trigger condition, no "contact if it seems bad" - Include a backup contact for every primary in case of no response within a stated time - Message template must fit in one screen (roughly 60 words) </constraints> <format> A markdown runbook with a contact table: Role | Trigger | Contact Order | Backup | Wait Before Backup, plus one message template. </format>

You are a DevOps engineer. <context> A service occasionally needs a controlled restart to clear a stuck state, and you want a runbook that does this safely instead of an ad hoc kill command. </context> <inputs> - Service and platform: [PLACEHOLDER, e.g. 'notifications-worker' on Kubernetes] - Symptoms that trigger a restart: [PLACEHOLDER, e.g. memory leak, stuck queue consumer] - Graceful shutdown behavior: [PLACEHOLDER, e.g. drains in-flight jobs for 30s] - Restart command: [PLACEHOLDER, e.g. kubectl rollout restart deployment/notifications-worker] </inputs> <task> Write a restart runbook: how to confirm a restart is the right fix (not masking a worse problem), the graceful restart sequence that avoids dropping in-flight work, the health checks to run after, and when a restart is not appropriate and should be escalated instead. </task> <constraints> - Include the check that distinguishes "restart will fix this" from "restart will just hide it and it comes back" - Restart sequence must preserve in-flight work where the service supports it - State the exact post-restart health signal to confirm success </constraints> <format> A markdown runbook with sections: When To Restart, When Not To, Restart Sequence, Post-Restart Verification. </format>

You are a backend infrastructure engineer. <context> Stale or corrupted cache entries are causing incorrect data to be served, and you need a runbook for invalidating safely without a thundering herd on the origin. </context> <inputs> - Cache layer: [PLACEHOLDER, e.g. Redis, CDN edge cache (Cloudflare)] - Scope of bad data: [PLACEHOLDER, e.g. one product's price cached wrong, or a full key prefix] - Origin capacity: [PLACEHOLDER, e.g. origin can handle 500 req/s before degrading] - Invalidation tooling: [PLACEHOLDER, e.g. redis-cli, Cloudflare purge API] </inputs> <task> Write a cache invalidation runbook: how to scope the invalidation as narrowly as possible, the exact command for the stated cache layer, how to avoid overwhelming the origin when the cache refills (staggered warm, rate limiting), and the verification that stale data is actually gone for end users. </task> <constraints> - Prefer narrow-scope invalidation over full flush, and state why in the runbook - Include a thundering-herd mitigation step whenever a broad invalidation is unavoidable - Verification must check from the user's perspective (a real request), not just cache stats </constraints> <format> A markdown runbook with sections: Scope The Blast Radius, Invalidate, Protect The Origin, Verify From The Edge. </format>

You are a network infrastructure engineer. <context> A backend node or entire availability zone behind your load balancer is unhealthy and you need a failover runbook that redirects traffic cleanly. </context> <inputs> - Load balancer type: [PLACEHOLDER, e.g. AWS ALB with target groups across 3 AZs] - Health check config: [PLACEHOLDER, e.g. /healthz every 10s, 3 failures to mark unhealthy] - Failover target: [PLACEHOLDER, e.g. remaining healthy AZs, or a standby region] - Traffic volume: [PLACEHOLDER, e.g. 2000 req/s average] </inputs> <task> Write a failover runbook: how to confirm the health check is correctly flagging the bad node or zone, how to manually force failover if automatic health checks are slow to react, the capacity check to confirm remaining nodes can absorb the traffic, and how to restore the failed node once it recovers. </task> <constraints> - Include the manual override commands, do not rely solely on automatic health checks - Capacity check must use real numbers (current traffic vs remaining node capacity) - Cover safely restoring the recovered node back into rotation, including a canary step </constraints> <format> A markdown runbook with sections: Confirm Unhealthy, Force Failover, Capacity Check, Restore Recovered Node. </format>

You are a systems administrator. <context> A host or database is approaching full disk, which risks a crash, and you need a runbook to recover space safely under time pressure. </context> <inputs> - System: [PLACEHOLDER, e.g. Postgres primary, /var/lib/postgresql at 92% full] - Likely space consumers: [PLACEHOLDER, e.g. WAL logs, old backups, Docker images] - Safe-to-delete list: [PLACEHOLDER, e.g. anything in /tmp older than 48h] - Monitoring alert threshold: [PLACEHOLDER, e.g. pages at 85%, critical at 95%] </inputs> <task> Write a disk space recovery runbook: how to identify what is actually consuming space (commands, not guessing), the order to reclaim space starting with the safest deletions, what must never be deleted (active WAL, live data files), and a longer-term fix to prevent recurrence (log rotation, retention policy, alerting earlier). </task> <constraints> - Give the exact commands to find top space consumers on the stated system - Explicitly list what is never safe to delete for that system, before the safe-to-delete steps - Include a prevention step, not just the emergency fix </constraints> <format> A markdown runbook with sections: Identify Consumers, Never Delete, Safe To Reclaim (in order), Prevent Recurrence. </format>

You are a platform engineer responsible for TLS certificate management. <context> A certificate is expiring soon (or already expired) and you need a runbook for renewing and deploying it without a customer-facing outage. </context> <inputs> - Domains covered: [PLACEHOLDER, e.g. *.example.com, api.example.com] - Issuance method: [PLACEHOLDER, e.g. Let's Encrypt via cert-manager, or manual via DigiCert] - Deployment target: [PLACEHOLDER, e.g. ALB listener, Kubernetes ingress secret] - Renewal automation state: [PLACEHOLDER, e.g. auto-renews but last run failed] </inputs> <task> Write a certificate renewal runbook: how to check current expiry and confirm the urgency, the renewal steps for the stated issuance method, how to deploy the new certificate without dropping active connections, verification that the new cert is actually being served, and how to fix the automation if it failed silently. </task> <constraints> - Include the exact command to check expiry and confirm which cert is actually being served (not just what is issued) - Deployment step must avoid a hard restart that drops active TLS connections where the platform allows a rolling update - Include a root-cause step for why automation failed, not just a one-time manual fix </constraints> <format> A markdown runbook with sections: Check Expiry, Renew, Deploy Without Downtime, Verify, Fix Automation. </format>

You are an infrastructure operations lead. <context> You need to run planned maintenance (patching, hardware swap, major upgrade) that requires a maintenance window, and want a runbook that keeps customers informed and the rollback ready. </context> <inputs> - Maintenance activity: [PLACEHOLDER, e.g. Postgres major version upgrade] - Expected duration: [PLACEHOLDER, e.g. 45 minute window] - Customer notice period: [PLACEHOLDER, e.g. 7 days advance notice via status page and email] - Rollback option: [PLACEHOLDER, e.g. snapshot restore if upgrade fails] </inputs> <task> Write a maintenance window runbook: the pre-window checklist (notify customers, confirm rollback path is tested, freeze deploys), the in-window sequence with time checkpoints, the go/no-go decision if running long, and the post-window verification and customer close-out message. </task> <constraints> - Include a hard time checkpoint for aborting and rolling back if the work is not done by a stated point - Customer notice must be scheduled at the stated lead time, not "notify customers" - Include the exact rollback trigger and command </constraints> <format> A markdown runbook with sections: Pre-Window Checklist, In-Window Steps With Time Checkpoints, Abort Criteria, Post-Window Verification, Customer Close-Out Message. </format>

You are a senior software engineer responsible for platform upgrades. <context> A major dependency (language runtime, framework, database driver) needs upgrading across a production service, and you want a runbook that catches breaking changes before customers do. </context> <inputs> - Dependency and versions: [PLACEHOLDER, e.g. Node.js 18 to 22] - Service affected: [PLACEHOLDER, e.g. api-gateway, 15 downstream consumers] - Known breaking changes: [PLACEHOLDER, e.g. deprecated crypto APIs, ESM-only packages] - Test coverage: [PLACEHOLDER, e.g. 78% unit, integration suite for critical paths] </inputs> <task> Build an upgrade runbook: the compatibility check before starting, how to stage the upgrade (local, staging, canary, full), the specific breaking changes to test for given the stated versions, and the rollback plan if the canary shows regressions. </task> <constraints> - Name the concrete breaking changes for the stated version jump, not generic "test thoroughly" advice - Require a canary stage before full rollout, with a stated success bar - Rollback plan must specify what gets reverted (code, or also config/infra changes made for the upgrade) </constraints> <format> A markdown runbook with a staged rollout table: Stage | What To Test | Success Bar | Rollback Trigger. </format>

You are a database administrator. <context> You need a runbook for restoring from backup, whether for disaster recovery or to recover from accidental data loss, and want it tested and documented before it is needed for real. </context> <inputs> - Database and backup method: [PLACEHOLDER, e.g. PostgreSQL, automated snapshots every 6h + WAL archiving] - Restore scenarios: [PLACEHOLDER, e.g. full instance loss, or a single table accidentally truncated] - RTO/RPO targets: [PLACEHOLDER, e.g. RTO 30 min, RPO 5 min] - Restore environment: [PLACEHOLDER, e.g. restore to a new instance, then swap] </inputs> <task> Write a backup and restore runbook covering both a full instance restore and a partial (single table or row range) restore, the exact commands for each scenario, how to verify the restored data before cutting traffic over, and how the stated RTO/RPO targets map to the restore steps timing. </task> <constraints> - Cover both scenarios (full and partial restore) as separate paths, not one generic procedure - Include a verification step that checks data integrity before traffic is switched, not after - State clearly where the RTO/RPO targets are at risk given the stated backup method </constraints> <format> A markdown runbook with two paths (Full Restore, Partial Restore), each with commands, a verification checklist, and a cutover step. </format>

You are an infrastructure engineer handling traffic growth and spikes. <context> You anticipate a traffic spike (launch, sale event, seasonal peak) or sustained growth, and need a runbook for scaling capacity ahead of it rather than reacting to an outage. </context> <inputs> - Service and current capacity: [PLACEHOLDER, e.g. checkout-api, 8 pods, handles 1200 req/s] - Expected peak: [PLACEHOLDER, e.g. 5x normal traffic during Black Friday] - Scaling mechanism: [PLACEHOLDER, e.g. Kubernetes HPA, manual pre-scale for known events] - Bottleneck risk: [PLACEHOLDER, e.g. database connection pool caps at 200] </inputs> <task> Write a capacity scaling runbook: the pre-event capacity plan with target numbers, the load test to validate it before the real event, the scaling actions to take at defined trigger points during the event, and the downscale plan afterward to avoid overspending. </task> <constraints> - Give concrete target numbers (pods, connections, throughput) based on the stated expected peak, not "scale up as needed" - Call out the stated bottleneck explicitly and whether it needs a separate fix before the event - Include the downscale step, this is not just a scale-up runbook </constraints> <format> A markdown runbook with sections: Pre-Event Capacity Plan, Load Test Checklist, In-Event Scaling Triggers, Post-Event Downscale. </format>

You are an infrastructure engineer responsible for retiring old systems. <context> A service, database, or piece of infrastructure is being decommissioned and you need a runbook that removes it safely without breaking something still depending on it. </context> <inputs> - System being decommissioned: [PLACEHOLDER, e.g. legacy 'reports-v1' service and its database] - Known and suspected dependents: [PLACEHOLDER, e.g. nightly export job, one internal dashboard] - Data retention requirement: [PLACEHOLDER, e.g. keep a final backup for 1 year] - Timeline: [PLACEHOLDER, e.g. 30 day deprecation notice before shutdown] </inputs> <task> Write a decommissioning runbook: how to find dependents you do not already know about (traffic logs, access logs, code search), the staged shutdown sequence (stop writes, then reads, then infra teardown) with a wait period between stages, the data retention step before final deletion, and how to reverse each stage if a missed dependent surfaces. </task> <constraints> - Include a concrete method for finding unknown dependents, not just asking around - Sequence shutdown in reversible stages with a wait period, never a single irreversible step - Data retention step must happen before infra teardown, not after </constraints> <format> A markdown runbook with staged sections: Find Dependents, Stop Writes, Stop Reads, Retain Data, Tear Down Infra, each with a reversal note. </format>

You are a site reliability engineering lead building a runbook program from scratch. <context> Your team has ad hoc tribal knowledge instead of runbooks, and you need a standard template every future runbook will follow so they are consistent and complete. </context> <inputs> - Team and service types: [PLACEHOLDER, e.g. backend team, 10 microservices] - Existing documentation tool: [PLACEHOLDER, e.g. Confluence, Notion] - Required metadata: [PLACEHOLDER, e.g. owner, last reviewed date, severity it applies to] - Audience: [PLACEHOLDER, e.g. on-call engineers with 6 months tenure minimum] </inputs> <task> Create a reusable runbook template with every required section (metadata, trigger conditions, steps, verification, escalation) and a filled worked example using a realistic sample service so the team sees exactly how to use it. </task> <constraints> - Template sections must work for any of the team's service types, not one specific service - Include the worked example fully filled in, not left as placeholders - Metadata must include an owner and a last-reviewed date field so staleness is trackable </constraints> <format> A markdown template followed by one fully worked example for a realistic sample service. </format>

You are a reliability engineering lead auditing existing runbooks for quality. <context> Your team has a pile of existing runbooks of inconsistent quality, some outdated, and you need a checklist to review and grade each one before trusting it during an incident. </context> <inputs> - Number of existing runbooks: [PLACEHOLDER, e.g. 34 across 6 teams] - Known problems: [PLACEHOLDER, e.g. some reference decommissioned tools, no owner listed] - Review cadence goal: [PLACEHOLDER, e.g. every runbook reviewed at least twice a year] - Sample runbook to grade: [PLACEHOLDER, paste one runbook's text] </inputs> <task> Build a runbook review checklist (accuracy, completeness, clarity, ownership, last-tested date) with a pass/needs-work/fail grade per criterion, then apply it to the pasted sample runbook as a worked example with specific fixes called out. </task> <constraints> - Checklist criteria must be objectively checkable, not subjective ("is it good") - Worked example must call out specific line-level problems in the pasted runbook, not general comments - Include a suggested review cadence tied to the stated goal </constraints> <format> A markdown checklist (criterion | how to check | grade) plus a completed review of the pasted sample runbook. </format>

You are an engineering manager onboarding a new on-call engineer. <context> A new hire is about to join the on-call rotation and needs a structured walkthrough of the team's runbooks before their first shift, not just a link dump. </context> <inputs> - New hire background: [PLACEHOLDER, e.g. 3 years experience, new to this stack] - Services they will cover: [PLACEHOLDER, e.g. 4 services: api, worker, scheduler, gateway] - Existing runbook library: [PLACEHOLDER, e.g. 12 runbooks in Notion] - Shadow shift plan: [PLACEHOLDER, e.g. 2 shadow shifts before solo on-call] </inputs> <task> Build a structured onboarding walkthrough: which runbooks to read first in priority order, a short quiz or scenario question after each to confirm understanding, and a final readiness checklist before they go solo on-call. </task> <constraints> - Prioritize runbooks by how frequently their triggering incident actually occurs, most common first - Include at least one scenario question per runbook that tests judgment, not just recall - Readiness checklist must be a concrete go/no-go, not a vague confidence check </constraints> <format> A markdown walkthrough plan: ordered runbook list with a scenario question for each, and a final readiness checklist. </format>

You are a reliability engineering lead assessing incident readiness. <context> You want to know which of your services could have a runbook but don't, before the gap gets discovered during a live incident. </context> <inputs> - Services list: [PLACEHOLDER, e.g. 15 services, list with names] - Existing runbook coverage: [PLACEHOLDER, e.g. runbooks exist for 6 of 15] - Recent incidents without a runbook: [PLACEHOLDER, e.g. 3 incidents in the last quarter had no matching runbook] - Risk signal: [PLACEHOLDER, e.g. customer-facing vs internal-only, request volume] </inputs> <task> Produce a gap audit: a prioritized list of services missing a runbook, ranked by risk (customer impact, incident frequency, complexity), and for the top 5 gaps, a one-paragraph starting outline of what that runbook should cover. </task> <constraints> - Ranking must use the stated risk signals explicitly, with the reasoning shown, not just a list - Cross-reference the stated recent incidents without a runbook, they should rank near the top - Starting outlines must be specific to each service, not a generic template restated 5 times </constraints> <format> A markdown table (Service | Risk Score | Reasoning) plus 5 short starting outlines for the top gaps. </format>

You are a reliability engineering lead running incident response drills. <context> You want to run a tabletop exercise, a simulated incident walkthrough with no real systems touched, to test whether the team's runbooks and escalation actually hold up. </context> <inputs> - Scenario type: [PLACEHOLDER, e.g. primary database goes fully unreachable at 2am] - Participants: [PLACEHOLDER, e.g. on-call engineer, EM, comms lead] - Runbooks being tested: [PLACEHOLDER, e.g. database failover runbook, escalation runbook] - Session length: [PLACEHOLDER, e.g. 60 minutes] </inputs> <task> Write a tabletop exercise script: the scenario briefing given to participants, a facilitator script with timed injects (new complications introduced partway through) to test the runbook under changing conditions, and a debrief template to capture what worked and what the runbook missed. </task> <constraints> - Include at least 2 timed injects that specifically stress-test a weak point in the stated runbooks (e.g. the named contact is unreachable) - Facilitator script must include approximate timestamps so the session fits the stated length - Debrief template must produce concrete runbook edits, not just "went well" </constraints> <format> A markdown script: Scenario Briefing, Facilitator Timeline With Injects, Debrief Template. </format>