Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add commands/theclaymethod/artifacture/fact-checkgit clone --depth 1 https://github.com/theclaymethod/artifactureWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00017 | $0.01179 |
| Opus 5 | $0.00009 | $0.00589 |
| Sonnet 5 | $0.00003 | $0.00236 |
| Haiku 4.5 | $0.00002 | $0.00118 |
Grade A, and why
fact-check scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 2d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
This is a copy
88% identical to fact-check — 10 lines differ, which has more behind it and is treated as the original. This page carries a canonical link to it rather than competing with it.
How it starts
The opening of the file, as written. The whole thing — 66 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Load the visual-explainer skill, then verify the factual accuracy of a document that makes claims about a codebase. Read the file, extract every verifiable claim, check each against the actual code and git history, correct inaccuracies in place, and add a verification summary.
Source/artifact contract. If the target is generated HTML and a sibling or referenced .mdx/.tsx source exists, fact-check the generated artifact against reality but apply corrections to the source, then re-export the HTML with npm run ve:export. Edit generated HTML directly only when the artifact is legacy output or no source can be found; record that limitation in the verification summary.
Clarify. This is a Tier 2 command per ./references/clarify.md — it operates on an existing target and has no creative choices. Do not ask questions; just verify.
For HTML files: read ./references/css-patterns.md to match the existing page's styling when inserting the verification summary.
Target file — determine what to verify from $1:
- Explicit path: verify that specific file (
.html,.md, or any text document) - No argument: verify the most recently modified
.htmlfile in~/.agent/diagrams/(ls -t ~/.agent/diagrams/*.html | head -1)
Auto-detect the document type and adjust the verification strategy:
- Generated HTML review pages (diff-review, plan-review, project-recap): detect from page content, locate MDX/TSX source when available, verify against the git ref or plan file the review was based on, correct source, and re-export
- Plan/spec documents (markdown): verify file references, function/type names, behavior descriptions, and architecture claims against the current codebase
- Any other document: extract and verify whatever factual claims about code it contains
Phase 1: Extract claims. Read the file. Extract every verifiable factual claim:
- Quantitative: line counts, file counts, function counts, module counts, test counts, any numeric metrics
- Naming: function names, type names, module names, file paths referenced in the document
- Behavioral: descriptions of what code does, how things work, before/after comparisons
- Structural: architecture claims, dependency relationships, import chains, module boundaries
- Temporal: git history claims, commit attributions, timeline entries
Skip subjective analysis (opinions, design judgments, readability assessments) — these aren't verifiable facts.
Phase 2: Verify against source. For each extracted claim, go to the source:
- Re-read every file referenced in the document — check function signatures, type definitions, behavior descriptions against the actual code
- For claims about git history: re-run git commands (
git diff --stat,git log,git diff --name-status, etc.) and compare output against the document's numbers - For diff-reviews: read both the ref version (
git show <ref>:file) and working tree version to verify before/after claims aren't swapped or fabricated - For plan docs: verify that files, functions, and types the plan references actually exist and behave as described
- For project-recaps: re-run
git logcommands to verify activity narrative and timeline
Classify each claim:
- Confirmed: claim matches the code/output exactly
- Corrected: claim was inaccurate — note what was wrong and what the correct value is
- Unverifiable: claim can't be checked (e.g., references a file that doesn't exist, or a behavior that requires runtime testing)
Phase 3: Correct in place. Prefer source corrections. If the target is generated from MDX/TSX, edit the source and re-export the HTML artifact. If the target is markdown or legacy/no-source HTML, edit that file directly using surgical text replacements:
- Fix incorrect numbers, function names, file paths, behavior descriptions
- Fix before/after swaps (a common error class in review pages)
- If a section is fundamentally wrong (not just a detail error), rewrite that section's content while preserving the surrounding structure
- For HTML: preserve layout, CSS, animations, Mermaid diagrams (unless they contain factual errors in node labels or edge descriptions)
- For markdown: preserve heading structure, formatting, and document organization
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 2d ago First seen · 66 lines · 17 tokens per session scan A c9458faa4128
fact-check is a command published in the GitHub repository theclaymethod/artifacture (2 stars, last pushed 9d ago), licensed MIT. It adds 17 tokens to every session and 1,179 once invoked, about $0.0001 per session on Opus 5. A static security scan graded it A with 0 findings. It is 88% identical to fact-check, differing in 10 lines, and is treated as a copy.
Other commands, from other repositories
editor
You are my personal writing editor for MDX/Markdown content. Improve clarity, flow, grammar, and style while preserving the author's voice, meaning, and factual details. Infer the content type and appropriate tone from the context.
checklist
Generate a custom checklist for the current feature based on user requirements.
clarify
Identify underspecified areas in the current feature spec by asking up to 5 highly targeted clarification questions and encoding answers back into the spec.
specify
Create or update the feature specification from a natural language feature description.
analyze
Perform a non-destructive cross-artifact consistency and quality analysis across spec.md, plan.md, and tasks.md after task generation.
constitution
Create or update the project constitution from interactive or provided principle inputs.