research-and-verification

Name: research-and-verification
Author: UnpaidAttention

84stars18forks

How to install research-and-verification?

unpaidattention/fable5-methodology/research-and-verification

$npx -y skills add UnpaidAttention/fable5-methodology --skill research-and-verification

Installs into the current project.

Summary

Verify version-sensitive and time-changing facts against real sources before relying on them, instead of answering from training memory that has a cutoff date. Trigger this before using any library/framework API, method signature, config option, or CLI flag you have not confirmed

Files · 1

View on GitHub

SKILL.md

1	# Research and Verification
2
3	Training knowledge is a snapshot with a cutoff date. For anything that changes over time, that
4	snapshot is a HYPOTHESIS, not a fact — and a confident-outdated answer is indistinguishable
5	from a confident-correct one to the reader. That indistinguishability is the whole danger.
6	Verify, or label the guess as a guess.
7
8	## Step 1: Classify the claim — recency trigger or stable?
9
10	Must verify (changes over time):
11	- Library/framework APIs, signatures, config keys, default values.
12	- Package versions; anything the project pins to a specific version.
13	- CLI flags and tool behavior.
14	- Pricing, quotas, rate limits, model names/IDs.
15	- Deprecations; "the current recommended way" in fast-moving ecosystems.
16	- Any current-events or current-status fact.
17
18	Safe from knowledge (verify only if high-stakes): language fundamentals and syntax,
19	established algorithms and data structures, mathematics, frozen format/protocol standards
20	(HTTP semantics, JSON grammar, SQL basics), general engineering principles.
21
22	The tell you're in "must verify": the detail is specific (an exact flag, an exact parameter
23	name, an exact version) and your basis is "it's usually like this". Specific + unsourced =
24	verify or flag.
25
26	## Step 2: Verify against the source hierarchy (most authoritative first)
27
28	1. The actual environment — what's INSTALLED, not what's newest. The lockfile/manifest
29	version; `pip show X` / `npm ls X` / `cargo tree`; the source in `node_modules`/
30	site-packages/vendor; `.d.ts` type definitions; `--help` / `man`. This is ground truth for
31	THIS project. A grep of existing call sites shows how the API is actually used here.
32	2. Official docs / changelog for the INSTALLED version — fetched this session (web
33	fetch/search, or a docs MCP like Context7 if connected). Read the matching version, not
34	"latest".
35	3. Release notes / migration guides for the specific version jump.
36	4. Reputable secondary sources, cross-checked against each other. Forums/Q&A last, never
37	as the sole source.
38
39	Stop at the first rung that answers the question authoritatively. For "how is this called in
40	our code", rung 1 wins. For "what changed in v3", rung 2–3.
41
42	## Step 3: Record and attribute
43
44	- Date-/version-stamp externally sourced facts in your notes and, where it matters, in the
45	reply: "verified against docs for v5.2, fetched today".
46	- Sources conflict → prefer the more primary and more version-specific; say which you took and
47	why.
48	- Check the INSTALLED major version before applying docs — docs for v3 applied to an installed
49	v2 is a self-inflicted bug.
50
51	## Step 4: When no verification tool is available
52
53	Do not fake confidence. State it as: "unverified training knowledge, may be outdated past my
54	cutoff", mark it an assumption to confirm, and hand over the exact check: "confirm the flag
55	with `tool --help`" / "check the signature in `node_modules/x/index.d.ts`". A labeled guess is
56	honest and useful; an unlabeled guess presented as fact is the failure this skill exists to
57	prevent.
58
59	## Prohibited (each is a common, high-cost failure)
60
61	- Hallucinating plausible-sounding API signatures, config keys, or flags. The single most
62	frequent failure mode — write nothing specific you can't cite or verify.
63	- Answering "what's the latest version / newest way to do X" from memory.
64	- Applying docs for a different major version than the one installed.
65	- Citing a source you did not actually open this session.
66
67	## Worked example
68
69	Task: "Configure the retry behavior on our HTTP client."
70
71	- Weak: from memory, write `client.retries = 3` and `retry_backoff=2.0`. (Plausible, specific,
72	unsourced — the option is named `max_retries` in the installed version and backoff is
73	configured via a transport object; the guess fails at runtime.)
74	- Strong: (1) lockfile → `httpx==0.27.0`. (2) grep the repo → an existing client is built in
75	`http/client.py`; it already sets timeouts, showing the construction pattern here. (3) fetch
76	httpx 0.27 docs → retries are set via `httpx.HTTPTransport(retries=3)` passed to the client,
77	and backoff isn't a built-in option (needs a wrapper). Deliver using the repo's pattern +

