Prompts we actually use, with the variables left in.

Here are three samples of my writing, delimited by ---.
Analyse them and produce a voice profile: sentence length, vocabulary level, rhythm, recurring structures, and three habits to avoid.
Then rewrite the target text to match that profile exactly. Do not add new claims.

Samples:
---
{{samples}}
---

Target text:
{{text}}

You are an editor. From the brief below, produce an outline with:
- a working title
- the single question the piece answers
- 4-6 section headings, each with the one claim it makes
- where each supplied example belongs
- one section you recommend cutting, and why

Do not write prose. Brief:
{{brief}}

Write 10 headlines for the article below. Use a different angle for each: contrarian, how-to, number-led, question, outcome, warning, comparison, definition, story, and plain-descriptive.
Label the angle. Max 12 words each. No colons, no "ultimate guide", no exclamation marks.

Article summary: {{summary}}
Audience: {{audience}}

Rewrite the text below for a smart reader outside the field.
Rules: keep every technical fact exact; define a term the first time it appears in six words or fewer; remove filler and hedging; keep paragraphs under four sentences.
Return the rewrite, then a list of terms you defined.

Text:
{{text}}

Write a production system prompt for the capability below, using exactly these sections:
1. Role and scope (including what it is NOT for)
2. Inputs and missing-field handling
3. Rules, numbered, where a higher number wins on conflict
4. Output contract (exact format)
5. Refusal and escalation cases
6. Two examples, one of them an edge case

Capability: {{capability}}
Consumer of the output: {{consumer}}

Audit the prompt below. Report:
- instructions that cannot be objectively checked
- contradictions or unresolved conflicts
- missing output contract details
- missing behaviour for absent or malformed input
- instructions that duplicate each other

Then return a rewritten version that fixes each item, and a changelog of what you changed and why.

Prompt:
{{prompt}}

Design a 30-case evaluation set for the task below.
Cover: 18 typical cases, 8 edge cases, 2 malformed inputs, 2 that must be refused.
For each case give: id, input, expected output or acceptance criteria, and the failure mode it probes.
Return as a markdown table.

Task: {{task}}
Output contract: {{contract}}

Review the diff below against this rubric, in order of severity:
1. Correctness and data loss
2. Security and authorisation
3. Error handling and edge cases
4. Performance at expected scale
5. Readability and naming

For each finding: severity, file and line, why it matters, and the concrete fix.
Say "no findings" for a clean category rather than inventing nits.

Diff:
{{diff}}

Given the symptoms, logs, and relevant code below, list the five most likely root causes.
Rank by probability. For each: the mechanism that would produce these exact symptoms, the cheapest test that confirms or eliminates it, and what the test would show.
Do not propose a fix until a cause is confirmed.

Symptoms: {{symptoms}}
Logs: {{logs}}
Code: {{code}}

Plan a refactor from the current state to the target state below.
Break it into steps that each keep the test suite passing and can ship independently.
For each step: what changes, what stays temporarily duplicated, the risk, and the rollback.
Flag any step that cannot be made backwards compatible.

Current: {{current}}
Target: {{target}}

Read the sources below, each numbered.
Produce: a synthesis of what they agree on, an explicit list of disagreements with the source numbers on each side, and the questions none of them answer.
Cite source numbers inline. Never assert anything that is not in a source.

Sources:
{{sources}}

List the assumptions the argument below depends on, separating stated from unstated.
For each: how load-bearing it is (the argument fails without it, weakens, or is decorative), and how it could be tested with data you could realistically obtain.

Argument:
{{argument}}

Using only the material supplied below, produce a teardown of {{company}}:
positioning in one sentence, target segment, core value claim, pricing model, three visible strengths, three visible gaps, and what their messaging avoids talking about.
Mark anything you are inferring as an inference.

Material:
{{material}}

I am new to {{topic}}. Produce:
- the 6 concepts I must understand first, each in two sentences
- the main schools of thought and what they disagree about
- 5 terms that mean something different here than in everyday use
- the 3 questions a practitioner would ask to test whether I understand it

No preamble.

Turn the notes below into a spec with: problem, who has it and how often, success metric, in scope, explicitly out of scope, user flows as numbered steps, edge cases, and open questions.
Put anything ambiguous under open questions rather than guessing.

Notes:
{{notes}}

Cluster the feedback items below into themes.
For each theme: a name, how many items it covers, two verbatim quotes, the underlying need, and the severity for the user.
List unclusterable items separately rather than forcing them into a theme.

Feedback:
{{feedback}}

The scope below is too large for {{timeframe}}.
Propose three versions: the smallest thing that still tests the core bet, a middle version, and the full scope.
For each: what is included, what is deferred, what you learn, and what risk you accept by cutting.

Scope:
{{scope}}

Write release notes for the commits below, for a non-technical user.
Group as: New, Improved, Fixed. One line each, describing the user-visible change and not the implementation.
Omit internal refactors entirely. No version numbers of dependencies.

Commits:
{{commits}}

Extract data from the text below into exactly this JSON schema:
{{schema}}

Rules: return JSON only, no preamble or code fences. Use null for any field not stated in the text — never infer. If the text contains conflicting values, use the most specific one and add the other to a "conflicts" array.

Text:
{{text}}

Given the schema below, write a single SQL query answering the question.
Before the query, list any assumption you had to make about grain, joins, timezone, or null handling.
After the query, state what the result set means, one row at a time.
Use CTEs over nested subqueries.

Schema:
{{schema}}
Question: {{question}}

A metric moved: {{metric}} changed from {{before}} to {{after}} over {{period}}.
List the possible explanation classes: measurement change, composition or mix shift, seasonality, upstream product change, external event, and genuine behaviour change.
For each, the cut of the data that would confirm or rule it out.
Do not name a single cause until the cuts are checked.

Write a dataset card for the sample and description below: what each column means, units, grain, known nulls and their meaning, collection method, time coverage, three ways it could mislead an analysis, and the questions it cannot answer.
Flag anything you could not determine from the material.

Description: {{description}}
Sample rows: {{sample}}

I want an agent that does: {{goal}}

Write a specification with:
1. The single success condition, checkable without the model's opinion.
2. The tools it needs, each with name, purpose, inputs, and whether it reads or writes.
3. Hard budgets: max steps, max tool calls, max wall-clock time.
4. The escalation path when it cannot finish.
5. Three failure modes this design is still exposed to.

Do not propose a framework. Keep it to one page.

You are an agent working towards one goal. You act in single steps.

Goal: {{goal}}
Available tools: {{tools}}
Step budget: {{budget}}

Every step, output exactly:
state:
  goal: <restate unchanged>
  done: <completed steps>
  next: <the single next action>
  blocked_by: <null or what is missing>
  steps_used: <n>/{{budget}}
action: <one tool call, or FINISH, or ESCALATE>

Never repeat a tool call that already failed with the same arguments.
If the budget is exhausted, output ESCALATE with what was tried.

Here is a function signature and what it does:
{{signature}}
{{notes}}

Write a tool description for an LLM containing:
- one sentence on what it does
- when to use it, and one line on when not to
- every parameter with type, units, format, and an example
- the success shape and the two most likely failures

Then list three requests where a model might wrongly pick this tool, and add wording to prevent each.

