tibsfox/gsd-skill-creator/rca-human-factors

Claude Code and agent skill by tibsfox/gsd-skill-creator

Trust tier 3
  • community
Source check pending

Checking that the SKILL.md file is still in the repository.

Human-factors root cause analysis for incidents involving operators, crews, clinicians, or any human actors. Covers James Reason's Swiss Cheese Model and active/latent failure taxonomy, HFACS (Human Factors Analysis and Classification System), Just Culture algorithm (Marx/GAIN), Crew Resource Management (CRM) findings, and high-reliability organization (HRO) principles. Use when investigating incidents in aviation, healthcare, nuclear operations, emergency response, or any context where "operator error" is a tempting but shallow explanation and the real question is what organizational and design factors made the error foreseeable.

Install

npx vskill@latest install tibsfox/gsd-skill-creator/rca-human-factors

SKILL.md

The same SKILL.md was published earlier as majiayu000/claude-skill-registry/rca-human-factors.

Human-Factors RCA

"The root cause was human error" is almost never a useful investigation finding. It stops the inquiry exactly where it should begin. This skill teaches the frameworks that treat human performance as a window into the system that produced it — so you end up redesigning the system rather than retraining the operator.

Why "human error" is a symptom, not a cause

Sidney Dekker's principle (2014, The Field Guide to Understanding "Human Error"): if your RCA concludes with a person doing something wrong, you are roughly 20% through the investigation. The next 80% is the question: why was that action reasonable from where the person was standing, with the information they had, under the pressures they faced?

This reframing is not soft on accountability. It is the opposite: it refuses to let organizational design off the hook by letting the nearest human take the blame.

Framework 1 — Reason's Swiss Cheese Model

James Reason (Managing the Risks of Organizational Accidents, 1997) proposed that defenses against accidents are arranged in layers, each with weaknesses ("holes"). An accident occurs when holes in successive layers align and a hazard passes through all defenses.

The slices
  1. Organizational influences — culture, resource allocation, policies, incentive structures.
  2. Unsafe supervision — inadequate oversight, planned inappropriate operations, failure to correct known problems.
  3. Preconditions for unsafe acts — environmental factors, fatigue, stress, poor communication, inadequate tools.
  4. Unsafe acts — errors (slips, lapses, mistakes) and violations (routine, exceptional, sabotage).
Active vs. latent failures
  • Active failures — unsafe acts at the sharp end by operators in direct contact with the system. Immediate and visible.
  • Latent failures — dormant conditions introduced upstream by decisions of designers, managers, and policymakers. May lie dormant for years before combining with a local trigger.

Reason's insight: latent failures are the more productive focus for investigation because they affect many future incidents, not just the one you're investigating. Fixing the sharp-end operator fixes one accident; fixing the latent condition fixes the class.

Perneger's 2005 validation

Perneger's cross-sectional study of 159 healthcare quality professionals found widespread misunderstanding of the Swiss Cheese Model even among practitioners who used it weekly. Common errors:

  • Treating "slices" as sequential (slice 1 must hold or we go to slice 2) when they are actually parallel layered defenses.
  • Treating "holes" as fixed when they are dynamic, opening and closing with operational conditions.
  • Treating "arrows" as a single trajectory when hazards can traverse multiple paths simultaneously.
  • Treating active errors as the only causes when latent conditions usually dominate.

Takeaway: use the model but verify that your team's mental model of it is correct. Test understanding before running the framework.

Framework 2 — HFACS (Human Factors Analysis and Classification System)

HFACS was developed by Shappell and Wiegmann at the U.S. Naval Safety Center (2000) as a taxonomy for classifying human-factors contributors to aviation mishaps. It is a direct operationalization of Reason's Swiss Cheese Model.

The HFACS hierarchy
Organizational Influences
├── Resource Management
├── Organizational Climate
└── Organizational Process
Unsafe Supervision
├── Inadequate Supervision
├── Planned Inappropriate Operations
├── Failure to Correct a Known Problem
└── Supervisory Violations
Preconditions for Unsafe Acts
├── Environmental Factors
│ ├── Physical Environment
│ └── Technological Environment
├── Condition of Operators
│ ├── Adverse Mental States
│ ├── Adverse Physiological States
│ └── Physical/Mental Limitations
└── Personnel Factors
├── Crew Resource Management
└── Personal Readiness
Unsafe Acts
├── Errors
│ ├── Decision Errors
│ ├── Skill-Based Errors
│ └── Perceptual Errors
└── Violations
├── Routine
└── Exceptional
How to apply HFACS
  1. Extract every contributing factor from the incident narrative.
  2. Classify each factor into exactly one HFACS category (with forced-choice rules).
  3. Tally classifications — look for patterns across many incidents.
  4. Corrective actions must target categories with high incident density, not one-off causes.
