Skip to content

Guide

Claude Cowork for Health & Safety Managers

A practical guide to using Claude as your AI co-worker for EHS documentation — incident write-ups, job hazard analyses, toolbox talks, inspection checklists, and corrective-action tracking, from setup to daily use.

ClaudeHealth & SafetyIntermediateGuide

What is Claude Cowork?

Claude Cowork is the practice of using Claude as a persistent, context-aware co-worker embedded in your EHS workflow. This is not about asking a general AI "what are the OSHA requirements for machine guarding." It is about configuring Claude with your site, your equipment, your crews, and your documentation conventions so it produces structured safety work — incident write-ups, job hazard analyses, toolbox talks, inspection checklists, corrective-action logs — that you can actually take into a review.

Claude-native prompts. The prompts in this guide use Claude's native XML tag structure (<context>, <instructions>, <format>, <avoid>) for more precise, consistent output. These tags help Claude parse your intent with less ambiguity. They work in ChatGPT too, but are optimized for Claude.

The job has a structural problem: a twenty-minute walkaround generates an afternoon of writing. Incident reports, JHAs, training records, and inspection write-ups all land on one desk, and the writing backlog grows faster than the hazard list shrinks. Claude, configured correctly, compresses the drafting so findings reach the floor while they still matter — with your judgment on every document that leaves your hands.

One boundary first, because it governs everything below. This is drafting help, not safety advice. Claude does not determine compliance, does not exercise professional judgment, and never sits in front of a reporting obligation. If an incident is reportable, report it on your regulator's timeline — in the US, OSHA requires fatalities within 8 hours and in-patient hospitalization, amputation, or eye loss within 24 hours [verify current requirements] — and write the draft afterward.

Install the Health & Safety Manager Plugin

This guide works on three Claude surfaces. The plugin is the fastest path on two of them. Pick whichever you use:

If you're on Cowork (desktop or mobile app)

Claude Cowork is Anthropic's agentic workspace — Claude completes work autonomously and returns finished deliverables. The Health & Safety Manager plugin packages the workflows below as native skills and slash commands.

  1. Open the Cowork plugin directory in your desktop app.
  2. Filter by Cowork, search for "Health & Safety Manager", and click Install.
  3. The plugin's slash commands and ambient skills are now available in any Cowork task.

If you don't see the plugin in the directory yet, install via custom marketplace: paste https://github.com/alexclowe/awesome-claude-cowork-plugins in your Cowork plugin settings.

If you're on Claude Code (CLI)

Install from your terminal:

claude plugin add alexclowe/awesome-claude-cowork-plugins/health-and-safety-manager

The plugin's slash commands and skills load on next session.

If you're on Claude.ai (web chat only)

Plugins aren't directly installable on the web chat surface. You have two options:

  1. Use the prompts in this guide directly in a Claude Project (covered in the next section). Same outputs, more typing.
  2. Upload the plugin's skills as a zip via Settings → Features → Custom Skills (Pro/Max/Team/Enterprise plans). Higher friction; only worth it if you want the auto-activating skills, not the slash commands.

What the plugin gives you (any surface)

Slash command What it does
/incident-report Draft a de-identified incident write-up from your notes — factual sequence, conditions, and contributing factors, with no blame language and no legal conclusions
/toolbox-talk Build a five-minute toolbox talk from a topic, a season, or a recent incident — written in plain language for the crew who has to act on it
/job-hazard-analysis Break a task into steps, surface the hazard at each step, and propose controls ordered by the hierarchy of controls rather than defaulting to PPE
/safety-audit-checklist Generate an inspection checklist for a specific area or activity — observable checks, evidence to look for, and space to record findings
/corrective-action-log Turn inspection findings, incident actions, and audit observations into a tracked corrective-action log with owners, due dates, and verification steps

It also ships two ambient skills:

  • Hazard Communication Style — worker-facing writing conventions: plain language, imperative actions tied to the moment they apply, concrete mechanisms of harm without fear tactics
  • Regulatory Caution — never certify compliance, mark regulatory references [verify current requirements], keep incident drafts factual, and put reporting obligations ahead of any draft

The plugin works standalone for one-off tasks. Pair it with the surface-specific setup below for persistent context across every task — that combination is the full Claude Cowork setup.

Setting Up Claude for Safety Work

Surface note: The Project setup below is for claude.ai web users. Cowork users have their own task-context mechanism (set context once when starting a Cowork task). Claude Code users get the plugin's ambient skills automatically — no Project setup needed. The workflows themselves are surface-agnostic — paste the prompts wherever you're working.

The key to consistent output is using Claude Projects. A Project stores your site, your equipment, your crews, and your documentation conventions across every conversation — which is what stops you re-explaining the layout every time you draft something.