Below is the log of an agent run that went wrong.
Classify the root cause as one of: goal drift, bad tool description, missing tool, unbounded retry, context overflow, or genuine model error.
Quote the exact step where it went wrong.
Then propose the smallest change that prevents it, and say what it would break.

Log:
{{log}}

Task the system performs: {{task}}
Write 12 evaluation cases: 6 typical, 4 edge, 2 adversarial.
For each: the input, the pass criteria in one checkable sentence, and why it is included.
Prefer cases that would fail today over cases that flatter the system.

Old prompt:
---
{{old}}
---
New prompt:
---
{{new}}
---
For each change: what behaviour it is meant to alter, the risk it introduces, and the evaluation case that would catch a regression.
End with a verdict: ship, ship with tests, or revert.

Here is a production prompt:
---
{{prompt}}
---
Split it into blocks and label each: instruction, example, evidence, format contract, or decoration.
Rank blocks by how likely removal is to change output quality.
Return a trimmed version at roughly half the length, plus the list of what you removed and why.

Release or claim: {{release}}
My current stack and constraints: {{context}}

Answer in order:
1. What can now be done that could not before, in one sentence.
2. Does it remove a component I maintain? Change cost or latency by 2x or more? Enable a new user outcome?
3. Verdict: adopt now, test this quarter, or ignore.
4. The single experiment that would settle it, and what result would change my mind.

Flag any claim you cannot verify from the source itself.

Summarise the paper below for a practitioner:
- the problem it addresses in plain language
- the technique, described so I could implement it
- the conditions under which it helped, and where it did not
- what would have to be true for it to help my case: {{context}}
- honest assessment of whether it is worth trying yet

Paper:
{{paper}}

Topic: {{topic}}
Audience: people who build with AI and dislike hype.
Video length: {{minutes}} minutes.

Produce:
- a hook in two sentences that names the problem, not the tool
- the one thing the viewer will be able to do afterwards
- 4-6 beats, each with what is shown on screen and the claim it proves
- the live demo moment and what could visibly go wrong
- a close that points to the written companion piece and the prompt used

No filler segments, no "smash that like button" language.

Video content: {{summary}}

Give 8 title options under 60 characters. For each: the curiosity gap it uses and whether the video actually delivers it.
Reject any title the content does not fully support and say why.
Then give 3 thumbnail concepts: the single focal object, the 3-word text overlay, and the emotion it signals.

Turn the transcript below into an article that stands alone without the video.
Rules:
- keep every technical detail, drop every verbal filler
- convert demonstrations into numbered steps or code blocks
- add headings that describe the claim of each section
- end with the exact prompts or commands used, ready to copy
- do not invent results that were not shown

Transcript:
{{transcript}}

Core topic: {{topic}}

Produce a matched content set:
- one video: angle, hook, and the demo that carries it
- one article: title, the question it answers, and 5 section headings
- three reusable prompts a viewer could copy, with the variables named
- one short-form cut: the 30-second idea that stands alone

Everything must reinforce the same single takeaway. State that takeaway first.

Design a multi-agent system for: {{objective}}

For each agent give: name, single responsibility, tools it owns, and what it must NOT do.
Define the handoff protocol: what one agent passes to the next, in what schema, and who owns the shared state.
Name the conflict-resolution rule for when two agents disagree (e.g. planner outranks executor on scope, executor outranks planner on feasibility).
State the single agent responsible for the final answer and format contract.

Agents available: {{agent_list}}
Constraints: {{constraints}}

You are the router for a multi-agent system. You do not answer requests yourself.

Sub-agents:
{{agent_roster}}

Given the request below, output:
route: <agent name>
reason: <one sentence, the signal that decided it>
fallback: <agent to try if the first fails, or ESCALATE_HUMAN>
confidence: <low|medium|high>

If confidence is low, route to the clarifying-question agent instead of guessing.

Request:
{{request}}

Design a shared scratchpad schema for agents collaborating on: {{task}}

Specify:
- the fields every agent may read
- the fields only the owning agent may write, and who owns each
- how an agent claims a task to avoid two agents duplicating work
- how a stale or conflicting write is detected and resolved
- the maximum scratchpad size before it must be summarised, and who summarises it

Output the schema as a JSON shape with a one-line comment per field.

Convert this tool description into a JSON schema for function calling:
{{description}}

Rules: every parameter has a type, a description with units/format, and required vs optional marked explicitly.
Add an enum wherever the value space is closed.
Add a "dry_run" boolean parameter if the underlying action mutates data.
Return only the JSON schema, then a two-line example call.

Capability to add: {{capability}}

Produce, in order:
1. The tool's function-calling schema (name, description, params, return shape).
2. The system prompt clause that tells the model when to call it and when not to.
3. Three test requests: one that should call it, one that should not, one ambiguous case and how to resolve it.
4. The error the tool should return on invalid input, and the recovery instruction for the model.

Task: {{task}}
Requirements the output must satisfy: {{requirements}}

Step 1: produce a draft.
Step 2: list every requirement above and mark it MET or MISSED against the draft, quoting the exact part of the draft that proves it.
Step 3: if anything is MISSED, revise the draft to fix only those items.
Step 4: return only the final revised output, with no trace of the critique.

System or prompt under test:
{{system_prompt}}

Generate 10 adversarial inputs designed to trigger confident fabrication: missing fields, questions outside its data, plausible-sounding fake entities, and contradictory instructions.
For each, state what a safe response looks like versus a hallucinated one.
Run each input against the system's actual behaviour if provided: {{transcripts}}
Report which inputs produced fabrication and the specific phrase that reveals it.

Agent purpose: {{purpose}}
User interactions happen over: {{cadence}}

Define a memory policy:
- what is worth persisting across sessions vs kept only in-session
- the schema for a persisted memory item (fact, source turn, confidence, expiry)
- how contradictions between a new fact and a stored one are resolved
- what must never be persisted (PII categories, one-off preferences, etc.)
- how a user can see and delete what is remembered about them

Total context budget: {{total_tokens}} tokens.
Components competing for space: {{components}}

Assign each component a token allocation and a priority tier (must-have, should-have, nice-to-have).
State what gets cut first when a single request exceeds budget, in order.
State the rule for truncating retrieved evidence vs truncating conversation history — which goes first and why.
Return the plan as a table: component, tokens, tier, truncation rule.

System prompt to audit:
{{prompt}}

For every distinct block, classify it as: instruction, example, retrieved evidence, formatting rule, or unexplained legacy text.
Flag any block that repeats information already stated elsewhere.
Flag any block you cannot tie to a specific past bug or requirement.
Propose a version with only the blocks that survive this audit, and list what you removed.

Query: {{query}}

Candidates (numbered):
{{candidates}}

For each candidate, score 0-10 on how directly it answers the query (not how related the topic is).
Return a JSON array sorted by score descending: [{ "id": n, "score": n, "reason": "one clause" }].
Penalise chunks that are topically relevant but do not contain the actual answer.

Document type: {{doc_type}}
Sample document: {{sample}}

Propose a chunking strategy: what structural boundaries to split on, target chunk size range, how much overlap (if any) and why, and what metadata to attach to every chunk (heading path, page, section id).
Identify the one failure mode this document type is most prone to (e.g. tables split mid-row, numbered lists losing their intro sentence) and how the strategy avoids it.

