Emerging

Correction memory

A durable rule captured from a correction: never do that again, always use this term.

M Billing repliesDraft for Kite & Co · 12 seats 1 edit to review

M Reply to Kite & Co You edited 1 phrase

Thanks for asking about extra seats. Your Pro plan Team plan covers up to 49 seats, so going from 12 to 15 seats adds $36 a month.

Remember this for next time?

Rule Milky would follow

Applies to

Nothing is learned until you save. You can edit or delete rules any time.

Rules Milky follows 2 rules

Refunds only go back to the original payment method. Never offer a different card or bank account.

From Sam Okafor's correction · 12 Sep · used 38×
Sign billing replies as “The Milky billing team”, not as a person.

From Maya Reyes · 3 Sep · used 112×

Try it: Milky asks before turning your one edit into a rule. Save it (tweak the wording or scope first) or keep it to this reply, then watch the next draft.

In the wild

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

Grammarly suggestion card titled Grammarly's Style Rules striking '10,000 applications and websites' and replacing it with '500,000 applications and websites', with Dismiss and See more buttons — Grammarly
Team style rules store a term to avoid and its preferred replacement once; Grammarly then flags that term wherever anyone on the team writes it.
Source: Grammarly Support ↗

Text thread with Lindy: Lindy says 'heads up, new invoice from deel', user replies 'no need to flag invoices, finance has those covered', Lindy answers 'got it, i won't flag those going forward' — Lindy
A one-line correction in chat becomes a standing rule: Lindy confirms it will stop flagging invoices from then on.
Source: Lindy Docs ↗

When to use

Repeat workflows where the same correction is otherwise made daily.

Seen in

ChatGPT memory rules, Cursor rules files, Claude project instructions, brand-term glossaries.

For engineers

Store rules as reviewable text the user can edit and delete; never infer them without confirmation.

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 "Correction memory" pattern: `RuleCapturePrompt`

## 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 durable rule captured from a correction: never do that again, always use this term.

Use it when: Repeat workflows where the same correction is otherwise made daily.

## What to build
A prompt that appears after a person corrects the AI, proposing to turn that correction into a standing rule written in plain, editable text with a clear scope. Nothing is remembered unless the person confirms, and saved rules can be listed, edited and deleted. It renders inline under the corrected output, with a companion list for managing rules.

### Props
- `correction`: { before: string; after: string }, what the person changed.
- `proposedRule`: { text: string; scope: string }, the agent's suggested wording, e.g. "Always write 'refund window', not 'return period'", and scope, e.g. "Billing replies".
- `scopeOptions`: Array<{ id: string; label: string }>, e.g. this reply only, this workflow, everyone on the team.
- `status`: "proposing" | "editing" | "saving" | "saved" | "declined", controlled.
- `rules?`: Array<{ id: string; text: string; scope: string; createdAt: Date; appliedCount?: number }>, existing rules for the management list.
- `onSave(rule: { text: string; scope: string })`, `onDecline()`, `onEditRule(id, text)` and `onDeleteRule(id)`: callbacks. The component never stores a rule itself.

### States it must render
- Proposing: "Remember this for next time?" with the before and after, the rule text and scope, and Save rule / Just this once.
- Editing: the rule text and scope become editable with a preview of how it reads.
- Saved: "Rule saved: applies to Billing replies" with Undo and a link to all rules.
- Declined: "Kept to this reply only"; the prompt closes and nothing is stored.
- Rules list: each rule as text with scope, when it was added and how often it applied, with Edit and Delete; empty list says "No saved rules".

### Interactions
- Save calls `onSave` with the possibly edited text and scope; Just this once calls `onDecline`.
- Ignoring the prompt (navigating away) counts as declined; no rule is inferred.
- Undo after saving calls `onDeleteRule` for the new rule.
- Delete in the list asks for inline confirmation.

### Edge cases
- A proposed rule broader than the correction (e.g. a single word change generalised to a style rule): default scope to the narrowest option.
- A new rule that conflicts with an existing one: show both and ask which to keep before saving.
- Duplicate rule: offer to update the existing one instead of adding another.
- Empty rule text after editing: Save is disabled.

## Must avoid
Silently learning from a one-off correction and generalising it into behaviour nobody asked for.

## Engineering constraint
Store rules as reviewable text the user can edit and delete; never infer them without confirmation.

## Accessibility
- The prompt is a labelled region announced politely when it appears; it does not steal focus from the editor.
- Scope options are a radio group; the saved confirmation is announced.

## 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?