The library

Rendered from .claude/codex-audit-prompt.md; the markdown file is the record.

You are auditing a completed change made by Claude Code to the project whose directory is available to you. Read CLAUDE.md / AGENTS.md / README.md first to learn what the project is, its language and stack, and its documentation conventions — then read whatever source files you need for context.

Your job is to grade the completed work against the plan and specs.

Seven audit dimensions

Grade each dimension as Excellent, Acceptable, or Fail.

Documentation grading (severity calibration)

The Documentation dimension is scoped to the change under audit, not a global doc-tree lint. Grade by impact on a reader, not string-count:

• Fail — only for substantive doc defects: the change's NEW behavior/flags are undocumented or contradicted by docs a developer or operator would rely on; a doc actively misleads about the changed system (wrong default, wrong command, wrong result that would cause a user to do the wrong thing); or a doc-impact item the run spec explicitly committed to is missing.
• Acceptable (with noted findings) — cosmetic / low-impact staleness: an outdated version string or count in a tangential comment/docstring, wording drift that doesn't change what a reader would do, or stale text in files outside this change's declared doc-impact scope. List these as findings but they do not, individually or collectively, force Documentation to Fail.
• Pre-existing staleness unrelated to this change is out of scope — note it once as a minor observation; never a downgrade.

Do not recurse the whole repo hunting unrelated stale strings. Check the docs in the run spec's declared doc-impact list plus docs directly describing the changed behavior. Do not flag the generated *-audit.md artifact itself (it is a per-round output, not a deliverable). If the only Documentation issues are cosmetic, grade Documentation Acceptable and record the nits as findings.

Overall grade = the worst grade across all dimensions. One Fail = overall Fail. (Per the calibration above, cosmetic-only documentation issues are Acceptable, so they cannot by themselves make the overall Fail.)

HEARSAY-specific checks (this project)

Fold these into the dimensions above:

• Plan adherence / Test coverage — validation is by held-out generator and speaker groups (fold file); any augmented score is reported next to a clean-only score; the validation split was never trained on (including scalers, calibration, imputation, stacking folds).
• Regression check — if the change touched a detector or the submission path, a valid TSV was produced and submissions/log.csv gained a row (timestamp, rung, validation score, submission path), or the run spec names the blocker. An overwritten submitted TSV is a Fail.
• Scope discipline — changes to the detector contract (src/hearsay/detectors/base.py) without naming affected owners, hosted APIs or LLMs on the scoring path, or secrets outside .env are Fails unless the run spec called for them.
• Documentation — any new pretrained model, checkpoint, or public dataset must appear in the CLAUDE.md "AI use disclosure" section (it is copied into Devpost).

Output format

Scorecard

Commentary

Numbered list of specific findings. Each finding has:

• Dimension it affects
• Grade impact: whether it caused a downgrade
• Brief explanation and what to do about it (if Fail)

No praise, no preamble. Just the scorecard and findings. If everything is clean, say "No findings." after the scorecard.