The model can call these tools: {{tools}}
Write the error-handling clause for the system prompt covering:
- timeout: retry once with the same args, then escalate
- invalid-argument error: fix the argument if the fix is obvious from context, else ask the user
- not-found result: state it plainly, do not substitute a guess
- rate-limit: wait-and-retry once, then switch to a lower-cost tool if one exists

Return the clause as numbered rules ready to paste into the system prompt.

Task types and volumes: {{task_breakdown}}
Available models and their cost/latency: {{models}}

Propose a routing policy: which task types route to which model by default, the signal used to detect a task type before generation, and the escalation rule for when a cheap-model response fails a confidence or validation check.
State the expected cost saving and the quality risk you are accepting.

System: {{system_description}}

Define a structured log schema for every model call, including: prompt version id, model + params, input hash, token counts, latency, cost, output, and a pass/fail flag from any automated check.
State which fields must be redacted or hashed before storage for privacy.
Propose the one dashboard view you'd check first during an incident, and what it should show.

System prompt and where untrusted content enters it:
{{prompt_and_data_flow}}

Identify every point where user-supplied or retrieved text could contain instructions the model might follow.
For each: the concrete injected string that would test it, and the mitigation (delimiting, instruction hierarchy, output validation, or tool permission scoping).
Rank the findings by what an attacker could actually achieve, not by how clever the injection looks.

Desired output: {{description}}

Write the JSON schema for it, then write a validation function in {{language}} that checks: required fields present, types correct, enums respected, and no extra top-level keys.
State what the calling code should do on validation failure: retry with the error appended to the prompt, or fail closed.

Task: {{task}}

Write the output instructions so the response is useful even if truncated mid-stream: most important information first, self-contained sections, no forward references ("as mentioned below"), and no payload-critical data in the final sentence.
State the section order and why that order is safe under truncation.

Old prompt version: {{old_version}}
New prompt version: {{new_version}}
Diff:
{{diff}}

Write a changelog entry: what changed, why (the failure it fixes or behaviour it adds), the eval delta if known, and the rollback condition — the signal that would tell you to revert this version.

Comparing prompt/model variant A vs B on the same eval set:
{{results_table}}

Write a one-page memo: the tradeoff in plain terms, who is affected by the latency difference, whether the quality gain is inside or outside noise given the sample size, and your recommendation with the one condition that would flip it.

Current implementation: one prompt handling {{task}}.
Symptoms driving the change: {{symptoms}}

Before proposing an agent, check: would a longer single prompt, better context, or a two-step pipeline fix this without a loop?
If a loop is genuinely needed (multi-step tool use, unknown number of steps, need to react to intermediate results), design the minimal loop: exit conditions, step budget, and the one tool that unlocks it.
State explicitly if an agent is overkill here.

Broad question: {{question}}

Decompose it into 4-6 sub-questions that are each independently answerable from a source.
For each sub-question: what kind of source would answer it, and what a good answer looks like.
Flag any sub-question that is really an opinion in disguise and cannot be answered by evidence.

Source: {{source}}
Claim it is being used to support: {{claim}}

Assess: authorship and their incentive, recency relative to the claim, whether it's primary or secondary, and whether the claim in question is actually what the source says or a stretched paraphrase.
Give a verdict: cite directly, cite with caveat, or find a better source — with the specific reason.

My argument: {{argument}}

Write the strongest possible counterargument a smart, informed critic would make — not a weak strawman.
Then say which parts of my argument survive it unchanged, which need a caveat, and which do not survive at all.
Do not soften the counterargument to make my position look better.

Topic: {{topic}}
What I'm trying to learn: {{goal}}

Write 8 interview questions: open-ended, no leading language, ordered from general to specific.
For each, note the follow-up you'd ask if the answer is vague, and the one question to avoid because it primes a particular answer.

Sizing estimate and method: {{estimate}}

List every assumption baked into the number: population, adoption rate, price point, frequency.
For each, give a plausible low and high value and recompute the range.
State which single assumption the final number is most sensitive to, and how you'd validate that one first.

Sources:
{{sources}}

For each: one-sentence summary, its stance or finding, methodology in one line, and a relevance note tied to {{research_question}}.
Order them from strongest to weakest evidence for the research question, and say why the top one outranks the second.

Spec: {{spec}}

List the risks across: technical feasibility, dependency on another team, user adoption, and data/privacy.
For each: likelihood, impact, the earliest signal that would reveal it's happening, and the owner who should watch for it.
Order by risk score, not by section of the spec.

Feature: {{feature}}

Split it into vertical slices (each one delivers real user value end to end, not a layer like "backend only").
For each slice: what a user can do after it ships, its size relative to the others (S/M/L), and its dependency on any earlier slice.
Flag if the feature genuinely cannot be sliced and must ship as one unit, and why.

Pricing page copy: {{copy}}
Target buyer: {{buyer}}

Check: is the cheapest path to value obvious in under 5 seconds, is any term used without definition, does any plan comparison require math the reader shouldn't have to do, and is the CTA specific to the tier rather than generic.
List each issue with the exact line it's on and the fix.

Proposed north star metric: {{metric}}
Business goal it's meant to represent: {{goal}}

Check: can a team improve this metric while making the actual business goal worse? Give a concrete gaming scenario.
Check: does it lag or lead the goal, and by how much time?
Propose one counter-metric to track alongside it that would catch the gaming scenario.

Flow steps and drop-off rates: {{funnel_data}}
Screenshots or copy at each step: {{step_details}}

For the step with the steepest drop, list the three most likely causes (unclear value, too much friction, trust/security concern, technical failure) ranked by fit with the evidence given.
Propose the smallest test that would confirm the top cause before redesigning anything.

Raw notes from the last {{period}}: {{notes}}

Write an update with: what shipped and its impact if known, what's at risk and why, what's blocked and what's needed to unblock it, and the single decision you need from leadership if any.
No status-theatre language. If nothing is blocked, say so instead of manufacturing a concern.

Table schema and sample rows: {{sample}}

Produce a profile: row count and grain, each column's type and null rate, columns that look like they should be unique but aren't, columns with suspicious value distributions (e.g. one value dominating), and likely foreign keys to other tables.
Flag anything that would break a naive average or count if not handled.

SQL:
{{sql}}

Explain, without jargon: what business question this answers, what each join is combining and why, any filter that could silently exclude relevant rows, and what "grain" means for this result (one row = one what?).
End with the one assumption a reviewer should double check.

Dashboard metrics and their current SQL/definitions: {{metrics}}

Check for: metrics with the same name computed differently in different places, metrics without a stated time window, metrics that silently change grain (e.g. per-user vs per-session) between charts, and any metric that can't be reproduced from the definition given.
List each issue with which two places disagree.

Experiment: {{experiment}}
Results: {{results}}
Sample sizes and duration: {{sample_info}}

Write: the headline result and whether it's statistically meaningful given the sample size, any secondary metric that moved in a concerning direction, novelty effects to watch for if the test just ended, and a ship/hold/kill recommendation with the confidence level attached.

Pipeline: {{pipeline_description}}
Symptom: {{symptom}}
Recent changes: {{recent_changes}}

Rank the five most likely causes: upstream schema change, late-arriving data, a recent deploy, a scaling/resource limit, or a silent data quality issue.
For each, the fastest check that confirms or rules it out, in order of speed not thoroughness.

Question: {{question}}
Available data: {{data_description}}

Define: the cohort grouping variable, the metric tracked over time per cohort, the time unit and window, and how a user who churns and returns should be counted.
Write this as a spec an analyst could implement without asking a clarifying question.

