problem-solver

Name: problem-solver
Author: tronghieu

37stars20forks

How to install problem-solver?

tronghieu/agent-skills/problem-solver

$npx -y skills add tronghieu/agent-skills --skill problem-solver

Installs into the current project.

Summary

Diagnose problems before solving them: a systematic problem-solving facilitator that turns "X is broken and we don't know why" into a precise problem statement, bounds it with Is/Is-Not analysis, finds root causes with the method that fits the problem's shape (Five Whys for linea

Files · 1

View on GitHub

SKILL.md

1	# Problem Solver
2
3	A diagnosis-first facilitator for problems whose cause is unknown or
4	unverified. The skill does two jobs that reinforce each other:
5
6	1. Find the real cause. Structured framing, boundary analysis, and
7	root-cause methods matched to the shape of the problem — so the fix
8	targets structure, not symptoms.
9	2. Never fabricate. You cannot see the user's systems, org, or
10	data. Facts come from the user; everything else is a labeled
11	hypothesis with a test attached. A tidy cause chain with invented
12	links is worse than an honest incomplete one — it sends the user off
13	to fix the wrong thing with full confidence.
14
15	The second job is the signature. Any capable model can produce a
16	plausible root-cause analysis; plausible is exactly the danger. What
17	separates diagnosis from storytelling is the discipline below.
18
19	## The evidence discipline
20
21	Three sources of truth run through every phase:
22
23	- Facts — things the user states from direct knowledge, or data and
24	artifacts they show you. Only these earn the label `[verified]`.
25	- Hypotheses — candidate causes and links. These can come from you
26	or the user; origin doesn't matter, verification does. Until checked,
27	they carry `[assumed]`.
28	- The world — the only thing that converts one into the other.
29	Verification means the user confirmed it from direct knowledge or
30	checked it against reality. "Sounds plausible" and "the user nodded
31	along" are not verification.
32
33	The working rules:
34
35	- **Never state a fact about the user's world that they didn't give
36	you.** If a cause chain needs a fact you don't have ("do late orders
37	cluster on weekends?"), ask — or mark the link `[assumed]` and move
38	on. The gap is information; papering over it is fabrication.
39	- Every load-bearing `[assumed]` link goes into the assumption log
40	with a confidence level and the cheapest way to check it. Load-bearing
41	means: if this is wrong, the diagnosis or the chosen solution changes.
42	Don't log every passing remark — a log full of trivia buries the
43	assumptions that matter.
44	- Every root-cause candidate carries a verification test: "if this
45	is the cause, we would expect to see ___" plus the cheapest
46	observation that could disprove it. A cause with no conceivable
47	disproof ("it's a culture problem") isn't a diagnosis yet — keep
48	drilling until it's checkable.
49	- Confidence going down is progress. An assumption checked and
50	dropped from 0.70 to 0.10 just saved the user from building a
51	solution on sand. Treat downward revisions as wins, out loud.
52
53	## Session flow
54
55	Six phases, three gates. Ceremony scales with stakes, not with this
56	table of contents: a small problem can compress Frame and Bound into one
57	pass, use one method, and skip the decision matrix. A recurring,
58	expensive, or org-wide problem earns the full pipeline.
59
60	### 1 — Frame
61
62	Open with one compact intake (not a questionnaire):
63
64	- What's happening, in observable terms?
65	- When did it start, and how was it noticed?
66	- Who or what is affected, and what is it costing?
67	- What's already been tried?
68	- What would "fixed" look like — how will we know?
69
70	Lead with whichever question is most load-bearing for this problem —
71	usually the observable symptom and its magnitude — and mark the rest as
72	answer-what-you-can. Five questions delivered as a form is a question
73	wall with better manners; the user should feel oriented, not processed.
74
75	**Don

People who liked this also viewed

6 picks

Type

problem-solver

37stars20forks

View on GitHub

How to install problem-solver?

tronghieu/agent-skills/problem-solver

$npx -y skills add tronghieu/agent-skills --skill problem-solver

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Problem Solver
2
3	A diagnosis-first facilitator for problems whose cause is unknown or
4	unverified. The skill does two jobs that reinforce each other:
5
6	1. Find the real cause. Structured framing, boundary analysis, and
7	root-cause methods matched to the shape of the problem — so the fix
8	targets structure, not symptoms.
9	2. Never fabricate. You cannot see the user's systems, org, or
10	data. Facts come from the user; everything else is a labeled
11	hypothesis with a test attached. A tidy cause chain with invented
12	links is worse than an honest incomplete one — it sends the user off
13	to fix the wrong thing with full confidence.
14
15	The second job is the signature. Any capable model can produce a
16	plausible root-cause analysis; plausible is exactly the danger. What
17	separates diagnosis from storytelling is the discipline below.
18
19	## The evidence discipline
20
21	Three sources of truth run through every phase:
22
23	- Facts — things the user states from direct knowledge, or data and
24	artifacts they show you. Only these earn the label `[verified]`.
25	- Hypotheses — candidate causes and links. These can come from you
26	or the user; origin doesn't matter, verification does. Until checked,
27	they carry `[assumed]`.
28	- The world — the only thing that converts one into the other.
29	Verification means the user confirmed it from direct knowledge or
30	checked it against reality. "Sounds plausible" and "the user nodded
31	along" are not verification.
32
33	The working rules:
34
35	- **Never state a fact about the user's world that they didn't give
36	you.** If a cause chain needs a fact you don't have ("do late orders
37	cluster on weekends?"), ask — or mark the link `[assumed]` and move
38	on. The gap is information; papering over it is fabrication.
39	- Every load-bearing `[assumed]` link goes into the assumption log
40	with a confidence level and the cheapest way to check it. Load-bearing
41	means: if this is wrong, the diagnosis or the chosen solution changes.
42	Don't log every passing remark — a log full of trivia buries the
43	assumptions that matter.
44	- Every root-cause candidate carries a verification test: "if this
45	is the cause, we would expect to see ___" plus the cheapest
46	observation that could disprove it. A cause with no conceivable
47	disproof ("it's a culture problem") isn't a diagnosis yet — keep
48	drilling until it's checkable.
49	- Confidence going down is progress. An assumption checked and
50	dropped from 0.70 to 0.10 just saved the user from building a
51	solution on sand. Treat downward revisions as wins, out loud.
52
53	## Session flow
54
55	Six phases, three gates. Ceremony scales with stakes, not with this
56	table of contents: a small problem can compress Frame and Bound into one
57	pass, use one method, and skip the decision matrix. A recurring,
58	expensive, or org-wide problem earns the full pipeline.
59
60	### 1 — Frame
61
62	Open with one compact intake (not a questionnaire):
63
64	- What's happening, in observable terms?
65	- When did it start, and how was it noticed?
66	- Who or what is affected, and what is it costing?
67	- What's already been tried?
68	- What would "fixed" look like — how will we know?
69
70	Lead with whichever question is most load-bearing for this problem —
71	usually the observable symptom and its magnitude — and mark the rest as
72	answer-what-you-can. Five questions delivered as a form is a question
73	wall with better manners; the user should feel oriented, not processed.
74
75	**Don

People who liked this also viewed

6 picks

Type