How to Use Claude Skills to Turn an On-Site Incident Note Into a Clear Incident Report

If Claude Skills is new to you

Skills are reusable folders of instructions, resources, and optional scripts that Claude can load when a task matches the Skill description. Anthropic's current help says Skills are available on Free, Pro, Max, Team, and Enterprise plans when code execution is enabled.

For this workflow, you only need the basics: create a folder with a Skill.md file, ZIP the folder, upload it in Claude under Customize > Skills, enable it, and test that Claude routes incident report requests to the Skill. The Claude Skills tool hub is useful further reading, but the setup steps you need are included below.

Problem and who this is for

Something happened on site. The first notes are rushed and incomplete. You may have a handwritten note, a screenshot of a witness text, and a short event summary from whoever was present. You need one clear incident report that is factual, neutral, and useful later.

This workflow is for local business owners and operators who need an internal incident report without turning messy source material into a liability.

What skill you will use in this workflow

You will build a private custom Skill called incident-report-builder. Its job is to turn raw incident notes into a factual report with a clear timeline, involved-party fields, source distinctions, and open questions.

This task deserves a Skill because incident reporting needs the same safety rules every time. The Skill keeps direct observation separate from witness statements, keeps missing information visible, and prevents a rushed prompt from adding cause, blame, or disciplinary conclusions.

Before using the Skill, prepare the source notes, any witness screenshots, and a short incident-basics.txt file with the date, location, known people or roles, and whether follow-up already happened.

Prerequisites

• Claude with Skills available and code execution enabled.
• At least one source note, photo, screenshot, or typed summary.
• Any related witness text screenshots or manager notes.
• A short incident-basics.txt file with date, location, known people or roles, and any already-completed follow-up.
• A reviewer who can verify names, dates, times, location details, direct quotes, and open questions.

How to gather the source material

1. Photograph handwritten notes in good light and crop out unrelated private information.
2. Save screenshots with descriptive names like witness-text-1.png.
3. Create one text file called incident-basics.txt with the date, location, people involved if known, and whether external follow-up already happened.
4. If a source includes speculation, emotion, or blame language, keep it in the source set but label it as a reported statement during review.
5. Keep direct observations, witness statements, and manager notes distinguishable. Do not flatten them into one blended summary.
6. Do not combine unrelated incidents in the same run.

Build the custom skill for this workflow

Create a folder named incident-report-builder. Inside it, create a file named Skill.md. Paste the starter Skill below, then edit it so it matches your business incident form, escalation language, and review rules.

When the folder is ready, ZIP the folder itself so the ZIP file contains incident-report-builder/Skill.md at the root. In Claude, open Customize > Skills, upload the ZIP file, and enable the Skill before you run the workflow.

Use this as a starting template, not a perfect final Skill:

---
name: incident-report-builder
description: Turn handwritten notes, witness screenshots, and a quick event summary into a clear incident report with a factual timeline, involved parties, and open questions.
---

# Incident Report Builder

Use this skill when the user wants to turn raw incident notes into a clean incident report for internal review.

## Required sections
- What happened
- Timeline
- People involved
- Witness or source notes
- Open questions

## Guardrails
- Keep the report factual and neutral.
- Do not infer cause or blame.
- Distinguish direct observation from secondhand statements.
- Keep missing information visible.

## Examples
- Turn these on-site notes into a factual incident report.
- Use my incident-report workflow on this witness text and summary.
- Draft a neutral report and keep open questions visible.

Optional official Anthropic skill

Anthropic's official internal-comms skill is a good public reference here because incident reports are one of its named fits. It can help you see the shape of concise internal communication.

Use the private incident-report-builder Skill for the actual workflow when your business needs house-specific fields, exact source labels, involved-party rules, timeline order, or legal and HR review language.

Skill-creator helper

Anthropic's official skill-creator skill can help draft or refine your private Skill before you upload it. Review the generated files before enabling any Skill, especially if it includes scripts or bundled resources.

Why this should be a custom skill, not a one-off prompt

A one-off prompt can accidentally blur facts, witness statements, and assumptions. A custom Skill is better because the same incident-report rules need to repeat every time: timeline ordering, source distinction, involved-party fields, open questions, and no-blame language.

Skill trigger test

