--- name: orca-replay category: development-code description: Answers questions about a past agent run from its recording rather than from memory, and replays or forks that run. Use when asked why an earlier run did something, or to reproduce a failure. --- # OrcaReplay Run Reader Coding agents are confidently wrong about their own history. A summary written from memory is missing the tool results, the exit codes, and the files that changed without anyone mentioning them. This skill enforces one rule: **when a question is about something that already happened, read the trace before answering.** Do not reconstruct it. If a recording exists, guessing is the wrong move even when the guess would have been right. ## When to Use This Skill - "Why did you delete / overwrite / move X?" - "What changed this file?" or "Which step broke the build?" - "Can you reproduce yesterday's failure?" - "Would a different model have got this right?" ## What This Skill Does 1. **Finds the run** — `orca_list_runs`, newest first, naming the run each fork came from. 2. **Narrows to the cause** — `orca_graph` with `to: ` returns only the chain that produced one event. That is the shape of an answer to *why*; the full timeline (`orca_show_run`) is the shape of an answer to *what*. 3. **Separates evidence from inference** — every edge is labelled `recorded` (the recorder watched it happen) or `inferred` (derived just now from a named rule). "The trace shows the `rm` at step 14 removed it" and "this looks like the `rm` at step 14, going by timing" are different claims, and collapsing them into one confident sentence is the exact failure this skill exists to prevent. 4. **Reproduces before explaining** — `orca_replay` re-runs the recording offline and reports what could not be reproduced. 5. **Compares models only when asked** — `orca_compare` forks one run onto several models from the same checkpoint, graded by a shell command whose exit code is the verdict. ## How to Use ### Basic Usage ``` Why did the last run overwrite src/config.ts? ``` The agent reads the trace instead of recalling the session, and answers from the tool call that did it. ``` Does yesterday's failure still reproduce? ``` ## Example **User**: "Which step broke the build?" **Output**: ``` Step 14 did. From the recording (recorded edge, not inferred): 14 TOOL file_editor {"command":"str_replace","path":".../tsconfig.json"} 15 SHELL npm run build exit 2 16 FILE tsconfig.json modified +1 -1 The edit at 14 removed "strict": true, and the build at 15 exited 2. I replayed the run (reused=5/5, divergences=0) and it fails the same way. ``` ## Tips - **Pass `worktree: true` to replay.** Without it, replay restores the recorded filesystem over the working tree for the duration of the run, so uncommitted work is absent in the meantime — and stays absent if the replay is interrupted. - **Check what re-executes before the first replay.** Replay serves the model's answers from the trace, but the agent process runs again for real, so its shell commands run again too. A run that only read files and edited the repository is free to replay; one that touched Docker, a database or a remote host is not. - **Replay is not a sandbox.** It blocks provider egress, not the network. - **A matching replay is not a determinism result.** The model is not re-asked, its recorded answers are served back — so replay cannot tell you whether a *fresh* run would fail the same way. Say so rather than implying it did. - **`reused=3/5` is usually not a failure.** Harnesses make calls for themselves — a quota probe, a session-naming request — and replay does not repeat them. - **No recording means no answer.** Say that plainly and offer to start one with `orca record claude`, rather than falling back to a reconstruction. ## Requirements The `orcareplay` npm package (Node 20+) with its MCP server registered as `orca`, and at least one recorded run in the project's `.orca/runs` directory. Apache-2.0 — [Continuum-AI-Corp/OrcaReplay](https://github.com/Continuum-AI-Corp/OrcaReplay).