fact-checking-explainers

Name: fact-checking-explainers
Author: analyticalmonk

15stars1forks

How to install fact-checking-explainers?

analyticalmonk/explain-this/fact-checking-explainers

$npx -y skills add analyticalmonk/explain-this --skill fact-checking-explainers

Installs into the current project.

Summary

Use to fact-check an explainer against its sources before delivery. Trigger on "fact-check this explainer", "verify the claims", "check this against its sources", research-time source checks, or the post-draft gate. Ensures every checkable claim traces to a cited source or, for c

Files · 1

View on GitHub

SKILL.md

1	# Fact-Checking Explainers
2
3	## Overview
4
5	An explainer's authority comes from being right. A reader who catches one confident, wrong claim stops trusting the rest of the piece, figures and all. This skill makes claim verification enforceable by tying every checkable claim to evidence you can point to, correcting it, or cutting it. It is not a proofreading pass and not advisory: it is the gate an explainer passes before it is delivered.
6
7	## The Iron Law
8
9	```
10	NO EXPLAINER SHIPS WITH AN UNVERIFIED FACTUAL CLAIM.
11	```
12
13	Every checkable claim either traces to a source that supports it, gets corrected to match the source, or gets cut.
14
15	Apply the same resolution loop to every factual claim:
16	- Support it with an actual source passage you can point to.
17	- Correct it until it matches the source.
18	- Cut it when no source supports it.
19
20	Treat memory, plausibility, background knowledge, and deadline pressure as signals to run the loop, not reasons to skip it. "Verify" means checking an actual source in this session.
21
22	## When to Use
23
24	Run this skill:
25	- At research-time, over the sources gathered for an explainer, before any drafting.
26	- Post-draft, over the finished article, before delivery. This is a blocking gate.
27	- On request, whenever asked to fact-check, verify, or audit an explainer or article.
28
29	`creating-explainers` and `explaining-codebases` both call this skill at the gates above. When they do, interactive explainer delivery waits for a PASS report.
30
31	When NOT to use: content that is not an explainer, or a pure opinion or editorial piece that makes no factual claims. (Most explainers make many factual claims. Default to running it.)
32
33	## What Counts as a Checkable Claim
34
35	A checkable claim is a specific factual or empirical assertion:
36	- numbers, dates, measurements, percentages
37	- names, attributions, who-did-what, who-built-what
38	- direct quotes
39	- historical events and their order
40	- performance results and benchmarks
41	- mechanism claims: "X uses Y", "X causes Y", "X is faster than Y because Z"
42
43	Not checkable (do not flag these as factual claims):
44	- clearly-labeled interpretation or opinion ("the most elegant part is...")
45	- analogies and illustrative scenarios the reader knows are illustrative
46	- the author's framing and transitions
47
48	Heuristic: if you are unsure whether something is a checkable claim, treat it as one and verify it. The cost of over-checking is small; the cost of a wrong claim shipping is the whole article's credibility.
49
50	## The Verification Process
51
52	1. Extract every checkable claim, with its location in the article (section, figure caption, or `file:line` for code).
53	2. Find the support. For each claim, locate the passage in the cited source that backs it, and read that passage. For codebase explainers, open the actual code at the exact path and line. Do not treat the existence of a citation as support; a cited source often does not say what the draft claims.
54	3. Assign a verdict (table below).
55	4. Resolve everything that is not `supported`.
56
57	\| Verdict \| Meaning \| Allowed at delivery? \|
58	\|---------\|---------\|----------------------\|
59	\| supported \| A source passage directly backs the claim \| Yes \|
60	\| needs-source \| Plausible but no citation yet \| No - add a source or downgrade \|
61	\| unsupported \| No source backs it \| No - source it, soften, or cut \|
62	\| contradicted \| A source says otherwise \| No - correct it or cut it \|
63
64	## The Two Gates
65
66	Research-time gate (inside `creating-explainers` research intake). Before drafting, go through the gathered sources and confirm each one exists and actually supports the points it will be used for. Fabricated, misremembered, or misread sources are cheapest to catch here, before they are baked into prose.
67
68	Post-draft gate (every explainer, before delivery). Audit every checkable claim in the finished article against its cited source. For codebase explainers, the source of truth is the real code. Every "this function does X", every quoted snippet, every architecture claim is checked against the actual implementation at a specific path and line. Code drifts; a snippet that was right yesterday may be wrong today.
69
70	## Resolution
71
72	At delivery, every checkable claim must be `supported`. Resolve each other verdict with the same loop:
73	- Add support from a source passage (turns `needs-source` into `supported`).
74	- Correct the claim to match what the source actually says.
75	- Soften to clearly-labeled interpretation, if the statement is genuinely interpretive rather than factual.
76	- Cut it.
77
78	An unresolved `needs-s

People who liked this also viewed

6 picks

Type

fact-checking-explainers

15stars1forks

View on GitHub

How to install fact-checking-explainers?

analyticalmonk/explain-this/fact-checking-explainers

$npx -y skills add analyticalmonk/explain-this --skill fact-checking-explainers

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# Fact-Checking Explainers
2
3	## Overview
4
5	An explainer's authority comes from being right. A reader who catches one confident, wrong claim stops trusting the rest of the piece, figures and all. This skill makes claim verification enforceable by tying every checkable claim to evidence you can point to, correcting it, or cutting it. It is not a proofreading pass and not advisory: it is the gate an explainer passes before it is delivered.
6
7	## The Iron Law
8
9	```
10	NO EXPLAINER SHIPS WITH AN UNVERIFIED FACTUAL CLAIM.
11	```
12
13	Every checkable claim either traces to a source that supports it, gets corrected to match the source, or gets cut.
14
15	Apply the same resolution loop to every factual claim:
16	- Support it with an actual source passage you can point to.
17	- Correct it until it matches the source.
18	- Cut it when no source supports it.
19
20	Treat memory, plausibility, background knowledge, and deadline pressure as signals to run the loop, not reasons to skip it. "Verify" means checking an actual source in this session.
21
22	## When to Use
23
24	Run this skill:
25	- At research-time, over the sources gathered for an explainer, before any drafting.
26	- Post-draft, over the finished article, before delivery. This is a blocking gate.
27	- On request, whenever asked to fact-check, verify, or audit an explainer or article.
28
29	`creating-explainers` and `explaining-codebases` both call this skill at the gates above. When they do, interactive explainer delivery waits for a PASS report.
30
31	When NOT to use: content that is not an explainer, or a pure opinion or editorial piece that makes no factual claims. (Most explainers make many factual claims. Default to running it.)
32
33	## What Counts as a Checkable Claim
34
35	A checkable claim is a specific factual or empirical assertion:
36	- numbers, dates, measurements, percentages
37	- names, attributions, who-did-what, who-built-what
38	- direct quotes
39	- historical events and their order
40	- performance results and benchmarks
41	- mechanism claims: "X uses Y", "X causes Y", "X is faster than Y because Z"
42
43	Not checkable (do not flag these as factual claims):
44	- clearly-labeled interpretation or opinion ("the most elegant part is...")
45	- analogies and illustrative scenarios the reader knows are illustrative
46	- the author's framing and transitions
47
48	Heuristic: if you are unsure whether something is a checkable claim, treat it as one and verify it. The cost of over-checking is small; the cost of a wrong claim shipping is the whole article's credibility.
49
50	## The Verification Process
51
52	1. Extract every checkable claim, with its location in the article (section, figure caption, or `file:line` for code).
53	2. Find the support. For each claim, locate the passage in the cited source that backs it, and read that passage. For codebase explainers, open the actual code at the exact path and line. Do not treat the existence of a citation as support; a cited source often does not say what the draft claims.
54	3. Assign a verdict (table below).
55	4. Resolve everything that is not `supported`.
56
57	\| Verdict \| Meaning \| Allowed at delivery? \|
58	\|---------\|---------\|----------------------\|
59	\| supported \| A source passage directly backs the claim \| Yes \|
60	\| needs-source \| Plausible but no citation yet \| No - add a source or downgrade \|
61	\| unsupported \| No source backs it \| No - source it, soften, or cut \|
62	\| contradicted \| A source says otherwise \| No - correct it or cut it \|
63
64	## The Two Gates
65
66	Research-time gate (inside `creating-explainers` research intake). Before drafting, go through the gathered sources and confirm each one exists and actually supports the points it will be used for. Fabricated, misremembered, or misread sources are cheapest to catch here, before they are baked into prose.
67
68	Post-draft gate (every explainer, before delivery). Audit every checkable claim in the finished article against its cited source. For codebase explainers, the source of truth is the real code. Every "this function does X", every quoted snippet, every architecture claim is checked against the actual implementation at a specific path and line. Code drifts; a snippet that was right yesterday may be wrong today.
69
70	## Resolution
71
72	At delivery, every checkable claim must be `supported`. Resolve each other verdict with the same loop:
73	- Add support from a source passage (turns `needs-source` into `supported`).
74	- Correct the claim to match what the source actually says.
75	- Soften to clearly-labeled interpretation, if the statement is genuinely interpretive rather than factual.
76	- Cut it.
77
78	An unresolved `needs-s

People who liked this also viewed

6 picks

Type