Replay Theater in Claude Code: review a turn's changes

Replay Theater is a demo by Claude Code Mods that allows you to reread edits of one turn, one pass at a time. The decisive distinction is between recorded call and successful edit: the sequence may include failed or rejected edits. To know what really changed you have to compare the replay with files and diffs of the repository. Official README Replay Theater.

Sources are verified on 9 October 2026. This guide proposes a method of review and hypothetical scenarios, without declaring saved time or tests performed by Giallo. If you want to orient yourself in the product first, read What are Claude's Mods. If you are interested in checking the correctness, also start from the guide to Review of the Code with Claude.

Why can the edit sequence help a review?

A final diff shows a state with respect to a reference. The sequence can instead help to understand the order of the attempts: which file was touched before, which part was rewritten and where an inconsistency could have been born. These are two different questions. The turn view is useful when the task is difficult to read as a single block.

This does not mean that the order automatically explains the reason. A passage may be part of a correction or an attempt then abandoned. To understand the intention you have to compare it with the request and with the reasoning recorded in the workflow. The panel makes the activity searchable, but does not assign a reliable purpose to each call.

A review therefore starts with a sentence: what behavior had to change? Then use the replay to find the interested parties and the real diff to check the result. If you can't describe the expected behavior, a well-presented sequence can make reading more enjoyable without making the decision more solid.

What operations does the official demo observe?

The README describes edit calls as Edit, Write and MultiEdit, grouped by turn. At the end it proposes an entrance to the replay, with navigation between passages and short diffs. The demo observes: it does not block, rewrite or delay edits. Its role is a later reading, not a protection before the action.

The Event Guide Mods It helps to understand the difference between observing a call and answering it directly. This boundary matters: if a team wants to prevent a change, it must choose a control with that responsibility. A panel that appeared after the shift cannot retroactively turn into prior authorization.

The perimeter must be returned to the internal procedure. "Replay of the turn" does not automatically mean "all changes produced by any process". A file may change by a different route than the ones observed. For this comparison with the repository remains necessary even when each step in the panel seems clear.

Call, shift diff and Git historian: what do they prove?

The three representations can be consistent without coinciding. A call says that an operation has been attempted or observed. A diff compares two chosen states. A Git historian retains committs and relations between them. The conclusion must be proportionate to the available test, not the amount of open screens.

The diff reference must be explicit. Comparing with the last commit, the start of the shift, or a different branch can produce different sets of changes. If the repository already contained work before the task, a global diff cannot be attributed in full to Claude. Write down the initial status before requesting a circumscribed change.

For those who use Claude in development, the guide to Claude by code helps define human demand and control. The demo adds a form of reading to that process; it does not replace branch identification or separation of work already present.

How to treat failed or rejected edits?

A failed call may be important to understand the path, but it should not be counted as an applied change. He may have searched for a text not present or encountered a rejection. If the replay shows it, read it as an attempt to link to the result. Do not infer that a function has been corrected because the proposal appears in the panel diff.

The practical control is simple: find the result of the call, open the real file and compare the relevant part. If the turn includes a later fix, check which version is left. The review decision concerns this version, although the previous attempt was more elegant. A mistake in the path can teach something without remaining a flaw in the result.

A shared procedure should use consistent words: «attempt», «applied», «verified». They must not become synonyms in the report to the manager. If you are building a view of your own, the guide to the first mod offers a way to fix the contract first of what you record.

Why is it necessary to open the full diff as well?

The demo shortens the diffs to keep the navigation readable. A short portion is useful for recognizing the passage, but can hide the necessary context: callers, import, conditions and nearby data. The review must not stop at the point where the view ends. If the decision depends on an omitted party, open the file and the full comparison.

A typical risk is to read only the added lines. A seemingly correct change can eliminate a control or alter a condition elsewhere. The relationship between files can also be important: name changed to one module and left old to another. Replay suggests where to look; research and project controls show if the whole is consistent.

A short review that uses replay without stopping at the panel

Reread the required behavior. Use the sequence to find relevant files and attempts. Distinguish the results of calls. Open full diff and file context. Perform the relevant checks. Finally, write down what behavior has been verified and what limit remains open, without attributing to the replay a test that belongs to the tests.

