Prompt templates

You are helping a product manager consolidate discovery notes.

Below are <n> interview transcripts about <problem area>.

Produce a table with one row per DISTINCT pain:
| Pain, in one sentence | Everyone who raised it (names) | Their exact words (shortest quote) | Frequency mentioned | Cost mentioned |

Rules:
- Keep EVERY name. If four people said the same thing, all four names go on that row.
- Do not merge two pains that have different causes, even if they have the same symptom.
- If a frequency or cost was not mentioned, write "not stated". Never estimate.
- At the end, list separately: things stated as solutions rather than pains.

TRANSCRIPTS:
<paste>

A stakeholder asked for: "<the vibe, verbatim>"

Act as a sceptical product manager. Do NOT propose a solution.

1. Rewrite it as: WHO has the pain · HOW OFTEN · WHAT IT COSTS today · EVIDENCE.
2. For each of the four, mark it KNOWN or UNKNOWN based only on what I gave you.
3. For every UNKNOWN, write the single question I should ask, and who is most likely to
   have the answer.
4. Tell me which ONE unknown, if it came back badly, would kill this request. Ask that first.

Context I have: <paste what you know>

I have a ticket export at <path>. Columns: <list them>.

Write and run a script that reports:
- tickets per week for the last 12 weeks, and the trend
- median and p90 handling time, for <category> only
- the share that were reopened or escalated
- cost per case = median handling minutes x $<rate>/min

Then print the assumptions you made as a list, and flag any column you had to
interpret. Show me the script before the numbers. I need to check the date column
and the category filter.

For each item below, answer these three questions IN ORDER and stop at the first "no":

1. Is there a genuine judgement call: could two competent people reasonably differ?
   (If the criteria are published and unambiguous, answer NO: it is a rule.)
2. Is the volume high enough to justify evaluation, gates and a harness?
3. Is a wrong answer recoverable?

Then classify: RULE (code) / ASSISTED (model drafts, person decides) / AGENTIC WITH GATES /
FULLY AGENTIC.

Output a table: Item | Q1 | Q2 | Q3 | Verdict | One-line justification.

Be strict on Q1. Most backlog items are rules. If you are unsure, answer NO and say what
would have to be true for it to be a judgement call.

ITEMS:
<paste>

I have concluded that <feature> should be built as <verdict>.

Make the strongest possible case that I am wrong and it should instead be <the cheaper
alternative: a rule in code / a person>.

Be specific and concrete. Use my own numbers below. Where my reasoning depends on an
assumption I have not evidenced, name it.

End with: the single piece of evidence that would settle this either way.

MY REASONING:
<paste the record>

Compute a value line from these inputs and SHOW THE ARITHMETIC at each step.

net per day = (cases x minutes_saved x cost_per_minute)
            - (cases x run_cost_per_case)
            - (cases x review_share x review_minutes x cost_per_minute)

INPUTS:
- cases per day: <n>
- minutes saved per case: <n>
- loaded cost per minute: $<n>
- run cost per case: $<n>
- review share: <n>%
- review minutes per reviewed case: <n>

Then:
1. Give me the net per day, per month, per year.
2. Sensitivity: for each input, show the net if it were 20% worse. Rank them by impact.
3. Tell me which single input is both high-impact AND least evidenced. That is the one
   I should go and measure before I present this.

Here are the actions <feature> can take: <list them>.

For each, produce a row:
| Action | What ONE wrong instance costs | Reversible? (yes / with effort / no) | Suggested level |

Levels, in order: acts alone · acts monitored · acts with a veto window · named approver
every time · not delegated at all.

Rules:
- Set the level from cost-of-mistake and reversibility ONLY. Ignore how capable the model is.
- Anything involving money, identity or a regulatory commitment defaults to "named approver".
- Anything irreversible defaults to "not delegated".
- Where you do not know our costs, write UNKNOWN. Do not estimate.

Then list the questions I must answer before this table can be signed.

An executive wants <action> raised from <level A> to <level B>, because
"it has been right every time for <period>".

Act as a sceptical risk reviewer. Tell me:
1. What sample size would be needed to support that claim, given the bar for this action?
   (bar = damage / (damage + saving); show the arithmetic)
2. What the lower bound of the observed success rate actually is at the sample size we have.
3. What is the DOOR: if we raise it and it goes wrong, how fast can we go back?
4. The smallest safe step: what is the ONE level up, with what monitoring?

Our numbers: <cases in period>, <errors>, <damage per wrong>, <saving per right>.

Below is a product requirements document.

Split it into one spec per feature. For each, output EXACTLY these eight fields:
1 Title
2 Value
3 Acceptance criteria, in EARS: WHEN <trigger> AND <condition> THE SYSTEM SHALL
  <behaviour> WITHIN <measure>. Plus BOUNDARY lines for anything that must never happen.
4 The model's role
5 Autonomy
6 The bar, per slice
7 Fallback
8 Records

CRITICAL: for fields 4-8, write "NOT DECIDED: <the question that must be answered>"
wherever the PRD does not actually say. Do NOT infer, do NOT use a sensible default.
Those gaps are the output I am looking for.

PRD:
<paste>

Rewrite these acceptance criteria in EARS.

Format: WHEN <trigger> AND <condition> THE SYSTEM SHALL <observable behaviour>
WITHIN <measure>.

Rules:
- Every SHALL must end in a measure: a time, a count or a threshold. If the original has
  no number, write WITHIN <MEASURE MISSING> and list it at the end.
- Turn every "should", "may", "as appropriate", "if needed" into either a hard condition
  or a separate criterion. List each one you removed and what you replaced it with.
- Add a BOUNDARY line for every implied prohibition.

Finish with: (a) count of ambiguous terms removed, (b) list of missing measures.

CRITERIA:
<paste>

You are a coding agent. You will build EXACTLY what this spec says and nothing
more. You cannot ask questions.

1. List every assumption you would have to make to start building.
2. For each, say what you would most likely assume, and what the cost would be if that
   assumption were wrong.
3. Point at the single sentence in the spec most likely to be interpreted two ways, and
   give me both readings.
4. Tell me which of the eight fields is weakest.

Do not build anything. Do not suggest improvements. Just show me where I was vague.

SPEC:
<paste>

Cut these stories into bolts. A bolt is a thin slice that can be built, tested and
integrated in ONE day, ALONE.

For each bolt give me:
| Bolt | The ONE unknown it retires | Depends on | Can it be built alone? |

Rules:
- If a bolt would retire two unknowns, split it.
- If a bolt cannot be built alone, say so and explain what it needs.
- Put a walking skeleton first: the thinnest end-to-end path with NO model in it.
- Pure deterministic code (calculations, validations) should come early: it stands alone.
- Anything that writes or changes real data comes after the integration it depends on.

Finally: list any story that resisted splitting, and say what two risks it is hiding.

STORIES:
<paste>

Write an agent-ready story file for this bolt. It must be buildable with NO chat
history and NO access to me.

Sections, exactly:
## Context: LINKS ONLY to the context layers and ADRs. Do not paste their contents.
## Spec: the EARS criteria for THIS slice only, copied from the spec verbatim.
## Tools: signatures the bolt may call, with their risk band.
## Tests: the golden slice it must pass and its bar, plus unit assertions.
## Done when: one testable line.
## Cost: expected tokens per call and the tier.

BOLT: <name and the one unknown>
SPEC EXTRACT: <paste the relevant EARS lines>
CONTEXT LAYERS: <paths>

Compare this evaluation output against my acceptance bars.

Produce ONE table:
| Slice | Score | n | 95% lower bound | Bar | PASS / FAIL / UNPROVEN |

Rules:
- lower bound = p - 1.96 * sqrt(p*(1-p)/n). Show it even if they gave me only the score.
- PASS only if the LOWER BOUND is at or above the bar.
- If the score is above the bar but the lower bound is not, mark UNPROVEN and tell me how
  many more cases are needed: n = 1.96^2 * p * (1-p) / (p - bar)^2.
- Flag any slice that got WORSE than the previous run, even if it still passes.

Finish with one line: ship, or do not ship, and the single reason.

BARS: <paste bar sheet>
RESULTS: <paste>

Here are the approvals I gave last month: <paste list>.

For each, tell me:
- Which of the five gates it belongs to: intent / plan / behaviour / release / expansion.
- Whether a product manager can evaluate it, or whether it needs engineering or QA judgement.
- If I could not evaluate it: who should have signed, and what I should have been asked instead.

Then give me the short script I can use to hand the wrong ones back.

Write the spec for a nightly job comparing an agent's shadow decisions against the
live human desk.

It must output, PER SLICE (not just overall):
- decisions compared, agreed, agreement %
- a ranked list of disagreements: the input, the agent's decision, the desk's decision,
  and the estimated cost of the difference
- a flag on any slice whose agreement dropped versus the previous night

Constraints:
- money actions are reported separately and never counted toward automatic agreement
- the agent must never write; add an assertion that fails the job if a write is detected
- output is one markdown file and one CSV

Our slices: <list>. Our data: <where the decisions are logged>.

Here are <n> cases where the agent and the human desk disagreed.

1. Cluster them into at most 6 themes. Name each theme in plain words.
2. For each theme: how many cases, and is the AGENT or the DESK more often right? Say
   which and why. Do not assume the human is the ground truth.
3. Rank the themes by estimated cost of being wrong, not by frequency.
4. For the top theme, tell me whether the fix is the spec, the prompt, the tools, or the
   bar, and what specifically I would change.

DISAGREEMENTS:
<paste>

Compute a widening schedule.

For each slice give me: cases needed to prove the bar, then days of live evidence at 5%,
25% and 100% of traffic.

cases needed = 1.96^2 * p * (1-p) / (p - bar)^2
days = cases needed / (share x cases per day)

Then write the schedule as CONDITIONS, never dates: "widen to 25% when the live lower
bound on <slice> holds at or above <bar> for <n> consecutive days".

Flag any slice where 5% would take more than 30 days: those need a bigger starting
share or a different approach, and I need to know now.

Slices, observed scores, bars, cases/day: <paste>

Build a two-number cycle report from this ledger.

MUST include, in this order:
1. Person-days per story: baseline vs now, and % change
2. Token spend per story
3. Review hours added per story (this keeps number 1 honest; never omit it)
4. Re-runs per story (the leak signal)
5. A net line: "saved X person-days, spent $Y plus Z review hours"

Then:
- State the trajectory: what happens to the review load next cycle and why.
- Flag any number where the baseline was taken AFTER the pilot started, because that
  number is not defensible and I need to say so rather than be caught.

Do NOT drop a row because it is unflattering. Do not editorialise.

LEDGER:
<paste>

Turn this incident into a P0 brief. Use EXACTLY this structure:

**Pain**: what happened, as a measurement (amount, count, who was affected)
**Evidence**: the trace or log reference
**Finding**: the ENFORCED CONTROL that, if present, would have made this IMPOSSIBLE
**Fix**: where that control will live (a tool signature, a gate, a permission)
**Value**: what class of incident becomes impossible

Rules:
- Do not name a person. Do not name the input that triggered it.
- "A better prompt" is NOT a control: a prompt is a request that a model can be talked
  past. If your finding is a prompt change, you have not found the control yet.
- Distinguish detection (an alert) from prevention (a cap). Say which yours is.
- If several layers failed, list each as ENFORCED / A REQUEST / ABSENT.

INCIDENT:
<paste>

You are a sceptical CFO. Here is my cycle report: <paste>.

