Standard

Approve with edits

A diff of the agent's proposal the user can amend before accepting, rather than accept-or-discard.

M Ticket #4821Reply to Dana Ortiz 3 suggested changes

M Milky's edits to your draft on v2 · Maya Reyes, 3 min ago

1Name the charge

sorry about the double charge. sorry you were charged twice for your August invoice.

2Say what was done

We'll look into it and get back to you. I've refunded the duplicate payment of $1,240 (invoice #8822). It will be back on your card within 5–10 business days.

Billing policy: card refunds land in 3–5 business days.

3Add a goodwill credit

As an apology, I've also added a free month to your account.

Credits need Sam Okafor's sign-off.

Dana will receive

Hi Dana,

Best,
Maya

Try it: Fix the refund time in change 2 and drop change 3, then send. Everything else Milky wrote goes out as is, with no regeneration.

In the wild

How 2 products ship this pattern. Click a screenshot to enlarge it.

Intercom inbox with a Copilot-drafted answer inserted into the reply composer, annotated 'Edit before sending to customer', next to the Copilot panel with an Add to composer button — Intercom Copilot
Copilot's suggested answer is dropped into the teammate's composer, where it can be edited before sending rather than sent as-is or thrown away.
Source: Intercom Help ↗

Copilot code review comment on a pull request showing a suggested changeset diff with Apply suggestion and Add suggestion to batch buttons — GitHub Copilot
Copilot code review proposes a fix as a diff; the reviewer can apply it, batch it with other changes, or reply and adjust instead of accepting blindly.
Source: GitHub Docs ↗

When to use

Drafting and code flows where the output is 80% right and rejection wastes the work.

Seen in

Cursor diff review, Copilot PR suggestions, agent draft replies in support tools, Grammarly.

For engineers

Apply as a patch against the version the agent read; detect and surface conflicts on stale bases.

Build prompt

A neutral, component-only prompt for a coding agent. Edit the stack block or anything else to fit your project, then copy it.

# Build the "Approve with edits" pattern: `EditableProposal`

## Stack (edit this block to match your project)
- React 18+ with TypeScript: one function component, typed props, no `any`.
- Tailwind CSS, using your design system's tokens if you have them.
- Presentational only: data comes in through props, decisions go out through callbacks. No fetching or global state inside.
- If your codebase already has conventions (naming, shared components, tokens), follow them over this spec.

## What the pattern is for
A diff of the agent's proposal the user can amend before accepting, rather than accept-or-discard.

Use it when: Drafting and code flows where the output is 80% right and rejection wastes the work.

## What to build
A review view of the agent's proposed changes as separate hunks the person can accept, edit or drop individually before applying the whole set. The edited result is sent as a patch against the version the agent read, so nothing is regenerated. It renders inline in a chat, review panel or composer.

### Props
- `hunks`: Array<{ id: string; label?: string; before: string; after: string; decision: "pending" | "accepted" | "edited" | "dropped"; editedText?: string }>, the proposal split into reviewable changes.
- `baseVersion`: string, the version id the agent read.
- `currentVersion`: string, the latest version; a mismatch means the base is stale.
- `status`: "reviewing" | "applying" | "applied" | "conflict" | "error", controlled.
- `conflicts?`: Array<{ hunkId: string; reason: string }>, hunks that no longer apply cleanly.
- `onDecide(hunkId, decision, editedText?)`: callback per hunk.
- `onApply()`: apply all non-dropped hunks as they stand, and `onDiscard()`: drop the whole proposal. The component never applies changes itself.

### States it must render
- Reviewing: each hunk shows before and after with Accept, Edit and Drop; a footer says "3 changes: 1 edited, 1 dropped".
- Editing a hunk: the after text becomes an editable field pre-filled with the agent's text; the original suggestion stays visible above it.
- Applying: controls disabled with a busy indicator.
- Applied: a receipt listing what went out as written, what was edited and what was dropped.
- Conflict: hunks that clash with newer edits are marked with the reason and options to re-review against the latest version or drop them; clean hunks can still be applied.

### Interactions
- Accept, Edit and Drop call `onDecide`; a dropped hunk collapses to one line with Undo.
- Apply is enabled once every hunk has a decision, or offers "Apply and accept the rest" when some are pending.
- Keyboard: J and K move between hunks; A, E and D decide the focused hunk (shown in a hint).
- Discard asks for confirmation if any hunk was edited, since that work would be lost.

### Edge cases
- `baseVersion` differs from `currentVersion`: show "The text changed since this was proposed" before the person starts reviewing.
- All hunks dropped: Apply becomes "Close" and calls `onDiscard`.
- An edited hunk is emptied: treat as a deletion and say so, rather than applying an empty string silently.
- A single-hunk proposal: still offer Edit, never only Accept and Reject.

## Must avoid
All-or-nothing accept buttons that force a full regeneration over one wrong sentence.

## Engineering constraint
Apply as a patch against the version the agent read; detect and surface conflicts on stale bases.

## Accessibility
- Each hunk is a group labelled by its label or position ("Change 2 of 3") and decision; before and after are labelled in text, not just by colour.
- After applying, focus moves to the receipt.

## House rules
- Real `<button>`/`<input>` elements, full keyboard use, visible focus; announce status changes with `aria-live="polite"`; respect `prefers-reduced-motion`.
- All user-facing text comes from props (or a `labels` prop) so it can be translated.
- One consistent accent marks anything the AI made or is doing; amber means "needs a person", red means risky, green means done. Never rely on colour alone.
- Fits a 360 px wide container without horizontal scrolling.

## Acceptance checks
- [ ] Every state above can be rendered by passing props, with no internal fake data.
- [ ] Every interaction and edge case above behaves as described.
- [ ] Nothing in "Must avoid" can happen with this component.

## Deliver
1. The component file with its exported prop types.
2. A short usage example that renders each state.

Download this prompt as Markdown, or every prompt as JSON for an agent.

Critique checklist for feedback & correction

0 of 4 checked

These questions apply to every pattern in this family. Ticks are saved in this browser.

Is correcting faster than regenerating?
Does the system capture why, not just thumbs?
Does a correction persist beyond this session?
Can the user get the previous version back?