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]

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]

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]

Compress this system prompt without changing model behaviour. It is billed on every single request, so every token matters.

Process:
1. Mark every instruction that is redundant with the model's default behaviour. Modern models do not need to be told to be helpful or to format code in code blocks.
2. Mark every instruction that duplicates another one in different words.
3. Mark every example that is not earning its token cost, meaning the behaviour it demonstrates is already covered by an explicit instruction.
4. Mark every hedge and politeness token that carries no instruction.
5. Identify anything ordered badly. Constraints belong near the top, formatting near the bottom.

Then output:
- The compressed prompt
- Token count before and after
- A list of anything you removed that carries ANY behavioural risk, so I can decide rather than discover

Do not remove anything whose effect you are unsure about. Flag it instead.

System prompt:
[PASTE]

Design the perceived-latency strategy for this AI feature. Users judge responsiveness by time to first token far more than by total generation time.

Produce:

1. LATENCY BUDGET: target time to first token, target total, and where the current implementation spends its time.
2. TTFT REDUCERS ranked by impact: shorter input context, prompt caching, a smaller routing model for the opening, speculative prefetch, and moving retrieval off the critical path.
3. WHAT TO SHOW DURING THE WAIT, per phase. Skeletons, streaming partials, tool-call status, and what NOT to show because it makes the wait feel longer.
4. STREAMING FAILURE HANDLING: what the user sees when a stream dies at 80 percent, and how to make retry non-destructive.
5. THE ONE CHANGE with the best perceived-latency return.

Feature:
[DESCRIBE]
Current measured latency:
[TTFT AND TOTAL]

Restructure this prompt so prompt caching actually works on it. Caching only helps when the prefix is byte-identical across requests, and most prompts break that without realising.

Do this:
1. Identify every part that is stable across requests and every part that varies.
2. Find the cache breakers: timestamps, request ids, user names, randomised example order, or anything dynamic sitting above stable content.
3. Reorder so all stable content comes first, in a fixed order, and everything variable comes last.
4. Mark where the cache breakpoint should be set.
5. Estimate the cached fraction before and after, and the resulting cost change.

Call out anything that cannot move without changing behaviour, and say why.

Prompt:
[PASTE]
What varies per request:
[DESCRIBE]

You are working in the codebase at [PATH]. Your task is to implement [FEATURE].

Follow this protocol:
1. First, READ the relevant files to understand the existing patterns (controllers, models, views).
2. Plan the change in 3-5 bullets. Don't implement yet.
3. Once I confirm the plan, implement step by step.
4. After implementation, run [TEST COMMAND] and report results.
5. Do NOT modify files outside the listed scope without asking.

Scope: only files in [DIRECTORY].
Constraints: keep the existing coding style. Don't add new dependencies.
Deliverable: working feature + brief PR description.

Start by reading and reporting back what you found. Don't change anything yet.

There's a bug in [PROJECT/COMPONENT]. The symptom is: [DESCRIBE SYMPTOM].

Do not fix it yet. First, INVESTIGATE:
1. Read the relevant files. List file paths and line numbers you suspect.
2. Form 3 hypotheses about the root cause, ranked by likelihood.
3. For each hypothesis, describe how you'd verify it (a test, a log, a manual check).
4. Recommend the cheapest verification path to start with.

Report back with the investigation summary. I'll tell you which hypothesis to verify first. Then we fix.