AI Prompts Library

You are a planning agent. Break the following goal into a dependency-ordered task list that another agent can execute without further clarification.

For each task give:
- A one-line imperative title
- The concrete acceptance check that proves it is done
- Which earlier tasks it depends on (by number)
- Whether it is safe to run in parallel with its siblings
- An effort estimate: trivial, moderate, or needs-review

Rules:
- No task may depend on information that does not exist yet at that point in the list
- Flag any task where the acceptance check cannot be automated and a human has to look
- If the goal is underspecified, list the specific questions blocking a clean decomposition BEFORE the task list, and stop

Goal:
[DESCRIBE THE GOAL]

Constraints:
[REPO, LANGUAGE, DEADLINE, ANYTHING OFF LIMITS]

You are a request classifier in a model routing layer. Read the user request below and output ONLY a JSON object, no prose.

Schema:
{
  "tier": "cheap" | "standard" | "frontier",
  "reason": "one short sentence",
  "confidence": 0.0-1.0,
  "needs_tools": true|false,
  "needs_long_context": true|false
}

Tier definitions:
- cheap: classification, extraction, formatting, short factual answers, routing, summarisation of short text
- standard: normal coding, drafting, multi-paragraph analysis, moderate reasoning
- frontier: multi-step reasoning, architecture decisions, hard maths, long autonomous work, anything where a wrong answer is expensive

Bias rule: when confidence is below 0.6, escalate one tier. A wasted expensive call is cheaper than a wrong cheap one.

Request:
[REQUEST]

You are compacting an agent's working context. Produce a structured record that lets a fresh context continue the work without the raw transcript.

Output exactly these sections, no others:

ORIGINAL GOAL
(Copy the original instruction verbatim. Do not paraphrase, shorten, or improve it.)

DECISIONS MADE
(Bullet list. Each: what was decided and why, one line.)

DECISIONS REVERSED
(Bullet list of anything tried and abandoned, with the reason. This prevents re-trying dead ends.)

FILES TOUCHED
(Path, and what changed in it.)

CURRENT STATE
(What is true right now. Test status, build status, what is half-finished.)

NEXT STEP
(The single next action, concrete enough to execute.)

OPEN QUESTIONS
(Anything genuinely blocking. Empty is a valid answer.)

Transcript to compact:
[PASTE TRANSCRIPT]

Build me a model evaluation set from real work instead of a public benchmark.

Given the closed issues and their merged fixes below, produce 20 eval tasks. For each:

1. TASK: the issue restated as a self-contained instruction, with no hints about the actual fix
2. CONTEXT NEEDED: which files a model would have to read to solve it
3. PASS CRITERIA: an objective check, ideally a test command, that distinguishes a real fix from a plausible one
4. DIFFICULTY: trivial / moderate / hard
5. TRAP: what a model is most likely to get subtly wrong here

Exclude issues that are pure dependency bumps, typo fixes, or anything where the fix is stated in the issue title.

Issues and fixes:
[PASTE]

Act as an LLM cost analyst. I will give you a description of an AI feature and its traffic. Produce a cost breakdown and a reduction plan.

Deliver:

1. CURRENT COST MODEL
   Per-request token estimate (input, cached, output), cost per request, monthly total. Show the arithmetic.

2. WHERE THE TOKENS GO
   Rank the biggest contributors: system prompt, retrieved context, conversation history, output length, retries.

3. REDUCTION LEVERS, RANKED BY SAVING PER UNIT OF EFFORT
   For each: estimated percentage saved, implementation effort, and what quality risk it carries.
   Consider at minimum: prompt caching, routing cheap requests to a smaller model, batch API, trimming the system prompt, retrieval instead of stuffing, capping output length, deduplicating retries.

4. THE ONE CHANGE TO MAKE FIRST
   Pick one. Justify it in two sentences.

Do not suggest anything that requires changing model provider unless the saving exceeds 40 percent.

Feature:
[DESCRIBE]
Traffic:
[REQUESTS PER DAY, AVERAGE SIZES]

Review this MCP server design before it ships. You are looking for the failure modes that only appear once an agent is driving it, not a human.

Check each of these and report concretely:

1. TOOL NAMING: are names unambiguous to a model that only sees the name and description? Flag any pair a model could confuse.
2. DESCRIPTIONS: does each description say when NOT to use the tool? Missing negative guidance is the top cause of wrong tool selection.
3. PARAMETER SCHEMAS: are required and optional correct? Any parameter a model will have to guess at?
4. ERROR MESSAGES: does a failure tell the model what to do differently, or just that something broke?
5. RESPONSE SIZE: which tool can return an unbounded payload and blow out the context window? Every one of them needs a limit.
6. DESTRUCTIVE OPERATIONS: which calls are irreversible, and is that obvious from the description alone?
7. IDEMPOTENCY: what happens if the agent retries after a timeout that actually succeeded?

