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 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]

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]

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]

Review this agent execution sandbox. Assume the agent will eventually run adversarial code, either because a user asked it to or because injected content told it to.

Assess:
1. FILESYSTEM: what can it read outside the workspace? Write? Are credentials, SSH keys, cloud metadata or environment files reachable?
2. NETWORK: outbound allowed? To where? Can it reach internal services, cloud metadata endpoints, or exfiltrate to an arbitrary host?
3. PROCESS: can it spawn long-running processes, escape the process tree, or survive the session?
4. RESOURCE LIMITS: CPU, memory, disk, execution time. What happens when it hits them?
5. SECRETS: what is in the environment? Anything that should not be?
6. PERSISTENCE: can state written in one run be read in the next, and should it be?
7. HOST BOUNDARY: container, VM, or neither? Be honest about what a container does and does not isolate.

Rank findings by severity and give the concrete fix for each.

Sandbox setup:
[DESCRIBE]