The dr-next-snapshot-replay Skill — Stage Snapshot Consumer Contract
How /dr-next reads a stage snapshot, validates it, assembles the resume prompt, and routes to the right next command — without re-reading the full task history.
Every time /dr-next runs, its first action is to look for a snapshot at datarim/snapshots/{TASK-ID}.snapshot.md. The dr-next-snapshot-replay skill defines the exact contract for what happens next: how the snapshot is validated, what prompt shape is emitted when it passes, and what happens silently when it does not.
Validation before use
The snapshot is not used on trust. A validator script — check-stage-snapshot-on-exit.sh --validate-frontmatter --task <ID> — must exit 0 before the snapshot contents enter the resume prompt. If the script exits with any other code, the skill falls through silently to the standard read pipeline: task-description, init-task, activeContext, in that order. There is no warning message, no interruption — the operator simply gets a slightly slower but complete recovery path.
This fallback policy exists because a corrupted or partial snapshot is worse context than no snapshot at all. The silent fallback means operators never need to manually clear a bad snapshot before resuming.
The replay prompt
When validation passes, the skill assembles a replay prompt in a fixed shape. The prompt opens with the recommended_next value from the snapshot's frontmatter — the command the previous stage suggested as the natural continuation — followed by a bilingual execution block. That block appears in both Russian and English in every replay prompt, regardless of the runtime's locale. The reason is practical: /dr-next runs under Claude Code, Codex CLI, and English-locale agents. A bilingual block guarantees the execution instruction reaches the model regardless of which runtime is active.
The snapshot body then follows under a literal done before: header, giving the model a compact record of what was already completed.
How the recommended command is chosen
The skill documents a heuristic for evaluating the recommended_next hint from the snapshot. The core principle is to maximise the marginal quality improvement of the solution. For a complex task that has just completed a plan but has had few verification passes, /dr-verify is preferred over jumping straight to /dr-do — a verification verdict costs far less than rolling back an implementation that built on undetected drift. When verification is saturated and implementation is done, /dr-archive is the natural next step.
The operator can always override the suggestion by typing a different command. The replay prompt shows the recommendation but does not block an override.
Where the snapshot comes from
The producer side is the stage-snapshot-writer skill, which runs at the end of each pipeline stage and writes the snapshot file that this skill later reads. The consumer contract here — dr-next-snapshot-replay — defines only the read side. The orchestrator plugin integrates this same contract before its subagent resolver, passing recommended_next as a hint that the resolver may accept or override.
See also the /dr-next command post for the command-level behaviour and what Datarim is for the broader context.