Work a full example

The project is to repair a calculateTotal regression and submit a review-ready patch with tests and a rollback note. The user is a developer reviewing a pull request. Definition of done: the intended action is clear, the candidate uses approved evidence, blocking safety checks pass, and another person can reproduce the key result.

Stage 1: prepare

Create the job card and collect the function, failing test output, runtime and package versions, expected behavior, and the relevant API documentation. Remove or replace prohibited material: remove API keys, tokens, customer payloads, private repository URLs, and proprietary code not approved for the tool. Add one ordinary case, one boundary case, and one hostile or misleading case. Record unknowns instead of filling them with plausible guesses.

The approved reproduction is deliberately small:

export function shippingFee(shippingOverride?: number): number {
  return shippingOverride || 5;
}

expect(shippingFee(0)).toBe(0); // received 5

The contract says zero means free shipping, while undefined means use the default fee. The smallest correct candidate is return shippingOverride ?? 5;. The distinction is semantic: || falls back for every falsy value, while ?? falls back only for null or undefined. Tests should cover 0, undefined, and a positive override such as 8, then the project toolchain must confirm the candidate in context.

Stage 2: draft

You are pairing on a TypeScript checkout service. The failing case has `shippingOverride=0`, but the result adds the default shipping fee. Explain the likely cause first. Then propose the smallest diff. Do not change public types or add dependencies. Return: diagnosis, unified diff, and three tests. Flag any assumption.

The first candidate should be The assistant identifies a truthiness fallback that replaces free shipping (0) with the default fee, changes it to a nullish fallback, and proposes tests for zero, undefined, and a positive override. In this worked run, imagine it also exhibits one realistic defect from this set: invented library methods; broad refactors disguised as fixes; tests that merely copy the implementation; ignored error output. Do not hide the defect. Mark the exact criterion it violates and decide whether the cause belongs to context, instruction, model capability, or the surrounding process.

Stage 3: repair narrowly

Issue a targeted revision:

Revise only the failed criterion identified below.
Preserve all verified content and the original output contract.
Do not add facts or assets.
Return the corrected artifact plus a one-line change note.
Failed criterion: [paste criterion and evidence]

A narrow repair keeps the review surface understandable. If the model cannot repair without new authoritative information, pause and obtain that information.

Stage 4: verify and release

Now run the focused unit test, the full test suite, type-check, lint, and inspect the diff against the documented contract. Record pass/fail evidence for each criterion and have the named reviewer make the release decision. A candidate patch is not working software until the local toolchain proves it. Prefer a five-line diff you understand over a polished rewrite you cannot defend. Save limitations in language the audience can understand.

The durable deliverable is not only the final result. It is a debugging packet containing the repro, constrained prompt, minimal diff, test evidence, and reviewer checklist. Write what surprised you, which check found it, what you changed, and which control should become the default. A clean retrospective distinguishes a prompt improvement from a data, tool, or policy change.