Step 1: Create a Safety Project. In Claude, click "Projects" and create one called "EHS — [Site]."

Step 2: Set your custom instructions. In the Project settings, add:

You are my EHS documentation assistant. Here is my context:

<site-profile>
- Role: [EHS manager / HSE lead / safety coordinator]
- Organization: [industry, headcount, number of sites]
- Site: [what happens here — processes, main equipment, layout notes]
- Crews: [shifts, trades, contractor presence, languages spoken]
- Jurisdiction: [country/state — and any state plan, industry regime, or
  customer safety requirements that layer on top]
- Documentation I maintain: [incident records, JHAs, training matrix,
  inspection schedule, corrective-action log — and where each lives]
</site-profile>

<rules>
- You draft documentation. You never determine compliance, never state that
  something meets a requirement, and never conclude that a hazard is
  adequately controlled
- Cite regulations as pointers only, marked [verify current requirements].
  Never invent a standard number, exposure limit, threshold, or deadline
- Incident drafts stay factual: observable sequence, conditions, and
  contributing factors framed as systems — never fault, negligence, or any
  legal characterization, and never names
- If I describe a serious incident, tell me about the reporting obligation
  before you write anything
- Propose controls in hierarchy-of-controls order. Flag when the only
  control on offer is PPE
- Mark every gap [Confirm: ...] rather than filling it with something
  plausible
</rules>

Step 3: Upload your document templates. Add the forms your organization actually uses — incident report template, JHA form, inspection checklist, corrective-action log — so drafts come back in the shape your records expect rather than a generic one.

Step 4: Add your equipment and process list. The single highest-value upload. A JHA written against your actual equipment beats a generic one every time, and it stops Claude inventing plausible-sounding machinery.

Step 5: Always work inside this Project. Every new conversation inherits your site, your jurisdiction, and your guardrails automatically.

Five High-Leverage Workflows

1. The Incident Write-Up

This is where the hours go, and where careless writing does the most damage. An incident report is a factual record that may be read by people who are not on your side — a regulator, an insurer, a lawyer. The discipline is separating what happened from what someone concluded about it.

<context>
Here are my notes from the incident and the interviews: [paste everything —
timeline, what people said, equipment state, conditions, what was done at
the scene]. Jurisdiction: [ ]. Outcome: [injury/near-miss/property damage].
</context>

<instructions>
Draft the incident write-up. Give me a factual summary, a sequence-of-events
table marking each entry as established or reported-and-uncorroborated, the
conditions at the time (task, equipment state, environment, staffing,
procedures, PPE), and contributing factors framed as conditions and systems
with a confidence rating on each. De-identify to roles. End with the open
questions the investigation still has to answer, ordered by what most
changes the analysis.
</instructions>

<avoid>
Any fault attribution, negligence framing, or legal characterization. Any
statement about whether something met a requirement. Filling gaps in the
timeline with plausible detail — mark them [Confirm: ...] instead.
</avoid>

The contributing-factors section is the one that earns its keep. "The operator was careless" ends an investigation; "jam clearing is not in the written procedure, and the interlock bypass had gone unreported for an unknown period" starts one.

2. The Job Hazard Analysis

The failure mode of most JHAs is the PPE reflex: identify a hazard, prescribe gloves, move on. A JHA that works down the hierarchy of controls finds the engineering fix that removes the hazard for everyone, permanently, instead of the one that makes each worker responsible for their own protection.

