Why it is written this way
The most common mistake people make when writing an incident report is blending excuses with facts in the same sentence. Writing "Because I had to rush, I opened the old file" shifts the reader's focus from objective facts to attitude. This prompt physically separates the two.
Breaking the task down into steps serves as a safeguard. Asking the AI to simply "write an incident report" causes it to lump sorting, judgment, and drafting together, often hallucinating missing timestamps plausibly. Structuring it as chronological sorting → separating facts from assumptions → drafting → summarizing root cause makes intermediate steps visible, allowing you to review tagged lines separately.
Constraints prevent emotional expressions and finger-pointing. Assigning blame to another department in an incident report alters the document's purpose regardless of factual accuracy. Barring legal or disciplinary judgments ensures the document stays purely factual; those evaluations belong to the decision-makers.
Prompting clarifying questions in the final paragraph prevents timestamp hallucinations. Notes often contain gaps, and models tend to fabricate intermediate times to fill them. Because a single fabricated timestamp can compromise the entire report's credibility, making the model ask first ensures accuracy.
Unfamiliar terms? See Aha AI: chain-of-thought, hallucination
Compared with a bad example
Write an incident report about sending the wrong email.
(paste notes)
The output ends up reading like an apology letter. Sentences like "I deeply reflect on this mistake and will ensure it never happens again" take up half the text, while what happened and when gets buried across paragraphs, forcing auditors to rebuild the timeline manually. Missing timestamps get filled with plausible estimates, which later conflict with actual system logs and require rewriting the entire report.
Variations
When Timestamps Are Scarce
I need to draft an incident report regarding {{incident overview}}, but I have very few exact timestamp records. First, provide a checklist of records I should verify (e.g., email dispatch logs, messenger chat history, system access logs). Next, organize the notes below into a table distinguishing items with confirmed timestamps from those without. I will draft the incident report after filling in the verified timestamps.
""" {{hourly note}} """
Relying purely on memory can conflict with actual audit logs later. Get a checklist of verifiable sources before drafting.
Adapting for Client Explanation
Please convert the internal incident report details below into an explanatory statement for our client. Remove internal jargon and employee names, and structure the narrative in the order clients care about: What happened · Impact on the client · Immediate actions taken · Preventive measures implemented. Restrict causes to {{root cause}} and actions to {{recurrence prevention plan}}, avoiding unconfirmed commitments.
""" {{hourly note}} """
Internal incident reports and client-facing notices follow different priorities. Clients prioritize the impact on their business over internal causes.
Model notes
Some models may produce the final document immediately despite instructions to show intermediate step results. In such cases, explicitly prompt: "Show only Step 1 and Step 2 first." If the model skips asking clarifying questions and generates the text right away, verify whether any missing timestamps were arbitrarily hallucinated without [Needs Verification] tags.
Related prompts
Last updated 2026-09-02 · Found a mistake? Let us know