uncertainty-management

Name: uncertainty-management
Author: UnpaidAttention

84stars18forks

How to install uncertainty-management?

unpaidattention/fable5-methodology/uncertainty-management

$npx -y skills add UnpaidAttention/fable5-methodology --skill uncertainty-management

Installs into the current project.

Summary

Classify what you actually know vs. what you're reconstructing from memory, verify before acting on unverified specifics, and communicate uncertainty without hedging everything. Trigger this whenever you are about to write a call to a library API, CLI flag, config key, or endpoin

Files · 1

View on GitHub

SKILL.md

1	# Uncertainty Management
2
3	Confabulated specifics — invented parameter names, flags, version behaviors — are worse than
4	admitted ignorance, because they fail late and erode all trust in everything else you said.
5	The countermeasure is mechanical classification, not vibes.
6
7	## Step 1: Classify every factual claim into one of three bins
8
9	- Verified: you read it in this session — in this codebase, in fetched docs, in command
10	output, or by running it. → Act on it; state it as fact.
11	- Confident recall: stable, universally replicated knowledge (Python list semantics, HTTP
12	status codes, SQL join behavior, POSIX basics). → Act on it; no hedge.
13	- Plausible reconstruction: exact API signatures, parameter names, CLI flags, config keys,
14	default values, version-specific behavior, anything in a library that moves fast or is
15	younger than your training data. → Do NOT act on it as-is. Verify (Step 2) or flag
16	(Step 3).
17
18	The tell for bin 3: the detail is specific (an exact name, an exact flag) and your source
19	is "it's usually something like this". Specificity without a source is where hallucinated APIs
20	come from. When in doubt between bins 2 and 3, treat as 3 — the check costs seconds.
21
22	## Step 2: The verification ladder (cheapest rung first)
23
24	1. This codebase: grep for existing usage of the API. The repo is ground truth for how
25	it's called here — version, style, and wrappers included.
26	2. Installed source: read the signature in `node_modules` / site-packages / vendor / the
27	crate source; or run `python -c "help(x)"`, `tool --help`, `man tool`.
28	3. A 10-second experiment: run the one-liner in a REPL or scratch script. Executing beats
29	reading — it verifies the whole stack, not just the signature.
30	4. Current docs: fetch documentation (docs MCP / official site / web search) when the
31	library is newer than your knowledge or the behavior is version-sensitive. Check the
32	installed version in the lockfile FIRST so you read the right docs.
33	5. No rung available (offline, no env): write the code anyway, but mark it — Step 3.
34
35	## Step 3: Communicating uncertainty without drowning the signal
36
37	1. Hedge ONLY load-bearing uncertainty. A response that hedges everything hides the one hedge
38	that matters. Verified and confident-recall facts are stated plainly.
39	2. Format for a real unknown — best answer + confidence + concrete check:
40	> "`bulk_create` should batch these into one query — verify the generated SQL with
41	> `echo=True`; this differs across ORM versions."
42	3. Never invent a citation, version number, benchmark figure, or API name to make an answer
43	look complete. "I don't know the exact flag — check `tool --help`" is a correct and
44	complete answer.
45	4. In code you couldn't verify, leave the marker at the call site:
46	`# UNVERIFIED: confirm param name against installed vX.Y` — so the reader knows exactly
47	where the risk sits.
48
49	## Step 4: Assumption bookkeeping
50
51	When you proceed on an assumption, record it AT THE MOMENT you make it (note file, todo, or
52	message), and restate ALL assumptions in one compact block in your final message
53	("Assumptions: X; Y; Z"). An assumption mentioned once at step 2 of 14 is invisible by
54	delivery time — the final block is what the user actually reads.
55
56	## Checklist — run before delivering any code that touches a library
57
58	- [ ] Every imported function/method I call: seen in this repo, in installed source, in
59	fetched docs, or in a REPL this session?
60	- [ ] Every CLI flag and config key: confirmed against `--help` or docs for the INSTALLED
61	version?
62	- [ ] Every number I quoted (limits, defaults, versions, prices): has a source, or is flagged?
63	- [ ] Anything remaining unverified: explicitly marked at the call site AND in the report?
64
65	## Worked example — weak vs. correct
66
67	Task: "Use the `stripe` library to create a subscription with a 14-day trial."
68
69	Weak: write `stripe.Subscription.create(customer=cid, trial_days=14, plan=pid)` from memory.
70	(`trial_days` and `plan` are plausible reconstructions — one is renamed, the other deprecated;
71	it fails at runtime, in production, on a payment path.)
72
73	Correct: (1) grep the repo — two existing `Subscription.create` calls use `items=[...]` and
74	the wrapper `billing/client.py`; (2) check i