Best-performing pieces (paste 3-5): {{samples}}

Extract: sentence length pattern, how claims are hedged or not, how examples are introduced, what kind of humour (if any) appears and how often, and three words or constructions that show up too often.
Turn this into a one-page style guide a new writer could follow.

Draft: {{draft}}
Recipient context: {{context}}

Rewrite to: one sentence establishing relevance to them specifically, one sentence on the concrete offer, one specific ask with a low-effort next step.
Delete any sentence that could be sent to any other company unchanged.
Target under 90 words.

Concept: {{concept}}
Audience: {{audience}}

Propose two candidate analogies. For each: where it correctly maps to the mechanism, and the one place it breaks down and could mislead the reader.
Pick the stronger one, write a two-paragraph explanation using it, and explicitly flag its limit in the last sentence.

Draft: {{draft}}
Target: cut by {{percent}}% while keeping every distinct claim.

Remove: throat-clearing openers, restated points, hedges that add no information, and any example that repeats a point already made.
Return the tightened draft, then a one-line note on what was cut and why nothing essential was lost.

Support tickets/transcripts: {{tickets}}

Cluster into recurring questions, using the customer's actual phrasing where possible.
For each: the question as a customer would ask it, the answer in plain language, and how many tickets it would have deflected.
Do not invent a question that didn't actually occur in the tickets.

Updates this period: {{updates}}
Audience: {{audience}}

Pick the single most important update as the lead story with two sentences of "why it matters."
List the rest as one-liners grouped by theme.
Cut anything that's internal-only and has no reader-facing effect.
End with one specific thing you want the reader to do, not a generic sign-off.

House style guide: {{style_guide}}
Piece that needs a different register and why: {{piece_context}}

Identify which style rules should flex for this piece and which are non-negotiable regardless of context.
Rewrite the opening paragraph to show the flexed version, then state in one line what would tell you the flex went too far.

Script with timestamps: {{script}}
Retention graph description (where it drops): {{retention_notes}}

At the drop point, check: does the pacing slow down, does a promised payoff get delayed, is there an unexplained topic shift, or does a visual stop matching narration?
Give the most likely cause and the specific rewrite of that section that would fix it.

Full script with rough timestamps: {{script}}

Produce chapter markers: timestamp, chapter title under 6 words describing the specific claim covered (not a vague label like "Overview"), ordered start to end.
Merge any chapter shorter than 30 seconds into its neighbour.

Full transcript: {{transcript}}

Identify 3-5 segments that work as standalone 30-60 second clips: each must make sense with zero context from the rest of the video and end on a complete thought.
For each: start/end timestamp, the hook line to lead with, and why it stands alone.

Comments: {{comments}}
Video context: {{context}}

For each comment: classify as question, correction, praise, or criticism.
Draft a reply that answers directly, admits it if a correction is valid, and never uses a generic "thanks for watching!" filler.
Flag any comment that surfaces a genuine error in the video for a pinned correction note.

List of past video titles/topics: {{past_videos}}
Recent comments/requests: {{requests}}

Identify topics viewers are asking for that haven't been covered, topics covered long enough ago to revisit with updated information, and one topic that's been over-covered relative to its actual demand.
Rank the gaps by how often they're requested.

Given the task below and a catalog of available tools, select the minimal subset of tools the agent needs.
For each chosen tool, state why it is necessary, what input it requires, and what failure mode it covers.
Then list any tools in the catalog that look tempting but are not needed, and why excluding them reduces risk.

Task: {{task}}
Tool catalog: {{tools}}

An agent executed the following plan step and got this result. Decide the next action:
- RETRY (same step, same args) — only if the failure is transient and idempotent.
- REPLAN (rewrite remaining steps) — if the environment changed or assumptions broke.
- ESCALATE (ask a human) — if the step is irreversible or confidence is below threshold.

Output a JSON object: { action, reason, revised_steps (if replan), confidence_0_to_1 }.

Step attempted: {{step}}
Result / error: {{result}}
Remaining plan: {{remaining}}

Agent A must hand off to Agent B. Produce a handoff packet containing:
1. Task state: what was attempted, what succeeded, what failed.
2. Open assumptions: things Agent A treated as true without verifying.
3. Artifacts produced: files, IDs, URLs.
4. The single decision Agent B must make first.
5. What Agent B should NOT redo (to avoid redundant work).

Task: {{task}}
Agent A log: {{log}}

Given the agent workflow below, estimate:
- Total input tokens per loop iteration (system prompt + context + tool results).
- Expected number of iterations.
- Estimated cost at $/1K tokens for the chosen model.
- Which step is the dominant cost driver.
- One change that would cut cost by >30% without losing quality.

Workflow: {{workflow}}
Model pricing: {{pricing}}

Draft a guardrail spec for the agent described below. Cover:
- Actions that are forbidden (never do X).
- Actions that require human approval (ask before Y).
- Data that must never leave the context (PII, secrets).
- Maximum autonomous steps before a checkpoint.
- How to behave when a tool returns an unexpected schema.

Return as a numbered list the agent can be instructed to follow verbatim.

Agent role: {{role}}
Environment: {{environment}}

Decompose the agent capability below into reusable skills. For each skill:
- Name it as a verb phrase (e.g., "extract-entities").
- State its input contract and output contract.
- Note which other skills depend on it.
- Flag any skill that is doing two things and should be split.

Capability: {{capability}}

Design an evaluation harness for the agent below. Specify:
- 5 tasks of increasing difficulty (with expected outcomes).
- The metrics: success rate, avg steps, avg cost, safety violations, unnecessary-tool-call rate.
- How to detect infinite loops and reward early completion.
- A baseline to compare against (e.g., a single-tool-call agent).

Agent description: {{agent}}

At the current agent step, decide what to inject into the context window from these sources: long-term memory, retrieved docs, prior tool outputs, user instructions.
For each source, state whether to include it now, defer it, or drop it — with a one-line reason.
Constraint: total injected tokens must stay under {{budget}}.

Current step: {{step}}
Available sources:
{{sources}}

Define a persona for the model to adopt. Include:
- Role and seniority (e.g., "principal engineer, 15 years in distributed systems").
- Three opinions this persona holds strongly.
- One opinion this persona is open to changing.
- A phrase this persona would never say (to prevent persona drift).
Then write the first response this persona gives to the question below.

Question: {{question}}

Rewrite the text below at five tone settings: formal-academic, casual-conversational, urgent-executive, skeptical-analyst, and encouraging-coach.
Keep the same facts in all five. Vary only word choice, sentence length, and structure.
After the five versions, note which tone best fits the stated audience and why.

Text: {{text}}
Audience: {{audience}}

Create an analogy for the concept below that a non-specialist would understand.
Rules:
- The analogy must map each key component of the concept to a physical object or everyday action.
- State where the analogy breaks down (what it cannot explain).
- Do not use "like a brain" or "like a cookbook" — avoid clichéd analogies.

Concept: {{concept}}
Audience: {{audience}}

Summarize the text below at three depths:
1. One-sentence TL;DR (max 25 words).
2. Five-bullet executive summary (each bullet one line).
3. Detailed paragraph (150-200 words) that a practitioner could act on.

Keep all three factually identical. Do not add information not in the source.

Text: {{text}}

