Executing a plan and reviewing its results
A research plan connects experiments to an objective. Choose how to discuss the work while it runs, then revisit the evidence in a results walkthrough. Execution produces new evidence; a walkthrough uses the records and outputs you already have.
Use the plan guide to create and maintain the plan itself.
The invocation reference lists skill names, prompts,
and the exact execution-mode meanings. Send these prompts to your coding agent, replacing
PLAN_PATH with the path to your plan.
Preview the proposed work
A plan preview explains the question, proposed experiments, dependencies, controls, decision rules, and expected resource use. It identifies assumptions worth challenging before execution. Previewing is read-only: it does not promote the plan, edit its files, submit jobs, or acquire responsibility for executing it.
Use research-lab-notebook to preview PLAN_PATH. Explain its objective, experiments, controls, dependencies, decision rules, costs, and uncertainties. Do not execute it or change any files.
Ask what observation could distinguish the competing explanations, what would count as a null result, and whether the instrument can reach the phenomenon. A preview can expose design problems, but it cannot establish that the design will work when run.
Execute interactively and pause after each experiment
Choose stepped when you want the conversation to shape the next experiment.
The agent performs the authorized work and records its results in the notebook before presenting them.
It explains the original design and setup before revealing the findings, then stops
until you say to proceed.
Use research-lab-notebook to execute PLAN_PATH in stepped mode. After each experiment, explain its original design and setup before its findings. Discuss validity, limitations, and the proposed next action, then wait for me. Do not queue the next experiment while waiting.
The pause is per experiment, not automatically per job. One experiment can contain a pilot, several execution attempts, or a sweep. Request additional job-level checkpoints if you need them. Parallel work must not start the next experiment before your reply.
Use the pause to ask: did the code implement the intended design? Did that design measure the intended quantity? Does the result support the proposed conclusion? A successful process exit answers none of these questions by itself.
Execute continuously within the approved scope
Continuous execution removes routine conversational pauses. It still stops at missing authority, required human review, scientific gates, and resource limits. Calling a run autonomous does not approve additional spend, a changed design, or a larger study.
narrated is the default execution mode: the agent reports each result and
what it changes without waiting for a reply. Choose handoff for a terminal
report, or unattended for notebook-only reporting. Name the mode explicitly
to set the reporting and pause behavior.
Use research-lab-notebook to execute PLAN_PATH in narrated mode within its approved scope and budget. Report each result without waiting for a reply, but respect all required gates. When execution stops, begin a results walkthrough using the saved records and outputs. Do not rerun jobs during the walkthrough. Pause after each experiment for discussion.
This request authorizes execution followed by a read-only results walkthrough. Asking only for a walkthrough or replay authorizes no execution. A blocked or partly complete plan can still be reviewed using the available evidence, with missing work identified.
Walk through existing results
A results walkthrough, also called a replay, uses saved records and outputs. It never launches, retries, or reruns jobs. It also does not repair scripts or recompute measurements to fill gaps in the account. A walkthrough can cover an incomplete or completed plan without executing it first.
Use research-lab-notebook for a results walkthrough of PLAN_PATH. Use existing records and outputs only. State how many experiments are available, then take them in dependency order. Explain each original design before its findings, and stop after each experiment for discussion. Do not run jobs, recompute results, or change files.
- Establish the inventory. Identify the experiments, their dependencies, and any missing records or artifacts. Say how many experiments the walkthrough will cover.
- Recover the original design. Explain the question, setup, controls, predictions, and what would have counted as a null. Distinguish the proposed method from what actually ran. Use the record from before the results, where available.
- Present the findings. Show the observed result, uncertainty, validity checks, and limitations. Explain what became apparent during execution or only afterward. Identify the records and artifacts behind the account.
- Discuss the interpretation and possible repairs. Separate established evidence from retrospective explanations and untested proposals. Stop here until the user asks to continue to the next experiment.
If the original design or an output is missing, the agent says what it cannot establish. It does not infer a preregistration from the results or silently regenerate missing output. Dependency order explains why later experiments were undertaken; it need not match the order in which jobs finished.
Decide which repairs to authorize
A walkthrough can uncover a coding defect, an inadequate design, a mistaken interpretation, or a claim that exceeds the evidence. Naming a possible repair does not establish that it will work, and discussing it does not authorize execution.
Decide separately whether to record a review correction, revise the design, or run a new experiment. Record an authorized correction with its reason and effects on downstream claims. Preserve the original prediction and distinguish planned from executed work. Follow the evidence-repair workflow for updates and the experiment-review workflow before collecting new evidence.