1. Incident Postmortem Writer
Copy-paste prompt
You are a senior DevOps engineer writing a blameless incident postmortem. Using the incident timeline below, produce a structured postmortem document that includes: 1. Incident summary (service affected, duration, severity level) 2. Timeline summary (key events in chronological order, condensed to the critical moments) 3. Root cause (the underlying technical or process failure that caused the incident) 4. Contributing factors (what made detection, response, or mitigation harder) 5. Impact statement (which users/systems were affected, quantified where possible) 6. Action items (each with: description, owner, due date, and priority level) 7. What went well (things that limited the blast radius or sped up recovery) Incident timeline: [paste your bulleted timeline here] Incident severity: [P1/P2/P3] Services affected: [list services] Tone: Blameless, factual, engineer-readable. Format: Suitable for sharing in Confluence or a Slack post-incident channel.
Why it works: Postmortems are high-stakes documents that teams dread writing under pressure. This prompt takes a raw timeline and produces a structured, blameless document that satisfies both engineering teams and management.
2. Runbook Author
Copy-paste prompt
You are a senior DevOps engineer writing an on-call runbook. Using the process description below, produce a clear, step-by-step runbook that includes: 1. Purpose (one sentence: when to use this runbook and why) 2. Pre-conditions (what must be true before starting — access required, services that must be running, safety checks) 3. Steps (numbered, each step on its own line with the exact command or action, expected output, and what to do if it fails) 4. Verification checks (how to confirm the process completed successfully) 5. Rollback instructions (step-by-step how to undo the procedure if something goes wrong) 6. Escalation path (who to contact if the runbook doesn't resolve the issue) Process description: [describe the process, e.g. "how to restart the auth service when it returns 503 errors"] Target audience: On-call engineers who may be unfamiliar with this service Format: Markdown. Optimised for reading quickly at 2am during an incident.
Why it works: Runbooks written in a rush are often incomplete or ambiguous. This prompt enforces the structure that makes a runbook actually usable by someone who has never touched the service before.
3. CI/CD Pipeline Change Summary Writer
Copy-paste prompt
You are a DevOps engineer writing a changelog entry for a CI/CD pipeline update. Using the list of changes below, write a concise, engineer-readable summary that includes: 1. Change overview (what changed at a high level — new stages, updated configs, removed steps) 2. Rationale (why these changes were made — performance, security, cost, reliability) 3. Risk level (Low / Medium / High) with a one-sentence justification 4. Testing approach (how the changes were validated — which environments, what tests were run, any rollback tested) 5. Who to contact if the pipeline breaks after this change Pipeline changes: [paste your list of changes — new steps, updated configs, removed stages, version bumps] Pipeline: [e.g. main deploy pipeline / PR validation / nightly integration tests] Format: Concise. Engineer-readable. Suitable for a PR description, Confluence page, or Slack engineering update.
Why it works: Pipeline changes are often shipped with minimal documentation, then blamed when something breaks three weeks later. This prompt creates an audit trail that makes rollbacks and post-incident analysis much faster.
Nexus Vault
Need more than the free prompts?
Get 200 business prompts, instant download, and no subscription.
4. On-Call Handoff Email Writer
Copy-paste prompt
You are a DevOps engineer writing an on-call handoff email to the incoming on-call engineer. Using the bullet notes below, draft a clear, comprehensive handoff that covers: 1. Current status (is everything green, or are there active issues?) 2. Open incidents (name, severity, current status, next action, owner) 3. Monitoring alerts to watch (alerts that fired this shift but were not paged, or ones likely to fire soon with context) 4. Known flaky tests or noisy alerts (what to ignore and why — to avoid false alarm fatigue) 5. Pending deploys (what's queued, when it's expected to go out, any risk factors) 6. Escalation contacts (who to call for each major service if things go sideways) 7. Any other context the incoming engineer needs to not be caught off guard Bullet notes: [paste your rough notes here] Shift duration covered: [e.g. Friday 6pm – Monday 9am] Tone: Direct, practical. No fluff. The incoming engineer is reading this while half-awake.
Why it works: A bad handoff means the incoming engineer is blindsided. This prompt turns a few rough bullet notes into a structured email that covers every category that matters — incidents, alerts, deploys, and escalation paths.
5. Architecture Decision Record (ADR) Writer
Copy-paste prompt
You are a senior engineer writing an Architecture Decision Record (ADR) to document a technology decision. Using the decision details below, produce a complete ADR that includes: 1. Title (short, descriptive — e.g. "ADR-012: Switch from Jenkins to GitHub Actions") 2. Status (Proposed / Accepted / Deprecated / Superseded) 3. Context (the problem or situation that necessitated a decision — what was broken, slow, expensive, or unsustainable) 4. Decision (what was decided, stated clearly and specifically) 5. Consequences — Positive (what improves as a result of this decision) 6. Consequences — Negative (what gets worse, what new complexity is introduced, what trade-offs are accepted) 7. Alternatives considered (each with a brief description and why it was rejected) 8. Related decisions or links (other ADRs or docs this connects to, if any) Decision details: [describe the technology decision, e.g. "switching from Jenkins to GitHub Actions for our CI/CD pipeline because Jenkins maintenance overhead is too high and we're already in GitHub"] Decision owner: [name/team] Format: Markdown. Suitable for committing to the /docs/adr/ directory in the repo.
Why it works: ADRs are one of the highest-value documents a team can maintain, but they rarely get written because engineers are already moving to the next problem. This prompt produces a complete, commit-ready ADR from a brief description of the decision.