Translate the text below from {{source_lang}} to {{target_lang}}.
Use the glossary exactly as given — never translate a glossary term to anything else.
If a glossary term appears with a different sense, flag it for human review instead of guessing.
After the translation, list any terms you could not match to the glossary.

Glossary:
{{glossary}}

Text:
{{text}}

Turn the article below into a 7-post social thread.
Post 1: a hook that states the single most surprising claim.
Posts 2-6: one key point each, with a concrete example from the article.
Post 7: a closing CTA that links back to the full article.
No emoji spam. No "🧵 1/7" — number posts naturally.

Article: {{article}}

Write documentation for the function below.
Produce: a one-line summary, a full description, @param entries with types and constraints, @returns with type and failure modes, and one usage example.
Follow the existing doc style in the file. Do not document obvious parameters like "config".

Function:
```
{{code}}
```

Generate unit tests for the function below. Include:
- Happy path (typical input).
- Boundary values (empty, zero, max, negative if applicable).
- Null/undefined and type-coercion cases.
- One test that should FAIL if the function regresses (regression guard).
Use the test framework already in the repo. Name tests descriptively.

Function:
```
{{code}}
```
Framework: {{framework}}

Write a conventional-commit message for the diff below.
Format: type(scope): subject
- Subject in imperative mood, max 50 chars, no period.
- Body (if needed): why the change was made, wrapped at 72 chars.
- If the diff spans two concerns, say so and recommend splitting into two commits.

Diff:
{{diff}}

Explain the code below to someone who has never programmed.
Rules:
- Use one analogy maximum.
- Do not mention loops, variables, or functions by their jargon — describe what they DO.
- End with "In plain terms, this code does: ____".

Code:
```
{{code}}
```

Build a regular expression that matches the requirement below.
Return:
1. The regex (flavor: {{flavor}}).
2. A line-by-line explanation of each group/quantifier.
3. Three strings that match and three that should not match.
4. One edge case the regex does not handle.

Requirement: {{requirement}}

From the cURL command below, produce an API contract:
- Method, path, and path params.
- Query params with types and whether required.
- Request body schema (as TypeScript types).
- Response body schema with status codes.
- Auth mechanism.
- Note any headers that look dynamic or environment-specific.

cURL:
```
{{curl}}
```

Rewrite the error message below so a user can fix the problem without support.
Rules:
- Say what went wrong in plain words.
- Say what the user can do about it.
- Never expose a stack trace, internal ID, or raw exception.
- Keep under two sentences.

Original error: {{error}}
Context: {{context}}

Plan a zero-downtime migration from the current schema to the target schema.
Provide the SQL for each step, in order, with:
- Backfill strategy.
- A deploy-safe order (add column → backfill → dual-write → switch → drop old).
- Rollback SQL for each step.
- When it is safe to run each step (off-peak, locked table, etc.).

Current schema:
{{current}}
Target schema:
{{target}}

Turn the incident notes below into a blameless postmortem with these sections:
1. Summary (what happened, impact, duration).
2. Timeline (chronological, UTC).
3. Root cause (the technical failure, not who did it).
4. Contributing factors.
5. Action items (each with an owner and due date, no "we should consider").
Keep it factual. Do not assign blame to individuals.

Incident notes: {{notes}}

From the list of papers below, produce a literature review skeleton:
- Group papers into 3-5 themes.
- For each theme, state the consensus and the disagreement.
- Identify the gap no paper addresses (the opening for new work).
- Rank themes by relevance to the research question.

Research question: {{question}}
Papers (titles + abstracts):
{{papers}}

Critique the research design below for threats to validity:
- Internal validity (confounds, selection bias).
- External validity (generalizability).
- Construct validity (does the measure measure the concept?).
- Statistical conclusion validity (sample size, multiple comparisons).
Then suggest one concrete fix per flaw found.

Research design: {{design}}

Build a semi-structured interview guide for the research goal below.
Include:
- A warm-up question (2 min).
- 5-8 core questions, ordered from broad to specific.
- 2-3 follow-up probes per core question.
- A closing question that invites anything missed.
- What to listen for as a signal (not just what to ask).

Research goal: {{goal}}

Review the survey questions below. For each question flag any of:
- Leading (pushes toward an answer).
- Double-barreled (asks two things at once).
- Ambiguous (term has multiple meanings).
- Assumes knowledge the respondent may not have.
Then rewrite each flagged question neutrally. Leave good questions unchanged.

Questions:
{{questions}}

Fact-check the single claim below.
Return:
1. Verdict: True / Partially True / False / Unverifiable.
2. Evidence for the verdict (with source URLs).
3. Evidence against (with source URLs).
4. Confidence (0-100%) and what would raise it.
Do not hedge. If unverifiable, say so plainly.

Claim: {{claim}}

From the competitor data below, build a feature comparison matrix.
Rows: competitors. Columns: the features that matter to {{buyer}}.
For each cell: Yes / No / Partial / Unknown.
Then note one feature only one competitor has, and one feature everyone is missing.

Competitor data:
{{data}}

From the event log below, reconstruct the user's journey:
- List each step in order with the page and action.
- Identify where the user hesitated (long gap or back-track).
- Identify the drop-off point (if any).
- State one hypothesis for why they dropped off.
- Recommend one change to test that hypothesis.

Event log:
{{log}}

From the Jira tickets below, synthesize a Product Requirements Document:
- Problem statement (what user pain these tickets address together).
- Proposed solution (one paragraph).
- Scope: in / out.
- Acceptance criteria (testable, one per ticket minimum).
- Open questions that need a product decision before engineering starts.

Tickets:
{{tickets}}

Score each feature below on three axes (1-5):
- Impact (user value if shipped).
- Effort (engineering + design weeks).
- Risk (technical, support, or compliance).
Then compute a priority score = Impact / (Effort × Risk^0.5) and rank.
Flag any feature where Impact and Effort are both 5 (a "bet").

Features:
{{features}}

The cohort data below shows a retention drop at week {{week}}.
Generate 5 testable hypotheses for why. For each:
- State the hypothesis as "Users who X are more likely to churn because Y."
- Name the metric that would confirm or refute it.
- Name the segment to compare against.
Then pick the hypothesis most cheaply testable.

Cohort data:
{{data}}

Write a churn exit survey for users who just cancelled.
- Max 3 questions (one open, two multiple-choice).
- The multiple-choice options must cover the top 4 real churn reasons for {{product}}, plus "Other".
- The open question must not be "Why did you cancel?" (too broad).
- Add one question that predicts win-back likelihood.

Product: {{product}}

Design an A/B test for the pricing change below.
Specify:
- Primary metric and minimum detectable effect.
- Guardrail metrics (things that must not degrade).
- Required sample size (with assumed baseline conversion and power).
- Duration, and the traffic split.
- The one confound that would invalidate results.

Pricing change: {{change}}
Baseline conversion: {{baseline}}

Turn the feature list below into a quarterly roadmap narrative for {{audience}}.
Structure: Now / Next / Later.
For each item: what it is, why it matters to the audience, and a non-committal date range.
Remove internal jargon. Tie each item to an outcome, not a deliverable.

Features:
{{features}}

Given the data profile below, produce a cleaning checklist:
- Columns with missing values over {{threshold}}% (recommend impute or drop).
- Columns with mixed types or encoding issues.
- Duplicate row detection strategy.
- Outlier detection method per numeric column.
- A validation query to run after cleaning.

