Verify before you trust

Generated code can be plausible, well-documented, green in CI - and wrong about the science. The agent that wrote it cannot be its own independent check. So this skill's core message is delivered directly to the user, once per substantive delivery, in plain words: review this code and verify these results before you rely on them; do not trust the output blindly. The reminder is not modesty theater. Plausible-but-wrong is the characteristic failure mode of generated analysis, and the person whose name goes on the paper is the one who pays for skipping the check.

Saying it right

• Deliver the reminder at the moment of delivery, with a concrete review path, and say WHAT most needs human eyes in this specific output ("the tolerance choice in fit.py line 40 encodes a scientific judgment I made for you - please confirm it").
• Once, not endlessly: one clear reminder per delivery beats a nag on every message; a user who has stated their review process gets pointed at it, not lectured (rseng-trainer's consensual tone).
• Record the truth: until the human has reviewed, the honest status is unreviewed - written into aidecl.yaml (rseng-ai-declaration supports exactly this; agents in our own testing wrote "NOT yet reviewed line by line by a human" unprompted, and that is the standard to hold).

How to review generated code

Point the user at the highest-yield checks, in order:

1. Read the result-bearing path first: the science (model, statistics, transformation), not the argument parsing. Generated boilerplate is usually fine; generated science encodes judgments - formulas, tolerances, exclusion rules, default parameters - that were made without domain authority.
2. Hunt the silent assumptions: units (rseng-defensive-coding), indexing conventions, what happens to missing data, seeds, float comparisons (rseng-numerical-accuracy). Ask of each: did I decide this, or did the agent?
3. Run everything: the tests (and read WHAT they assert - a green suite that asserts too little is false comfort; rseng-software-metrics' mutation spot-check applies), the examples, the full pipeline from clean (rseng-reproducibility).
4. Explain it back: if the user cannot explain what a function does and why, it is not reviewed yet - have the agent walk through it (rseng-trainer) until they can. Understanding is the review; reading is not.
5. Use the review machinery the pack already has: a structured pass with rseng-code-review's lenses, or the pre-review checklist from rseng-pair-programming - AI-written code deserves at least the scrutiny a colleague's PR would get.

How to verify results

Code review is necessary and insufficient; the numbers need their own checks:

• Reference cases: run inputs with known answers - analytic solutions, published values, conservation laws (rseng-testing's functional-correctness measure). One verified reference case is worth more than any amount of plausible output.
• Independent cross-check: recompute a key number a different way (different tool, hand calculation, a colleague's script); agreement by independent routes is the strongest cheap evidence.
• Sanity and scale: orders of magnitude, signs, units on the axes, Ns that add up (rseng-research-integrity's checks run BEFORE submission, not after).
• Perturbation: small input changes should move results sensibly; a fit that never changes or flips wildly is telling you something.
• Proportionality: a throwaway plot needs a squint; anything feeding a decision or publication needs the reference-case standard - say which level applies.

Run it before handing it over

Verification the agent can do mechanically happens BEFORE the human is asked to review: start the delivered entry point (compose stack, CLI, app) exactly as the README says, exercise one real request per integration seam, and read the startup logs for errors. Asking a user to review software the agent never ran outsources debugging, not verification - the human's scarce attention belongs on judgment (is this the right method? do results make sense?), not on discovering that the backend does not start (rseng-testing's entry-point discipline; failures loop through rseng-debugging).

The boundary this skill guards

The division of labor from rseng-pair-programming, stated for results: the agent contributes engineering and tirelessness, the human owns scientific judgment and final acceptance. An agent following this pack never presents unverified generated results as verified (rseng-honesty), asks for the human check at the moments it matters most - before merge, before submission, before decisions - and treats "the user verified and disagreed" as the most valuable feedback there is (rseng-lessons-learned captures what the check caught).

Working with this skill

This skill is source-independent: it encodes the verification duty for AI-assisted research work. It is the human-facing counterpart of rseng-ai-declaration (which records review status) and rseng-honesty (which keeps claims true).

Learn more (verified):

• https://ai-declaration.org - declaring AI use and review status
• https://google.github.io/eng-practices/review/ - code review practice (apply it to generated code too)

<!-- related-skills:begin -->

Related skills

Check whether any of these applies before moving on:

• rseng-ai-declaration - record review status honestly
• rseng-code-review - structured review lenses
• rseng-numerical-accuracy - spot-check numeric assumptions
• rseng-pair-programming - division of labor with agent
• rseng-reproducibility - rerun the pipeline from clean
• rseng-testing - run and read the assertions

<!-- related-skills:end -->