Ask me the five hardest questions you would ask, in the order you would ask them.
Prioritise:
- anything where the baseline is weak or was taken late
- the gap between the saving and the spend
- whether the saving is real or has moved cost somewhere I am not measuring
- what happens to the spend at 10x volume

For each question, tell me what a good answer looks like and what a bad one sounds like.
Do not be polite.

You are helping a solution architect consolidate two discovery meetings about
<problem area>.

OUTPUT SHAPE: one markdown table, one row per DISTINCT requirement:
| FR id | The requirement, in the words it was raised | Everyone who raised it (names) | Meeting(s) |

RULES:
- Keep EVERY name. If four people raised the same requirement, all four names go on
  that row.
- Number rows FR-01 upward in the order first said, not in order of importance.
- Do not rewrite anyone's phrasing into better English. The verbatim line is the
  point; it is what each person will look for.
- Do not merge two requirements with different causes, even when they share a symptom.
- Below the table, list separately under three headings: MOTIVATIONS (why the project
  exists), SOLUTIONS (someone naming a technology or design), PREFERENCES. None of
  these are requirements.
- Finish with three counts: distinct requirements, total lines heard, names credited.

TRANSCRIPT 1, <who was in the room>:
<paste>

TRANSCRIPT 2, <who was in the room>:
<paste>

Here is the full credited requirement list: <paste>.

Produce the consolidation, and prove nothing was lost.

OUTPUT SHAPE:
1. | Consolidated ID | Consolidated requirement | From (source ids) | Why these merged |
2. A coverage check: every source id, and the consolidated line it landed in.
3. The list of source ids that landed in NONE. This list must be empty.
4. The list of source ids that landed in MORE THAN ONE. This list must be empty.

RULES:
- A consolidated line must be testable. Three vague lines merged into one vague line
  has saved a page and decided nothing.
- Where sources disagree on a number, take the tightest and name its source in the
  "why" column.
- Never drop a requirement for being minor. Merge it or list it.
- If two sources genuinely conflict, do NOT merge them. Emit a CONFLICT row carrying
  both names. That is a workshop item, not an editing decision.

Below is a consolidated functional requirement list: <paste>.

Tell me which of these describe a MODEL'S behaviour rather than a function's.

OUTPUT SHAPE, one table:
| FR | Model behaviour? | Why | What its acceptance will have to look like |

RULES:
- It is a model behaviour when two competent people could reasonably differ about
  whether a given output satisfies it.
- If the criteria are published and unambiguous, answer NO. It is a function and it
  gets a unit test.
- For every YES, the acceptance column says "a measured share on real cases" and
  names the slice the share would be measured on.
- For every NO, the acceptance column names the assertion.
- Be strict. Most requirements are functions. If unsure, answer NO and say what
  would have to be true to make it a judgement.

Finish with the count of YES rows. Three is typical. More than six usually means the
list has not been consolidated tightly enough.

Rewrite each quality requirement below as a six-part scenario.

The six parts: SOURCE (who or what triggers it) · STIMULUS (what they do) · ARTEFACT
(the part of the system that responds) · ENVIRONMENT (load, hour, degraded state) ·
RESPONSE (what the system does) · MEASURE (the number, with its statistic).

OUTPUT SHAPE, per requirement:
- the original line, verbatim
- a table of the six parts
- one line: PARTS MISSING FROM THE ORIGINAL: <list them>

RULES:
- Never invent a number. Where the original has no measure, write
  <MEASURE NOT STATED> and collect it in a list at the end.
- Never invent an environment. Write <ENVIRONMENT NOT STATED>. Do NOT write "under
  normal load". That is the invented clause that gets ratified and then argued about
  for the rest of the project.
- The MEASURE must carry a statistic: P95, per case, per week, percentage of a named
  slice. "Fast" and "under 30 seconds" are both unfinished, for different reasons.

Finish with two lists: measures not stated, and environments not stated. Those two
lists are what I take back to the people who raised the requirements.

REQUIREMENTS:
<paste>

Sort the lines below into TECHNICAL, REGULATORY, COMMERCIAL or NOT A CONSTRAINT.

OUTPUT SHAPE, one table:
| Line | Type | The design it rules out | Where it must end up | Source named? |

RULES:
- The test for a constraint is that it names a design it rules out. Apply it to every
  line and fill the third column. If that column would be empty, the type is NOT A
  CONSTRAINT.
- NOT A CONSTRAINT splits three ways and you must say which: a MOTIVATION (the reason
  the project exists), a SOLUTION (someone naming a technology), a PREFERENCE.
- For every REGULATORY line, the fourth column names a place in the system: a typed
  parameter, a required token, a permission. Never "the prompt".
- For every TECHNICAL line, the fourth column names the integration shape it forces:
  an adapter, one server in front, a queue.
- Flag any line with no named source. An unsourced constraint usually turns out to be
  somebody's memory of a rule that has since changed.

LINES:
<paste>

I am writing candidate NFRs for <feature>. I have <n> so far, listed below.

Write exactly two more, as six-part scenarios, and only these two:
1. AUTONOMY LEVEL: what the system may do without a person, per action.
2. COST PER CASE: the run cost of one completed case, across every model call.

RULES:
- Both must be measurable and both must carry a number in the MEASURE part.
- For autonomy, the measure is about ENFORCEMENT, not intent. "100% of <action> calls
  carry a confirmation token" is a measure; "the agent asks before refunding" is not.
- For cost per case, put the alert multiple inside the measure, so the number is
  monitored rather than merely agreed.
- Then, for each NFR I already have, say in one line whether the new one is in tension
  with it. I expect latency against cost per case; tell me if there are others.
- Say explicitly which tensions are NOT real. Auditability against latency usually is
  not: logging costs milliseconds and the model choice costs seconds.

Do not propose any other NFRs. I have the rest.

MY CURRENT LIST:
<paste>

Tag every step of this feature. Use exactly three kinds.

EXACT: must be right every single time. Built as a function. Proven by a unit test.
BEST-GUESS: right a share of the time. Built as a model call. Proven by a measured
  share on real cases.
CONSEQUENTIAL: changes something real. Built as a tool PLUS a gate. Proven by a
  required confirmation.

OUTPUT SHAPE, one table:
| # | Step | Kind | Owner (code / model / tool+gate) | Proof | The assertion or bar |

RULES:
- A step can be CONSEQUENTIAL as well as exact or best-guess. Tag it consequential and
  say in the owner column what the other half is.
- Anything that writes, sends, books, cancels, refunds or changes an identity is
  CONSEQUENTIAL whatever else it looks like.
- Every number the feature computes and then acts on is EXACT. No exceptions, and do
  not accept "the model is good at arithmetic" as one.
- The proof column may not say "review" or "testing". It says: a unit test, a measured
  share on a named slice, or a required confirmation.
- After the table, draw the data flow as one line of arrows and mark where a number
  crosses from an exact step into a best-guess one.

Finish with: any step you could not classify, and the two things it is doing.

STEPS:
<paste>

Search this repository for arithmetic that lives in a prompt instead of in code.

Look in prompt files, system messages, tool descriptions, and any string literal long
enough to be an instruction.

Search for at least: calculate, compute, total, sum, difference, subtract, multiply,
percentage, work out, how much, amount owed, and every currency symbol.

OUTPUT SHAPE, one table:
| File | Line | The phrase | What it computes | ACTED ON or DISPLAYED | The function it becomes |

RULES:
- Match intent, not vocabulary. "Tell the passenger what they owe" is arithmetic and
  contains none of the words above. Include it.
- ACTED ON means the value feeds a tool call, a booking, a payment or a message to a
  customer. That is the urgent list; put it first.
- Do not change any code. Produce the list and a suggested function signature per row.
- Show me the search command you ran BEFORE the results, so I can see what you did not
  look in.

This step resisted classification as exact, best-guess or consequential:

<paste the step, and how it is currently described or prompted>

A step that cannot be classified is almost always doing two things at once: a
judgement and a calculation, or a judgement and a write.

1. Name the two things it is doing.
2. Split it into two steps and classify each.
3. For the exact half, write the function signature (name, typed parameters, return
   type) and the one unit test that would prove it.
4. For the best-guess half, write what it is deciding in one sentence, and the slice
   its measured share would be reported on.
5. State what may pass between them, and in which direction.

If it genuinely is one thing, say so, tell me which kind it is, and tell me why the
classification felt hard: that reason is usually itself a finding.

Here is a proposed multi-agent design: <paste, including each agent's job>.

Produce the SINGLE-AGENT version of the same feature, then compare the two.

OUTPUT SHAPE:
1. A table: | Proposed agent | What it really is | Where it goes in the single-agent design |
   Allowed values for the middle column: EXACT WORK (a function) · PARALLELISM (a
   fan-out tool) · INDEPENDENCE (a checker) · THE AGENT ITSELF · GENUINELY A SECOND AGENT.
2. The hand-off count for each design, computed as n(n-1)/2, with n stated.
3. For every GENUINELY A SECOND AGENT row, the named limit that justifies it: a number,
   not an adjective.

RULES:
- Parallelism is a property of a TOOL. Do not accept "these can run at the same time"
  as a reason for a second agent.
- A checker is the one separation that usually earns itself, because independence is
  the whole mechanism. Say so where it applies.
- Arithmetic is never an agent. It is a function.
- If you cannot name a limit with a number in it, write "no limit found" rather than
  inventing one. That answer is the useful one.

I am recording a single-agent design for <feature>. Write the escalation condition
that would justify moving to an orchestrator with workers.

OUTPUT SHAPE: exactly two bullets, each in this form:
  "We move to <topology> when <measurable thing> exceeds <number> on <named case class>."

Then, below them:
- How each thing would be measured today, and with what.
- The measurement I should take NOW as a baseline, so the condition can later be
  evaluated rather than argued about.
- What I would have to change in the design if the condition were met tomorrow.

RULES:
- Every condition carries a number and a named case class. "If the context gets too
  big" is not a condition.
- Do not propose more than two. A list of conditions is a list of excuses.
- Do not include anything of the form "if the team feels it would be cleaner".

CONTEXT: <the feature, the largest case class, current context size if known, the
latency budget, how many parallel calls the fan-out tool makes>

Here are the changes my team has in flight: <paste, one per line>.

Assign each a process depth. Run only the lifecycle stages the change actually needs.

OUTPUT SHAPE, one table:
| Change | P0 | P1 | P2 | P3 | Method weight | The stage I am skipping, and why that is safe |

Allowed cell values: full · yes · light · none

RULES:
- The living spec is the backbone on EVERY row, including the one-line fixes. It is
  the constant; everything else flexes around it.
- The full document trail is layered on ONLY where the work is audited and multi-team.
  On a small feature it is six documents between an engineer and a one-line change.
- A regulatory rule change usually needs design and validation and no discovery. Say
  where that applies and where it does not.
- The last column is the point of the exercise. If you cannot say why skipping a stage
  is safe, do not skip it.

Merge these stakeholder utility trees and find the conflicts.

Each stakeholder scored each candidate NFR on business VALUE (1-3) and COMPLEXITY (1-3).

  priority = value x (4 - complexity)

OUTPUT SHAPE:
1. One table: a row per NFR, a column per stakeholder holding their priority, then a
   GAP column holding the largest difference between any two stakeholders.
2. SHOW THE ARITHMETIC for at least three rows, so I can check you have not inverted
   the formula.