Data profile:
{{profile}}

The query below is slow. Analyze it and:
1. Rewrite it for performance (avoid SELECT *, reduce subqueries, use CTEs if clearer).
2. Recommend indexes (state which columns, and whether clustered/b-tree/BRIN).
3. Identify if the query is doing a full scan unnecessarily.
4. Estimate the before/after cost qualitatively.

Query:
```sql
{{query}}
```
Table sizes: {{sizes}}

Given the metrics below, recommend a dashboard layout:
- For each metric, the best chart type and why (time-series → line, part-of-whole → donut, etc.).
- Which metrics go on the top row (most glanced-at).
- Which need a filter control.
- Which two metrics should NOT be on the same chart (different scales).
- One metric that is vanity and should be removed.

Metrics:
{{metrics}}

Interpret the A/B test results below.
State:
1. Whether the result is statistically significant (alpha = 0.05), showing the p-value.
2. The confidence interval for the lift.
3. Whether the lift is practically meaningful for the business.
4. Whether the sample size was adequate or the test is underpowered.
5. The one next step: ship / iterate / kill.

Results:
{{results}}

The metric {{metric}} changed by {{delta}} in the window below.
Generate 5 ranked root-cause hypotheses. For each:
- The suspected cause.
- The corroborating signal to check (another metric that would also move).
- The refuting signal (a metric that would NOT move if this is the cause).
- How quickly it can be verified.
Then name the most likely single cause.

Time window: {{window}}
Related metrics:
{{metrics}}

From the table schema below, produce a data dictionary.
For each column: name, data type, description (plain English), whether nullable, example value, and business meaning.
Flag columns whose name and type are misleading (e.g., a string column called "is_active").

Schema:
{{schema}}

Write 5 opening hooks (first 7 seconds of a YouTube video) for the topic below.
Each hook must use a different technique: question, bold claim, pattern-interrupt, story tease, or problem-statement.
Rank them by predicted first-10-second retention. State the ranking reason for the top and bottom.

Topic: {{topic}}
Target audience: {{audience}}

Write a thumbnail brief for the video below that a designer can execute in 20 minutes.
Include: the single emotion to evoke, the focal subject, 2-word overlay text max, background treatment, and the color palette (with hex codes).
State what NOT to include (clutter that kills readability at 120px).

Video title: {{title}}
Angle: {{angle}}

Audit the YouTube script below for retention risk.
Mark each section as: Hook (0-15s), Setup (15-60s), Value (60s+), Payoff, CTA.
Flag any section longer than 90 seconds without a pattern interrupt (cut, b-roll, text, question).
Suggest one pattern interrupt per flagged section.

Script:
{{script}}

Write a YouTube description for the video below.
Include:
- First 2 lines (above the fold): a hook + the value, no links.
- Timestamps for 4-6 chapters (from the script outline).
- 3-5 relevant links (subscribe, related video, newsletter).
- 8-12 comma-separated tags targeting search intent, not brand.
Do not keyword-stuff. Tags must be terms people actually search.

Video: {{title}}
Script outline: {{outline}}

Break the topic below into a 5-episode YouTube series.
For each episode: a working title, the single thing the viewer learns, the prerequisite episode (if any), and one cliffhanger that leads into the next.
Ensure episode 1 needs no prior knowledge and episode 5 delivers a payoff the whole series built toward.

Topic: {{topic}}

Triage the comments below into: REPLY, PIN (high-value question or testimonial), HIDE (spam/off-topic), REPORT (policy violation).
For REPLY comments, draft a 1-2 sentence reply. For PIN, say why. Never PIN your own comment.
Return as a list with the action and rationale.

Comments:
{{comments}}

Build a rubric for deciding what to keep in a context window when it overflows.
Score each candidate chunk on: recency, relevance-to-current-step, uniqueness (not duplicated elsewhere), and authority (source trust).
Provide a formula combining them into a single keep-score. Then state the threshold below which a chunk is dropped, and what happens to dropped chunks (summarize? evict? archive?).

Current task: {{task}}

Configure a hybrid retrieval pipeline for the corpus below.
Specify:
- Vector model and dimension.
- Keyword indexer (BM25) and preprocessing (stemming, stop-words).
- The fusion method (RRF or weighted) and recommended weights.
- Top-K per retriever before fusion.
- How to handle zero-result queries.

Corpus description: {{corpus}}
Query types: {{queries}}

Check whether the answer below is fully grounded in the retrieved context.
For each claim in the answer, mark it: GROUNDED (found in context, cite chunk), PARTIALLY GROUNDED (some support, rest inferred), or UNGROUNDED (not in context).
If any claim is UNGROUNDED, rewrite the answer to remove it or add "[not in sources]".
Do not add facts that are true but absent from the context.

Answer:
{{answer}}
Context chunks:
{{context}}

Rewrite the user query below to improve retrieval.
Produce:
1. A cleaned version (fix typos, expand abbreviations).
2. Two sub-queries that cover different facets of the intent.
3. One hypothetical answer (HyDE) the retriever can match against.
4. Any stop-words to remove before embedding.

User query: {{query}}

Build a scoring rubric for evaluating LLM outputs on the task below.
Dimensions: accuracy, completeness, instruction-following, safety, and one task-specific dimension.
For each dimension: a 1-5 scale with concrete anchors for 1, 3, and 5.
Then state whether to use an LLM-as-judge or human judge for each dimension, and why.

Task: {{task}}

Design a regression test suite for the prompt below.
Include:
- 8 test inputs (2 easy, 4 typical, 2 adversarial).
- For each, the expected output shape (not exact text) and what must NOT appear.
- A pass/fail rule (LLM-judge threshold or exact-match on a field).
- Which tests would catch each of: format drift, refusals, hallucination, and length regression.

Prompt:
{{prompt}}

Write an MCP tool spec for the capability below.
Include: tool name (snake_case), a one-line description, JSON Schema for input (with required fields and constraints), JSON Schema for output, error codes, and idempotency notes.
Then write the single instruction an agent would receive to know when to call it vs. an alternative.

Capability: {{capability}}

The agent produced the tool call below. Validate it against the tool's schema.
If valid, say OK. If invalid, return:
1. The specific field that failed.
2. The constraint violated.
3. The corrected call (as a JSON object the agent can re-emit).
Do not guess values not derivable from the original call + schema.

Tool call:
{{call}}
Schema:
{{schema}}

The agent trace below is hard to read. Summarize it as a story:
1. What the agent was trying to do.
2. The path it took (key decisions, in order).
3. Where it went wrong (the first wrong turn).
4. What it should have done instead.
5. Whether retrying would help or the plan itself was flawed.

Trace:
{{trace}}

For the capability below, decide whether it belongs in the system prompt or as a tool call, and justify:
- Put in PROMPT if: static, cheap, no latency concern, no external dependency.
- Put in TOOL if: dynamic, needs fresh data, expensive, side-effecting, or needs retries.
- SPLIT if part is static (instructions) and part is dynamic (data).
Then state the downside of getting this wrong (prompt bloat vs. tool-call overhead).

Capability: {{capability}}

Given the streaming chunk sequence below, reconstruct the full output and emit structured deltas:
- Text deltas as they arrive.
- When a tool-call JSON completes, emit it as a parsed object.
- Detect and flag a partial tool-call at the end of the stream.
Return the reconstructed text, the list of completed tool calls, and any partial call.

