agentleFS
Sign inStart free
ashley-eyekyamashley-eyekyam/probematrix-learnings-coach/skills/barrier-learnings/SKILL.md

barrier-learnings

Skill0 starsChanged 28 days agoMITView on GitHub

Analyse which safety barriers and controls failed in a ProbeMatrix investigation - prevention barriers before the event and mitigation barriers after it - who owned each, how it degraded, and how strong the fix should be on the hierarchy of controls, with leading indicators. Use when someone asks about barriers, controls, defences, bow-tie style learning, critical controls, "why didn't our safeguards work", or wants recommendations stronger than retraining.

The file

We split this skill into the rules it gives an agent

2 rules. About 0 are common, 1 is distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈1

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Do not declare a barrier effective or ineffective beyond what the evidence states.

    line 28
  2. Very specific:

    Write the pack <run>/outputs/barrier-learnings.json (schema: learnings-coach/references/pack-schema.md), then:

    line 36

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Barrier Learnings

Engine: PMLC = python3 <skills-root>/learnings-coach/scripts/pmlc.py (this skill needs the learnings-coach skill installed alongside it). Read learnings-coach/references/output-style.md (hierarchy of controls, leading indicators).

Identify barriers

From the incident narrative (<ws>/incident.json) and the highest-rated findings (PMLC select <ws> --top-rated --brief), list the barriers that were supposed to stand between the hazard and the outcome:

  • Prevention side (before loss of control): design and specification, maintenance and testing, inspection, procedures and permits, competence, change management.
  • Mitigation side (after loss of control): detection, alarm, isolation, ignition control, emergency response, fire protection, escape and recovery.

For each barrier

FieldContent
Barriername and side
Ownerentity and tier (from the findings' clusters)
State on the dayabsent / degraded / defeated / worked partly / worked
How it degradedthe L2–L4 findings behind its state, with dates if known
Fixproposed control and its HoC tier
Leading indicatorhow the owner will know the barrier is healthy
Evidencefinding and evidence IDs

Do not declare a barrier effective or ineffective beyond what the evidence states. Use "[GAP]" where the export does not tell you.

Learn

Summarise: which barriers carried the most weight, whether failures clustered on one side, and what share of proposed fixes are above the administrative tier. Give a short ranked list of "critical controls to verify first" for the owners.

Output

Write the pack <run>/outputs/barrier-learnings.json (schema: learnings-coach/references/pack-schema.md), then:

PMLC check-pack <ws> <run>/outputs/barrier-learnings.json   # fix every problem it lists
PMLC pack <ws> <run>/outputs/barrier-learnings.json         # -> barrier-learnings.html (primary) and .md

Sections and the kinds that fill them:

  • Barriers: one barrier per row of the table above, with group = "Prevention" or "Mitigation". The table's fields map like this:
    • Barrier → barrier, plus type
    • Owner → owner
    • State on the day → state
    • How it degraded → failure_mode (write "[GAP] …" where the export does not say)
    • Fix → fix and hoc_tier
    • Leading indicator → indicator
    • Evidence → cites
  • Summary: para.
  • Critical controls to verify first: check items, in ranked order.

Set "scope": {"min_rating": "top"}. Put data-quality corrections in data_quality, findings left out on purpose in exclusions, and same-condition findings in supporting_cites. For a bow-tie, hand the barrier items to a bow-tie tool.

{"kind": "barrier", "group": "Prevention", "barrier": "…", "type": "prevention", "owner": "…", "state": "absent",
 "failure_mode": "…", "hoc_tier": "engineering", "fix": "…", "indicator": "…", "cites": ["FND-…"]}

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

Check your setup, free