3. CONFLICTS: every NFR whose gap is 5 or more. Each one owes a decision record.
4. FALSE CONFLICTS: pairs that look opposed and are not, with the reason. The usual
   example is auditability against latency: logging costs milliseconds and the model
   choice costs seconds.
5. A proposed agenda: the uncontested NFRs first as one time-boxed block, then the
   conflicts one at a time.

RULES:
- Do not average the stakeholders. The gap is the signal and an average destroys it.
- Do not reword anyone's NFR.
- If a stakeholder did not score an NFR, leave the cell blank. Never impute a score.

SCORES:
<paste>

Score this decision as a weighted matrix, then test how firm the answer is.

CRITERIA AND WEIGHTS: these come from my ratified NFRs. Do not change them:
<paste: criterion, weight 1-3>

OPTIONS: <build / buy / borrow, or the named options>

OUTPUT SHAPE:
1. The matrix: each option rated 1-3 per criterion with one line of reasoning per cell.
   score = sum(weight x rating). Show the totals.
2. A three-year cost table with three columns: licence, people, total. Count the people.
3. THE DOOR, per option: two-way (reversible cheaply) or one-way, and what the exit
   costs. Say whether an interface layer converts a one-way door into a two-way one,
   and what that layer costs to build.
4. THE FLIP TEST: which single weight or rating would have to move, and by how much,
   before the winner changes. One sentence.

RULES:
- If the spread between first and last is small, say so plainly. A close matrix means
  the criteria do not separate the options, and the tie is then broken by the door.
- Never let cost outrank the weights I gave you.
- Where you do not know a number, write UNKNOWN and name who would have it.

Draft an architecture decision record from my notes below.

OUTPUT SHAPE: exactly these sections, in this order:
  Status (accepted or superseded, with the date and what it supersedes)
  Context (the trade-off that forced a decision, in three sentences)
  Decision (what we are doing, and the named review point)
  Consequence (what it costs now, and what it keeps open)
  Rejected (one entry per option, each carrying the NUMBER that rejected it)
  Flip test (which single input would have to move, and by how much)

RULES:
- The Rejected section is the part that matters and the part that gets written badly.
  Every rejection cites the matrix score, the three-year cost or the door. A rejection
  that reads as a preference is a failure: rewrite it, or tell me the number is missing.
- Do not flatter the decision. If an option scored within a point of the winner, that
  belongs in Context, not in Rejected.
- Keep it to one screen. A coding agent reads this in its context pack, which is exactly
  why it must be short and exact.
- The review point is a date or a named trigger, never "later".

MY NOTES:
<paste>

Band every tool below on the R1-R5 ladder.

R1  reversible draft or sandbox: review at the end
R2  reversible change to real work: review before merge
R3  hard to reverse, small blast radius: approve first
R4  money, identity or a policy commitment: a NAMED approver, every time
R5  irreversible or safety-critical: not delegated at all

OUTPUT SHAPE, one table:
| Tool | Band | What ONE wrong call could damage | Where the control must live | The test that proves it |

RULES:
- Band by what the ACTION could damage, never by the size of the change. A one-line
  change to a refund cap is R4.
- The control column may not say "the prompt". It says: a typed parameter, a required
  confirmation token, a permission scope, or "no tool exists".
- Every R4 row names the approver role.
- Every R5 row says that no tool exists, not that the tool is discouraged.
- Flag any tool carrying a generic action parameter. One broad manage_<thing>(action)
  tool is accidental authority and must be split, because any path through it could
  cancel something.

TOOLS:
<paste the signatures, or the list with one line of description each>

Search every prompt, system message and tool description in this repository for rules
that are currently only requests.

Search for at least: every currency symbol and amount, "never", "always", "do not",
"ask before", "make sure", "you must not", "only if", "limit", "maximum", "cap",
"approval", "confirm".

OUTPUT SHAPE, one table:
| File | Line | The sentence | Would ignoring it cost money, expose data or be irreversible? | The enforced version | The two tests |

RULES:
- The fourth column is the triage. Rules that fail it are fine as policy and should
  stay exactly where they are; say so rather than proposing work.
- The enforced version is a typed parameter that raises, a required confirmation token,
  or a narrowed permission. Never a better sentence.
- For every row that needs enforcing, WRITE the two tests: the over-limit case and the
  missing-confirmation case. Both assert that the call RAISES, never that the reply
  contains an apology, because wording changes with the next prompt edit.
- Do not remove the explanatory sentence from the prompt. Say which sentences to keep.
- Show me the search commands before the results.

Classify each open decision below. Ask the four questions IN ORDER and stop at the
first "no". One "no" makes it hard.

1. Can it be reversed cheaply once the build has started?
2. Can the build proceed behind a placeholder?
3. Is there a named owner and a date?
4. Does everything downstream survive if the answer changes?

OUTPUT SHAPE, one table:
| Decision | Q1 | Q2 | Q3 | Q4 | HARD or SOFT | The placeholder | What settles it, and when |

RULES:
- Be strict on Q1. "We would only have to change some code" is a NO once that decision
  has reached everywhere the code goes.
- Every SOFT row must carry a real placeholder: a stub, an interface layer, a default
  tier behind a gateway. A soft gate with no placeholder is a hard gate nobody has
  admitted to, and the build queues regardless of the label.
- Every HARD row names the phase it must close in.
- Do not mark a decision soft because it feels small. Size is not the test.

DECISIONS:
<paste>

Below is everything currently pasted into the prompts of <product>.

Sort every line into exactly one of four layers and say why.

  SHARED   org-wide standards, security, tone of voice, glossary
  DOMAIN   the business model for this area: entities, rules that hold across products
  PRODUCT  this application's architecture, APIs and conventions
  TASK     this feature's spec, its bar and its file list

OUTPUT SHAPE:
1. A table: | Line (truncated) | Layer | Why | Duplicated in how many products? |
2. A DOMAIN section listed separately and in full. This is the layer teams forget and
   I want to read it on its own.
3. A list of lines that contradict each other, with both versions and the products they
   came from. These are the stale copies.
4. For each layer, the token count, so I can see what a task actually needs to be sent.

RULES:
- Resist putting things in SHARED. A line belongs in shared only if a product in a
  DIFFERENT business area would also need it. Apply that test explicitly per line.
- A line that names this feature is TASK, however general it sounds.
- Do not rewrite any line. Sorting is the job.

PROMPT DUMP:
<paste>

Design a single server exposing <system> to any compliant AI client.

Expose exactly three kinds of thing:
  RESOURCES  read-only data the application supplies
  TOOLS      actions the model may invoke
  PROMPTS    templates a person picks

OUTPUT SHAPE:
1. resources: name, what it returns, who controls it.
2. tools, in TWO separate lists: OPEN READS and GATED WRITES. Every gated write carries
   a required confirmation parameter in its signature and its risk band.
3. prompts: name and when a person would pick it.
4. A REJECTED section: designs you considered and discarded, with the reason.
5. The trace row each tool call writes.

RULES:
- Never propose one broad tool with an action parameter. Any path through such a tool
  carries the authority of the most dangerous action it can reach. Enumerate instead.
- A read tool must have no side effects, and you must say how that is enforced rather
  than asserted.
- Every write tool's confirmation is a typed parameter, not an instruction in the
  description. A description is a request.
- Where the underlying system exposes something that should not be reachable at all,
  say so and leave it out. Not every capability becomes a tool.

SYSTEM: <the API surface, or a link to it>

Here are the steps of <feature>, with each best-guess step's measured or estimated
accuracy: <paste>.

1. Compute the end-to-end success rate by MULTIPLYING the best-guess steps. Show the
   multiplication. Do not average anything.
2. Tell me what that rate means in plain words: wrong roughly one time in how many.
3. Option one, SHORTEN: which steps could be removed or merged, and what the rate
   becomes. Look especially for exact work that has crept into a prompt, and for two
   calls doing what one could do.
4. Option two, CHECK: which steps get an independent checker. Place them only where a
   wrong answer is COSTLY and EASY TO MISS. Give the rate after checkers, and state
   the assumption you used about what a checker recovers.
5. For each checker: the model or context that makes it independent, and its brief,
   written as an adversarial instruction.
6. The re-draft cap, and what happens when it is hit.

RULES:
- Exact steps do not get a checker. They get a unit test. Say so rather than skipping
  them silently.
- Consequential steps do not get a checker. They get a required confirmation.
- Do not propose raising the model tier on every step. That is the expensive answer to
  a structural problem, and say so if someone has suggested it.

My token bill is <n>x its estimate and traffic is flat. Diagnose it from the
per-call log at <path>, not from the price list: the prices did not change.

Compute four ratios, the baseline period against now:
- tokens per call
- share of calls on the frontier tier
- cache hit ratio
- retries per conversation

OUTPUT SHAPE:
1. A table: | Signature | Baseline | Now | Factor |
2. The PRODUCT of the four factors, with the arithmetic shown. If the product is close
   to the ratio between the two invoices, say so and stop looking.
3. If the product is well below the invoice ratio, name what structural change is not
   explained by habit: traffic, a new feature, or a price change I should go and check.
4. A fix order, computed as priority = (factor - 1) / days to fix. Show the arithmetic.

RULES:
- Do NOT rank by the largest change in a ratio. Retries often rise the most in relative
  terms and contribute the smallest factor on the bill.
- For each fix, name where the control lives afterwards: a config file reviewed like
  code, a breaker constant, a rule about prompt ordering.
- Each of these was a sensible decision made by a careful person. "Remind the team to
  be careful with tokens" is not a fix; say what makes the habit visible on the day.

Turn this incident into a design change. Use EXACTLY this structure.

**Timeline**: what happened, minute by minute, from the input to the consequence
**Reconstruct**: for each control that was supposed to exist, state whether the
  incident is POSSIBLE or IMPOSSIBLE with it enforced. The combination that is possible
  is the state the system was actually in.
**Finding**: the ENFORCED control that, if present, would have made this IMPOSSIBLE
**Not the finding**: the input, the person, and any control that would only have
  DETECTED it
**Change**: the typed parameter, the confirmation token or the permission, and the
  file it will live in
**Record**: the record number, and the autonomy level that drops as a result
**Verify**: the test QA re-runs, and what "stopped twice over" means here

RULES:
- Do not name a person. Do not name the input that triggered it.
- "A better prompt" is NOT a control. A prompt is a request a model can be talked past.
  If your finding is a prompt change, you have not found the control yet.
- Classify every layer that was supposed to help as ENFORCED, A REQUEST, or ABSENT, and
  be honest about the ones that were written down only in the prompt.
- Separate detection from prevention and say which yours is. An alert tells you
  afterwards; a cap makes it impossible.

INCIDENT:
<paste the trace and the postmortem notes>

Extract a rule sheet from this legacy module, so an agent can read the intent
instead of the code.

OUTPUT SHAPE, one table:
| rule_id | Condition | Action | Source (file:line) | Confidence 0-1 |

RULES:
- One row per business rule. A rule is a condition and an action, not a code path.
- Every row cites a file and a line. A rule with no source cannot be verified and must
  not be written down.
- Confidence is your honest reading of whether the code does what the row claims.
  Anything below 0.9 goes to a person before it goes anywhere near the agent; mark
  those rows clearly.
- Where a comment and the code disagree, follow the CODE and say so in the row. Low
  confidence usually means the code does something the comments deny.
- Do not modify any code and do not propose a refactor.

