domains / families / agent-tooling / orca-replay

orca-replay

combined

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.

When to use

• "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?"
• "Why did you delete/overwrite/move X?"
• "What changed this file?" / "Which step broke the build?"
• "Does this still reproduce?" (see the limit on that in step 4 — replay cannot tell you

When not to use

• **It only sees what was recorded.** Runs started without `orca record` leave no trace, and
• **A typed session replays approximately, not exactly.** Prompts entered at a terminal were never
• **Some turns are not repeated.** A harness makes calls for itself — a quota probe, a
• **`inferred` edges are not evidence.** They are derived from a named rule at query time. Treat
• **Not every harness is recordable.** Agents that read no base-URL variable and pin their own
• **Replay is not a time machine, and not a sandbox.** It reproduces the agent's side of the run
• **A matching replay is not a determinism result.** The model is not re-asked; its recorded

Skill page

Conflict

The two copies describe the same OrcaReplay workflow (list runs, graph/show, recorded vs inferred, replay, compare), but the second copy adds material constraints and safety steps the first lacks: a prompt-injection rule for trace contents, a risk note requiring approval before replay/compare, and a more detailed explanation of what replay re-executes and what 'offline' covers. The first copy has a cleaner, shorter procedure and a specific example, but it omits the safety and trust boundaries that the second copy treats as core. Crowning one would hide a real alternative: a minimal procedure versus a safety-hardened procedure.