Fancy UI KitFancy UI Kitv0.5
DocsLearnPackagesTUIFlowUse CasesInspirationShowcaseLeaderboard
Sign in
All use cases
Agents in your app

Let people accept or reject an agent's edits

Per-change review for anything a model rewrites.

The problem

A model rewrites a document and hands back the whole thing. Now someone has to read all of it to find what moved, and the only controls are "keep everything" or "throw it away" — so people paste it into a diff tool, or just accept it and hope.

Rewriting is not the hard part. Reviewing is. What is missing is a way to see each change on its own and take the good ones.

What you are building

Live surfaces, not screenshots — every one composed from the same components you would install.

Per-hunk review

A real git unified diff, with accept/reject per hunk — an agent proposes, a human decides.

Proposed by agent2 hunks
app/Support/Pricing.phppartial
12 public function monthly(Plan $plan): int
12 public function monthly(Plan $plan): int
13 {
13 {
14- return $plan->amount;
14+ // Annual plans quote a monthly-equivalent, so the page can compare
15+ // like with like instead of showing a yearly figure beside a monthly one.
16+ return $plan->interval === 'year'
17+ ? intdiv($plan->amount, 12)
18+ : $plan->amount;
15 }
19 }
16}
20}

The code

Feed it the unified format git already producestsx
// `source` is a discriminated union: {before, after} to diff in-house,
// {unified} for a git patch, {diff} for a pre-built structure. Accepting the
// unified format matters because it is what your VCS and your agent already
// produce -- no conversion step to get wrong.
<FancyDiff
  source={{ unified: patch }}
  onAcceptHunk={(hunk) => apply(hunk)}
  onRejectHunk={(hunk) => discard(hunk)}
/>

How to solve it

  1. Render the before and after as hunks

    The diff surface splits a rewrite into individual changes, each accepted or rejected on its own.

    Run thisbash
    npm install @particle-academy/fancy-diff

  2. Keep the agent on the same document model

    The shared document core gives the editors, viewers and writers one node/tree/op model, so a change proposed against one surface means the same thing in another.

  3. Apply only what was accepted

    Accepted hunks compose back into the document. Rejected ones never landed, so there is nothing to undo.