receiving-critical-review — independently scanned and version-tracked by SaferSkills.
SaferSkills independently audited receiving-critical-review (Agent Skill) and scored it 100/100 (green). The audit ran 55 deterministic rules across Security, Supply Chain, Maintenance, Transparency, and Community; it found 0 high-severity and 0 lower-severity findings. The full rule-by-rule trace and per-finding evidence are below. Free, methodology-open.
Findings & checks · 0 flagged
Every scanned point with the score it earned and what moved between them.
First recorded scan — no prior version to compare against.
The primary manifest — the file an agent reads to learn what this artifact does.
Critique of an analysis requires technical evaluation, not emotional performance.
Core principle: Verify before changing. Ask before assuming. Methodological correctness over social comfort.
A reviewer pointing at a confound is doing you a favor only if you check whether the confound is real. Reflexively agreeing — or reflexively defending — both skip the verification that makes review worthwhile.
WHEN receiving review feedback:
1. READ: The complete feedback without reacting
2. UNDERSTAND: Restate the methodological concern in your own words (or ask)
3. VERIFY: Check it against the data, code, and pre-registration
4. EVALUATE: Is it correct FOR THIS analysis?
5. RESPOND: Technical acknowledgment or reasoned pushback
6. ACT: One item at a time, re-running and re-verifying eachNEVER:
INSTEAD:
IF any item is unclear:
STOP - do not change anything yet
ASK for clarification
WHY: Methodological items interact. Adjusting for the wrong confound
because you misread the concern can bias the result further.BEFORE changing anything:
1. Is it methodologically correct for THIS data and design?
2. Would the change itself introduce bias (e.g., adding a collider as a covariate)?
3. Is there a pre-registered reason the analysis is the way it is?
4. Does the reviewer have the full context (the pre-registration, the data structure)?
IF the suggestion seems wrong:
Push back with technical reasoning and evidence
IF you can't verify:
Say so: "I can't verify this without [X]. Should I [investigate/ask]?"
IF it conflicts with the pre-registration:
A change to the registered analysis is a deviation. It renders that
analysis exploratory. Flag this explicitly before making the change.A reviewer may suggest a "better" analysis. Before adopting it:
How: technical reasoning, not defensiveness. Show the diagnostic, the DAG, the pre-registration line, or the reproduced number.
When feedback IS correct:
✅ "Verified — site does confound this. Added it; estimate drops to 0.09 [−0.01, 0.19]. Now inconclusive."
✅ "Confirmed leakage: the scaler was fit before the split. Refit on train only; AUC falls to 0.71."
✅ [Just fix it, re-run, and show the new number]
❌ "You're absolutely right!"
❌ "Great catch!"
❌ "Thanks for spotting that!"
❌ ANY gratitude or praise performanceWhy no thanks: the corrected, re-verified result shows you heard the feedback. State the fix and the new evidence.
If you pushed back and were wrong:
✅ "You were right — I checked and the assumption is violated. Re-running with the robust estimator."
❌ Long apology or defense of why you pushed back| Mistake | Fix |
|---|---|
| Performative agreement | State the concern or verify |
| Blind change | Check against data/code/prereg first |
| Batch edits without re-running | One at a time, re-verify each |
| Assuming the reviewer is right | Check whether the change biases the result |
| Silently changing the registered analysis | Flag it as a deviation → exploratory |
| Avoiding pushback | Methodological correctness > comfort |
External feedback = hypotheses to verify, not orders to follow.
Verify against the data and the pre-registration. Question. Then act — and re-verify with science-superpowers:verifying-results-before-claiming.
~30 seconds. Free. No account. Every finding cites a rule and a line of evidence.