Use prompt moves that transfer

First, orient the model with the real audience and decision. Second, ground it in supplied sources. Third, constrain scope, format, and forbidden actions. Fourth, inspect by asking for assumptions, unsupported claims, or tests. Applied to this topic, those moves support diagnose and repair a wrong order-total function without widening the change, not vague content generation.

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 likely useful output is: 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. Follow with a critic pass, not a request to “improve it”:

Audit the draft against the original contract. Return a table:
criterion | pass/fail | exact evidence | smallest correction.
Do not introduce new facts. List unresolved questions separately.

This second prompt changes the mode from creation to inspection. For alternatives, request deliberately different options and specify the axis of difference. For revision, name one defect and freeze everything else. For extraction, require a schema and define unknown/null behavior. For decisions, ask for criteria, evidence, assumptions, and sensitivity—not hidden private reasoning.

A useful response would look like this: 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. That description is intentionally observable. “Looks good” is not acceptance. The operator must run the focused unit test, the full test suite, type-check, lint, and inspect the diff against the documented contract. Keep the source material beside the draft so review means comparison, not memory.

Do not confuse fluent explanations with evidence. 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. The prompt is successful only when the resulting artifact survives an external check.

Watch for invented library methods; broad refactors disguised as fixes; tests that merely copy the implementation; ignored error output. If the answer is too broad, shrink the deliverable. If it invents, tighten “use only” boundaries and require source labels. If formatting drifts, provide a short valid example and validate mechanically. If every option sounds alike, define meaningful axes. If revision damages good sections, quote the exact passage to preserve.

Keep prompt versions with short notes: what changed, why, and what happened. That creates transferable knowledge. Copying a “perfect prompt” without its data, risk level, and reviewer rarely does.