cause-and-effect

Name: cause-and-effect
Author: NeoLabHQ

836installs132forks

How to install cause-and-effect?

neolabhq/context-engineering-kit/cause-and-effect

$npx -y skills add NeoLabHQ/context-engineering-kit --skill cause-and-effect

Installs into the current project.

Summary

Systematic Fishbone analysis exploring problem causes across six categories

Files · 1

View on GitHub

SKILL.md

1	# Cause and Effect Analysis
2
3	Apply Fishbone (Ishikawa) diagram analysis to systematically explore all potential causes of a problem across multiple categories.
4
5	## Description
6	Systematically examine potential causes across six categories: People, Process, Technology, Environment, Methods, and Materials. Creates structured "fishbone" view identifying contributing factors.
7
8	## Usage
9	`/cause-and-effect [problem_description]`
10
11	## Variables
12	- PROBLEM: Issue to analyze (default: prompt for input)
13	- CATEGORIES: Categories to explore (default: all six)
14
15	## Steps
16	1. State the problem clearly (the "head" of the fish)
17	2. For each category, brainstorm potential causes:
18	- People: Skills, training, communication, team dynamics
19	- Process: Workflows, procedures, standards, reviews
20	- Technology: Tools, infrastructure, dependencies, configuration
21	- Environment: Workspace, deployment targets, external factors
22	- Methods: Approaches, patterns, architectures, practices
23	- Materials: Data, dependencies, third-party services, resources
24	3. For each potential cause, ask "why" to dig deeper
25	4. Identify which causes are contributing vs. root causes
26	5. Prioritize causes by impact and likelihood
27	6. Propose solutions for highest-priority causes
28
29	## Examples
30
31	### Example 1: API Response Latency
32
33	```
34	Problem: API responses take 3+ seconds (target: <500ms)
35
36	PEOPLE
37	├─ Team unfamiliar with performance optimization
38	├─ No one owns performance monitoring
39	└─ Frontend team doesn't understand backend constraints
40
41	PROCESS
42	├─ No performance testing in CI/CD
43	├─ No SLA defined for response times
44	└─ Performance regression not caught in code review
45
46	TECHNOLOGY
47	├─ Database queries not optimized
48	│ └─ Why: No query analysis tools in place
49	├─ N+1 queries in ORM
50	│ └─ Why: Eager loading not configured
51	├─ No caching layer
52	│ └─ Why: Redis not in tech stack
53	└─ Synchronous external API calls
54	└─ Why: No async architecture in place
55
56	ENVIRONMENT
57	├─ Production uses smaller database instance than needed
58	├─ No CDN for static assets
59	└─ Single region deployment (high latency for distant users)
60
61	METHODS
62	├─ REST API design requires multiple round trips
63	├─ No pagination on large datasets
64	└─ Full object serialization instead of selective fields
65
66	MATERIALS
67	├─ Large JSON payloads (unnecessary data)
68	├─ Uncompressed responses
69	└─ Third-party API (payment gateway) is slow
70	└─ Why: Free tier with rate limiting
71
72	ROOT CAUSES:
73	- No performance requirements defined (Process)
74	- Missing performance monitoring tooling (Technology)
75	- Architecture doesn't support caching/async (Methods)
76
77	SOLUTIONS (Priority Order):
78	1. Add database indexes (quick win, high impact)
79	2. Implement Redis caching layer (medium effort, high impact)
80	3. Make external API calls async with webhooks (high effort, high impact)
81	4. Define and monitor performance SLAs (low effort, prevents regression)
82	```
83
84	### Example 2: Flaky Test Suite
85
86	```
87	Problem: 15% of test runs fail, passing on retry
88
89	PEOPLE
90	├─ Test-writing skills vary across team
91	├─ New developers copy existing flaky patterns
92	└─ No one assigned to fix flaky tests
93
94	PROCESS
95	├─ Flaky tests marked as "known issue" and ignored
96	├─ No policy against merging with flaky tests
97	└─ Test failures don't block deployments
98
99	TECHNOLOGY
100	├─ Race conditions in async test setup
101	├─ Tests share global state
102	├─ Test database not isolated per test
103	├─ setTimeout used instead of proper waiting
104	└─ CI environment inconsistent (different CPU/memory)
105
106	ENVIRONMENT
107	├─ CI runner under heavy load
108	├─ Network timing varies (external API mocks flaky)
109	└─ Timezone differences between local and CI
110
111	METHODS
112	├─ Integration tests not properly isolated
113	├─ No retry logic for legitimate timing issues
114	└─ Tests depend on execution order
115
116	MATERIALS
117	├─ Test data fixtures overlap
118	├─ Shared test database polluted
119	└─ Mock data doesn't match production patterns
120
121	ROOT CAUSES:
122	- No test isolation strategy (Methods + Technology)
123	- Process accepts flaky tests (Process)
124	- Async timing not handled properly (Technology)
125
126	SOLUTIONS:
127	1. Implement per-test database isolation (high impact)
128	2. Replace setTimeout with proper async/await patterns (medium impact)
129	3. Add pre-commit hook blocking flaky test patterns (prevents new issues)
130	4. Enforce policy: flaky test = block merge (process change)
131	```
132
133	### Example 3: Feature Takes 3 Months Instead of 3 Weeks
134
135	```
136	Problem: Simple CRUD feature took 12 weeks vs. 3 week estimate
137
138	PEOPLE
139	├─ Developer unfamiliar with codebase
140	├─ Key architect on vacation during critical phase
141	└─ Designer changed requirements mid-development
142
143	PROCESS
144	├─ Requirements not finalized before starting
145	├─ No code review for first 6 weeks (large diff)
146	├─ Multiple rounds of design revision
147	└─ QA started late (found issues in week 10)
148
149	TECHNOLOGY
150	├─ Codebase has high coupling (change ripple effects)

People who liked this also viewed

6 picks

Type

azure-diagnosticsDebug Azure production issues on Azure using AppLens, Azure Monitor, resource health, and safe triage. WHEN: debug production issues, troubleshoot app service, app service high CPU, app service deploySkillsJul 2026472k1.3k
systematic-debuggingUse when encountering any bug, test failure, or unexpected behavior, before proposing fixesSkillsJul 2026197k259k
safe-debugRigor Debug / Rigor Audit skill for deep learning research work. Use when the user pastes a traceback, terminal error, CUDA OOM, checkpoint load failure, shape mismatch, NaN loss symptom, or training SkillsMay 2026161k507
explore-runRigor Improve / Rigor Explore run leaf skill for bounded exploratory evidence in deep learning research repositories. Use when the researcher explicitly authorizes exploratory runs such as small-subseSkillsMay 2026161k507
minimal-run-and-auditRigor Run skill for README-first deep learning repo reproduction. Use when the task is specifically to capture or normalize evidence from the selected smoke test or documented inference or evaluation SkillsMay 2026161k507
insforge-debugUse when diagnosing problems in an InsForge project — reactive failures (SDK error object, HTTP 4xx/5xx, gateway timeout 502/503/504, edge function failure or timeout, login/OAuth/auth errors, RLS denSkillsJul 202618k31

cause-and-effect

836installs132forks

View on GitHub

How to install cause-and-effect?

neolabhq/context-engineering-kit/cause-and-effect

$npx -y skills add NeoLabHQ/context-engineering-kit --skill cause-and-effect

Installs into the current project.

Summary

Systematic Fishbone analysis exploring problem causes across six categories

Files · 1

View on GitHub

SKILL.md

1	# Cause and Effect Analysis
2
3	Apply Fishbone (Ishikawa) diagram analysis to systematically explore all potential causes of a problem across multiple categories.
4
5	## Description
6	Systematically examine potential causes across six categories: People, Process, Technology, Environment, Methods, and Materials. Creates structured "fishbone" view identifying contributing factors.
7
8	## Usage
9	`/cause-and-effect [problem_description]`
10
11	## Variables
12	- PROBLEM: Issue to analyze (default: prompt for input)
13	- CATEGORIES: Categories to explore (default: all six)
14
15	## Steps
16	1. State the problem clearly (the "head" of the fish)
17	2. For each category, brainstorm potential causes:
18	- People: Skills, training, communication, team dynamics
19	- Process: Workflows, procedures, standards, reviews
20	- Technology: Tools, infrastructure, dependencies, configuration
21	- Environment: Workspace, deployment targets, external factors
22	- Methods: Approaches, patterns, architectures, practices
23	- Materials: Data, dependencies, third-party services, resources
24	3. For each potential cause, ask "why" to dig deeper
25	4. Identify which causes are contributing vs. root causes
26	5. Prioritize causes by impact and likelihood
27	6. Propose solutions for highest-priority causes
28
29	## Examples
30
31	### Example 1: API Response Latency
32
33	```
34	Problem: API responses take 3+ seconds (target: <500ms)
35
36	PEOPLE
37	├─ Team unfamiliar with performance optimization
38	├─ No one owns performance monitoring
39	└─ Frontend team doesn't understand backend constraints
40
41	PROCESS
42	├─ No performance testing in CI/CD
43	├─ No SLA defined for response times
44	└─ Performance regression not caught in code review
45
46	TECHNOLOGY
47	├─ Database queries not optimized
48	│ └─ Why: No query analysis tools in place
49	├─ N+1 queries in ORM
50	│ └─ Why: Eager loading not configured
51	├─ No caching layer
52	│ └─ Why: Redis not in tech stack
53	└─ Synchronous external API calls
54	└─ Why: No async architecture in place
55
56	ENVIRONMENT
57	├─ Production uses smaller database instance than needed
58	├─ No CDN for static assets
59	└─ Single region deployment (high latency for distant users)
60
61	METHODS
62	├─ REST API design requires multiple round trips
63	├─ No pagination on large datasets
64	└─ Full object serialization instead of selective fields
65
66	MATERIALS
67	├─ Large JSON payloads (unnecessary data)
68	├─ Uncompressed responses
69	└─ Third-party API (payment gateway) is slow
70	└─ Why: Free tier with rate limiting
71
72	ROOT CAUSES:
73	- No performance requirements defined (Process)
74	- Missing performance monitoring tooling (Technology)
75	- Architecture doesn't support caching/async (Methods)
76
77	SOLUTIONS (Priority Order):
78	1. Add database indexes (quick win, high impact)
79	2. Implement Redis caching layer (medium effort, high impact)
80	3. Make external API calls async with webhooks (high effort, high impact)
81	4. Define and monitor performance SLAs (low effort, prevents regression)
82	```
83
84	### Example 2: Flaky Test Suite
85
86	```
87	Problem: 15% of test runs fail, passing on retry
88
89	PEOPLE
90	├─ Test-writing skills vary across team
91	├─ New developers copy existing flaky patterns
92	└─ No one assigned to fix flaky tests
93
94	PROCESS
95	├─ Flaky tests marked as "known issue" and ignored
96	├─ No policy against merging with flaky tests
97	└─ Test failures don't block deployments
98
99	TECHNOLOGY
100	├─ Race conditions in async test setup
101	├─ Tests share global state
102	├─ Test database not isolated per test
103	├─ setTimeout used instead of proper waiting
104	└─ CI environment inconsistent (different CPU/memory)
105
106	ENVIRONMENT
107	├─ CI runner under heavy load
108	├─ Network timing varies (external API mocks flaky)
109	└─ Timezone differences between local and CI
110
111	METHODS
112	├─ Integration tests not properly isolated
113	├─ No retry logic for legitimate timing issues
114	└─ Tests depend on execution order
115
116	MATERIALS
117	├─ Test data fixtures overlap
118	├─ Shared test database polluted
119	└─ Mock data doesn't match production patterns
120
121	ROOT CAUSES:
122	- No test isolation strategy (Methods + Technology)
123	- Process accepts flaky tests (Process)
124	- Async timing not handled properly (Technology)
125
126	SOLUTIONS:
127	1. Implement per-test database isolation (high impact)
128	2. Replace setTimeout with proper async/await patterns (medium impact)
129	3. Add pre-commit hook blocking flaky test patterns (prevents new issues)
130	4. Enforce policy: flaky test = block merge (process change)
131	```
132
133	### Example 3: Feature Takes 3 Months Instead of 3 Weeks
134
135	```
136	Problem: Simple CRUD feature took 12 weeks vs. 3 week estimate
137
138	PEOPLE
139	├─ Developer unfamiliar with codebase
140	├─ Key architect on vacation during critical phase
141	└─ Designer changed requirements mid-development
142
143	PROCESS
144	├─ Requirements not finalized before starting
145	├─ No code review for first 6 weeks (large diff)
146	├─ Multiple rounds of design revision
147	└─ QA started late (found issues in week 10)
148
149	TECHNOLOGY
150	├─ Codebase has high coupling (change ripple effects)

People who liked this also viewed

6 picks

Type