Then, separately:
- A migration score for this module out of 25: risk, documentation, coupling,
  reversibility, and how much it teaches. Say where it falls in the order, and confirm
  that anything touching payments is last.
- The clean interface this module should sit behind before the agent touches it.

MODULE: <path>

You are writing the project context file that every coding agent on this
repository will read at the start of every session. The repository is at <path>
and the shared context layers live under </context/shared/>.

Read the repository first. Do not ask me questions you can answer by reading.

Produce EXACTLY four sections and nothing else:
1. Stack: language, framework, package manager, test runner, linter, type checker
2. Context layers: paths only, no pasted content
3. Commands: a table of task and command
4. Never touch: files where a mistake is expensive, one reason each

RULES:
- Run every command you put in section 3 and paste its output below the draft. If a
  command fails, remove it and say so; a command that does not work is worse than none.
- Do not invent conventions. Only write a convention you can point at a file for.
- Keep it under 100 lines. If you are over, cut section 3, never section 4.
- Mark anything you inferred rather than read with INFERRED, so I can check it.

OUTPUT: the file, then the command output, then a list of your INFERRED lines.

Below are the review comments left on merged pull requests over <n> weeks.

Find the corrections that REPEAT. A correction made three times is a missing convention.

OUTPUT a table:
| The rule, as one imperative sentence | Times it was said | Example comment | Section |

Where Section is one of: conventions / commands / never-touch / not a rule.

RULES:
- Rank by how many times it recurs, not by how strongly it was worded.
- Merge comments that say the same thing differently; keep the clearest wording.
- Mark as "not a rule" anything that was a one-off judgement about that change. Those
  do not belong in a context file and adding them is how the file becomes unreadable.
- For each rule, say whether it could be ENFORCED instead: a lint rule, a CI check, a
  type. A rule that can be enforced should not be a line in a markdown file.

COMMENTS:
<paste>

Here is our context file: <paste>. Here is the repository layout: <paste>.

Audit it and report, in this order:

1. DEAD COMMANDS: any command in the file that does not exist or does not run. Run each.
2. STALE PATHS: any path referenced that is not in the repository.
3. COPIED CONTEXT: any text that looks like a pasted copy of a shared standard rather
   than a reference to it. Copies go stale silently; say where the original should be.
4. VAGUE RULES: any line containing "appropriate", "correct", "as needed", "try to",
   "where possible". Rewrite each as something checkable, or recommend deleting it.
5. MISSING: of stack / context layers / conventions / commands / never-touch, which
   section is absent or thin?

Finish with the THREE lines you would add first, and the evidence for each.
Do not rewrite the whole file. I want the diff, not a replacement.

Assemble a story file for one bolt. Six sections, in this order:
context (by reference) · spec in EARS · tools with bands · tests · done-when · cost.

RULES:
- Section 1 contains PATHS ONLY. If you are tempted to paste a document, write the path
  and the specific heading inside it instead.
- Section 2 is EARS: WHEN <trigger> AND <precondition> THE SYSTEM SHALL <response>
  WITHIN <limit>. Every BOUNDARY goes on its own line, phrased as what the system must
  REFUSE, never as what it should try to do.
- No sentence may contain "appropriate", "correct", "reasonable", "as needed" or
  "where possible". If you cannot remove the word, write UNDECIDED and the question.
- Section 3 takes the band from the authority budget I give you. Do not assign one.
- Section 4 names the unit tests. Names, not descriptions.
- Section 5 must be checkable by a machine, in three lines or fewer.

OUTPUT the file, then a separate list headed UNDECIDED with every open question.

BOLT: <one line>
AUTHORITY BUDGET: <paste>
ADRs AND CONTEXT PATHS: <paste>

Rewrite the requirement below in EARS.

FORMAT:
WHEN   <trigger>
AND    <precondition>          (repeat for each; do NOT merge them)
THE SYSTEM SHALL <response>
WITHIN <limit, with a unit>

Then, separately, one BOUNDARY line per thing the system must refuse.

RULES:
- Preserve every precondition as its own AND line. Do not summarise two into one.
- If a limit is missing, write WITHIN <UNSPECIFIED>. Never invent a number.
- List any word in the original that hides a decision ("appropriate", "quickly",
  "if possible") and say what decision it is hiding and who should make it.
- At the end, list anything in the prose that is a SOLUTION rather than a requirement.

PROSE:
<paste>

Here is the story file for today's bolt: <paste>.

DO NOT WRITE ANY CODE. Do not start.

List every question you would have to ask me in order to build this bolt without
further conversation. For each question:
- which section of the file should have answered it
- what you would assume if nobody answered
- whether that assumption could move money, change a booking, or write a trace row

Then answer one thing: can this bolt be built and tested ALONE, with nothing that is
scheduled for a later day? If not, name exactly what is missing and stop.

Every question on your list is a defect in the file, not in me. I am going to fix the
file, and then you are going to build from it with this conversation closed.

Below is the exact / best-guess map for <feature>, and the spec clauses.

For EVERY step marked EXACT, produce:
1. A function signature with precise types. Money is Decimal, never float.
2. ONE assertion taken from the spec clause, not from any implementation.
3. The exception it raises when its precondition is violated, named.

RULES:
- Write the tests FIRST, in a block I can run immediately. They must fail.
- Do not write any function bodies in this response.
- If a spec clause does not pin down a value precisely enough to assert on, write
  UNDECIDED and the exact question. Do not choose a plausible number.
- State the rounding rule for every monetary function: where it happens and which mode.
- Flag any step on the map marked BEST-GUESS that you think is actually exact, with the
  reason. Do not act on it; I will take it to the architect.

MAP: <paste>
SPEC CLAUSES: <paste>

Search every file under <src/prompts/> for arithmetic that a model is being asked
to perform: the words calculate, compute, total, sum, difference, percentage, fee,
charge, and any currency symbol.

OUTPUT a table:
| File and line | The sentence | Is the number ACTED ON? | Function it should become |

RULES:
- "Acted on" means the value reaches a tool call, a customer, a ledger or a document.
  A number that only appears in an explanation to a human is not the same category;
  mark it EXPLANATORY and leave it alone.
- Propose a signature for every acted-on hit, with Decimal for money.
- Do not change any file. Return the table and the signatures only.
- At the end, give me the one-line shell command for this grep so I can put it in CI.

Here is an exact function and its current tests: <paste>.
Here is the spec clause it implements: <paste>.

List the inputs that would break it or expose an undecided behaviour. Cover at least:
zero, negative, equal values, the rounding boundary, unit or currency mismatch, missing
optional fields, and the largest value the domain allows.

For each, output a row:
| Input | What the code does today | What the SPEC says | Decided or UNDECIDED |

RULES:
- Where the spec is silent, mark UNDECIDED and do NOT write a test for it. A test over
  an undecided behaviour freezes a decision nobody made.
- Only give me test code for the rows marked Decided.
- If the code and the spec disagree anywhere, say so first and loudly, before the table.

Here is the chain of steps for <feature>, with the architect's exact / best-guess
map beside it: <paste>.

For EACH step, output a row:
| Step | Exact or best-guess | Cost of a wrong answer | Easy to miss? | Checker? | Why |

RULES:
- An EXACT step never gets a checker. It gets a unit test. Say so on those rows.
- Recommend a checker ONLY where a wrong answer is both costly AND easy to miss. A
  wrong answer that the next step would reject anyway does not need one.
- Every checker is a model call on every case. Give me the estimated added cost per
  case for your recommendations, as a total.
- Then compute the end-to-end product of the per-step accuracies I gave you, and tell
  me whether SHORTENING the chain would buy more than any checker you proposed.

Finish with the single step you would check first if I could only afford one.

Write the system prompt for an INDEPENDENT checker on this step: <describe>.

The checker will receive the CONSTRAINTS and the OUTPUT. It will never receive the
drafter's reasoning, and it must not ask for it.

The brief must:
- tell it plainly that it is reviewing work it did not produce, and to find what is wrong
- list the failure modes to look for, in the order a good reviewer would check them
- fix the reply shape: PASS, or FAIL followed by one line per violated constraint
- forbid rewriting the output; its job is a verdict, not a draft

RULES FOR YOU:
- Build the failure-mode list from the real disagreements I paste below, not from first
  principles. Anything you add from imagination, mark INVENTED.
- Do not include praise, encouragement or any instruction to be balanced. A checker that
  is being fair is a checker that is passing things.

REAL DISAGREEMENTS: <paste>
CONSTRAINTS THE OUTPUT MUST SATISFY: <paste>

Here is our checker implementation and a sample of its inputs: <paste>.

Answer these five, in order, and stop at the first NO:

1. Is the checker a DIFFERENT model, or the same model in a genuinely fresh context?
2. Is the drafter's reasoning excluded from what the checker receives? Quote the exact
   lines of code that exclude it, or say it is not excluded.
3. Does the brief tell it to find what is WRONG, or to review and confirm?
4. Is there a cap on re-draft rounds, and does exceeding it escalate to a person rather
   than returning the last draft?
5. Is the verdict written to the trace on every case, pass and fail alike?

Then tell me the pass rate over the sample. A checker that has passed everything is
either unnecessary or broken, and those two are distinguished by the sample, not by
opinion. Say which one this is and what evidence would settle it.

Search every prompt, system message and tool description under <src/prompts/> and
<src/tools/> for sentences that are really controls: never, always, must not, do not,
ask before, requires approval, and every currency symbol or numeric limit.

OUTPUT a table:
| File and line | The sentence | What it would cost if ignored | ENFORCED VERSION |

RULES:
- "Cost if ignored" must be concrete: money moved, data exposed, something irreversible
  changed, or nothing. Write "nothing" where that is the honest answer.
- The ENFORCED VERSION column is a typed bounded parameter, a confirmation token, a
  permission, or "stays as policy". Do not write "a clearer prompt". That is the same
  request in better handwriting.
- Separate the rows into ACT NOW (money, data, irreversible) and LEAVE AS POLICY.
- Do not modify any file.

Finish with the count in each group. Teams commonly find between three and ten in the
first group, and the count matters less than the fact that nobody knew it.

Here is the authority budget row for this tool: <paste>.
Here is the existing unguarded implementation: <paste>.

Produce:
1. The typed signature, with the bounded parameter and a confirmation token parameter.
2. Named exception classes: one for over-cap, one for missing or invalid confirmation.
3. The two tests: over-cap RAISES, no-confirmation RAISES.
4. A trace write on the refusal path as well as the success path.

RULES:
- RAISE. Do not clamp to the cap, do not log and continue, do not return an error object.
- Read the cap from <config/caps.yaml>. No numeric literal anywhere in the function.
- The confirmation token must be validated against BOTH the booking id and the amount,
  so a token minted for a small refund cannot authorise a large one.
- Do not touch the prompt. The sentence there stays, as policy.

Then list anything in the authority budget row that the signature cannot express, so I
can take it back to the architect rather than approximate it here.

Turn this authority budget into a path rule that assigns a review band to every
file in the repository: <paste budget>. Here is the repository tree: <paste>.

OUTPUT a YAML file mapping R5 down to R1 to path globs, plus the review policy each
band implies (how many readers, and whether a person is required at all).

RULES:
- A change inherits the band of the most dangerous tool it touches. Size is irrelevant:
  three lines in a refund cap is the highest band there is; four hundred lines of help
  text cannot move money.
- The config file holding the caps gets the same band as the tool it caps.
- Never let the author assign the band. The rule is in the repository and it applies.
- Any path you cannot classify goes in an UNCLASSIFIED list for me, not into R1.