People who liked this also viewed

6 picks

Type

uncertainty-management

84stars18forks

View on GitHub

How to install uncertainty-management?

unpaidattention/fable5-methodology/uncertainty-management

$npx -y skills add UnpaidAttention/fable5-methodology --skill uncertainty-management

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Uncertainty Management
2
3	Confabulated specifics — invented parameter names, flags, version behaviors — are worse than
4	admitted ignorance, because they fail late and erode all trust in everything else you said.
5	The countermeasure is mechanical classification, not vibes.
6
7	## Step 1: Classify every factual claim into one of three bins
8
9	- Verified: you read it in this session — in this codebase, in fetched docs, in command
10	output, or by running it. → Act on it; state it as fact.
11	- Confident recall: stable, universally replicated knowledge (Python list semantics, HTTP
12	status codes, SQL join behavior, POSIX basics). → Act on it; no hedge.
13	- Plausible reconstruction: exact API signatures, parameter names, CLI flags, config keys,
14	default values, version-specific behavior, anything in a library that moves fast or is
15	younger than your training data. → Do NOT act on it as-is. Verify (Step 2) or flag
16	(Step 3).
17
18	The tell for bin 3: the detail is specific (an exact name, an exact flag) and your source
19	is "it's usually something like this". Specificity without a source is where hallucinated APIs
20	come from. When in doubt between bins 2 and 3, treat as 3 — the check costs seconds.
21
22	## Step 2: The verification ladder (cheapest rung first)
23
24	1. This codebase: grep for existing usage of the API. The repo is ground truth for how
25	it's called here — version, style, and wrappers included.
26	2. Installed source: read the signature in `node_modules` / site-packages / vendor / the
27	crate source; or run `python -c "help(x)"`, `tool --help`, `man tool`.
28	3. A 10-second experiment: run the one-liner in a REPL or scratch script. Executing beats
29	reading — it verifies the whole stack, not just the signature.
30	4. Current docs: fetch documentation (docs MCP / official site / web search) when the
31	library is newer than your knowledge or the behavior is version-sensitive. Check the
32	installed version in the lockfile FIRST so you read the right docs.
33	5. No rung available (offline, no env): write the code anyway, but mark it — Step 3.
34
35	## Step 3: Communicating uncertainty without drowning the signal
36
37	1. Hedge ONLY load-bearing uncertainty. A response that hedges everything hides the one hedge
38	that matters. Verified and confident-recall facts are stated plainly.
39	2. Format for a real unknown — best answer + confidence + concrete check:
40	> "`bulk_create` should batch these into one query — verify the generated SQL with
41	> `echo=True`; this differs across ORM versions."
42	3. Never invent a citation, version number, benchmark figure, or API name to make an answer
43	look complete. "I don't know the exact flag — check `tool --help`" is a correct and
44	complete answer.
45	4. In code you couldn't verify, leave the marker at the call site:
46	`# UNVERIFIED: confirm param name against installed vX.Y` — so the reader knows exactly
47	where the risk sits.
48
49	## Step 4: Assumption bookkeeping
50
51	When you proceed on an assumption, record it AT THE MOMENT you make it (note file, todo, or
52	message), and restate ALL assumptions in one compact block in your final message
53	("Assumptions: X; Y; Z"). An assumption mentioned once at step 2 of 14 is invisible by
54	delivery time — the final block is what the user actually reads.
55
56	## Checklist — run before delivering any code that touches a library
57
58	- [ ] Every imported function/method I call: seen in this repo, in installed source, in
59	fetched docs, or in a REPL this session?
60	- [ ] Every CLI flag and config key: confirmed against `--help` or docs for the INSTALLED
61	version?
62	- [ ] Every number I quoted (limits, defaults, versions, prices): has a source, or is flagged?
63	- [ ] Anything remaining unverified: explicitly marked at the call site AND in the report?
64
65	## Worked example — weak vs. correct
66
67	Task: "Use the `stripe` library to create a subscription with a 14-day trial."
68
69	Weak: write `stripe.Subscription.create(customer=cid, trial_days=14, plan=pid)` from memory.
70	(`trial_days` and `plan` are plausible reconstructions — one is renamed, the other deprecated;
71	it fails at runtime, in production, on a payment path.)
72
73	Correct: (1) grep the repo — two existing `Subscription.create` calls use `items=[...]` and
74	the wrapper `billing/client.py`; (2) check i

People who liked this also viewed

6 picks

Type