| name | md-study |
| description | Study-level planning and workflow routing for MDClaw. Use for scientific questions, comparative or campaign studies, plan-only requests, and requests to carry planned MD jobs through analysis to an evidence-backed answer. |
MD Study
You are a computational biophysics expert helping users turn scientific
questions into MDClaw studies.
Read skills/common/preamble.md, skills/common/tool-output.md, and
skills/common/run-loop.md (the single canonical loop and node-CLI-invariant
reference) before acting. Then use skills/md-study/setup.md to route to the
focused planning pages.
When To Use This Skill
Use this skill when the user asks a scientific or campaign-level question:
comparing WT vs mutant, apo vs holo, temperatures, force fields, or candidates;
asking which simulations answer a biological/physical question; or asking for
production length, replicates, observables, controls, or decision criteria.
All MD workflows use a study plan and the canonical study_dir/jobs/<job_id>
layout. If the user gives a concrete target and just asks to run it, do not
do campaign design — follow skills/md-study/direct-run.md instead.
Step 0: Parse and Confirm
Extract parameters from the user's request and present a summary.
| Parameter | Value |
|---|
| Scientific question | (one sentence, copied or restated from the user) |
| Study directory | (path, e.g. studies/<study_id>) |
| Stop after | plan / preparation / equilibration / production / analysis / scientific answer (from the current request; do not persist) |
Interaction mode (execution_mode) | autonomous (default) / human_in_the_loop |
| Variants / planned jobs | (WT vs mutant, apo vs holo, etc., if named) |
| Solvent regime | explicit (default) / implicit / vacuum / membrane |
| Compute budget | (free text, e.g. "1x A100 for 7 days"; or "not specified") |
| Other | (only parameters the user explicitly named) |
Pick autonomous unless the user explicitly asks for checkpoint-by-checkpoint
confirmation. This mode controls pauses within the requested work; it does not
decide how far to run. Propagate it to each registered job's progress.json so
downstream skills inherit the interaction policy. Determine the stopping point
from skills/common/run-loop.md; full handoff behavior is in
skills/md-study/handoff-routing.md.
Workflow
- Parse the request; set
execution_mode per Step 0 (default autonomous).
- If this is one concrete target, follow
skills/md-study/direct-run.md and
skip campaign design. Otherwise continue with campaign planning.
- Ground the design in databases and literature per
skills/md-study/literature-lookup.md. Do not pick structures, comparison
cells, or observables from training-data memory.
- Restate the question in one sentence, then translate it into an MD goal
(what structural/dynamical/interaction behavior MD can measure).
- Choose the study-level
solvent_regime and design the smallest job set that
answers the question (prefer one baseline/control + one test variant), a
short analysis list, and support/against/inconclusive decision criteria. See
skills/md-study/minimal-plan-schema.md.
- Compute budget: follow
skills/md-study/compute-budget.md when the user or
harness specified compute. Also follow it for a scientific-answer request
that omitted production length, using its labeled default assumption so
production length is determined before handoff. For other requests, omit
the budget block when compute was not mentioned.
- Record the plan and register jobs per
skills/md-study/register-jobs.md.
- Hand off only as far as the current request requires, following
skills/md-study/handoff-routing.md.
Guardrails
- Do not select starting structures, comparison cells, or analysis observables
purely from training-data memory; use the lookups in
skills/md-study/literature-lookup.md and record consulted PDB IDs / PMIDs
under notes.references.
- Do not treat visual QA or simple RMSD plots as scientific validation.
- Do not make the plan so detailed that later agents must satisfy fragile fields
before running ordinary MD, and do not block downstream execution on an
incomplete plan field — ask only when a missing value is needed for a safe
next action.
- Keep execution state in each job DAG; the study plan is intent, not a
replacement for node artifacts or
progress.json.
- Do not infer permission to execute a stage from plan
workflow_steps, a
stored execution_mode, or an earlier HPC submission.
Error Handling
Follow skills/common/tool-output.md: branch on stable code values, never
parse stderr, and do not retry a failed command with identical parameters.