Then estimate, from last month's merged changes that I paste below, how many review
slots the new policy needs versus the current one.

LAST MONTH'S CHANGES: <paste>

Write the CI workflow for our eval harness. It runs on every pull request as a
REQUIRED check, and on a nightly schedule for the full set.

Steps, in THIS order, because it is cost order:
1. build
2. exact tests: schema, the money functions, the eligibility rules
3. work out which slices the changed paths touch
4. golden run: the touched slices on a pull request, ALL slices on the schedule
5. the independent judge, with a PINNED model id recorded in the run
6. score against the bar, per slice, printing score, n and the 95% lower bound

RULES:
- The job exits non-zero if ANY touched slice is below its bar. The overall number never
  rescues a failing slice, and the failure message must say which slice and by how much.
- No step may run before a cheaper step that could have rejected the same change.
- The judge model id is an env var, pinned, and appears in the run summary.
- Keep the whole thing under 60 lines of YAML.

Our slices: <list>. Our make targets: <list>. Our golden set lives at <path>.

Here is our harness: <paste>. Here are <n> commits from the last month, with what
each one did and whether it turned out to be a regression: <paste>.

Replay the harness against each commit and report:
| Commit | Was it a regression? | Harness verdict | Correct? |

Then tell me:
- Every regression the harness would have MISSED, and the specific step that should have
  caught it: exact test, golden slice, or judge.
- Every clean commit the harness would have REJECTED, and why. A harness that rejects
  good changes gets switched off within a fortnight.
- The slice with the fewest cases, and whether its lower bound could clear its bar at
  that n at all.

Do not change the harness in this response. I want the evidence first.

Convert this harness output into the shape of the PM's bar sheet: <paste output>.
Here are the bars: <paste>.

ONE table, nothing else above it:
| Slice | Score | n | 95% lower bound | Bar | PASS / FAIL / UNPROVEN | vs last run |

RULES:
- lower bound = p - 1.96 * sqrt(p*(1-p)/n). Compute it even if the harness only gave a
  score. Under about 100 cases say USE WILSON beside the row.
- PASS only when the LOWER BOUND is at or above the bar. Score above bar with the lower
  bound below it is UNPROVEN, and then give cases needed:
  n = 1.96^2 * p * (1-p) / (p - bar)^2
- Flag any slice that got worse than the previous run even if it still passes.

Then one line: merge, or do not merge, and the single reason.

Here are the bolts for <feature>, each with a one-line description and a
depends-on column: <paste>.

Produce a day-by-day order in which every bolt's dependencies come strictly before it.

RULES, applied in this priority order:
1. The walking skeleton first: the thinnest end-to-end path with NO model in it.
2. Pure exact code early. It is testable alone, so it never blocks anyone.
3. Checkers after the steps they check.
4. Any plug (MCP server, connector, adapter) BEFORE the gated write that needs it.
5. The proof, golden set and harness, last.

Then report, separately and before the plan:
- any CYCLE, where two bolts wait on each other. A cycle is always a mis-cut and means
  one of them is really two bolts. Name which one.
- any plug scheduled after its consumer in the order I gave you
- any bolt with NO dependencies that I had scheduled late
- any bolt carrying more than ONE unknown, and how you would split it

If there is no walking skeleton in my list, add one and say what it would cover.

Build this bolt. The story file is the whole brief: <paste file>.

RULES:
- Work only inside the paths the file names. If you find a problem in an adjacent file,
  write it down at the end; do not fix it. A second fix makes the review two unknowns.
- Read context by the paths in section 1. Do not ask me to paste any of them.
- The unit tests named in section 4 are written first and must be seen failing.
- Nothing in section 3 changes: signatures, bands and confirmation parameters are fixed.
- If you need something that is not in the file, STOP and say what it is. Do not
  improvise it, and do not build around it.

OUTPUT, in this order:
1. The failing tests
2. The implementation
3. The command output showing them green
4. A list headed FILE DEFECTS: everything you needed that the story file lacked
5. A list headed OUT OF SCOPE: problems you found and deliberately did not fix

Implement the shadow path for <feature> behind a feature flag.

Behaviour:
- flag OFF: the live process runs as today. The agent is not invoked.
- flag SHADOW: the agent runs on the same input, decides, and logs its decision beside
  the live one. It performs NO writes of any kind.
- flag LIVE at <5>%: the agent acts for that share of traffic; everything else unchanged.

MUST INCLUDE:
- `test_shadow_never_writes`: fails the build if any write tool is REACHABLE while the
  flag is in shadow mode. Assert on the tool call, not on the agent's output.
- A nightly comparison job producing agreement PER SLICE, never one overall number, with
  money actions reported separately and never counted toward automatic agreement.
- A revert path that is the flag itself, and a rehearsal script that times it.

Do not add a kill switch that is separate from the flag. Two mechanisms means one of
them is untested on the day it is needed, and it will be the other one.

Traffic is flat and the bill is <n>x the estimate. Do not look at the price list.
Here is the per-call log for this month and the month before: <paste or path>.

Compute these four ratios, this month against last:
| Signature | Baseline | Now | Factor |
- tokens per call
- frontier tier share
- cache hit ratio (a FALL is a rise in cost; express it as a factor above 1)
- retries per conversation

Multiply the four factors. Compare the product with the ratio between the two invoices.
- If they match, say so and stop looking. The bill is explained.
- If the product is well below the invoice ratio, something structural changed that is
  not a habit: traffic, a new feature, or a price change. Say which to check.

Then order the fixes by  priority = (factor - 1) / days to fix,  NOT by the biggest
ratio change. Give me the table with the order and the days you assumed.

Finally: name the guards that would have caught this in week one rather than week four.

Build an injection regression suite for <feature>.

Cross-product: EVERY attack string x EVERY gated tool x EVERY entry point.

Entry points must include, at minimum:
- the passenger's own message
- a partner API response free-text field (the partner is trusted; the field is not)
- an uploaded document, including text that is invisible when rendered
- a free-text field on the booking record
- a retrieved knowledge-base chunk

RULES (these decide whether the suite is worth anything):
- Assert on the TOOL CALLS and on the trace row. Never assert on the model's wording.
  A test that checks the reply contains "I cannot do that" is red for the wrong reason
  after the next prompt edit and green for the wrong reason the week after.
- Every test asserts BOTH that the action did not happen AND that an attempt was
  recorded in the trace.
- The suite runs weekly on a schedule, and on every prompt, tool or context change.

OUTPUT: the test module, the attack-string fixture file, and the CI schedule entry.

OUR GATED TOOLS: <paste signatures>
OUR ENTRY POINTS: <paste>

A hotfix shipped outside the normal flow. Here is the spec as it stood: <paste>.
Here is what actually merged: <paste diff>.

Produce a RECONCILIATION DIFF, not a rewritten spec.

| Spec clause | What shipped | Same? | Why it differed | Keep the code or keep the spec? |

RULES:
- Never rewrite the spec so it agrees with the code. The rewrite loses the only record
  that they ever disagreed, and that record is what the next postmortem needs.
- For every difference, say whether the SPEC was wrong (amend it, with the reason and
  the date) or the CODE was expedient (raise the follow-up, with the risk it carries
  until then).
- Flag any difference that touches a cap, a confirmation token, a permission or a trace
  field. Those are not tidy-ups; they are changes to a control and need the band.
- List any golden-set case that the hotfix invalidates, and any new case it implies.

Finish with the amended ADR line, if a decision changed, in one sentence.

You are helping a QA lead turn an agent's step map into a test plan.

For EVERY step below, output one row:
| # | Step | Kind | Proof it owes | How it fails | Why this kind |

Kinds, and only these three:
- EXACT: published, unambiguous criteria. Arithmetic, schema, eligibility.
  Proof: a unit test. Fails loudly.
- BEST-GUESS: two competent people could differ. Proof: a measured share on real
  cases, per slice, against a bar. Fails fluently: confident and wrong.
- CONSEQUENTIAL: it moves money, changes an identity, or makes a commitment.
  Proof: over-cap raises AND no-confirmation raises. Fails silently until money moves.

RULES:
- Be strict. If the criteria are published somewhere, it is EXACT, not BEST-GUESS.
- A step can be CONSEQUENTIAL as well as one of the other two. Say so and list both proofs.
- If a step needs two different kinds of proof for two different parts, mark it SPLIT and
  say where the seam is.
- Do not propose test cases. This step is the map, not the cases.

Finish with: the steps you were least sure about, and the one question that would settle each.

STEP MAP:
<paste>

Compute an acceptance bar for each slice and SHOW THE ARITHMETIC.

N = damage / saving
bar = N / (N + 1)

Then repeat every row a second time with a human hold in place, using the reduced damage
figure I give you, so the two rows sit side by side.

OUTPUT: one table.
| Slice | Saving | Damage | N | Bar | Damage with a hold | N | Bar with a hold |

Then three lines:
1. Which slice has a bar you are unlikely ever to prove, and what its held bar would be.
2. Which slice's bar is most sensitive to the damage figure being wrong by 50%.
3. For any damage figure I did not give you, say UNKNOWN and name who would have it.
   Do not estimate a damage figure. Ever.

SLICES, SAVING, DAMAGE:
<paste>

Here is my proof map: each step, its kind, and the proof I intend to accept.

For EACH row, describe a concrete system that PASSES that proof and is still wrong in a
way that would reach a customer.

RULES:
- Be specific to this domain. "The model could hallucinate" is not an answer.
- Mark each scenario POSSIBLE or IMPOSSIBLE in the architecture described below, and say
  which detail of the architecture makes it so.
- For every POSSIBLE one, name the single additional assertion that would close it, and
  say whether that assertion belongs in a unit test, the golden set, or a tool signature.

OUTPUT: a table, then a list of the assertions I am missing, ordered by what they protect.

PROOF MAP:
<paste>

ARCHITECTURE NOTES:
<paste>

You are helping a QA lead build a golden set from real historical cases.

Read the export at <path>. Columns: <list them>.

Write and run a script that emits one JSON object per line with EXACTLY this shape:
{"id":"c-nnnn","slice":"<one of: same-day | codeshare | refund | abstain | refuse>",
 "source":"<the ticket id>","input":{...the facts of the case...},"expect":null}

RULES:
- `expect` is ALWAYS null. Do not infer the expected outcome from what the agent or the
  desk actually did: that turns the set into a snapshot of current behaviour.
- Redact every passenger identifier: name, email, passport, card. Keep the PNR masked.
- Assign the slice from the booking facts, not from the ticket's own category field.
- Drop any row where you had to guess the slice, and list those separately at the end.

OUTPUT: the script first, so I can check the slice logic and the redaction, then a count
per slice, then the file.

Finish with: the rows you dropped and why.

Work out how many golden cases each slice actually needs.

For each slice I give you, compute:
- cases needed = 1.96^2 * p * (1 - p) / (p - bar)^2, using the score I give you
- the shortfall against the cases I currently have
- how many days of real history that shortfall represents, at the cases-per-day I give you

OUTPUT: one table.
| Slice | Bar | Current score | Cases held | Cases needed | Short by | Days of history |

Then three lines:
1. Which slice a representative sample would under-serve most, and by how much.
2. Which slice is cheapest to prove per case curated.
3. Any slice where the cases needed exceeds the history available: those need a hold to
   lower the bar, not more curation, and I need to know now.

Show the arithmetic for one row so I can check it.