Why it works

HFACS forces investigators to look beyond the proximate unsafe act. A well-run HFACS analysis on an aviation incident typically finds 3–5 latent conditions for every active error. Over a fleet of incidents, the taxonomy produces patterns that drive systemic interventions.

HFACS variants
  • HFACS-ME (maintenance environment)
  • HFACS-MI (military operations)
  • HFACS-RR (rail) — adapted for rail incident investigation
  • HFACS-HC (healthcare) — adapted for clinical settings

Use the variant matched to your domain, or adapt the generic framework with domain-specific sub-categories.

Framework 3 — Just Culture algorithm

The Just Culture concept, developed by David Marx (Outcome Engenuity) and adopted by the Global Aviation Information Network (GAIN), provides a decision algorithm for distinguishing the kind of unsafe act that calls for:

  • Console (the actor was in the hands of an unsafe system)
  • Coach (at-risk behavior drift needs course correction)
  • Discipline (reckless or intentional violation)
The three behaviors
BehaviorDefinitionResponse
Human errorUnintended deviation from what was plannedConsole; analyze system
At-risk behaviorBehavioral choice that increases risk where risk is unrecognized or believed justifiedCoach; remove incentive
Reckless behaviorConscious disregard of substantial and unjustifiable riskDiscipline
The Marx algorithm for a specific action

For each person involved in an unsafe act, walk through these questions in order:

  1. Impairment test. Was the person impaired (drugs, alcohol, medical condition)? If yes → discipline (or medical).
  2. Foresee-ability test. Would a professional in the same role at that moment have seen the risk? If no → human error, console.
  3. Alternate-action test. Was there a clearly better alternative? If no → human error, console.
  4. Substitution test. Would three similarly-situated peers have taken the same action? If yes → system problem, console.
  5. History test. Is this a pattern of drift, or a single lapse? Pattern → at-risk, coach. Single → human error.
  6. Recklessness test. Did the person knowingly disregard a substantial and unjustifiable risk? If yes → reckless, discipline.

A well-run Just Culture investigation protects operators from punitive responses to system-induced errors while maintaining accountability for reckless behavior. The algorithm is not a license to excuse everything — it is a disciplined classifier.

Counterexample: punitive response undoes reporting

Organizations that punish human error destroy their own incident-reporting systems: operators learn to hide errors, and latent conditions accumulate invisibly. This is well-documented in aviation (pre-ASRS era), healthcare (pre-AHRQ PSOs), and nuclear (pre-INPO). Just Culture is an organizational survival mechanism, not moral philosophy.

Framework 4 — CRM (Crew Resource Management)