For each finding: severity, the concrete failure scenario, and the fix.

Server definition:
[PASTE TOOL DEFINITIONS]

Write the brief for a subagent. The subagent starts with an empty context and only sees what you write here.

Produce:

OBJECTIVE
One sentence. What done looks like.

CONTEXT IT NEEDS
Only what is required. Every extra token here is paid on every turn of the subagent's run.

OUT OF SCOPE
Explicit list. Subagents drift by default; this is what stops it.

TOOLS IT MAY USE
And any it must not.

RETURN FORMAT
Exactly what to hand back to the parent. Be specific: the parent will parse this.

STOP CONDITION
When to stop and report, including when to report failure rather than keep trying.

Parent task:
[DESCRIBE]
Subtask to delegate:
[DESCRIBE]

You are red-teaming an AI feature for prompt injection. The system processes untrusted content from [SOURCE: web pages / emails / uploaded documents / user messages].

Produce an attack list. For each attack:
- The injected payload, written out
- Where it would be placed in the untrusted content
- What it tries to make the system do
- Which defence, if any, in the system below would stop it
- Severity if it succeeds

Cover at minimum: direct instruction override, authority impersonation, delayed or conditional triggers, encoded and obfuscated payloads, payloads hidden in markup or metadata, tool-call hijacking, data exfiltration via crafted URLs, and multi-turn setup attacks.

Then state the single strongest defensive gap.

System description:
[DESCRIBE THE SYSTEM, ITS TOOLS, AND ITS CURRENT DEFENCES]

Help me decide whether to use retrieval or to stuff the context window for this workload. Be opinionated.

Analyse:

1. CORPUS SHAPE: total size, how often it changes, how the relevant span is distributed (single findable fact, or diffuse across many documents)
2. THE LONG-CONTEXT COST: tokens per request, cost per request, and cost per month at my volume, with and without prompt caching
3. THE RETRIEVAL COST: embedding cost, storage, query latency, and the engineering time to build and maintain it
4. QUALITY: which approach gives better answers for THIS corpus shape, and why. Account for lost-in-the-middle degradation honestly.
5. VERDICT: one recommendation. If it is hybrid, say exactly what goes in retrieval and what goes in context.

Do not hedge. Pick one.

Corpus:
[DESCRIBE]
Volume:
[REQUESTS PER DAY]
Budget:
[MONTHLY]

Harden this output schema so a model cannot produce something that parses but is wrong.

For each field, check and fix:
- Is the type as narrow as it can be? Prefer an enum over a string, an integer over a number, a bounded array over an unbounded one.
- Can the model omit it? Should it be able to?
- Is there a sensible value the model will pick when it does not know? If so, add an explicit unknown option so the model does not fabricate.
- Does the field name alone tell the model what goes in it, with no schema description?
- Are there two fields a model could plausibly swap?

Then give me:
1. The hardened schema
2. The three most likely ways a model still produces valid-but-wrong output
3. A validation rule for each, to run after parsing

Schema:
[PASTE JSON SCHEMA]

An agent run failed. Diagnose it properly rather than guessing.

Work through, in order:

1. WHERE IT WENT WRONG: the first turn where the agent's state diverged from correct. Not where it crashed, where it started being wrong.
2. CLASSIFY THE FAILURE:
   - Goal drift (lost track of the objective)
   - Context loss (needed information had fallen out of the window)
   - Tool misuse (wrong tool, or right tool wrong arguments)
   - Bad tool output handling (misread a result)
   - Hallucinated state (believed something it never verified)
   - Loop (repeating without progress)
   - Genuine capability limit
3. ROOT CAUSE: harness, prompt, tool design, or model. Be specific about which.
4. WHY IT WAS NOT CAUGHT: what check would have surfaced this at turn N instead of turn N+20?
5. THE FIX, and whether it is a prompt change, a tool change or a harness change.

Run transcript:
[PASTE]

I am being sold on a model based on the benchmark claims below. Stress-test them.

For each claim:
1. Is the benchmark contamination-prone? Public repos, well-known problem sets and anything predating the model's training cutoff all are.
2. Was the number produced under conditions I can reproduce? Note any scaffolding, retries, best-of-N, or custom harness.
3. What does the benchmark actually measure, and is that the thing I care about?
4. What is the sibling benchmark this result should predict, and does it?
5. What is conspicuously absent from the claim set?

Then tell me: what would I have to test myself to know whether this model is better for MY workload, and what is the cheapest version of that test?

Claims:
[PASTE]
My workload:
[DESCRIBE]