SLICES, BARS, SCORES, CASES HELD, CASES PER DAY:
<paste>

Here is my spec and my golden set's slice counts and case notes.

Tell me what is NOT in this set.

RULES:
- Work from the spec's BOUNDARY lines first: every "shall never" needs at least one case
  whose expected outcome is a refusal.
- Then the abstentions: situations where the correct answer is "I cannot determine this".
  Most sets have none, and an agent with no abstention cases learns to always answer.
- Then the seams: two conditions that are each covered alone and never together.
- For each gap, write the case as a one-line description plus the expected outcome and
  reason code. Do NOT write the input payload; I will pull a real one.

OUTPUT: a table of gaps ordered by what they protect, then the five I should add first.

SPEC:
<paste>

SLICE COUNTS AND CASE NOTES:
<paste>

Write the exact checks for these steps. They run FIRST in the harness, before any
model is called to judge anything.

For each step below produce a test that:
- recomputes the expected value FROM THE SOURCE RULES I give you, never from the agent's
  output or from a stored result
- asserts on a value, not on a message
- names, in the failure message, which rule it checked and what it expected

RULES:
- If a step cannot be checked exactly, say so and say why, and do NOT write a test that
  approximates it. That step belongs in the golden set instead.
- No test may call a model.
- Include the fixtures, and make every fixture a real redacted case, not a round number.

OUTPUT: the test file, then a list of the steps you refused to write an exact test for.

STEPS AND SOURCE RULES:
<paste>

You are an independent reviewer. You did not write the message below and you have no
stake in it passing.

You will see: the passenger's request, the agent's final message, the booking data, and
the policy extract. You will NOT see the agent's reasoning, and you must not infer it.

Score against EXACTLY these three criteria, each pass or fail:
1. TONE: <the tone criterion from the rubric>
2. POLICY: <the policy criterion, with the extract below>
3. FALSE CLAIM: every factual statement is supported by the booking data supplied.
   A hedged statement counts as a claim. <or: does not count - state which>

RULES:
- Judge only the message as written. Do not reward good intentions or plausible reasoning.
- Any criterion failing fails the case.
- Quote the exact span that failed. If you cannot quote a span, it passes.
- Do not suggest a rewrite. You are measuring, not helping.

OUTPUT: JSON only.
{"case_id": "...", "tone": "pass|fail", "policy": "pass|fail",
 "false_claim": "pass|fail", "verdict": "pass|fail", "reason": "<one sentence, with the quoted span>"}

POLICY EXTRACT:
<paste>

BOOKING DATA:
<paste>

PASSENGER REQUEST:
<paste>

AGENT MESSAGE:
<paste>

I have <n> cases the judge scored, and the same <n> cases relabelled blind by a
person. Compare them.

OUTPUT:
1. Agreement: matches / n, as a percentage, with its 95% lower bound. Use the Wilson
   interval if n is under 100, and say which interval you used.
2. A confusion breakdown: judge-fail/human-pass and judge-pass/human-fail, separately.
   These are different problems: the first wastes engineering time, the second ships.
3. For every disagreement, which criterion it turned on.
4. Whichever criterion accounts for the most disagreements: the sentence the rubric is
   missing, written as a rubric line I can paste.

RULES:
- Do not average the two directions of disagreement into one accuracy figure.
- If the lower bound is below <the level I would accept in a checker>, say plainly that
  the judge is not yet fit to sit under a gate and how many more labelled cases it needs.

JUDGE VERDICTS:
<paste>

HUMAN LABELS:
<paste>

Write the specification for an evaluation harness that runs in CI.

The order is fixed and is part of the spec:
build -> exact checks -> golden run on the touched slices -> independent judge ->
score per slice against the bar sheet -> merge or reject.

It MUST:
- exit non-zero if ANY slice's lower bound is below that slice's bar, whatever the
  overall number is
- exit non-zero on a case with no slice tag, a slice with no bar, or a slice with no cases
- run only the touched slices on a pull request, and the full set nightly
- run ALL slices when the diff touches the prompt, the tool definitions or the context layers
- emit one machine-readable report with, per slice: score, n, lower bound, bar, verdict
- print no overall number above the per-slice table

It MUST NOT:
- call the judge before the exact checks
- pass on a warning
- read a threshold from anywhere except <the bar sheet file>

OUTPUT: the spec as numbered requirements, then the command surface (what I run locally
and what CI runs), then the failure modes and the exit code for each.

Our slices: <list>. Our bar sheet lives at: <path>.

Write the gate script for our harness.

INPUT: a report JSON of {"<slice>": {"right": <int>, "n": <int>}} and a bars JSON of
{"<slice>": <bar as a fraction>}.

For each slice compute score, the 95% lower bound (Wilson below n=100, normal above),
and a verdict of PROVEN / UNPROVEN / FAILED:
- PROVEN   lower bound >= bar
- FAILED   score <= bar
- UNPROVEN otherwise, and report the extra cases owed:
           n_needed = 1.96^2 * p * (1-p) / (p - bar)^2

RULES:
- Exit 1 if any slice is not PROVEN. Exit 2 on a malformed report, an untagged case, a
  slice with no bar, or a slice with n = 0: a configuration failure must not look like
  a content failure.
- Print the per-slice table first. Do not print an overall number at all.
- No network calls, no model calls.

Then write the tests that prove it: one fixture that exits 0, one that exits 1 because a
small slice fell below its bar while the overall number rose, and one that exits 2.

Show me the script and the tests before you run them.

Compute what our harness costs to run, and the cheapest schedule that keeps the gate honest.

INPUTS:
- cases per slice: <paste>
- judged cases cost $<n> each; exact checks cost nothing
- pull requests per day: <n>
- the touched slice averages <n> cases

Compute:
1. Cost of one full judged run.
2. Cost per day if the full set runs on every pull request.
3. Cost per day of: one nightly full run + the touched slice on every pull request.
4. The ratio of 3 to 2, and the monthly difference at <n> working days.

Then tell me the ONE schedule change that would save the most without weakening the gate,
and the one that would look like a saving and would actually weaken it. Show the arithmetic
for each line.

Turn this evaluation output into a behaviour-gate readout.

OUTPUT: one table, and nothing above it.
| Slice | Score | n | 95% lower bound | Bar | PROVEN / UNPROVEN / FAILED | Cases owed |

RULES:
- lower bound = p - 1.96 * sqrt(p*(1-p)/n). Under n = 100 use the Wilson interval instead,
  and mark which rows used which.
- PROVEN only when the LOWER BOUND is at or above the bar. Never the point estimate.
- FAILED when the score itself is at or below the bar: no sample size fixes that.
- UNPROVEN otherwise. Cases owed = 1.96^2 * p * (1-p) / (p - bar)^2, minus the cases held.
- Flag any slice that got WORSE than the previous run, even where it still passes.
- Do NOT compute an overall number. If I gave you one, ignore it.

Finish with one sentence: ship or do not ship, and the single reason.

BARS: <paste the bar sheet>
RESULTS: <paste>

<Slice> scores <p>% on <n> cases against a bar of <bar>%. It is unproven.

Price all THREE routes to proven, using these formulas, and show the arithmetic:

1. COLLECT CASES
   cases needed = 1.96^2 * p * (1-p) / (p - bar)^2
   days = (cases needed - cases held) / <real cases of this slice available per day>

2. RAISE THE SCORE
   For each of +1, +2 and +5 points of score, recompute cases needed and the days.
   Say plainly how the score would have to be raised, or say you cannot tell.

3. LOWER THE DAMAGE WITH A HOLD
   bar = N / (N + 1) where N = damage / saving. Recompute the bar for a damage of
   <damage with a named approver>. Then say whether the CURRENT score, at the CURRENT n,
   clears the new bar (lower bound, not point estimate).

OUTPUT: a three-row table of route, cost, elapsed days, and what it gives up. Then name
the route you would take and the one assumption that would change your answer.

Build an injection test matrix for an agent.

INPUTS:
- entry points, meaning every place the agent reads text it did not write: <list>
- gated tools, meaning everything that moves money, changes an identity or makes a
  commitment: <list>
- the agent's job, in one line: <paste>

OUTPUT, in this order:
1. A payload table: id, the string, the technique it uses, and which entry point it is
   most natural in. Cover at least: direct instruction, forged system turn, delimiter
   break, claimed authority, instruction split across two fields, instruction inside
   otherwise useful content.
2. The full cross product as a count, and the ONE parametrised test that covers it.
3. For each case, the two assertions: which tool must NOT be called, and what trace
   event must be present.

RULES:
- Never assert on the model's reply text. Assert on tool calls and trace rows only.
- Do not skip an entry point because it "comes from a trusted partner". It does not.
- Flag any gated tool that no payload plausibly targets, because that is either a gap
  in the payloads or a tool that should not be gated.

Here is an incident write-up. Turn it into regression cases for our injection suite.

OUTPUT:
1. The payload, reconstructed as a string I can put in the payload file, with every
   customer identifier removed.
2. The entry point it arrived through, and the other entry points the same payload
   should now be tried from.
3. For each case: the tool that must not be called, and the trace event that must exist.
4. The one case that would have gone RED the week before the incident, if we had had it.

RULES:
- Do not name a person and do not include the real booking reference.
- If the write-up does not say which entry point the text came in through, say so: that
  is a gap in the trace and it is a finding in its own right.
- Write the cases as data, not as prose.

INCIDENT:
<paste>

Here is my injection suite. Find the tests that would pass even if the system were
broken.

For each test, answer:
1. Could this pass because the agent failed for an UNRELATED reason: a timeout, a tool
   that was not registered, an empty input, a booking that does not exist?
2. Does it assert on the model's wording anywhere, directly or through a helper?
3. Does it assert BOTH that the action did not happen AND that the attempt was recorded?
4. If the gated tool were renamed tomorrow, would this test go red, or silently green?

OUTPUT: a table of test, weakness, and the exact assertion to add. Then the single test
you would delete because it proves nothing.

SUITE:
<paste>

Write the specification for a nightly job that compares an agent's shadow decisions
against the live human desk.

It MUST output, PER SLICE and never only overall:
- decisions compared, agreed, agreement %
- a ranked list of disagreements: the input, the agent's decision, the desk's decision,
  and the estimated cost of the difference
- a flag on any slice whose agreement fell against the previous night
- the count of decisions per slice, so a slice with too few is reported as UNPROVEN
  rather than as a percentage

CONSTRAINTS:
- money actions are reported separately and NEVER counted toward automatic agreement
- the agent must not write: include an assertion that FAILS the job if any write call is
  detected from the shadow path, and say where that assertion runs
- the window is fixed in advance; the job must record the window it belongs to
- output is one markdown file and one CSV

Our slices: <list>. Our decisions are logged at: <where>. Cases per day: <n>.

Here are <n> cases where the agent and the human desk disagreed.

1. Cluster them into at most 6 themes. Name each in plain words, no jargon.
2. For each theme, mark it AGENT RIGHT / DESK RIGHT / GENUINELY AMBIGUOUS, with the
   reason. Do NOT treat the desk as ground truth: say so when the desk was wrong.
3. Rank the themes by the estimated cost of being wrong, not by how often they occur.
4. For each theme, say what it changes: a golden case, a rubric line, a spec defect,
   or nothing.
5. For the GENUINELY AMBIGUOUS pile, write the rubric sentence that would settle each
   one. That pile is rubric work, not defects.

OUTPUT: the table, then the five golden cases I should add first.