Chunks (in order):
{{chunks}}

Design a fair A/B comparison between model {{model_a}} and {{model_b}} on the task below.
Specify:
- 20 prompts (same for both models, same temperature, same system prompt).
- The evaluation: blind LLM-judge or human, and the rubric.
- How to handle ties and variance.
- The metric that decides the winner.
Then state one confound that could make the comparison unfair.

Task: {{task}}

Design a hallucination canary for the task below:
1. A fictional entity or fact the model should NOT know about, planted in a system note.
2. The detection rule: if the output references the canary as real, flag as hallucination.
3. A second test: ask about a real entity the model should know — if it denies the real one, that's a different failure.
4. The threshold for action.

Task: {{task}}

Compress the prompt below to use fewer tokens without losing any instruction.
Rules:
- Keep every directive; remove only redundancy, preamble, and examples that repeat a rule.
- Merge overlapping instructions.
- Do NOT change the output format or requirements.
- Report the before/after token estimate and what you removed.

Prompt:
{{prompt}}

Define stopping criteria for the agent loop below:
- SUCCESS: the goal condition is verifiably met (state the check).
- BUDGET_EXHAUSTED: max tokens or steps reached (state the numbers).
- STUCK: the same tool call repeated N times with no state change (state N).
- SAFETY: a guardrail triggered (state which).
- ESCALATE: confidence below threshold after a replan (state threshold).
For each, state what the agent does next (return, retry, ask human).

Agent loop: {{loop}}

From the example pool below, select the best 3-5 few-shot examples for the task.
Selection criteria:
- Diversity: examples should cover different input patterns, not be near-duplicates.
- Clarity: the input→output mapping is unambiguous.
- Edge coverage: include at least one tricky input.
- Length: shortest examples that still teach the pattern.
Then state why each rejected example was excluded.

Task: {{task}}
Example pool:
{{pool}}

Answer the question below in two passes:
PASS 1 — Generate the best answer you can.
PASS 2 — List every factual claim in the answer. For each, verify it against your own knowledge. If a claim is unverifiable or likely false, strike it and note why.
Output the verified answer (strikethroughs removed) and a list of claims you could not verify.

Question: {{question}}

Normalize the messy input below into the target JSON schema.
Rules:
- If a field is ambiguous in the input, set it to null and add a "warnings" array noting the ambiguity.
- If a field is present but empty, keep it as empty string/array, not null.
- Do not invent fields not in the schema.
- Dates must be ISO 8601; if unparseable, null + warning.

Schema:
{{schema}}
Input:
{{input}}

Model the agent below as a state machine.
List: states, the transitions between them (with the trigger condition for each), the terminal states, and the guard on each transition.
Then mark any state where the agent could get stuck in a cycle, and add an escape transition.

Agent description: {{agent}}

Given the model's knowledge cutoff date and the question below, decide:
- CAN ANSWER: the question is about concepts or events before the cutoff.
- STALE: the concept exists but details have changed since the cutoff (state what).
- BEYOND: the question is about events after the cutoff and requires a tool/search.
For STALE and BEYOND, state the exact search query or tool call needed.

Model cutoff: {{cutoff}}
Question: {{question}}

Summarize the patent claim below for an engineer.
Return:
1. The invention in one sentence.
2. The novel part (what the "wherein" clauses add).
3. What prior art this claim is trying to distinguish from (if inferable).
4. One way the claim could be designed around without infringing.

Claim:
{{claim}}

Assess the impact of the regulation below on the planned feature.
For each requirement in the regulation, state: APPLIES (feature touches this), DOES NOT APPLY (state why), or UNCLEAR (needs legal review).
For APPLIES items, state the design change needed and the user-facing friction it adds.

Regulation: {{regulation}}
Feature: {{feature}}