Crew Resource Management emerged from the 1979 NASA workshop on flight-crew errors and the 1978 United 173 crash (fuel exhaustion due to captain's preoccupation with a landing-gear indicator). Its premise: technical skill is not enough; the crew as a team must manage communication, workload, and decision-making under stress.

Core CRM topics
  • Authority gradient management — flattening excessive authority gradients so first officers will challenge captains.
  • Closed-loop communication — standard readback protocols.
  • Assertiveness training — giving junior crew permission and protocols to speak up.
  • Workload management — delegation, task prioritization, fatigue awareness.
  • Situation awareness — shared mental model of the current operational state.
  • Error management — acknowledging that errors will happen and building trap/recover loops.
Paper 4 finding (our research)

The meta-analytic review of CRM training found consistent positive effects on aviation safety metrics (40–60% reduction in crew-related incidents after mature CRM adoption) but much smaller effects in healthcare, where CRM-style training was often delivered without the authority-gradient-flattening cultural change that makes it work. CRM training without culture change is classroom theatre.

Healthcare CRM: TeamSTEPPS

AHRQ's TeamSTEPPS program adapted CRM for clinical settings. Key additions:

  • SBAR (Situation-Background-Assessment-Recommendation) communication protocol.
  • CUS (Concerned, Uncomfortable, Safety issue) escalation phrases.
  • Two-challenge rule — if you raise a concern and it's dismissed, you're obligated to raise it again before acting.
  • Briefs / huddles / debriefs — short structured team alignments at shift start, mid-shift, and shift end.

Framework 5 — HRO principles

High-reliability organizations — aircraft carriers, nuclear power plants, wildland firefighting crews, air traffic control — operate complex systems with very low accident rates despite enormous intrinsic hazard. Weick and Sutcliffe (Managing the Unexpected, 2015) identified five cultural practices common to HROs:

  1. Preoccupation with failure. Small anomalies are treated as precursors and investigated seriously. "Near miss" is a diagnostic tool, not a report to file.
  2. Reluctance to simplify. Teams maintain skeptical, detailed, nuanced interpretations of what's happening. Categorical labels are resisted.
  3. Sensitivity to operations. Leaders have direct contact with the sharp end. "Management by walking around" is cultural.
  4. Commitment to resilience. Teams assume that something will go wrong and invest in the capacity to recover. Drill and rehearse recovery procedures.
  5. Deference to expertise. Decision-making migrates to whoever has the best information in the moment, regardless of rank. Hierarchies flatten during operations and reassert for planning.

These five practices are not incident-investigation techniques, but they describe the organizational substrate in which human-factors RCA actually produces change. Without them, findings get filed and the same incident recurs.

Integration pattern

Incident occurs
│
▼
Just Culture triage
├── Discipline (rare) — proceed to HR process
├── Coach (at-risk) — document drift pattern, feedback
└── Console (most cases) — proceed to RCA
│
▼
HFACS taxonomy — classify contributing factors
│
▼
Swiss Cheese mapping — identify latent conditions at each layer
│
▼
CRM / teamwork analysis — was this a coordination failure?
│
▼
HRO principle check — which cultural practices were absent?
│
▼
Corrective actions — target latent conditions and organizational practices,
not operator retraining (unless retraining addresses a genuine skill gap)

Anti-patterns to avoid

Anti-pattern 1 — Countermeasure theater

After an incident, the organization announces "additional training" and "updated procedures." Nothing else changes. The operator who had the incident is retrained, feels ashamed, and the next operator makes the same error six months later. Recovery: ask "what would make this error physically impossible or immediately correctable," not "how do we remind people to be careful."

Anti-pattern 2 — Paperwork apology

This is the start of the file. Read the full SKILL.md on GitHub.

Security

  • Security scanPassed, 95 of 100Pattern checks on the skill's files.
  • Model reviewPassed

Quality evaluation

  • Task evaluationNot runNo evaluation yet. Run one in Skill Studio.

Source

Popularity

Repository stars
57
Repository forks
8
Repository npm downloads, 7 days
65
7-day trend score
35

Stars and forks are for the whole GitHub repository, not this skill alone. Downloads are for the repository's npm package. Refreshed 17 May 2026, 5 months ago.

Works with

Any agent vskill installs to: 56 targets in all. These 39 have a page on this site.

  • Claude Code
  • Cursor
  • GitHub Copilot
  • Windsurf
  • Codex
  • Gemini CLI
  • Cline
  • Amp
  • Roo Code
  • Goose
  • Continue
  • Kilo Code
  • Junie
  • Trae
  • OpenHands
  • Qwen Code
  • AI Agent
  • Tabnine Chat
  • Sourcegraph Cody
  • Amazon Q
  • Firebase Genkit
  • Sweep
  • Devin
  • Phind
  • Mentat
  • Claude Desktop
  • Aider
  • GPT Pilot
  • Plandex
  • bolt.new
  • v0
  • Replit Agent
  • Anse
  • TypingMind
  • BetterChatGPT
  • LibreChat
  • Warp AI
  • Pieces
  • Fig AI
Embed badge
vskill VERIFIED badge
[![vskill VERIFIED](https://verified-skill.com/api/v1/skills/tibsfox/gsd-skill-creator/rca-human-factors/badge)](https://verified-skill.com/skills/tibsfox/gsd-skill-creator/rca-human-factors)

Something wrong with this skill or its page? Tell us.