<context>
Task: [describe it — what, how often, how many people, what equipment].
Current controls: [what's in place today]. Environment: [ ].
Anything that's gone wrong before: [ ].
</context>

<instructions>
Build the JHA. Decompose the task into steps in the order they happen —
including setup and cleanup, not just the main work. For each step, name
the hazards and propose controls working down the hierarchy: elimination,
substitution, engineering, administrative, PPE. Label which level each
control sits at and state the residual risk. Then call out separately any
hazard currently handled by PPE or procedure where an engineering control
plausibly exists.
</instructions>

<avoid>
"Be careful," "stay alert," and "use good judgment" as controls. Invented
exposure limits, torque figures, or equipment specifications. Declaring the
task safe or compliant once the controls are listed.
</avoid>

Note that setup and cleanup steps are where most JHAs miss hazards, because people analyze the interesting middle of a task and skip the parts either side of it.

3. The Toolbox Talk

A talk fails at the point of delivery, not on paper. The crew is tired, standing up, possibly reading in a second language, and has heard a hundred of these. Specificity is the only thing that cuts through — a talk anchored in something that happened here last week gets attention that a generic ladder-safety sheet never will.

<context>
Trigger: [recent incident or near miss, seasonal hazard, or a change in the
work]. Crew: [trade, size, experience mix, languages]. Time available: [ ].
</context>

<instructions>
Write the toolbox talk. Open with why we're talking about this today
(de-identified if it's a real incident). Name the hazard and the actual
mechanism of harm. Give the required actions as numbered imperative steps
tied to the moment on the job they apply. Add the site-specific conditions
to watch for today, three open questions that get the crew talking — at
least one inviting a near-miss story — and close with the single ask plus
who to raise concerns with.
</instructions>

<avoid>
Fear tactics, graphic injury detail, or statistics used as shock. Anything
that implies the crew is careless. Passive policy statements instead of
imperative actions. Claiming the talk satisfies a training requirement.
</avoid>

4. The Inspection Checklist

The test of a checklist is whether two different inspectors walking the same area reach the same answers. That means every line has to be answerable by observation, with the evidence a pass requires written down.

<context>
Scope: [the specific area or activity]. Industry and setting: [ ].
Equipment present: [ ]. Time I have for the walk: [ ].
</context>

<instructions>
Build the checklist, grouped by what I walk past rather than by regulation
chapter. Each line: the observable check, what a pass actually looks like,
and space to record result, finding, location, and severity. Add four or
five questions to ask the people working in the area. Close with what this
checklist deliberately doesn't cover.
</instructions>

<avoid>
Checks that can't be answered by observation ("is the program adequate?").
Invented inspection frequencies, exposure limits, or citations. Framing a
completed checklist as evidence of compliance.
</avoid>

The "ask the people working here" section consistently outperforms the checklist itself. Crews know about the workaround that became normal and the equipment that "does that sometimes" — none of which appears on any inspection form.

5. The Corrective-Action Log

Findings that live only in an inspection report do not close. Turning them into actions with an owner, an interim control, a due date, and a verification step is the difference between a safety program and a filing habit.

<context>
Findings from [source — inspection, incident actions, audit, insurer report]:
[paste the list, with severity or urgency where you noted it].
Roles available to own actions: [ ].
</context>

<instructions>
Convert each finding into one discrete, completable action with an owner
role, a proposed priority with the reasoning visible, an interim control
for anything that can't be fixed immediately, a target date, and what
verification looks like plus who confirms it. Flag findings that suggest
immediate risk separately. Then group findings that point at one systemic
cause and propose the single action that addresses the group.
</instructions>

<avoid>
"Improve awareness," "monitor," and "remind staff" as actions — everything
needs a done state. Inventing regulatory deadlines. Closing or downgrading
any finding; status is mine to set.
</avoid>

The systemic-cause grouping is the part worth reading twice. Fifteen findings that all trace to one maintenance backlog is a single conversation with one manager, not fifteen work orders.

What This Looks Like in Your Week

  • After any walkaround: /corrective-action-log on the findings while they're fresh — the log gets written in ten minutes instead of waiting for the afternoon that never comes
  • Within 24 hours of an incident: report first if it's reportable, then /incident-report on your interview notes while the detail is still recoverable
  • Before Monday start: /toolbox-talk built on something that actually happened on site last week
  • When a task changes or a new one starts: /job-hazard-analysis before the first run, then verify it on the floor with the crew who'll do the work
  • Ahead of a scheduled inspection: /safety-audit-checklist scoped to the specific area, so the walk follows a route instead of a regulation index

What to Avoid

  • Letting a draft delay a report. Statutory reporting timelines run from the incident, not from when your paperwork is ready. Report first, always
  • Treating any output as a compliance determination. Claude drafts documents. Whether your site meets a requirement is your professional judgment and, ultimately, your regulator's finding
  • Accepting invented regulatory detail. Standard numbers, exposure limits, inspection frequencies, and deadlines are exactly what an AI will produce confidently and wrongly. The plugin marks these [verify current requirements] — if you see a specific figure you didn't provide, treat it as wrong until you've checked it against a current authoritative source
  • Putting names and medical detail into drafts. De-identify to roles. Injury information is sensitive personal data in most jurisdictions, and an incident record only needs what the record needs
  • Letting blame language back in during your edit. The draft comes out factual. The temptation to add "should have known better" comes from you, at 5pm, after a bad week. Don't
  • Skipping the floor. A JHA written from a description is a starting point, not a JHA. It needs the walkaround and the crew's input before it governs any work

Resources

Free · 2 minutes

Set up AI for your job — free, in about 2 minutes

Pick your profession and get your first working AI tool, a step-by-step guide, and a $0 plugin to take home. No credit card.

Get my free setup

Get weekly AI prompts for Health & Safety professionals

Join professionals already saving hours every week. Free. No spam.