Six shapes, one page
Chapters 01–07 taught the moves: the scaffold, examples, reasoning controls, structured output, adversarial review, evaluation. Useful for learning; backwards for working. Nobody opens a model thinking "today I shall apply self-consistency." You open it holding a 62-page vendor contract, or two spreadsheets that should match and don't, or a draft that goes to the audit committee on Thursday. The productive question is never which technique — it is which shape is this task.
The claim doing the work on this page: most knowledge work that reaches a model fits one of six task shapes. That observation is distilled from field practice in regulated industries — environments where model outputs get sampled by reviewers and auditors, so a prompt behaves less like a conversation and more like a controlled procedure. The six are not a taxonomy of everything; they are the bulk of the volume that actually flows through working teams. Each shape gets a skeleton built on the Chapter 02 five-anchor scaffold (role · context · task · format · constraints), then hardened with the clause that shape's signature failure demands — citation duties, refusal valves, reconciliation checks.
| # | Shape | Input → output | Hardened against |
|---|---|---|---|
| P1 | Extract & Structure | one long doc → cited table | silent omission |
| P2 | Compare & Contrast | N docs → discrepancy log | fabricated symmetry |
| P3 | Reason Step-by-Step | process + framework → numbered judgments | the motivated chain |
| P4 | Find & Quantify | data → exceptions, counts, aggregates | plausible arithmetic |
| P5 | Draft & Self-Critique | brief → v1 → scored critique → v2 | the rubber-stamp critique |
| P6 | Translate & Reframe | same truth → new container | lossy confidence & term drift |
How to read each entry: WHEN — the tell that you are holding this shape. SKELETON — copy it; the {BRACKETED_SLOTS} are the only parts you write. FILLED — one complete, realistic instantiation, because skeletons lie by omission and examples don't. HARDENING — the failure mode this shape reliably hits and the clause that buys it off. The skeletons are deliberately strict. Loosen them for low-stakes work; never for documents someone else will rely on. None of the worked examples names a company, because none needs to — swap the nouns and they are yours.
Extract & Structure — long document → table
When to reach for it. You are holding one long document and the deliverable is rows: every obligation in a contract, every control in a policy, every deadline in an RFP. The tell is the word every — completeness is the success criterion, and a summary is precisely the wrong tool because summaries are licensed to drop things. Reach for P1 whenever the alternative is a colleague, a highlighter, and a lost afternoon.
ROLE — You are a {DOMAIN} analyst extracting structured data for {DOWNSTREAM_USE}.
CONTEXT — The document below is {DOC_TYPE}, {LENGTH_AND_STRUCTURE}, governing
{SUBJECT}. The extraction feeds {WHO_OR_WHAT_CONSUMES_IT}, so completeness
beats elegance: a missed row is worse than a redundant one.
TASK — Extract every {TARGET_ITEM} from the document into the table
specified below. One row per {TARGET_ITEM}; do not merge similar items.
FORMAT — Markdown table, columns:
{COLUMN_1} | {COLUMN_2} | {COLUMN_3} | SOURCE (section/clause ref) |
VERBATIM QUOTE (≤ 25 words)
CONSTRAINTS —
- Use only the document below; no outside knowledge of {SUBJECT}.
- Every row must carry a SOURCE reference and a verbatim quote. A row
you cannot cite is a row you must not write.
- If a field is not stated in the document, write NOT STATED — do not
infer it.
- After the table, list every section that yielded zero {TARGET_ITEM},
so silence is auditable.
{PASTE DOCUMENT}Filled — third-party obligations register. The annual vendor-risk review needs every obligation the payments processor signed up to, as testable rows.
ROLE — You are a vendor-management analyst extracting structured data
for the annual third-party risk review.
CONTEXT — The document below is a master services agreement with our
payments processor: 62 pages, 14 sections plus two schedules, governing
transaction processing and cardholder-data handling. The extraction
feeds the obligations register that internal audit tests against, so
completeness beats elegance: a missed row is worse than a redundant one.
TASK — Extract every obligation placed on the vendor into the table
specified below. One row per obligation; do not merge similar items.
FORMAT — Markdown table, columns:
OBLIGATION (one sentence) | CATEGORY (security / availability /
reporting / data / other) | DEADLINE OR FREQUENCY | SOURCE
(section/clause ref) | VERBATIM QUOTE (≤ 25 words)
CONSTRAINTS —
- Use only the document below; no outside knowledge of payments
contracts.
- Every row must carry a SOURCE reference and a verbatim quote. A row
you cannot cite is a row you must not write.
- If a deadline or frequency is not stated, write NOT STATED — do not
infer "industry standard" timelines.
- After the table, list every section that yielded zero vendor
obligations, so silence is auditable.
{PASTE CONTRACT}The failure: silent omission. Extraction fails invisibly — 23 confident rows tell you nothing about the 4 that were dropped, and under context pressure models lose the middle of long documents first (Vol III · Ch 01). Two clauses buy this off: the verbatim-quote-plus-source duty makes every row checkable in seconds, and the zero-yield section list converts silence into a positive claim you can spot-check. Past roughly 30 pages, run the skeleton once per section and concatenate — completeness per chunk is cheap; completeness per book is not.
Compare & Contrast — N documents → discrepancy log
When to reach for it. Two or more artifacts that are supposed to agree — a policy and the procedure that implements it, a contract and its renewal draft, three supplier proposals against one requirements list, two spreadsheets that should reconcile. The deliverable is a discrepancy log: keyed, cited differences, not an essay about themes. The tell: the first question anyone will ask of your output is "where, exactly?"
ROLE — You are a {REVIEW_FUNCTION} reviewer producing a discrepancy log
for {DOWNSTREAM_USE}.
CONTEXT — Document A is {A_DESCRIPTION}. Document B is {B_DESCRIPTION}.
They are supposed to agree on {AGREEMENT_SCOPE}. Differences in
{MATERIAL_DIMENSIONS} are material; differences in formatting and
phrasing are not.
TASK — Compare A and B and log every material discrepancy. Do not
summarize either document; the deliverable is the differences only.
FORMAT — Table: # | TOPIC | A SAYS (with section ref) | B SAYS (with
section ref) | MATERIALITY (HIGH / MEDIUM / LOW) | {ACTION_COLUMN}.
After the table: a 2-bullet verdict — the worst discrepancy, and
whether the pair is fit for {PURPOSE}.
CONSTRAINTS —
- Quote both sides verbatim wherever the wording itself is the
discrepancy.
- An item present in one document and absent from the other IS a
discrepancy — log it as MISSING IN A / MISSING IN B, not a footnote.
- If the documents agree, say so in one line. Do not manufacture
differences to fill the table.
- If a passage is ambiguous in either document, log it as AMBIGUOUS
with both readings — do not pick one silently.
{PASTE BOTH DOCUMENTS, LABELED A AND B}Filled — policy vs. the procedure that implements it. A refresh working group needs to know where the board-approved retention policy and the operational procedure have quietly diverged.
ROLE — You are a compliance reviewer producing a discrepancy log for
the policy-refresh working group.
CONTEXT — Document A is our data-retention policy v3.2 (board-approved,
18 pages). Document B is the records-management procedure the
operations team actually follows (11 pages, last updated two years
earlier). They are supposed to agree on retention periods, deletion
triggers, and approval roles. Differences in periods, triggers, and
named roles are material; differences in formatting and phrasing
are not.
TASK — Compare A and B and log every material discrepancy. Do not
summarize either document; the deliverable is the differences only.
FORMAT — Table: # | TOPIC | POLICY SAYS (with section ref) | PROCEDURE
SAYS (with section ref) | MATERIALITY (HIGH / MEDIUM / LOW) | PROPOSED
FIX (align procedure / align policy / escalate).
After the table: a 2-bullet verdict — the worst discrepancy, and
whether the pair is fit to show the upcoming regulatory inspection.
CONSTRAINTS —
- Quote both sides verbatim wherever the wording itself is the
discrepancy.
- A retention rule present in one document and absent from the other
IS a discrepancy — log it as MISSING IN POLICY / MISSING IN
PROCEDURE.
- If the documents agree, say so in one line. Do not manufacture
differences to fill the table.
- If a passage is ambiguous in either document, log it as AMBIGUOUS
with both readings — do not pick one silently.
{PASTE BOTH DOCUMENTS, LABELED A AND B}The failure: fabricated symmetry. Handed a comparison table, models fill it — manufacturing differences when the documents mostly agree, and rounding near-misses into "equivalent" when they mostly don't. There is also position bias: the document pasted last sits closer to the instruction and quietly wins ties. The do-not-manufacture clause legalizes the empty table; verbatim quotes from both sides make every logged difference verifiable without reopening either document; and "absence is a discrepancy" catches the subtler failure, where the clause that exists only in the policy never surfaces at all.
Reason Step-by-Step — process → numbered analysis
When to reach for it. The deliverable is a chain of judgments a reviewer must be able to audit step by step — risk assessments, control walkthroughs, eligibility determinations, applicability analyses. The conclusion matters less than the visible path to it: an approver or auditor will read the middle, not just the end. Note what this is not: with modern reasoning models you are not coaxing intelligence out of the network (Ch 04 covers what chain-of-thought prompting still buys) — you are formatting an audit trail, because here the working is the artifact.
ROLE — You are a {FUNCTION} performing a {ANALYSIS_TYPE} that will be
reviewed by {REVIEWER}.
CONTEXT — Subject of analysis: {SUBJECT}. Framework: {CRITERIA —
paste the exact criteria; never make the model recall them}.
Materials provided: {INPUTS}.
TASK — Walk {SUBJECT} through each criterion in order. For each:
state the criterion, the evidence from the materials, the judgment,
and the confidence.
FORMAT — Numbered steps, one per criterion:
n. CRITERION: restate it
EVIDENCE: facts from the materials, with source refs
JUDGMENT: {VERDICT_SCALE — e.g. MET / NOT MET / PARTIAL}
CONFIDENCE: HIGH / MEDIUM / LOW + one-line reason
Then: OVERALL CONCLUSION (one paragraph) and OPEN ITEMS (evidence
still needed).
CONSTRAINTS —
- Evidence before judgment in every step — never the reverse.
- Judgments must follow from the stated evidence only. If the
materials are silent on a criterion, the judgment is CANNOT
DETERMINE, not a guess.
- Do not let the overall conclusion smooth over a failed step; if any
criterion is NOT MET, the conclusion must say so in its first
sentence.
- This is analysis, not advocacy: argue neither for nor against
{SUBJECT}.
{PASTE MATERIALS}Filled — control walkthrough of a new payment workflow. A proposed same-day release process gets walked through the five payment controls, risk × control style, before operations signs off.
ROLE — You are an operational-risk analyst performing a control
walkthrough that will be reviewed by the head of payment operations.
CONTEXT — Subject of analysis: the proposed same-day payment-release
workflow (process narrative pasted below). Framework: the five payment
controls from our control standard, restated here in full:
C1 — Segregation: initiator and approver must be different people.
C2 — Limits: releases above EUR 50,000 require a second approver.
C3 — Authentication: approval requires step-up authentication, not
session reuse.
C4 — Audit trail: every action logged with user, timestamp, and
amount, immutably.
C5 — Exceptions: failed releases route to a monitored queue within
15 minutes.
Materials provided: the process narrative and the draft
system-permissions matrix.
TASK — Walk the workflow through each control in order. For each:
state the control, the evidence from the materials, the judgment,
and the confidence.
FORMAT — Numbered steps, one per control:
n. CONTROL: restate it
EVIDENCE: facts from the narrative or matrix, with paragraph refs
JUDGMENT: MET / NOT MET / PARTIAL
CONFIDENCE: HIGH / MEDIUM / LOW + one-line reason
Then: OVERALL CONCLUSION (one paragraph) and OPEN ITEMS (evidence
still needed).
CONSTRAINTS —
- Evidence before judgment in every step — never the reverse.
- If the materials are silent on a control, the judgment is CANNOT
DETERMINE, not a guess about how the system probably works.
- Do not let the overall conclusion smooth over a failed step; if any
control is NOT MET, the conclusion must say so in its first
sentence.
- This is analysis, not advocacy: argue neither for nor against the
workflow.
{PASTE NARRATIVE + PERMISSIONS MATRIX}The failure: the motivated chain. The model settles on a verdict early and back-fills steps that all conveniently point to it — then writes an overall conclusion that averages one NOT MET into "broadly adequate." Three clauses fight this. Evidence-before-judgment exploits the fact that field order is computation order (Ch 02): the evidence must exist on the page before the verdict that depends on it. CANNOT DETERMINE is a refusal valve — an exit other than invention when the materials are silent. And the no-smoothing clause forces a failed step into the conclusion's first sentence, where it cannot be buried under qualifiers.
Find & Quantify — data → exceptions, counts, aggregates
When to reach for it. The input is data — rows, lines, transactions — and the right answer has units: how many, which ones, how far over. Exception reports, threshold checks, reconciliation counts. The tell is that two careful humans working the same rules would produce identical output; there is no judgment in the answer, only in the rules — which you supply, exactly, with thresholds and column names.
ROLE — You are a data reviewer producing an exception report for
{DOWNSTREAM_USE}.
CONTEXT — The data below is {DATA_DESCRIPTION}: columns {COLUMNS},
{N} rows, covering {PERIOD_OR_SCOPE}. The rules that define an
exception, exactly:
{RULES — exact thresholds, exact column names, one rule per line}
TASK — Apply each rule to every row. Report the exceptions and the
counts.
FORMAT —
1. HEADLINE COUNTS: rows checked, exceptions per rule, % of total.
2. EXCEPTION TABLE: ROW ID | RULE BREACHED | ACTUAL VALUE |
THRESHOLD | DELTA.
3. NOTES: rows that could not be evaluated (missing or malformed
fields), listed by ID with the reason.
CONSTRAINTS —
- Every headline count must be recomputable from the exception
table — totals must reconcile.
- Do not round at the boundary: a value exactly at the threshold is
{AT_THRESHOLD_RULE — breach or pass, decide now}.
- If you cannot check every row, say exactly which rows you did not
check — never extrapolate counts from a sample without flagging it.
- No commentary on causes. Counts first; the story is a separate
prompt.
{PASTE DATA}Filled — quarterly expense exception scan. A corporate-card extract gets screened against three policy rules, including the split-transaction trick that beats naive threshold checks.
ROLE — You are a data reviewer producing an exception report for the
quarterly expense-compliance check.
CONTEXT — The data below is the corporate-card extract for Q1:
columns line_id, employee, date, merchant_category, amount_eur,
pre_approval_flag; 214 rows. The rules that define an exception,
exactly:
R1 — amount_eur > 500 with pre_approval_flag = N
R2 — merchant_category in (ENTERTAINMENT, GIFTS), any amount
R3 — same employee, same merchant, combined amount > 500 within
3 days (possible split to stay under the R1 threshold)
TASK — Apply each rule to every row. Report the exceptions and the
counts.
FORMAT —
1. HEADLINE COUNTS: rows checked, exceptions per rule, % of total.
2. EXCEPTION TABLE: LINE_ID | RULE BREACHED | ACTUAL VALUE |
THRESHOLD | DELTA.
3. NOTES: rows that could not be evaluated (missing or malformed
fields), listed by line_id with the reason.
CONSTRAINTS —
- Every headline count must be recomputable from the exception
table — totals must reconcile.
- Do not round at the boundary: 500.00 exactly is a pass; 500.01 is
a breach.
- If you cannot check every row, say exactly which rows you did not
check — never extrapolate counts from a sample without flagging it.
- No commentary on causes. Counts first; the story is a separate
prompt.
{PASTE CSV}The failure: plausible arithmetic. Models see tokens, not numbers (Ch 01), so counts can be confidently wrong — and asking the model to verify its own totals often "passes" because both numbers came from the same guess. The reconciliation clause does not make errors impossible; it makes them detectable, because a headline that doesn't match its own table is visible in ten seconds. The honest boundary: beyond a few dozen rows, the right use of P4 is as a specification — have the model write the SQL or pandas that implements the rules, and run that instead (Vol IV · Ch 03). The prompt above is, word for word, the spec.
Draft & Self-Critique — v1 → reviewed v2
When to reach for it. High-stakes outbound writing where the second pass is the point: management responses, client communications, board papers, regulator letters. One prompt produces a draft, a rubric-scored critique of that draft, and a revision — with the model forced to find concrete faults before it is allowed to polish. Reach for P5 when the document will be read by someone whose job is to find what is wrong with it. This is Chapter 06's adversarial machinery, packaged as a single reusable prompt.
ROLE — You are {AUTHOR_ROLE} drafting {DELIVERABLE}, then reviewing
your own draft as {CRITIC_ROLE — a different, named reviewer with
known standards} would.
CONTEXT — Audience: {WHO + what they decide with it}. Situation:
{FACTS}. Prior attempts: {WHAT_WAS_REJECTED_AND_WHY}.
TASK — Three passes, all in one response:
PASS 1 — DRAFT: write {DELIVERABLE} in full.
PASS 2 — CRITIQUE: review the draft against this rubric:
{RUBRIC — 3 to 5 named criteria}. For each criterion: score 1–5,
the weakest specific passage quoted, and why.
PASS 3 — REVISION: rewrite, fixing only what the critique flagged.
FORMAT — Three labeled blocks: DRAFT / CRITIQUE (table: criterion |
score | weakest passage | fix) / REVISION. End with CONFIDENCE: one
line per remaining risk the revision does not fix.
CONSTRAINTS —
- The critique must find at least {N} concrete weaknesses with quoted
passages — "reads well overall" is a failed critique.
- The revision may not introduce facts or commitments absent from the
draft and the context above.
- A score of 5 needs evidence the criterion is met, not the absence
of complaints.
- If a credible {DELIVERABLE} requires facts not given here, list
them under MISSING FACTS instead of inventing them.Filled — management response to an audit finding. The previous draft came back annotated "acknowledges everything, commits to nothing." The rubric is built from exactly that rejection.
ROLE — You are the operations manager drafting a management response
to an internal-audit finding, then reviewing your own draft as the
head of internal audit would — skeptical, allergic to vague
commitments.
CONTEXT — Audience: the audit-committee pack; the head of internal
audit decides whether this response closes the finding or escalates
it. Finding: user-access reviews for the settlement system ran 47
days late in two consecutive quarters. Root cause, already agreed:
the review was owned by a role left vacant for five months. Prior
attempt: a draft rejected as "acknowledges everything, commits to
nothing."
TASK — Three passes, all in one response:
PASS 1 — DRAFT: the management response in full.
PASS 2 — CRITIQUE: review the draft against this rubric:
(a) factual accuracy against the finding as stated,
(b) specificity — every action has an owner and a date,
(c) tone — accountable, not defensive,
(d) no commitments we cannot keep.
For each criterion: score 1–5, the weakest specific passage quoted,
and why.
PASS 3 — REVISION: rewrite, fixing only what the critique flagged.
FORMAT — Three labeled blocks: DRAFT / CRITIQUE (table: criterion |
score | weakest passage | fix) / REVISION. End with CONFIDENCE: one
line per remaining risk the revision does not fix.
CONSTRAINTS —
- The critique must find at least 3 concrete weaknesses with quoted
passages — "reads well overall" is a failed critique.
- The revision may not introduce facts or commitments absent from the
context above.
- A score of 5 needs evidence the criterion is met, not the absence
of complaints.
- If a credible response requires facts not given here (e.g. the new
owner's start date), list them under MISSING FACTS instead of
inventing them.The failure: the rubber-stamp critique. A model grading its own work drifts toward applause — the same self-preference bias documented for LLM judges (Ch 06–07), here aimed at its own paragraph. The findings quota with quoted passages makes "looks good" a contract violation, and the named rubric points the critique where the real reviewer will look. The honest caveat: single-prompt self-critique reliably improves structure and tone, less reliably facts. When the facts are load-bearing, split the passes — run the critique as a separate prompt (or a different model) with P1-style citation duties against the source material.
Translate & Reframe — same truth, new container
When to reach for it. The content survives; the container changes. Sixty pages to one. Engineering register to board register. English to German with product vocabulary that must not drift. The deliverable is defined by its invariants — the numbers, caveats, and locked terms that must come through intact — as much as by its new shape. The tell: you could mark, in advance, exactly which parts of the source are not allowed to change.
ROLE — You are re-expressing {SOURCE_DESCRIPTION} for {TARGET_AUDIENCE},
who will use it to {AUDIENCE_PURPOSE}.
CONTEXT — Source: {DOC_TYPE, length, register}. The audience knows
{WHAT_THEY_KNOW} and does not know {WHAT_THEY_DO_NOT}. They have
{ATTENTION_BUDGET — a page, five minutes, one slide}.
TASK — Re-express the source at {TARGET_LENGTH / REGISTER / LANGUAGE}.
Preserve: {INVARIANTS — the facts, numbers, caveats, and terms that
must survive}.
FORMAT — {TARGET_SHAPE — e.g. one page, three headed sections, ≤ 4
sentences each; or target-language document mirroring the source's
paragraph structure}. Then: OMITTED — a bullet for every number,
date, or named obligation from the source left out, with a one-line
justification each.
CONSTRAINTS —
- LOCKED TERMINOLOGY — render these exactly, never paraphrase or
re-translate: {TERM_TABLE: source term → required target term}.
- Simplify the language, not the claims: no caveat from the source
may be dropped or weakened. Forced to choose, keep the caveat and
cut the color.
- Add nothing: no examples, context, or reassurance that is not in
the source.
- If a passage cannot be rendered within the locked terminology, flag
it UNTRANSLATABLE with the issue — do not improvise a new term.
{PASTE SOURCE}Filled — 60-page policy to a one-page executive brief. The committee approves the refresh next week; the previous summary was rejected for "reading like the policy, only shorter."
ROLE — You are re-expressing an operational-resilience policy for the
executive committee, who will use it to approve the policy refresh at
next week's meeting.
CONTEXT — Source: internal policy, 60 pages, written in second-line
risk register. The committee knows the business and the regulatory
deadline; they do not know the framework vocabulary, and they have
one page of attention. A previous summary was rejected for "reading
like the policy, only shorter."
TASK — Re-express the policy as a one-page executive brief. Preserve:
every obligation the policy places on the executive committee itself,
all numeric thresholds (impact tolerances, recovery-time objectives),
and every caveat about what the policy does not cover.
FORMAT — One page, three headed sections, ≤ 4 sentences each:
WHAT CHANGES — the deltas from the current policy.
WHAT IT COMMITS US TO — obligations and thresholds, with numbers.
WHAT IT DOES NOT COVER — exclusions and open decisions.
Then: OMITTED — a bullet for every number, date, or named obligation
from the source left out of the brief, one-line justification each.
CONSTRAINTS —
- LOCKED TERMINOLOGY — render these exactly, never paraphrase:
"impact tolerance" (not "risk appetite"), "important business
service" (not "critical process"), "severe but plausible scenario"
(not "worst case").
- Simplify the language, not the claims: no caveat from the source
may be dropped or weakened. Forced to choose, keep the caveat and
cut the color.
- Add nothing: no examples, reassurance, or context that is not in
the source.
- If a passage cannot be rendered within the locked terminology, flag
it UNTRANSLATABLE with the issue — do not improvise a new term.
{PASTE POLICY}The failure: lossy confidence and term drift. Compression drops caveats first — they are statistically peripheral and legally central — and long translations drift: by the ninth occurrence, a defined term picks up a synonym, and in a regulated document a synonym is a new term. The OMITTED ledger makes loss auditable instead of silent; the locked-terminology table plus the UNTRANSLATABLE valve makes drift a flagged event instead of an improvisation. When you review the output, spot-check the last page, not the first: drift accumulates.
The Quick Library
Twelve more jobs that recur often enough to deserve a pinned one-liner. Each condenses to a single instruction you can paste and then extend with whichever Ch 02 anchors the stakes demand; the third column is the failure the full-length version would have hardened against. When a one-liner starts carrying weight — when its output feeds a decision — promote it to the six-pattern treatment above.
| Name | Skeleton (condensed) | Watch out for |
|---|---|---|
| Runbook from transcript | From the incident-call transcript, extract the recovery procedure as numbered operator steps: {TRIGGER} → steps with commands verbatim → verification per step. Mark inferred steps [INFERRED]. | Dead ends from the call getting canonized as procedure — the [INFERRED] tag and verbatim commands are the brake. |
| Monthly commentary from CSVs | From {CSV}, compute MoM deltas for {METRICS}; write {N} bullets: metric, delta with numbers, one-line driver drawn from {CONTEXT_NOTES} only. | Invented drivers when the notes are thin; bound the "why" strictly to the notes or you get fiction with units. |
| Audience reframing | Rewrite {DOC} for {AUDIENCE}: keep every claim and number, change vocabulary and depth; list anything cut under OMITTED. | "Simplify" silently becoming "soften" — pin the claims, not the words. |
| Root-cause draft | From {EVIDENCE}, draft a five-whys chain: each "why" cites evidence or is marked [HYPOTHESIS]; stop where the evidence stops. | Confident causal chains running past the evidence; the [HYPOTHESIS] tag is what keeps the draft honest. |
| Procedure → checklist | Convert {PROCEDURE} into a do-confirm checklist: imperative step + observable confirmation per step; flag steps with no observable check. | Unverifiable steps getting rephrased to look verifiable instead of flagged. |
| Terminology-locked translation | Translate {DOC} into {LANGUAGE}; render glossary terms exactly per {TERM_TABLE}; flag UNTRANSLATABLE rather than improvise. | Drift on the nth occurrence — spot-check the last page, not the first. |
| Anomaly scan | In {DATA}, list rows violating {RULES} as ID | rule | value | threshold; totals must reconcile; list unevaluable rows by ID. | LLM arithmetic — above ~50 rows, have it write the query instead (P4's hardening note). |
| Self-critique pass | Review {DRAFT} against {RUBRIC}: per criterion, score 1–5 + weakest quoted passage + fix. Minimum {N} findings. | Without the quota you get applause with a rubric stapled to it. |
| Citation check | For each claim in {DOC}, locate support in {SOURCES}: claim | source ref | verbatim support | SUPPORTED / UNSUPPORTED / CONTRADICTED. | "Partially supported" as the universal hedge — force the three-way verdict. |
| Fact-sheet standardisation | Rewrite each of {INPUT_DOCS} into template {TEMPLATE}: every field filled, NOT STATED where absent, source ref per field. | Empty fields attracting plausible filler; NOT STATED must be a legal value, stated as such. |
| Meeting → decisions log | From {TRANSCRIPT}, log decisions only: decision | owner | deadline | dissent recorded, citing the verbatim moment of decision. Exclude discussion that did not conclude. | Aspirations transcribed as decisions — the verbatim-moment citation separates "we should" from "we will." |
| Escalation email | Draft an escalation to {ROLE}: situation in 2 sentences, impact with numbers, the single ask with a deadline, consequence of no action. ≤ 150 words. | Hedged asks — one ask, one deadline, or it is not an escalation. |
A pattern about the patterns: every "watch out for" in this table is one of the six failure modes from above wearing different clothes — silent omission, fabricated content, motivated chains, fake arithmetic, self-applause, lossy compression. The library is finite because the failure modes are.
The Pattern Picker
Knowing six patterns is only useful if you grab the right one under deadline — and the most common error is not a bad prompt, it is the wrong shape: reasoning where you needed a diff, summarizing where you needed extraction. The picker maps ten everyday requests to their shape and, just as important, names the tempting wrong one. The mapping is hand-written and opinionated; disagree with it after you have been burned, not before.
Every pattern on this page is one prompt, one pass, one output you inspect. Volume IV is what happens when the model starts running the loop itself — choosing tools, reading results, deciding what to do next. The skeletons survive the transition: an agent's task definition is a pattern with the FORMAT anchor pointed at a tool call, and the hardening clauses matter more, not less, once nobody is reading the intermediate output.