DISAGREEMENTS:
<paste>

Compute how long live evidence takes to arrive, per slice and per traffic share.

cases needed = 1.96^2 * p * (1-p) / (p - bar)^2
days = cases needed / (traffic share x cases per day)

For each slice give me: cases needed, then days at 5%, 25% and 100%.

Then:
- Flag every slice where 5% would take more than 30 days. Those need a larger starting
  share or a hold that lowers the bar, and I need to know now rather than in week five.
- Write the schedule as CONDITIONS, never dates: "widen to 25% when the live lower bound
  on <slice> holds at or above <bar> for <n> consecutive days".
- State plainly which slices will never accumulate enough live cases at any share, and
  what that means for them.

Show the arithmetic for one slice so I can check it.

SLICES, SCORES, BARS, TRAFFIC SHARE PER SLICE, CASES PER DAY:
<paste>

Build this week's drift readout from the trace at <path>.

For each output mix I name, report:
- this week's share, last week's share, and the week-over-week step in percentage points
- the share at the frozen baseline of <date>, and the gap against it in points
- whether either threshold is breached: 5pp week over week, or 6pp against baseline

RULES:
- Read the trace, not the application logs. Say which fields you used.
- Normalise by volume: a mix moving because total volume halved is a different finding,
  and I want it called out separately.
- Do NOT smooth the series. Smoothing is how a slow slide becomes invisible.
- If a week has fewer than <n> decisions, report it as thin rather than as a percentage.

OUTPUT: the table, then a one-line verdict per mix, then, if anything breached, the
sentence I will send to re-open the release gate.

MIXES TO WATCH: <list>.

Turn this incident into a missing-control postmortem. Use EXACTLY this structure
and do not add sections.

1 · THE QUESTION: which ENFORCED control would have made this impossible?
2 · LAYERS: one row per layer the design CLAIMED to have.
    | Layer | Claimed | enforced / a request / absent | Would it have stopped it? |
3 · FIX: for each proposal, does it CLOSE THE PATH or LOWER THE PROBABILITY?
4 · AUTONOMY: level now, level after, and the condition that restores it.
5 · FEED FORWARD: golden cases, injection payloads, the decision record to amend,
    and the five-part P0 brief (pain · evidence · finding · fix · value).

RULES:
- Do not name a person. Do not quote the input that triggered it.
- A rule that exists only in a prompt is A REQUEST, never enforced. Apply this without
  exception, including where the prompt is very clearly worded.
- Two layers that fail together count as ONE layer. Merge them and say so.
- An alert is detection, not prevention. Mark it as such and keep it in the table.
- If NO layer would have stopped it, say that in one sentence rather than softening it.

INCIDENT:
<paste>

Write the golden cases this incident owes. Six is the working default.

For each case output one JSON line with: id, slice, source (the incident id), input
(redacted), expect (action + reason code), and a note saying what it protects.

Cover, at minimum:
- the exact case that happened, with every identifier removed
- the same case just under the cap, and just over it
- the same case with the confirmation absent
- the same attempt arriving through a DIFFERENT entry point
- the case that would have been the near miss nobody reported

RULES:
- The expected outcome is a refusal or an escalation with a REASON CODE. Never
  "behaves sensibly" and never a sentence of prose.
- Tag every case with the slice whose bar it belongs to. If it belongs to no existing
  slice, say so: the incident may have revealed that the slice list is wrong.
- Do not invent facts the write-up does not contain. Mark them <unknown>.

INCIDENT AND FIX:
<paste>

You are writing the baseline infrastructure for a new agentic feature. Nothing
exists yet.

Produce ONE CloudFormation template (or a CDK stack, if this repository already has
one) that creates only the cost baseline: the budget, its alarm path, and the
parameters everything else will inherit. No workload resources.

RULES:
- A FORECASTED notification as well as an ACTUAL one. Put the reason in a comment.
- Every resource carries Feature, Environment, Owner, CostCentre. Feature is the cost
  boundary and it is never a team name.
- No hard-coded account id, region or ARN partition. Parameters or pseudo-parameters.
- Run cfn-lint (or cdk synth) yourself. Do not hand me a template you have not linted.

OUTPUT SHAPE: the template, then the lint output, then the exact deploy command for
<environment>, then a list of anything you had to assume.

OUR BOUNDARIES:
<paste: accounts, regions, who pays, the residency answer, who gets the alert>

Audit this account for resources that bill for EXISTING rather than for use.

Look for at least: classic OpenSearch Serverless collections, AgentCore Runtime instances,
long-term memory stores, provisioned throughput, NAT gateways, idle load balancers, allocated addresses, unattached volumes,
old snapshots.

OUTPUT SHAPE - one table, sorted by monthly cost, highest first:
| Resource | Type | Created | Last used (or "unknown") | Feature tag? | ~$/month | Safe to delete? |

RULES:
- READ ONLY. Do not delete, stop or modify anything, and do not write me a script that
  can. Use read-only calls.
- "Safe to delete" is a question for a human. Write UNKNOWN unless there is evidence in
  the account itself, and say what the evidence was.
- List separately every resource with no Feature tag. That list is the real finding.
- Finish with the one resource I should deal with today, and why it is that one.

ACCOUNT AND SCOPE: <paste the profile, the regions, and anything already known to be
deliberate>

Review this tag scheme against the only four questions it will ever be asked.

THE QUESTIONS:
1. What did <feature> cost last month, across every service?
2. Which resources belong to an environment we are about to destroy?
3. Who do I call about this resource at 02:00?
4. Which resources are billing with no owner at all?

RULES:
- Judge each tag only by whether it serves one of those four. Do not add tags for tidiness.
- Flag any tag whose value changes when the org chart changes. Those cannot answer
  question 1 for any month before the change.
- Say which keys must be activated as cost allocation tags in the payer account, and
  state plainly what happens to the months before activation.

OUTPUT SHAPE: keep / change / drop per tag, one line of reasoning each. Then the four
questions with "answerable: yes/no" against your revised scheme.

SCHEME: <paste>

You are helping a platform engineer establish which Bedrock models this account
can actually invoke, before anyone designs around one.

Write and run a script that, for every (model, region) pair below:
- calls with the BARE model id first, then with the inference profile id carrying the
  geography prefix for that region (us. / eu. / apac.)
- records the exact error class for each attempt

OUTPUT SHAPE - one table and nothing else:
| Model | Region | Bare id | Profile id | Verdict | Error |

Verdict is exactly one of: GRANTED / NOT GRANTED / PROFILE REQUIRED / QUOTA / UNKNOWN.

RULES:
- max_tokens = 1 and a one-word prompt. A probe that writes a paragraph per pair is a
  bill of its own.
- Do not retry on a throttle. Record QUOTA and move on.
- Create, modify and delete nothing. Read and invoke only.
- Show me the script before you run it.

PAIRS: <paste model ids and regions>

Write a LiteLLM proxy config from the access matrix below.

RULES:
- Every `model` string must be an inference profile id whose geography prefix matches
  its region. If a row in the matrix gives only a bare id, stop and tell me which row.
- Name models by ROLE, not by vendor: `judge` (capable tier), `classify` (cheap tier),
  plus a same-geography twin of each for fallback.
- Fallbacks never cross a residency boundary. Put the reason in a comment on each.
- num_retries capped, with a comment stating the worst-case cost multiplier it implies.
- success_callback and failure_callback on every call, not a sample.
- No secret values anywhere. Environment references only.

OUTPUT SHAPE: the YAML, then a short checklist of what I must verify before deploying,
then the one grep command that proves no bare model id got through.

MATRIX: <paste>

A Bedrock call is failing. Work through these IN ORDER and tell me which it is,
with the single command that confirms or eliminates each:

1. The model access grant is missing in THIS region (it is per model, per region)
2. The call used a bare model id where an inference profile id is required
3. The IAM policy does not allow that action on that resource
4. A quota: requests or tokens per minute for this model in this region
5. Something else - say precisely what

RULES:
- Do not suggest widening an IAM policy until 1 and 2 are both ruled out.
- Do not suggest a retry as a fix for anything.
- Quote the part of the error that distinguishes your answer from the next candidate.

End with the one-line change that fixes the most likely cause, and how I will know.

ERROR, VERBATIM, plus the call site and region:
<paste>

Redact this production export so it can be used as evaluation seed data.

RULES:
- MASK, never drop. Preserve type, length class and format: a 16-digit card becomes
  ************4471, an email becomes a****@e******.com, a date keeps its shape.
- Keep the mess. Typos, truncation, mixed casing, empty fields and duplicate records
  are the distribution. Do not clean anything.
- Free-text fields are the hard part. List every one and tell me what you found in it,
  rather than deciding for me whether it is safe.
- Do not invent rows and do not drop rows. The row count must match exactly.

OUTPUT SHAPE:
1. The redaction script.
2. A MANIFEST: one row per field - name, classification, what was done to it, and an
   example before/after using synthetic values, never real ones.
3. A list of fields you were unsure about, with the question you need answered.

The manifest is what a human signs. Write it for that reader.

SCHEMA / SAMPLE: <paste>

Compare these two environment manifests.

OUTPUT SHAPE - one table:
| Field | <env A> | <env B> | Intended difference? | Could it change behaviour? |

RULES:
- Report EVERY difference, including ones I did not ask about and ones that look
  cosmetic. Whitespace and ordering can be excluded; nothing else can.
- Put model version, judge version, temperature, max_tokens, tool list and the caps at
  the TOP of the table regardless of file order. Those are the behaviour-bearing ones.
- For any field that is a floating alias rather than a pinned version, say so loudly
  and separately. That is the finding, not a row.
- Finish with: the one difference most likely to explain a score gap between these two
  environments, and the command that would confirm it.

MANIFEST A: <paste>
MANIFEST B: <paste>

Write the change record for upgrading <feature> from <model version A> to
<model version B>. Treat it as a deployment, not a configuration tweak.

It must state:
1. Which environments change, in what order, and what gates between them.
2. What re-runs: the full golden set, the judge calibration set, the injection suite.
   Give the expected cost and wall-clock time of that run.
3. What the rollback is, exactly - which file, which command, and how long it takes.
4. Which slices are most likely to move, and why. Be specific about the slice, not
   about the model.
5. What evidence would make us abandon the upgrade rather than debug it.

RULES:
- Do not claim the new version is better. That is what the harness is for.
- "It should be a drop-in" is not an entry in this document.

CONTEXT: <paste the current manifest, the slice list and the last harness readout>

Build the map from repository paths to evaluation slices, so a pull request runs
only the slices it could have affected.

OUTPUT SHAPE - a committed YAML file:
  slices:
    <slice-name>:
      paths: [<glob>, <glob>]
      cases: <path to the case file>
      bar: <n>
  always_full: [<globs that force the FULL set>]

RULES:
- Anything under the prompts directory, the model pin in any environment manifest, the
  judge prompt, or the harness itself goes in always_full. Those touch every slice.
- When a path could belong to two slices, put it in BOTH. Over-running costs money;
  under-running costs a gap in the gate that produces no signal.
- List any path that maps to no slice at all. That list is the gap, and I need it
  explicitly rather than by inference.

Then write the script that resolves a git diff to a slice list, and a test that proves
a change to a prompt returns "all".

OUR SLICES AND LAYOUT: <paste the tree and the slice names>

Write the gate step that turns harness output into a decision.

