Rca ishikawa
Skill iggmasterdev/badquality-lab/rca-prevention-facilitator/skills/rca-ishikawa
Agents and skills that bring Quality Engineering into AI-assisted SDLC workflows. badquality.dev
npx -y skills add iggmasterdev/badquality-lab --skill rca-ishikawaAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Runs an Ishikawa / fishbone contributing-factors sweep across five categories — Process · People · Tooling · Requirements · Environment — so an RCA doesn't tunnel on the single obvious cause. Use for the Contributing-factors step of a SEV1/rollback RCA session, when a root cause feels too simple, or when you want to check "what else made this more likely." Only records categories that actually apply; keeps "People" blameless (systemic conditions, not fault). Called by rca-session-facilitator; usable standalone.
SKILL.md
3.7 KB, as published. Nobody here has run it
Ishikawa / fishbone — contributing factors
Purpose
After the 5 Whys finds the dominant root cause, sweep the five categories where causes hide so you don't miss the conditions that made the failure more likely. This is a checklist against tunnel vision — not a second root-cause hunt.
When to use / triggers
Contributing-factors field of an RCA + Prevention Record · "what else contributed" · a root cause that seems too clean · deciding whether the one prevention is aimed at the right category.
The five categories (prompt each; skip the ones that don't apply)
| Category | Ask | Example signals |
|---|---|---|
| Process | Which step/gate was missing, skipped, or unowned? | no pre-release check, no DoD item, no review gate |
| People | What systemic condition around people raised risk? (capacity, onboarding, knowledge silo — never individual blame) | single point of knowledge, no onboarding for the component, overloaded owner |
| Tooling | What did the tools fail to catch or make hard? | no schema validator, no contract test, flaky suite ignored |
| Requirements | What was undefined, ambiguous, or unwritten? | "required fields" never defined, no written data contract, unclear AC |
| Environment | What about infra/data/config/release channel contributed? | runtime-only behaviour, staged rollout masked the fault, prod-only data shape |
How to run it
- Take the ROOT CAUSE from the 5 Whys as the spine of the fishbone.
- Walk the five categories in order. For each, ask the category question once. If nothing real surfaces, write nothing for that category — empty is honest; padding is noise.
- For People, force the systemic reframe: convert any "X person did/didn't…" into the condition that allowed it ("no onboarding path for the event schemas", not "X didn't know").
- Mark which single category the chosen prevention will target — that's the handoff to
rca-prevention-design. If contributing factors cluster in a category other than where the prevention lands, flag it: the prevention may be aimed at the wrong bone.
Worked example (data-contract failure)
- Process: no pre-release step captures/validates emitted events. ✅ (prevention targets this)
- Requirements: required-field schema per event was never written down. ✅
- Tooling: no runtime event-capture/validation harness exists yet.
- People: — (nothing systemic beyond the above; leave blank)
- Environment: events only exist at runtime, so a build-time check can't see them — the guard must run against an instrumented build. ✅ (shapes how the prevention is built)
Quality gate (all must hold)
- Only categories with a real contributing factor are recorded — no padding.
- "People" entries are systemic conditions, never individual fault.
- The category the prevention targets is identified.
- Nothing here silently replaces the 5 Whys root cause — this is contributing, not the cause.
- Terminology clean — "QA engineer" / "test engineer", never "manual tester".