Fulcra Content Review

Fulcra Content Review

For content a human will put their name on. Code review checks that a thing works; content review checks that a thing persuades, in the owner's voice, without overclaiming. Every rule here was paid for in one real editing session — the provenance notes say where.

0. Decide point of view FIRST

Whose voice is this? Decide before any line edit — POV drives everything else. A document that says "we" (the agents), describes its owner in third person, and credits itself in the colophon is incoherent the moment the owner shares it as theirs. If the owner's voice: first person, owner's diction, agents described as tools they used. (Provenance: the Modest Proposal draft failed exactly this way.)

Pronoun-referent audit. Once POV is chosen, extract every "we/us/our" sentence programmatically and check each referent against the choice. One document, one "we" — a draft that uses "we" for the authors in one sentence and for the company being addressed in the next reads as sloppy to exactly the reader it's trying to persuade. Same failure class as everything else on this list: two names for one thing, and the text trusts the wrong one. (Provenance: v3 of the same draft shipped 8 referent slips; the owner caught them in the first few sentences.)

1. Claims discipline — before style, always

• A single measurement is not a rate. Label it: "first live wake: 55 s",

never a bare "55 s" in a stat block. One data point presented as steady-state is the most common quiet overclaim.

• Necessary vs sufficient. When a test proves half a capability, say which

half. "A scheduled run reached its tools" does not show it will act on instructions it finds elsewhere — design the second test instead of rounding up. (Provenance: the ChatGPT scheduled-task tests — the owner caught the overclaim, and the honest second test then passed cleanly.)

• Unforgeable evidence beats self-report. Verify from the system of record

(a change feed, a timestamped upload), not the actor's account of itself. Put a token in the test that exists only on the path under test — and call it read-evidence, not "unguessable"; a short hex nonce proves the file was read, it is not cryptography.

• Preserve every leg of the evidence. Result files prove the actor did the

work; only the preserved instructions prove the work wasn't smuggled in with them. Archive the prompt/charter verbatim next to the result, and state preconditions a skeptic would ask about (e.g. a one-time human pre-approval that let the run act unattended). (Provenance: second-round review caught the missing prompt artifact after the test itself had already passed.)

• Numbers are measured or labeled estimates. If the colophon claims "every

number was measured," make that true.

• Don't infer intent from your own experience of the surface. "We didn't

have to change it" does not mean "it wasn't built for this" — ease of use is usually evidence of deliberate design, not of accident. Claims about why a product is the way it is belong to its owner; check before printing one. (Provenance: a draft claimed the platform "wasn't built for agents" because the fleet rode it unmodified; the owner's correction was that the agent-facing surfaces are heavily worked precisely so models find them easy.)

• Enumerate, don't name-match, when auditing claims. Checking a document

for "the claims I remember making" has unbounded false negatives — walk every number, every stat block, every "we proved" systematically. (Same failure class as the credential sweep: four corrections because the search was scoped by a name the searcher chose.)

2. The measured tic sweep — count, then judge

Run scripts/tic-count.py (or the inline equivalent) before and after editing. Judging your own prose by taste fails; counts do not. Thresholds from a real 8,742-word draft that read as AI-written:

| Tell | Found | Target | |---|---|---| | Em-dashes per 100 words | 1.0 | ` — strips HTML/Markdown, counts the §2 table, prints per-100-word rates. Run pre- and post-edit; the diff is the edit's receipt.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: ashfulcra
• Source: ashfulcra/fulcra-tools
• License: MIT
• Homepage: https://fulcradynamics.com

Install and usage instructions live in the source repository linked above.