Where does the UI appear and how long does the recording last?

The README indicates a terminal surface, with panel or representation in the band depending on the layout. Requires Claude Code 2.1,287 or later for the recommended route of use. The state is in memory and should not be treated as a permanent archive. Evidence and screenshots from previous builds remain statements by the author, not verifications of the reader's machine.

Before evaluating the utility, check loading and available space. A missing UI may depend on the surface; a zero sequence may depend on the life cycle of the state. The Diagnosis of Mods distinguish these symptoms. Do not ask Claude to repeat all edits just to reconstruct a missing sight.

For a handover, keep a note of the project: target, initial status, affected files, controls, and remaining work. You can consult the replay as you prepare it, but the note must remain understandable even without that panel. It is the criterion that allows a colleague to resume the review in a different session.

How to prepare a controlled demo test?

Choose an instructional repository with a small edit and a known initial state. Prepares a normal case and one where an edit call is not applied. The second case serves to verify the interpretation, not to cause damage: it must be designed with synthetic contents and test tools.

Then compare three things: observed steps, call results and actual diff. Write where they coincide and where they answer different questions. If the demo is useful, the team should be able to explain what ambiguity it solves. A test does not necessarily have to produce an economic measure: it may conclude that sight is useful for some tasks and superfluous for others.

The Guide to Test Mods explains how to simulate events and interactions without a call to the model. For upload follow installation and update, after reviewing the code. An observer component remains code executed in your environment and requires trust in the source.

Two hypothetical review scenarios in Italy

Hypothetical example: an SME in Parma updates an order screen. Claude Code attempts more edits on labels and validation. The handler uses the replay to orient himself, then opens the branch diff and discovers that a call has not been applied. The requested correction cannot therefore be considered concluded only because it appears in the sequence.

The team checks the use case with synthetic data: a valid order, an incomplete order and a condition at the limit. After the check, prepare the report of the remaining changes. The value of replay is to have made it easier to find the relevant attempt, while the outcome comes from the trials. No real customer data is needed for this first evaluation.

Hypothetical example: an agency in Genoa renames a shared component. The sequence shows passages in different files and a short diff for each. The reviewer checks the final name, remaining references, and imports, then performs the project's expected check. A panel with all the steps does not prove on its own that there are no references elsewhere.

During the handover the chart is no longer available. The colleague uses branch, note and diff, without repeating the activity. If the team wants to prevent a delicate operation before it happens, evaluate instead Blast Radius or a gate consistent with the policy. Review after shift and check before action have different responsibilities.

What errors distort the reading of the result?

Counting each step as a successful edit hides waste and errors. Attributing all diff to turn ignore previous work. Reading only the short diff It omits context. Considering temporary history an archive It makes the passage of deliveries fragile. Concluding that the project works from the sequence replaces the controls with a representation of the activity.

To avoid these errors use a precise vocabulary in the report: what calls were observed, what changes are present and what behaviors were verified. A phrase like "I've seen five edits" must not become "I've verified five corrections". Even the AI Hallucinations are reduced in the process when claims are tied to identifiable evidence.

The comparison with the Data Security counts whether the view retains or has sensitive content. Before adopting a custom registration, ask what material needs to be kept and for how long. A review UI does not automatically need to become telemetry or complete archive of people's work.

What note to leave after reading the replay?

It preserves the required behavior, the really changed files, and the checks performed. If a call has failed but a later fix has resolved the point, distinguish the two steps without leaving the colleague an ambiguous story. The note must help verify the current status even when temporary replay is no longer available in the session.

How to insert it into the team review without adding noise?

Try the demo on tasks where the order of attempts really helps: distributed modification, correction after error or difficult handover. For a minuscule modification the diff can already suffice. The adoption criterion is the clarity of the review, not the number of screens used. An optional feature allows the reviewer to choose when to open it.

If a view adapted to the internal process is needed, the path of custom software can start from the contract of evidence: attempts, outcomes and final state. The guides to Claude Code and to Code Revision help keep the replay in the right role, as a support for reading the result.