After enabling incident-report-builder, test it with a small incident-note sample before the first production run. Use one short note, one witness text, and a minimal incident-basics.txt.

Try prompts like:

• Turn these incident notes into a factual report.
• Use my incident-report workflow and separate direct facts from witness statements.
• Draft a neutral incident report without inferring blame.
• Create an incident report with a timeline, people involved, source notes, and open questions.

If Claude does not appear to use the Skill, revise the Skill description so it clearly mentions incident notes, factual reports, timeline, involved parties, witness statements, source distinction, and open questions.

Numbered workflow steps

1) Gather and clean the source material

Create a source package with three parts:

• Incident notes, photos, screenshots, or a typed event summary.
• Witness texts or manager notes, kept separate from direct observations.
• incident-basics.txt with date, location, known people or roles, and already-completed follow-up.

Remove unrelated private material. Keep anything uncertain visible as uncertain instead of cleaning it up into a false fact.

2) Create or enable the custom Skill

If this is your first run, create and upload incident-report-builder using the build steps above. If you already created it, open Claude's Skills settings and confirm the Skill is enabled before starting a new chat.

Use a fresh chat for the production run so the Skill starts from the current incident material, not an old report.

3) Run a quick trigger test

Before the full run, paste a small incident-note sample and ask:

Use my incident-report workflow on this small sample. Create a neutral factual report, separate direct facts from witness statements, keep the timeline explicit, and do not infer cause or blame.

Check that Claude keeps direct observations, reported statements, and open questions separate. It should not add fault, motive, discipline, or root cause language.

4) Run the actual workflow with the Skill active

Attach or paste the full incident source package and incident-basics.txt. Ask Claude:

Use incident-report-builder to turn these handwritten notes, witness screenshots, and event summary into a clear internal incident report. Include what happened, timeline, people involved, witness or source notes, and open questions. Keep the report factual and neutral, distinguish direct observation from secondhand statements, and do not infer cause, blame, fault, or disciplinary conclusions.

The useful output should make the record easier to review later without making the business sound more certain than the source material supports.

5) Review the report before saving or sharing

Do a human review before the report goes into an incident file, insurance packet, HR note, or manager log. Check:

• Do names, dates, times, locations, and direct quotes match the source material?
• Are direct observations separate from witness or secondhand statements?
• Are missing or unclear details still visible?
• Did Claude avoid cause, blame, motive, fault, and disciplinary conclusions?
• Are follow-up owners or next checks stated only when the source supports them?

If you know a correction, add it as a separate verified note. Do not silently overwrite original source wording.

6) Save, send, or reuse the result

Save the approved report in the system your business already uses for incident documentation. Keep the source package and final report together if your policy allows it.

If the format works, keep incident-report-builder enabled for future reports. Update the Skill when your incident form, review rules, or escalation process changes.

Tool-specific instructions

Claude Skills

Use incident-report-builder as the main workflow tool. The Skill should encode timeline ordering, direct-versus-secondhand source labels, involved-party fields, missing-information handling, and a strict no-blame rule.

Use the official skill-creator skill only as a helper for drafting or improving your private Skill. Treat the Claude Skills tool hub as further reading for broader setup context, not a prerequisite for this workflow.

Official public skill reference

The internal-comms public Skill is relevant because its documented use cases include incident reports and internal updates. It is not a substitute for your private incident report Skill because it does not know your required fields, source labels, escalation path, or review language.

Quality checks

1. The final report preserves the difference between facts, direct quotes, and unverified statements.
2. Names, dates, times, and locations match the verified sources.
3. Missing details remain visible instead of being guessed.
4. The timeline is chronological and does not fill gaps with assumptions.
5. The report avoids cause, blame, motive, fault, and disciplinary conclusions unless those are explicitly documented by an approved source.
6. The report would still make sense to someone reviewing it later with no extra context.

Common failure modes and fixes

Claude turns a witness claim into a fact

Fix: rerun the draft with an explicit instruction to keep Witness or source notes separate from What happened.

The report sounds accusatory

Fix: tell Claude to remove causal, blame, motive, and discipline language unless the source explicitly documents it.

Too many details are still unclear

Fix: generate the report with clear uncertainty markers, then append a short follow-up checklist for the manager to confirm.

The report blends several incidents together

Fix: split unrelated events into separate runs and separate reports.