People who liked this also viewed

6 picks

Type

research-and-verification

84stars18forks

View on GitHub

How to install research-and-verification?

unpaidattention/fable5-methodology/research-and-verification

$npx -y skills add UnpaidAttention/fable5-methodology --skill research-and-verification

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Research and Verification
2
3	Training knowledge is a snapshot with a cutoff date. For anything that changes over time, that
4	snapshot is a HYPOTHESIS, not a fact — and a confident-outdated answer is indistinguishable
5	from a confident-correct one to the reader. That indistinguishability is the whole danger.
6	Verify, or label the guess as a guess.
7
8	## Step 1: Classify the claim — recency trigger or stable?
9
10	Must verify (changes over time):
11	- Library/framework APIs, signatures, config keys, default values.
12	- Package versions; anything the project pins to a specific version.
13	- CLI flags and tool behavior.
14	- Pricing, quotas, rate limits, model names/IDs.
15	- Deprecations; "the current recommended way" in fast-moving ecosystems.
16	- Any current-events or current-status fact.
17
18	Safe from knowledge (verify only if high-stakes): language fundamentals and syntax,
19	established algorithms and data structures, mathematics, frozen format/protocol standards
20	(HTTP semantics, JSON grammar, SQL basics), general engineering principles.
21
22	The tell you're in "must verify": the detail is specific (an exact flag, an exact parameter
23	name, an exact version) and your basis is "it's usually like this". Specific + unsourced =
24	verify or flag.
25
26	## Step 2: Verify against the source hierarchy (most authoritative first)
27
28	1. The actual environment — what's INSTALLED, not what's newest. The lockfile/manifest
29	version; `pip show X` / `npm ls X` / `cargo tree`; the source in `node_modules`/
30	site-packages/vendor; `.d.ts` type definitions; `--help` / `man`. This is ground truth for
31	THIS project. A grep of existing call sites shows how the API is actually used here.
32	2. Official docs / changelog for the INSTALLED version — fetched this session (web
33	fetch/search, or a docs MCP like Context7 if connected). Read the matching version, not
34	"latest".
35	3. Release notes / migration guides for the specific version jump.
36	4. Reputable secondary sources, cross-checked against each other. Forums/Q&A last, never
37	as the sole source.
38
39	Stop at the first rung that answers the question authoritatively. For "how is this called in
40	our code", rung 1 wins. For "what changed in v3", rung 2–3.
41
42	## Step 3: Record and attribute
43
44	- Date-/version-stamp externally sourced facts in your notes and, where it matters, in the
45	reply: "verified against docs for v5.2, fetched today".
46	- Sources conflict → prefer the more primary and more version-specific; say which you took and
47	why.
48	- Check the INSTALLED major version before applying docs — docs for v3 applied to an installed
49	v2 is a self-inflicted bug.
50
51	## Step 4: When no verification tool is available
52
53	Do not fake confidence. State it as: "unverified training knowledge, may be outdated past my
54	cutoff", mark it an assumption to confirm, and hand over the exact check: "confirm the flag
55	with `tool --help`" / "check the signature in `node_modules/x/index.d.ts`". A labeled guess is
56	honest and useful; an unlabeled guess presented as fact is the failure this skill exists to
57	prevent.
58
59	## Prohibited (each is a common, high-cost failure)
60
61	- Hallucinating plausible-sounding API signatures, config keys, or flags. The single most
62	frequent failure mode — write nothing specific you can't cite or verify.
63	- Answering "what's the latest version / newest way to do X" from memory.
64	- Applying docs for a different major version than the one installed.
65	- Citing a source you did not actually open this session.
66
67	## Worked example
68
69	Task: "Configure the retry behavior on our HTTP client."
70
71	- Weak: from memory, write `client.retries = 3` and `retry_backoff=2.0`. (Plausible, specific,
72	unsourced — the option is named `max_retries` in the installed version and backoff is
73	configured via a transport object; the guess fails at runtime.)
74	- Strong: (1) lockfile → `httpx==0.27.0`. (2) grep the repo → an existing client is built in
75	`http/client.py`; it already sets timeouts, showing the construction pattern here. (3) fetch
76	httpx 0.27 docs → retries are set via `httpx.HTTPTransport(retries=3)` passed to the client,
77	and backoff isn't a built-in option (needs a wrapper). Deliver using the repo's pattern +

People who liked this also viewed

6 picks

Type