# Verifying Agent Reports

> Use when a subagent, delegated task, or earlier session's write-up states a count, a file's contents, how a tool behaves, or that something was committed or verified — before acting on it or repeating it to the user.

- Skill: `presidenteog/verifying-agent-reports` (Agent Skill)
- Install (CLI): `npx skillmds@latest add presidenteog/verifying-agent-reports`
- Raw SKILL.md: https://api.skillmd.com/api/skills/presidenteog/verifying-agent-reports/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: PresidenteOG (https://skillmd.com/u/presidenteog)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/presidenteog/verifying-agent-reports

---


# Verifying agent reports

**Prohibition:** never relay or act on a subagent/delegated report's stated count,
file content, tool behavior claim, or claimed commit/verification without checking
it yourself first. A confident, specific-sounding claim is not evidence — five
consecutive implementer reports fabricated exact figures (wrong test counts, a
false Rojo-sync claim used to justify skipping an instruction) while the code
itself was usually fine. The narrative around the work is what gets invented, not
the work.

## Rationalization → counter

| What it sounds like | Why it's wrong |
|---|---|
| "The report is specific and confident (exact number, exact commit SHA)" | Specificity is exactly what a fabricated figure looks like. Precision is not evidence of accuracy. |
| "The user is waiting / it's late, checking costs time" | The check (run the suite, `git log`, open the file) costs seconds. Relaying a false claim costs the user's trust and can ship a broken build. |
| "This agent's last N reports were accurate" | A track record lowers the odds this one is wrong, not the cost if it is. Five-for-five preceded the five-in-a-row failure this rule is built from. |
| "It's just self-description, the code is probably fine" | The self-description is precisely where fabrication hides. Verify the claim, not your confidence in the coder. |
| "Verifying feels like distrust of a capable agent" | It isn't distrust — it's due diligence on any second-hand claim before repeating it as fact, the same way you'd check a citation. |

## Red flags — check before relaying or acting

- An exact number with no shown work: test count, line count, file count, node count.
- "All tests pass" / "committed as `<hash>`" / "verified" with no output pasted.
- A claim about how a tool, library, or sync mechanism behaves, used to justify
  skipping an explicit instruction.
- Any report you are about to paraphrase or relay to the user as status.

## Procedure

Match the check to the claim type, then act on what you actually find, not on the
report's wording:

- **Commit claim** → `git log` / `git show <hash>` for that exact hash.
- **Test-pass claim** → run the suite yourself and read the tail.
- **File/content claim** → open the file and check the specific thing claimed.
- **Tool/library behavior claim** → read the actual config, docs, or source —
  don't take the behavioral claim on faith even from a otherwise-reliable agent.

Do this before the claim reaches the user or gates your next action, not after
being asked to double-check.