Best Prompts for Engineering

After an incident, facts are spread across alerts, chat threads, tickets, deployment records, dashboards, and personal notes. The team needs a coherent account while memories are fresh, but the people with the most context are often busy restoring normal service and clearing follow-up work.

AI can assemble a first draft, saving the team from a blank page. It should not decide the root cause, assign fault, or turn uncertain timestamps into a neat story.

Why ordinary prompting fails

“Write a postmortem from these logs” encourages narrative completion. Missing intervals disappear, correlation becomes causation, and copied chat speculation can become a formal conclusion. A model may also overemphasize the first visible failure rather than the conditions that allowed impact to spread.

A dependable prompt must preserve chronology, distinguish source types, mark conflicts, and frame causal claims for engineering review.

Reusable prompt

Copy
ROLE
You are an incident documentation assistant. Produce a blameless first draft from supplied evidence. You organize facts and open questions; the incident lead and service owners validate causes, impact, and actions.

REQUIRED INPUTS
1. Incident identifier, services, severity, and declared time window: [details]
2. Timeline sources with timestamps and time zones: [alerts, logs, chat, tickets, deploys]
3. Impact evidence: [customer reports, error rates, affected functions]
4. Detection, response, mitigation, and recovery records: [sources]
5. Relevant changes before the incident: [deployments or configuration]
6. Existing action items and owners: [list]
7. Postmortem template and audience: [paste]

STEPS
1. Inventory sources and normalize timestamps to one stated time zone while retaining originals.
2. Build an event timeline and mark source, fact type, and confidence.
3. Separate observed system behavior from contemporaneous hypotheses and later analysis.
4. Summarize impact without estimating unsupported customer counts or duration.
5. Describe detection, escalation, mitigation, and recovery.
6. Draft contributing factors across system, process, safeguards, and organizational context without assigning personal blame.
7. Identify conflicting evidence, missing intervals, and causal claims needing validation.
8. Convert verified gaps into specific corrective actions only when an owner and completion check can be named.

OUTPUT FORMAT
- Status: Draft, requires validation
- Incident summary
- Impact and scope
- Detection
- Timeline table: normalized time, original time, event, source, confidence
- Response and recovery
- Preliminary causal analysis: direct evidence, contributing conditions, unverified hypotheses
- What helped
- What made response harder
- Corrective actions table: action, risk addressed, owner, priority, due date, verification
- Open questions and evidence needed
- Source index

EVIDENCE AND UNCERTAINTY RULES
- Cite a source for every timestamp, impact statement, and causal assertion.
- Never invent missing events, counts, owners, or deadlines.
- Mark conflicting timestamps instead of silently choosing one.
- Do not treat chat speculation as fact.
- Use “preliminary” for causal analysis until service owners approve it.
- Describe roles and system conditions, not personal fault.
- If sensitive data appears, omit it from the draft and flag the source for restricted review.

What to provide

Collect evidence before asking for prose. Export relevant chat messages with timestamps, alert histories, deployment events, dashboard snapshots, ticket updates, and links to durable logs. State the time zone for each source. If metrics have retention limits, preserve them promptly through approved channels.

Define the incident window and affected services, but allow the timeline to show earlier contributing changes. Include the organization’s postmortem template and severity definitions so the draft fits the existing process. Redact secrets, tokens, personal data, and unnecessary customer content.

How to review the output

Have the incident lead review the timeline against primary sources. Confirm the start of impact, detection, mitigation, and recovery separately, since these are often different times. Check whether “recovered” means error rates normalized, backlogs cleared, or all customer effects ended.

Service owners should challenge the causal section. Ask what evidence would disprove each claim and whether the draft stops at the triggering event. A bad deployment may trigger an incident, but missing isolation, weak rollback paths, or delayed detection may explain the scale and duration.

Review actions for verifiability. “Improve monitoring” is vague. “Alert when queue age exceeds the agreed threshold for ten minutes, then test the alert in staging” can be owned and checked.

Where it fails

Sparse telemetry cannot support a precise account. The draft may remain incomplete until logs, traces, vendor records, or customer reports are recovered. Distributed systems can produce clocks that disagree, and normalized timestamps do not automatically resolve event ordering.

This prompt is not a substitute for security, privacy, legal, or regulatory incident procedures. Evidence preservation and communications may require specialist control. It also cannot make a blameless culture real if the review process still rewards certainty and punishes disclosure.

Practical takeaway

Use AI to lower the documentation burden, not the standard of proof. A strong first draft makes the source trail and uncertainty easier to inspect. Try this prompt in Agentic Workers on a closed, low-severity incident, then compare the draft with the final reviewed postmortem to improve future inputs.

<!-- X derivative: A useful incident postmortem prompt builds a cited timeline, separates facts from chat hypotheses, and leaves causal conclusions marked preliminary until engineers validate them. -->