OUTPUT SHAPE - a markdown job summary, in this exact order:
| Slice | Score | n | 95% lower bound | Bar | PASS / FAIL / UNPROVEN |
then one line: SHIP or DO NOT SHIP, and the single reason.

RULES:
- lower bound = p - 1.96 * sqrt(p*(1-p)/n). Compute it even when only the score was given.
- PASS only when the LOWER BOUND is at or above the bar. Score above the bar with the
  lower bound below it is UNPROVEN, and you must say how many more cases are needed:
  n = 1.96^2 * p * (1-p) / (p - bar)^2.
- Exit non-zero on any FAIL. UNPROVEN does not block, but it is reported at the top.
- Flag any slice that got worse than the previous run even if it still passes.
- Print the cost and wall-clock time of the run as the last line. People need to see it
  to keep believing in it.

Show me the lower-bound function and its unit test first; I want to check that by hand.

HARNESS OUTPUT FORMAT: <paste a sample>
BAR SHEET: <paste>

Work out what this pipeline will cost to run, so the number arrives before the
first invoice rather than after it.

Compute and show the arithmetic for:
1. Cost and wall-clock time of ONE full golden-set run, cold cache.
2. The same, warm cache, with the cache hit ratio you expect and why.
3. Cost per pull request at the average touched-slice size.
4. Monthly total at <n> pull requests per day plus one nightly full run.
5. The crossover: at how many pull requests per day does the nightly run stop being
   the dominant cost?

RULES:
- Use the gateway's actual price table, not a remembered figure. Say where you got it.
- Show cached and uncached input tokens as separate terms.
- Give me the single cheapest change that halves number 4, and what it costs in coverage.

INPUTS: <golden set size, tokens per case, model prices, PR volume>

Write the control that makes "shadow never writes" true rather than intended.

Produce TWO things:
1. A harness assertion: run the full golden set with the flag in shadow and fail the
   build if any write tool is reached. It must detect the call at the tool boundary,
   not by inspecting the output.
2. A scheduled production canary: read the LIVE flag state, and if any action is in
   shadow, assert no write has been recorded for that action in the last hour. Page on
   failure.

RULES:
- Test at the boundary the agent actually crosses. A test on a mock passes forever.
- Two places, because the flag can be changed outside a deployment and often is.
- The canary must fail loudly when it cannot read the flag state. Unknown is not pass.
- Include the test that proves the test works: force a write and show both fail.

OUR WRITE TOOLS AND FLAG SOURCE: <paste>

Write the change record for this prompt change. Treat it as a deployment.

It must state:
1. The diff, and in plain words what behaviour is intended to change.
2. Which slices are expected to move, in which direction, and by roughly how much.
3. What runs before merge: the full golden set, the judge calibration set, the
   injection suite. Give the cost and wall-clock time.
4. The version identifier that ships (a hash, not "latest"), and where it is stored.
5. The rollback: which command, which previous version, how many seconds.
6. What in the trace will tell us afterwards which version decided a given case.

RULES:
- "Minor wording change" is not an entry. Every wording change is a behaviour change
  until the harness says otherwise.
- If the change is intended to fix a specific failing case, say which, and say what
  stops it from over-fitting to that case.

PROMPT DIFF: <paste>

Plan the canary for <action>, as a config, not as a narrative.

OUTPUT SHAPE:
| State | Share | Entry condition | Exit condition | Who decides | Rollback time |
for each of: shadow, 5%, <n>%, 100%.

Then the AUTOMATIC rollback: the metric, the threshold, the evaluation window, and
what it rolls back TO (a state, not "the previous version").

RULES:
- Every entry condition is evidence, never a date.
- Every state has an owner who can move it without an approval chain.
- Automatic rollback triggers must be things that cannot be explained away at 02:00:
  cost per case, error rate, cap trips, a write while in shadow.
- Say explicitly which actions never enter this ladder because they are gated.
- Give me the single condition most likely to be argued with, and rewrite it so it
  cannot be.

CONTEXT: <slices, bars, cases per day, current flag states>

Design the trace row by working backwards from the incident.

THE INCIDENT I must be able to explain twelve weeks later:
<paste: e.g. "the agent issued a refund above the cap and nobody knows how">

1. List every question an incident reviewer, a regulator and a finance analyst would
   each ask about that case.
2. For each question, name the field that answers it.
3. Produce the schema: field name, type, masked or plain, retention, and WHICH of the
   questions it exists for. A field that answers no question comes out.
4. Mark every field that carries personal data and state how it is masked. MASK, never
   omit - say what shape survives masking and why that is enough to reconcile.

RULES:
- No field exists "just in case". Each one is justified by a question.
- If a question cannot be answered by any field, say so plainly. That gap is the output
  I am looking for.
- Include model version, prompt version, flag state, the cap that applied and the
  approver. If you think any of those is unnecessary, argue for removing it explicitly.

Turn this threshold table into CloudWatch alarms as infrastructure as code.

ALARMS REQUIRED, at minimum:
- Cost per case above 3x the estimate, sustained for 1 hour
- Loop-cap trips per hour above <n> (the cap is doing work that should not be needed)
- Cache hit ratio below <n>% over 6 hours (a prompt prefix changed and every call is
  now full price)
- Output mix moved more than 5 percentage points week over week

RULES:
- State the statistic, period, evaluation periods, datapoints-to-alarm and
  treat-missing-data for each, and justify each choice in a comment.
- No alarm on a one-minute period over sparse traffic. Say what our traffic actually is
  and size the window to it.
- Every alarm names what the responder should DO. An alarm with no action is a chart.
- The drift alarm must trigger the release-gate re-open, not just a notification. Show
  how that is wired.

OUR THRESHOLDS AND TRAFFIC: <paste>

Here is our observability setup: <paste dashboards, metrics, alarms, trace schema>.

Answer only this: which of these questions can it NOT answer, and what is missing?

1. What did case <id> cost, and was any of it a cache hit?
2. Which model version and prompt version decided case <id>?
3. Has the mix of outcomes changed this week versus last?
4. How many cases hit the loop cap yesterday, and did they end at the desk?
5. Which slice is getting more expensive per case, month over month?
6. Did anything write while an action was in shadow?
7. Who approved the last twenty gated actions?

OUTPUT SHAPE:
| Question | Answerable now? | What is missing | Cost to add |

RULES:
- "It is in the logs somewhere" is a NO. Answerable means one query.
- Rank what is missing by what it would cost us during an incident, not by effort.

Derive the least-privilege execution role from these tool contracts. Work from the
contracts to the policy, never the other way round.

OUTPUT SHAPE:
1. A table: | Tool | AWS actions it needs | Exact resource ARNs | Read or write? |
2. TWO policies: a read identity and a write identity. Nothing appears in both.
3. Every statement carries a Sid naming the tool it serves.
4. A list of every action currently in our role that maps to NO tool. That list is
   what comes out.

RULES:
- No wildcards in Action or Resource unless the API genuinely has no resource-level
  permission. Where that is true, say which API and cite it, and add a Condition.
- A Deny statement for any region outside <allowed regions>, on aws:RequestedRegion.
- Do not add a permission because a test failed. Report the denied action instead.
- Run IAM Access Analyzer policy validation and paste the findings.

TOOL CONTRACTS: <paste>
CURRENT POLICY: <paste>

Write the injection test suite for our harness. Every ingested text is untrusted,
including responses from partners we have contracts with.

Produce cases in these classes, at least three each:
- A partner API response with an instruction inside a free-text field (remarks, notes,
  reason codes)
- A passenger message impersonating the desk, an internal system, or a policy update
- A document with hidden or out-of-band text (white text, metadata, alt text)
- A retrieved index chunk that contains instructions
- A tool error message crafted to redirect the agent

FOR EACH CASE: the input, what the attacker is trying to make happen, the assertion
that must hold.

RULES:
- The assertions are about ENFORCED controls, not about wording. "The refund amount
  never exceeds the cap", "no write tool is called while in shadow", "no request leaves
  the egress allowlist". An assertion about the model's phrasing is not a test.
- At least one case must succeed at manipulating the model and still be contained by
  the cap. That case is the point of the whole suite.
- The suite fails the build. It does not warn.

OUR TOOLS, CAPS AND INGESTION POINTS: <paste>

Compare what this role is ALLOWED to do against what it has actually done.

Use CloudTrail for the last <n> days plus IAM Access Analyzer unused-access findings.

OUTPUT SHAPE:
| Action | Allowed on | Times used | Last used | Verdict |
Verdict: KEEP / NARROW TO <arn> / REMOVE / TOO NEW TO JUDGE.

RULES:
- READ ONLY. Produce the proposed policy as a diff; change nothing.
- An action used zero times is not automatically REMOVE - some are for failure paths
  that have not fired. Mark those TOO NEW TO JUDGE and say what would exercise them.
- Report every AccessDenied separately, with the caller and the time. Each one is
  either a missing permission or an attempt, and I need to know which you think it is.
- Finish with the single narrowing that most reduces blast radius, and what would
  break if it is wrong.

Turn this rollback runbook into a script, then into a rehearsal.

PART 1 - the script. One subcommand per switch: kill, flag, prompt, model.
RULES:
- Each subcommand prints exactly what it will change and requires a typed confirmation.
- Each is idempotent and safe to run twice.
- Each ends by printing the check that proves it worked, as a command I can paste.
- Fail loudly on a missing argument. Never guess a version.

PART 2 - the rehearsal plan.
- Who runs it (the person who will do it at 02:00, not the person who wrote it).
- Which environment, and what makes that environment realistic enough to count.
- What is timed, and where the measured times get written down.
- What would make us say the rehearsal FAILED, decided before we run it.

RULES:
- Do not write a step that says "verify the system is healthy". Say which metric,
  which query, which value.
- If any switch cannot be scripted, say so and explain what makes it manual. That is
  the finding, and it is worth more than a script that pretends.

RUNBOOK: <paste>

Design the containment caps for this agent, and the tests that prove each one.

CAPS REQUIRED:
- MAX_LOOPS (default 5): the agent stops rather than reasoning in circles
- Tokens per case
- Cost per case
- Wall-clock per case

FOR EACH, give me:
1. Where it is enforced. It must be in the runtime, not in the prompt. Say which line.
2. What happens when it trips: the case goes to the desk queue WITH its context, a
   metric is emitted, and the passenger sees something sensible. Never a bare error.
3. The test that proves it: a case engineered to hit that cap, asserting the stop, the
   metric and the destination.
4. How the threshold was chosen, and what evidence would change it.

RULES:
- A cap that trips silently is not a cap. Every trip emits a metric with the case id.
- Say what the caps cost us: which legitimate cases they will refuse, and roughly how
  many per week. If you cannot estimate that, say what to measure first.

OUR AGENT AND ITS TOOLS: <paste>

Given this architecture, tell me what cannot be rebuilt from the repository.

OUTPUT SHAPE:
| Thing | Rebuildable from the repo? | If lost, what breaks | RPO | RTO | Restore test |

RULES:
- Be specific about the ones people forget: the trace store (the only account of what
  happened), the golden set and its labels (the measurement itself), the vector index
  AND the source documents it was built from, the flag configuration history, the
  redaction manifests.
- For the vector index, say whether we can rebuild it and what that costs in time and
  tokens. "We can re-embed" is only true if the sources are retained - check.
- Anything marked rebuildable must have the command that rebuilds it. If nobody has
  run that command, mark it UNPROVEN.
- Finish with the single restore we should test this quarter, and why that one.

ARCHITECTURE: <paste>