Use when receiving critical feedback on an analysis or manuscript, before implementing suggestions, especially if feedback seems unclear or methodologically questionable - requires verification, not performative agreement or blind changes
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
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 each
NEVER:
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 performance
Why 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.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Use when you have an approved research question and need a concrete analysis plan, before touching outcome data or fitting any model
The English summary is being prepared. Showing the original description.
Use when facing 2+ independent investigations that can proceed without shared state - parallel literature survey, multi-dataset replication, or pre-specified robustness checks
The English summary is being prepared. Showing the original description.
Use when your human partner has explicitly opted into exploratory or feasibility mode - a compute-heavy simulation, an unproven pipeline, an unbenchmarked solver, an untested cluster job - or when whether the work can run at all is still unknown, when a plan's largest configuration has never been executed, when a memory or wall-clock ceiling is estimated rather than measured, or when someone proposes pre-registering over runs that have never happened
The English summary is being prepared. Showing the original description.
Use when you have a pre-registered analysis plan to execute inline in this session with review checkpoints, on a platform without subagents
The English summary is being prepared. Showing the original description.
You MUST use this before any data analysis or investigation - before exploring a dataset, loading or profiling data, running a model, computing a statistic, or testing an idea, and before any outcome data is touched
The English summary is being prepared. Showing the original description.
Use when a result is surprising, impossible, contradicts a sanity check, a pipeline fails, a model won't converge, or a replication fails - before adjusting anything
The English summary is being prepared. Showing the original description.