Decompose the north-star metric below into a metric tree.
- Level 1: the north-star metric.
- Level 2: 2-3 input metrics that directly drive it (with the formula connecting them).
- Level 3: for each Level 2 metric, one or two controllable inputs.
- Mark each leaf as a "lever" (a team can move it) or a "gauge" (it reflects but isn't directly controllable).

North-star metric: {{metric}}

Write a rollout spec for the feature flag below.
Include: flag key, data type (boolean/variant/percentage), the 4 rollout stages (internal → beta → 25% → 100%) with the gate criteria between each, the kill-switch condition, the metric to monitor at each stage, and how long to hold at each stage before promoting.

Feature: {{feature}}

Specify a churn-prediction model for the product below.
Include:
- The prediction target (define churn precisely: "no activity in 30 days").
- The feature set (usage, support, billing, tenure) with the top 5 expected features.
- The model type (logistic / gradient-boosted / survival).
- The evaluation metric (precision@top-decile, not accuracy).
- The expected LTV per retained user to size the intervention budget.

Product: {{product}}

From the SQL below, trace the lineage of the output column {{output}}.
List every upstream table and column it depends on, in order.
Flag any upstream column that is derived from another transform (note the dependency chain).
Then state which source a data-quality issue would surface in first if it broke.

SQL:
```sql
{{sql}}
```

Before trusting the experiment results below, run these sanity checks:
1. Sample ratio mismatch (is the split actually 50/50?).
2. Peeking: was the test stopped at a peak? (check the day-by-day p-value).
3. Bot/traffic contamination.
4. Metric definition drift (did the metric formula change mid-test?).
5. Simpson's paradox in any segment.
Flag any check that fails and what it means for the result.

Results:
{{results}}

The video below has low click-through. Iterate on title + thumbnail as a single "packaging" unit.
Generate 3 alternative title+thumbnail pairs. For each:
- Title (max 60 chars, no clickbait, curiosity gap > hype).
- Thumbnail concept (1 focal point, 2-word overlay).
- Why this pair beats the current one on CTR without misleading.
Then pick the strongest and state the test (A/B via YouTube's thumbnail test or publish-time swap).

Video: {{title}}
Current CTR: {{ctr}}

Write a collaboration pitch email to the creator below.
Rules:
- Subject line under 8 words, no "opportunity".
- First line: what's in it for THEIR audience (not yours).
- One sentence on why this collab is a fit (shared audience, not shared size).
- Propose a specific format (guest, cross-over, joint live).
- End with a low-friction ask (a 10-min call), not a commitment.

Creator: {{creator}}
Your channel: {{channel}}
Their audience: {{audience}}

Turn the outline below into a YouTube script written to be SPOKEN.
Rules:
- Short sentences. No sub-clauses longer than 8 words.
- Write contractions ("you'll", "it's") — it's speech, not prose.
- Add [B-ROLL] and [TEXT] cues where a visual beat is needed.
- End with a CTA that names the specific next video, not "subscribe."

Outline:
{{outline}}

Curate the raw prompts below into a clean library.
For each prompt: assign a category, write a one-line summary, detect duplicates (same intent, different wording — keep the clearer one), and flag any prompt that is unsafe to ship (asks for PII, jailbreak-adjacent).
Return a table: id | category | summary | status (keep / merge / drop / review).

Raw prompts:
{{prompts}}

Simulate the agent below running against the scenario. Do NOT actually call tools — simulate their return values as stated.
Walk through: the plan the agent forms, the first tool call, the (simulated) result, the replan decision, and the final output.
Then critique: where would the real run diverge from this simulation? What assumption is most fragile?

Agent spec: {{agent}}
Scenario + simulated tool returns:
{{scenario}}

Check the prompt below for anti-patterns:
- Vague quantifiers ("be concise", "thorough") with no anchor.
- Conflicting instructions ("be detailed but short").
- Missing output format (the model guesses JSON vs. prose).
- Over-negation ("don't do X, don't do Y…") instead of stating what TO do.
- Hidden assumptions about the model's defaults.
For each found, quote the line and suggest the fix.

Prompt:
{{prompt}}

Split the agent prompt below into two sections:
1. PERSONA (who the agent is — stable across tasks).
2. TASK (what to do this run — changes per call).
Move any task-specific detail out of PERSONA. Move any identity-stable detail out of TASK.
Then state why this split matters (persona is cached; task changes invalidate cache).

Prompt:
{{prompt}}

Given the cached context below and the current task, detect staleness:
- Is any timestamp older than the freshness requirement for its source type?
- Does any chunk reference a state that may have changed (a price, a status, a count)?
- Is the current task asking about something time-sensitive the cache doesn't cover?
For each stale item, state the refresh action (re-fetch, re-embed, or invalidate).

Current task: {{task}}
Cached context:
{{context}}

Build 10 adversarial test inputs for the prompt below. Target these failure modes:
- Ambiguous instructions (the prompt can be read two ways).
- Boundary inputs (empty, huge, all-symbols, mixed-language).
- Prompt-injection attempts (embedded "ignore instructions").
- Out-of-distribution queries (the task doesn't cover this).
For each input, state the expected behavior and the failure signal if the prompt breaks.

Prompt:
{{prompt}}

Define a fallback policy for when the primary model is unavailable or slow.
Specify:
- The primary model and the latency/cost SLA.
- The fallback model (cheaper/faster) and what tasks it may handle.
- What the fallback model must NOT do (complex reasoning, tool use) — those queue instead.
- The circuit-breaker threshold (N failures in M seconds → switch).
- The recovery condition to switch back to primary.

Primary model: {{primary}}
Fallback model: {{fallback}}

Specify the observability setup for the agent below.
Metrics (with units): success rate, p50/p95 latency, cost per run, tool-call error rate, loops-to-completion.
Logs: every tool call (input hash, output hash, latency, status), every replan (trigger reason), every escalation.
Traces: a run-level trace ID linking all calls.
Then state the single alert that would wake someone at 3am and the one that should NOT.

Agent: {{agent}}

Rewrite the answer below with inline citations to the source chunks.
Format: [1], [2] after the claim, with a Sources list at the end mapping each number to the chunk title and URL.
If a claim has no supporting chunk, remove it and note "[unsourced, removed]".
Do not cite a chunk for a claim it doesn't actually support.

Answer:
{{answer}}
Source chunks (with IDs and URLs):
{{chunks}}

Adapt the prompt below for {{target_locale}}.
Do NOT just translate. Adjust:
- Examples to ones recognizable in the target culture.
- Idioms and metaphors that don't carry over.
- Date/number/currency formats in the instructions.
- Politeness level and formality to match the locale.
Then list what you changed and why a naive translation would have failed.

Prompt:
{{prompt}}

Audit the article structure below.
For each section: does it earn its place (does it advance the thesis)? Is it too long, too short, or out of order?
Identify: the section a reader would skim, the section that needs a concrete example, and the section that should move earlier.
End with a revised section order.

Article structure (headings + one-line each):
{{structure}}

Cluster the feedback items below into themes.
For each theme: a short name, the count of items, one representative quote, and the severity (blocker / friction / nice-to-have).
Then rank themes by (severity × frequency) and identify the one theme that, if fixed, would eliminate the most items.

Feedback items:
{{items}}

For each ticket below, assign:
- Category (bug / how-to / billing / feature-request / abuse).
- Priority (P0/P1/P2/P3) based on impact and affected-user count if inferable.
- Suggested first response (macro or draft).
- Route to (engineering / support / billing / product).
Do not over-prioritize loud-but-low-impact tickets. Flag any ticket that looks like a security report as P0 regardless of wording.

Tickets:
{{tickets}}

Review the spec below for ambiguities and contradictions.
For each issue found:
- Quote the conflicting or vague text.
- State why it is ambiguous (two valid readings) or contradictory.
- Propose a disambiguating rewrite.
Then rate the spec's overall clarity 1-5 and list the top 3 things to nail down before engineering starts.

Spec:
{{spec}}

Produce a human-readable explanation of the agent's decisions from the trace below.
For each tool call: what the agent wanted to know, what it learned, and how that changed the next decision.
End with: the single decision that mattered most, and what would have changed the outcome.
Do not justify — explain. If a step was wasteful, say so.

Trace:
{{trace}}

Review the data below for PII and privacy risks before it is shared or logged.
Flag: direct identifiers (email, phone, SSN), quasi-identifiers (DOB + ZIP), free-text fields likely to contain PII, and any field that could re-identify a "de-identified" record.
For each, recommend: redact, hash, generalize, or drop.
State whether the dataset is safe to share as-is after the recommended changes.

Data sample / schema:
{{data}}

Plan the end screen for the video below to maximize session retention.
Choose between: "next video" card, "subscribe" button, or "best-for-newcomers" link.
Justify the choice based on the video type (first-impression vs. deep-dive vs. series).
Then write the 10-second spoken CTA that sets up the end screen, naming the specific next video by title.

Video: {{title}}
Candidate next videos:
{{candidates}}

Curate the corpus below for RAG indexing.
Steps:
1. Dedupe near-identical documents (state the similarity threshold).
2. Detect low-quality docs (boilerplate, nav, scraped UI text) and mark for removal.
3. Propose a chunking strategy (by section, by fixed size, or by semantic boundary) with the chunk size.
4. State which docs need metadata (title, date, source) for filtering before retrieval.

Corpus (file list + sizes):
{{corpus}}

Design a benchmark suite to compare agent frameworks (e.g., CrewAI, AutoGen, LangGraph).
10 tasks across: single-tool, multi-tool, tool-selection, error-recovery, and human-escalation.
For each task: the setup, the success criterion, the budget (max steps, max cost), and what a "cheating" solution would look like (so it can be rejected).
Ensure tasks are model-agnostic (don't require a specific model's quirks).

Write a changelog entry for the prompt change below.
Include:
- What changed (diff summary, not full text).
- Why (the problem the old prompt had).
- Expected impact (which outputs improve, which regress, which are unaffected).
- The eval result before vs. after (or "pending" if not yet run).
- Rollback note (the old version is tagged {{tag}}).

Old prompt: {{old}}
New prompt: {{new}}

From the search queries below, find content gaps:
- Queries with impressions but low CTR (the page exists but doesn't satisfy intent).
- Queries with no ranking page (the topic is uncovered).
- Queries where the current page ranks but the query implies a different format (e.g., "how-to" but the page is an essay).
For each gap, propose the page to create or update, and the format.

Search queries (query | impressions | CTR | page):
{{queries}}

From the run log below, compute:
- Total runs, successful runs, success rate.
- Total tokens (input + output) and total cost.
- Cost per successful run (total cost / successful runs) — the metric that matters.
- The failure mode that wastes the most cost (which step do failed runs reach before dying?).
- One change to reduce wasted cost (fail faster? cheaper model for early steps?).

Run log:
{{log}}