agentleFS
Sign inStart free
niksavisniksavis/basicly/.agents/skills/root-cause/SKILL.md

root-cause

Skill2 starsChanged 5 days agoMITView on GitHub

Finds the cause of a failure, a bug that came back or a test that fails intermittently, link by link with evidence, to a control this repository owns. Use when asked why something broke, keeps breaking or fails, and the cause is unclear.

27 other projects use a version of this, 1 of them edited.

Adopted by

Most recently taken up by

Used with

Projects with it also use prove-it, grill and 10 more.

Other files people use alongside this one.

Files found in the same public projects as a version of this one, more often than they turn up anywhere else. Each project counts once, large collections count for less, and this file's own repository is left out.
  • Neko-Catpital-LabsSkill

    prove-it

    Shared evidence rule for investigating, diagnosing, debugging, proving, or explaining what happened or why for any problem or situation: do not assert something is fixed, working, passing, merged, or running unless you personally observed it this turn and can show what you saw; do not assert it was caused by X until a repro and controlled isolation prove that cause.

    Also in 3 projects that use this

  • renatorozasSkill

    grill

    Adversarial code review. Don't let me ship until the changes pass your scrutiny.

    Also in 4 projects that use this

  • sunnyclinches44Skill

    explain

    Explains code using real-world analogies and ASCII diagrams

    Also in 5 projects that use this

  • jasonmichaelbell78-creatorSkill

    skill-audit

    Interactive behavioral quality audit for individual skills. Evaluates against 12 quality categories (including T25 convergence loop and completion verification) to surface attention management issues and produce actionable decisions. Includes self-audit verification that all decisions were actually implemented. Uses convergence loops in its own discovery phase. Produces a decision record and updated skill files.

    Also in 3 projects that use this

  • Microsoft AzureSkill

    design

    Design rules and conventions for the API Center Portal. Use when editing detail pages, card components, badges, layout, navigation, sidebars, or headers. Covers badge styling, metadata placement, page navigation patterns, and layout alignment.

    Also in 4 projects that use this

  • SentrySkill

    spec

    Produce a verified spec — problem, desired outcome, and acceptance criteria — before building. Use when given a GitHub/Linear issue link, when starting from a fuzzy in-conversation idea, or asked to "figure out what to do" / "scope this" / "what should I build" — whenever the *what* isn't yet pinned down. Grills the ambiguities, checks the premise against the code, and produces acceptance criteria you sign off on — then hands to design-first.

    Also in 3 projects that use this

The file

We split this skill into the rules it gives an agent

1 rule. 0 are common, 0 are distinctive, and 1 is very specific to this project.

  • 0

    Common

    Most of the 25 edited versions we read keep these.

  • 0

    Distinctive

    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. Very specific:

    Ask why until the answer is a cause this repository controls.

    line 23

“Common” is measured: kept by at least 6 in 10 of the 25 edited versions of this file we could read. “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
<!-- Generated by `basicly skills-build` from skill.yaml. Do not edit; edit the source. -->

Root Cause

Find the demonstrated cause of the observed failure and the control that would have refused it. This skill diagnoses; repair-in-place or the owner fixes.

Rules

  • Every link cites an observation. A link that you reasoned to is where the chain becomes a story.
  • Stop at a cause this repository owns. A vendor decision or "the model was wrong" gives you nothing to build a Control against.
  • Never stop on a person. "Someone forgot" means the chain stopped early. Ask what let the mistake reach a commit.

1. Reproduce the defect

Run the failing command and paste its output. Record the input, the observed failure and the expected behaviour. For a recurring failure, read the record's tracker notes and git log -S SYMBOL for earlier attempts. When two causes predict the same result, use falsify-first to find an observation that tells them apart.

2. Ask why

Ask why until the answer is a cause this repository controls. Each link cites a file:line, a command and its output, a ledger row or a recorded verdict. When the next why leaves this repository, go back one link and name the Control there.

At each link where a second answer was available, name it and say why you took the other one.

3. Test the chain

  • Per cause: if you removed this cause, would the failure still happen? If yes, it is a condition you noticed, not a cause. Continue the chain.
  • For the chain: if you removed every cause in it, could the failure still happen? If yes, a link is missing, and that link needs the Control.

A second person can run these two tests against your chain without a new derivation.

4. Output

FieldContent
ChainEach why with its cited observation, in order, ending at the cause this repository owns
ControlThe check, gate, schema field, refusal or document that would have stopped this defect; its Tier says how strongly
TierHow strongly the Control acts, in the engine's terms: control (a gate fails), warning (it reports and continues) or documentation (a person must read it). Record a documentation tier as a downgrade, with the reason that no stronger control was available
CoversThe observed defect and related call paths established by evidence
Branch not takenOne line

Hand the fix to repair-in-place, or to the owner, with the Control row. Record other improvements as separate recommendations.

For a worked chain from signal to control, read example.

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