agentleFS
ashley-eyekyamashley-eyekyam/probematrix-learnings-coach/skills/engineering-integrity-learnings/SKILL.md

engineering-integrity-learnings

Skill0 starsChanged 27 days agoMITView on GitHub

Produce learning for engineering, design, asset integrity, inspection, reliability, instrumentation and management-of-change functions from a ProbeMatrix investigation export - specifications and documents, change control, inspection and corrosion programmes, testing after maintenance, alarm and safety-system design, ageing equipment - with technical recommendations rated on the hierarchy of controls. Use when someone asks what engineers, the technical authority, integrity or reliability teams, MOC owners or instrument engineers should learn, or wants a technical lessons pack from an incident.

The file

We split this skill into the rules it gives an agent

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

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈0

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 2

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

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

    line 30
  2. Very specific:

    Numbers rule: Do not specify engineering values (pressures, thicknesses, intervals, percentages, durations) beyond what the cited records …

    line 52

≈ “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

Engineering & Integrity Learnings

Audience: the Learning Clusters tagged engineering (in the default taxonomy F04 instrumentation, control and calibration, F05 asset integrity, corrosion and inspection, F07 engineering, design, documents and MOC, and F03 electrical, for hazardous-area equipment).

Engine: PMLC = python3 <skills-root>/learnings-coach/scripts/pmlc.py (this skill needs the learnings-coach skill installed alongside it). Read learnings-coach/references/learning-principles.md.

Gather

PMLC select <ws> --tag engineering --brief
PMLC select <ws> --tag engineering --level 3 4 --top-rated
PMLC select <ws> --text "specification|drawing|P&ID|MOC|change|inspection|thickness|corrosion|calibrat|interlock|test|design" --brief
PMLC timeline <ws> --before incident

Write

  1. Technical learnings by theme: specification and substitution of parts; testing after maintenance; change management; inspection and corrosion programmes; documents and as-built records; detection, alarm and shutdown design; hazardous-area equipment integrity; ageing equipment. Only themes the evidence supports.
  2. For each learning: the technical condition, how it persisted (L3–L4), the barrier it weakened, a recommendation with HoC tier (engineering controls first where credible), and a technical leading indicator.
  3. Engineering decisions pending: questions the technical authority must settle (e.g. test pressure policy after pressure-boundary work, acceptance of substitute components), stated as decisions, not answers.
  4. Data and records: what technical records were missing or unreliable, and what the minimum record should be.

Output

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

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

Sections → kinds:

  1. For each learning, write three items with the same group (the theme):
    • a learning: the technical condition and how it persisted;
    • a barrier for the barrier it weakened (type, owner, state, failure_mode, hoc_tier, fix, indicator);
    • a recommendation, engineering controls first where credible.
  2. decision items (options, no answers), with owner = the technical authority.
  3. check items stating the minimum record, with when = the point in the work.

Set "scope": {"tags": ["engineering"]}. Put data-quality corrections in data_quality, findings left out on purpose in exclusions, and same-condition findings in supporting_cites.

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

Numbers rule. Do not specify engineering values (pressures, thicknesses, intervals, percentages, durations) beyond what the cited records state; never add a figure from outside the export; make them decision items for the technical authority.

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.