"Fan out verification over a typed full inventory of the session's claims (assumptions, facts, specifics, premises, recommendations) against primary sources at a configurable depth, with a per-item ledger. Use when: 'deep research pass', 'verify every claim', 'audit all our claims', 'fact-check everything', 'go make sure those are all right', 'we've made a lot of load-bearing claims', or the session's judgment is the suspected bias. For one fact-check ('fact-check that'), use do-your-research."
Resources
1Install
npx skillscat add melodic-software/claude-code-plugins/plugins-discipline-skills-do-your-research-deep Install via the SkillsCat registry.
Do your research. Deep
The verification-fan-out tier of the sibling /discipline:do-your-research.
Same research discipline; heavier execution. Where the base skill re-anchors
and audits inline in the current context, this one enumerates a TYPED FULL
INVENTORY of the session's claims and verifies them against primary sources, the execution tier the base skill's context cannot provide from within itself.
The shared method. Re-anchor, audit, correct forward, report, and the tone
that firing this is not an accusation, lives in
`${CLAUDE_PLUGIN_ROOT}/context/re-anchor-audit-correct.md`.
The discipline this re-anchors and its portable baseline live in the sibling
`do-your-research`. Read both; this file adds
only the fan-out delta. There is no separate copy of the discipline here; update the sibling and this tier follows.
When this tier, not the inline audit
Reserve the fan-out for when the accumulated claims are load-bearing enough to
justify the subagent cost: a long session with many concrete specifics the
rest of the work now rests on, a "fact-check everything" request that wants
provable coverage, or where your own judgment is the suspected source of bias
across many claims, a self-check in the context that produced the claims is
weak by construction. For a single unbacked claim or a short session, the
inline audit in the sibling is the right tool; this tier is overkill.
Verification depth (configurable)
This tier is the expensive one by design, so its depth is configurable.
Resolve it once, before enumerating, by this precedence:
- Invocation argument wins. When this skill is invoked with an explicit
depth.tieredorfull(seeargument-hint). Honor it over the
configured default. - Otherwise the configured default:
${user_config.research_deep_verification}. - Otherwise
tiered. Treat an empty value, a surviving literal${user_config.…}token, AND any unrecognized string (a typo like
"teired") all as unset. Fall back totiered, never error.
- tiered (default). Resolve trivial and non-load-bearing inventory items
inline and cheaply (a quick check in this context, or an already-cited
source), and fan fresh-context subagents out only over the load-bearing
items. Most sessions want this: it spends the subagent budget where drift
actually matters. - full. Subagent-verify EVERY inventory item, trivial or not. Reach for
it when the cost of a single wrong "trivial" item is high enough to pay for
exhaustive independent checking.
Report which depth ran and why (argument / configured / default).
The fan-out
Run this in place of the base skill's inline audit and correct-forward steps:
- Enumerate a typed full inventory. List EVERY claim the session rests
on, as a checklist, each tagged with its type so coverage is provable. Not
just the obviously load-bearing ones:- assumptions. Unstated premises the work took for granted;
- asserted facts. Statements presented as true;
- concrete specifics. Paths, filenames, defaults, flags, signatures,
versions, any "standard/conventional X"; - load-bearing premises, the conclusions the rest of the work now
depends on; - recommendations. Each option, verdict, default, or next step put to
the user and not yet settled, verified against the contract in
`${CLAUDE_PLUGIN_ROOT}/context/recommendation-basis.md`.
The typing makes the inventory auditable: each item carries its type, and
step 5's ledger has exactly one row per item. Do not spot-check one, and do
not silently drop an item as "obvious", an obvious item is averified
ledger row, not an omission.
- Fan out, throttled. Scope set by the resolved depth. Dispatch
fresh-context subagents (blind to the reasoning that produced each item) to
verify each against a PRIMARY source, not the same recall that produced it.
Under tiered, the fan-out covers the load-bearing items while the
trivial / non-load-bearing ones are resolved inline (and still get a ledger
row); under full, every item goes through the fan-out. Dispatch per
`${CLAUDE_PLUGIN_ROOT}/context/fan-out.md`:
blind fresh-context subagents, bounded waves, failed-subset retry. - Match the method to the item type. An externally-verifiable item (an
asserted fact, a concrete specific) resolves against a source or the live
environment. An INTERNAL item (an assumption, or a load-bearing premise with
no external referent) has no citation to fetch. Its honest verdict is a
fresh-context re-derivation or a flag for the user to confirm, never a
manufactured source. The 100%-coverage rule is coverage of the checklist,
not a demand that every row name a URL. - Merge and correct. Fold the returns together, correct every falsified
or unbacked item THIS turn, and surface anything that stays unverifiable
rather than smoothing over it. - Report a per-item ledger. 100% of the inventory. One row per checklist
item (no silent drops), keyed by claim, each carrying:- verdict. Verified / corrected / unverifiable, plus withheld for a
recommendation row only; - source. What resolved it: a fetched primary source, the live
environment, or "internal. Re-derived / needs user confirm" for an item
with no external referent; for an unverifiable item, where you looked; - source tier. How authoritative that source is, per the consuming
project's own research discipline. Resolve its source of truth by the
shared method's ladder, the project'sCLAUDE.md/.claude/rules/
notion of official / authoritative / trusted, degrading to the portable
baseline when none is declared; - consensus count. How many INDEPENDENT authoritative sources agreed;
a lone source is weaker than a consensus, so note when only one was found; - recency. For a fact that can go stale (versions, pricing, APIs,
defaults), the date or version the source reflects.
A recommendation row also carries its outcome from the contract:Basis: verifiedorBasis: judgment(never on a consequential one),
or withheld, with noBasis:label and the open question naming the
evidence that would settle it. A corrected row adds old → new → why; a
verified one says unchanged and why.
- verdict. Verified / corrected / unverifiable, plus withheld for a
What this skill does NOT do
- Not a lighter inline pass. For a single re-anchor + audit without the
subagent cost, invoke the sibling/discipline:do-your-researchvia the Skill tool. - Does not fabricate a citation or a violation. An honest per-item
"verified", "internal. Needs user confirm", or "stays unverifiable" is the
right output when true; the fan-out never manufactures a finding, or a
source, to look diligent.
Gotchas
- Coverage is the checklist, not the URLs. 100% coverage means every typed
inventory item has exactly one ledger row. An internal assumption with no
external source is covered by an honest re-derived / needs-confirm verdict,
not by a fabricated citation. - Depth is resolved once, up front. Argument beats the configured default
beatstiered; empty, an unexpanded token, and an unrecognized value all
meantiered. Never error on a bad value.