Cause And Effect
Run structured Fishbone (Ishikawa) analysis when incidents or quality issues need causes explored across six standard categories.
Overview
cause-and-effect is a journey-wide agent skill that applies six-category Fishbone analysis to problems—usable whenever a solo builder needs to map causes before committing to a fix.
Install
npx skills add https://github.com/neolabhq/context-engineering-kit --skill cause-and-effectWhat is this skill?
- Fishbone (Ishikawa) analysis with six default categories: People, Process, Technology, Environment, Methods, Materials
- Six-step flow from problem statement through prioritized solutions
- Per-category brainstorming with follow-up “why” deepening
- Separates contributing causes from root causes before prioritization
- Slash command: /cause-and-effect with optional problem_description
- Six default Fishbone categories: People, Process, Technology, Environment, Methods, Materials
- Six documented analysis steps from problem statement to solutions
Adoption & trust: 521 installs on skills.sh; 1.1k GitHub stars; 3/3 security scanners passed (skills.sh audits).
What problem does it solve?
You see a symptom—slow API, broken deploy, confused users—but ad-hoc guessing leaves blind spots across team, process, and environment factors.
Who is it for?
Builders debugging production issues, retrospective facilitators, or agents helping structure postmortems without jumping to a single fix.
Skip if: Cases where you already have automated distributed tracing root-cause IDs and only need code patches with no systemic review.
When should I use this skill?
Apply when you need systematic Fishbone analysis; run /cause-and-effect with an optional problem_description or prompt for the problem.
What do I get? / Deliverables
You get a categorized cause tree, root-cause shortlist ranked by impact and likelihood, and concrete solution proposals for the top branches.
- Structured cause map across six categories
- Prioritized root and contributing causes with proposed solutions
Recommended Skills
Journey fit
Useful at every journey phase - explore requirements and options before committing to a direction.
Where it fits
Map why checkout failures spiked by examining data pipelines (Materials) and on-call handoffs (People).
Before merge, trace recurring test flakes across Process and Environment instead of blaming one line of code.
Challenge a MVP cut that ignores Methods and third-party Materials risks surfaced in early user interviews.
Diagnose API response latency using the kit’s example pattern across Technology and Methods branches.
Frame competitive or operational risks before build starts using the same six-category lens.
How it compares
Use instead of unstructured “five whys in chat” when you want equal coverage across six Ishikawa categories.
Common Questions / FAQ
Who is cause-and-effect for?
Solo and indie builders, plus agents assisting them, who need disciplined root-cause exploration beyond the first hypothesis.
When should I use cause-and-effect?
Use it in Operate when triaging errors, in Ship during review or launch regressions, in Validate when scope assumptions fail, in Build when architecture choices cause recurring defects, and in Idea when early risk brainstorming needs structure.
Is cause-and-effect safe to install?
It is analytical prose with no built-in shell or network calls in the documented flow; still review the Security Audits panel on this Prism page before installing any kit skill.
SKILL.md
READMESKILL.md - Cause And Effect
# Cause and Effect Analysis Apply Fishbone (Ishikawa) diagram analysis to systematically explore all potential causes of a problem across multiple categories. ## Description Systematically examine potential causes across six categories: People, Process, Technology, Environment, Methods, and Materials. Creates structured "fishbone" view identifying contributing factors. ## Usage `/cause-and-effect [problem_description]` ## Variables - PROBLEM: Issue to analyze (default: prompt for input) - CATEGORIES: Categories to explore (default: all six) ## Steps 1. State the problem clearly (the "head" of the fish) 2. For each category, brainstorm potential causes: - **People**: Skills, training, communication, team dynamics - **Process**: Workflows, procedures, standards, reviews - **Technology**: Tools, infrastructure, dependencies, configuration - **Environment**: Workspace, deployment targets, external factors - **Methods**: Approaches, patterns, architectures, practices - **Materials**: Data, dependencies, third-party services, resources 3. For each potential cause, ask "why" to dig deeper 4. Identify which causes are contributing vs. root causes 5. Prioritize causes by impact and likelihood 6. Propose solutions for highest-priority causes ## Examples ### Example 1: API Response Latency ``` Problem: API responses take 3+ seconds (target: <500ms) PEOPLE ├─ Team unfamiliar with performance optimization ├─ No one owns performance monitoring └─ Frontend team doesn't understand backend constraints PROCESS ├─ No performance testing in CI/CD ├─ No SLA defined for response times └─ Performance regression not caught in code review TECHNOLOGY ├─ Database queries not optimized │ └─ Why: No query analysis tools in place ├─ N+1 queries in ORM │ └─ Why: Eager loading not configured ├─ No caching layer │ └─ Why: Redis not in tech stack └─ Synchronous external API calls └─ Why: No async architecture in place ENVIRONMENT ├─ Production uses smaller database instance than needed ├─ No CDN for static assets └─ Single region deployment (high latency for distant users) METHODS ├─ REST API design requires multiple round trips ├─ No pagination on large datasets └─ Full object serialization instead of selective fields MATERIALS ├─ Large JSON payloads (unnecessary data) ├─ Uncompressed responses └─ Third-party API (payment gateway) is slow └─ Why: Free tier with rate limiting ROOT CAUSES: - No performance requirements defined (Process) - Missing performance monitoring tooling (Technology) - Architecture doesn't support caching/async (Methods) SOLUTIONS (Priority Order): 1. Add database indexes (quick win, high impact) 2. Implement Redis caching layer (medium effort, high impact) 3. Make external API calls async with webhooks (high effort, high impact) 4. Define and monitor performance SLAs (low effort, prevents regression) ``` ### Example 2: Flaky Test Suite ``` Problem: 15% of test runs fail, passing on retry PEOPLE ├─ Test-writing skills vary across team ├─ New developers copy existing flaky patterns └─ No one assigned to fix flaky tests PROCESS ├─ Flaky tests marked as "known issue" and ignored ├─ No policy against merging with flaky tests └─ Test failures don't block deployments TECHNOLOGY ├─ Race conditions in async test setup ├─ Tests share global state ├─ Test database not isolated per test ├─ setTimeout used instead of proper waiting └─ CI environment inconsistent (different CPU/memory) ENVIRONMENT ├─ CI runner under heavy load ├─ Network timing varies (external API mocks flaky) └─ Timezone differences between local and CI METHODS ├─ Integration tests not properly isolated ├─ No retry logic for legitimate timing issues └─ Tests depend on execution order MATERIALS ├─ Test data fixtures overlap ├─ Shared test database polluted └─ M