AI Agent Prompt Library

You are designing the core execution loop for an agent whose job is: [task].

Define, explicitly:
1. Trigger — what starts a run.
2. The Thought → Action → Observation cycle this agent should follow, including what counts as a valid "Action" (which tools it may call).
3. Stopping condition — the exact signal that means the task is done.
4. Iteration cap — a hard maximum number of loop cycles, and what happens when it's hit.
5. Failure mode — what the agent should do if three consecutive actions produce no useful progress.

Output this as a numbered operating procedure I can paste directly into the agent's system prompt.

Here is an agent loop that just failed to complete its task: [paste transcript or logs].

Write a short self-critique from the agent's point of view: what it assumed, what actually happened, and what it should try differently. Then rewrite the critique as a single paragraph suitable for injecting back into the agent's context at the start of its next attempt.

Design an OODA loop for an agent that watches [system/metric] and responds to anomalies.

- Observe: what raw signals does it collect, and how often?
- Orient: what context (baselines, recent changes, known issues) should it check before deciding anything?
- Decide: what's the decision tree between "log it," "self-heal," and "escalate to a human"?
- Act: what's the smallest safe action it should try first?

Write this as a runbook, not code.

The following task has interdependent steps where a pure "act one step at a time" loop is likely to go down the wrong path: [task].

Write a Plan-then-Execute procedure: the agent should first output a full numbered plan with explicit dependencies between steps, get it validated (by a rule or a human), and only then execute step-by-step — re-planning only the remaining steps if something breaks, not starting over from scratch.

Here's a task currently handled by one agent running a single loop: [describe current setup].

Redesign it as an explicit graph:
- List every node (agent, tool call, or deterministic function) and what it owns.
- List every edge and the condition that triggers it.
- Define the shared state object that flows between nodes — what fields does it carry?
- Flag any node that should require human approval before its edge can fire.

Output as a nodes/edges table, not prose.

Design an orchestrator-worker graph for: [task, e.g. "research a topic from five angles and combine findings"].

- The orchestrator's job: decompose the task into independent subtasks.
- Worker nodes: what each one receives, does, and returns.
- Fan-in step: how the orchestrator combines worker outputs and decides whether more work is needed.
- Failure handling: what happens if one worker fails — does the whole graph stall, or does the orchestrator route around it?

Set up an evaluator-optimizer loop inside a graph for: [task, e.g. "generate marketing copy that must pass a brand-voice check"].

- Generator node: produces a candidate output.
- Evaluator node: scores it against explicit, listed criteria (not vibes) and returns pass/fail plus specific reasons.
- Edge logic: on fail, route back to the generator with the evaluator's reasons attached; on pass, route forward.
- Cap the number of retry cycles and define what happens if it never passes.

Here's an existing agent graph: [describe nodes/edges].

Insert a human-approval guard node before [high-risk action, e.g. "sending money," "deleting data," "publishing content"]. Specify:
- Exactly what state/context is shown to the human at that checkpoint.
- What the graph does while waiting (does it pause, timeout, or proceed with a default after N hours?).
- What happens on rejection — does it retry, dead-end, or route to a fallback node?

Here's what's currently being loaded into context for this agent on a typical run: [list/paste — system instructions, retrieved docs, tool definitions, conversation history, memory].

Categorize each piece as: essential every turn, situational (only sometimes needed), or dead weight. Estimate the token cost of each category and flag the single biggest opportunity to cut without losing capability.

Design a write policy for what this agent should and shouldn't persist to long-term memory: [describe the agent and what it does].

Specify: what's worth writing (durable facts, decisions, corrections it's had to repeat) vs. what should stay ephemeral (one-off details, anything easily re-derived), and the rule for when an old memory should be updated vs. left alone vs. deleted.

Here's a long transcript/session history: [paste].

Compress it into a summary that preserves every decision made and every constraint established, while dropping exploratory back-and-forth that didn't end up mattering. The compressed version should be usable to resume the task cold, without the original transcript.

This agent retrieves from [data source] before acting, but often pulls irrelevant or stale material into context: [describe symptom/example].

Diagnose whether the problem is in what gets written to the retrieval store, how it's ranked/selected at retrieval time, or both — and propose the specific fix (e.g. better chunking, recency weighting, a relevance threshold) rather than a general "improve retrieval" suggestion.

Build a scoring rubric for judging this agent's output on [task type]: [describe task].

Define 4-6 concrete criteria (not "quality" — things like "cites a source for every factual claim," "stays under the stated budget," "asks before taking an irreversible action"). For each, specify what a pass vs. fail actually looks like with a short example of each.

Here's a real case where this agent did the wrong thing: [describe/paste transcript].

Turn it into a repeatable eval case: the exact input that should be given, the specific behavior that would count as a pass this time, and the specific behavior that would count as a repeat of the same failure. This should be addable to a standing regression suite.

This agent has access to: [list tools/scope, e.g. "file system, GitHub, ability to run shell commands"].

Generate a set of adversarial test prompts that probe for: goal hijacking (getting the agent to abandon its actual instructions), tool misuse (using a tool outside its intended scope), and injected instructions arriving through retrieved content or tool output rather than the user directly. For each, state what a safe response looks like.

Here's the full list of tools/permissions this agent currently has: [list].

For each one, state the worst realistic action it enables if the agent is tricked or malfunctions, and whether that permission is actually needed for the agent's stated job. Recommend which permissions should be scoped down, made read-only, or gated behind a human approval step.

I want to rank/get cited for content about: [topic].

Produce:
1. A primary keyword and 8-10 related long-tail variants, grouped by search intent (informational / comparison / transactional).
2. The core entities (people, products, concepts) that should be clearly and consistently named so an AI system can resolve what this page is about.
3. 5 question-form queries a real user might type into ChatGPT or Perplexity that this page should be the best possible answer to.

Restructure this draft for both traditional SEO and AI citation: [paste draft].

Rules:
- Open each major section with a 1-3 sentence direct answer before any elaboration.
- Use descriptive H2/H3s that double as questions where natural.
- Keep each answerable "chunk" self-contained enough to be lifted out of context and still make sense.
- Flag anywhere the draft is vague about a fact, number, or claim — those need to be tightened for citation-worthiness.

Generate valid JSON-LD schema markup for this page: [paste content or URL].

Use the most specific applicable schema type(s) (e.g. Article, FAQPage, Product, HowTo, SoftwareApplication). Include all fields an AI answer engine would need to resolve entity, author, date, and — if applicable — price/rating/availability. Output only the JSON-LD block.

Here is a page and its top 3 competitors for the query "[query]": [paste all four, or URLs].

Compare them on: answer-first structure, entity clarity, presence of concrete stats/data, schema markup, and freshness. Identify the specific reasons an AI answer engine would be more likely to cite a competitor over this page, ranked by impact.

Build a [7/14/30]-day content calendar for growing [platform, e.g. "an X account"] focused on [niche/topic].

For each day, specify: content type (post/thread/reply/article), the specific angle or hook, and one line on why it fits that day's slot (trend-riding, evergreen, engagement-bait, etc.). End with a short note on what to track weekly to know if the calendar is working.

Write [N] [platform] posts about: [topic/announcement].

Constraints: [tone], [character limit], must include a hook in the first line, no more than one call-to-action per post, avoid generic AI-sounding phrasing. Vary the angle across posts — don't just reword the same one.

Here's what I'm selling: [product/service]. Here's who I think buys it: [rough audience].

Sharpen this into: a one-sentence positioning statement, a 3-bullet ideal-customer profile (who, what pain, what triggers them to act), and 3 competitor alternatives they'd consider instead — with the one honest reason each competitor might still win.

Here's the data from a campaign that just ended: [paste metrics/results].

Write a retro: what worked, what didn't, and — most importantly — one specific, testable hypothesis for what to change next time. Avoid vague takeaways like "post more" or "engage more"; every recommendation needs a concrete next action.

Write a first-touch outreach message to [type of prospect] about [offer].

Constraints: under [N] words, one clear and specific reason this particular prospect (not just "companies like them") would care, one low-friction call-to-action, no generic flattery. Write 2 variants with different opening hooks.

Here are the objections we hear most often when selling [product/service]: [list objections].

For each one, write a short response that acknowledges the concern honestly (don't dismiss it), then reframes toward value — and flag which objections are actually valid limitations we shouldn't spin our way past.

Design a [3/5]-touch follow-up sequence for a prospect who [showed interest but went quiet / attended a demo but didn't convert / etc: describe state].

For each touch: the gap in days since the last one, the specific angle (not just "checking in"), and the one thing that should make this touch different enough from the last to be worth sending.

Draft a reply to this support ticket: [paste ticket].

Tone: [tone]. Requirements: acknowledge the specific issue (don't paraphrase it back generically), give a concrete next step or fix, and if the fix requires something from the customer, ask for exactly one thing at a time.

Here's an incoming support ticket: [paste ticket].

Classify it: severity (blocking / degraded / cosmetic / question), the team or system it belongs to, and whether it's a duplicate of a known issue (if I paste a list of known issues, check against that list). Output a one-line routing decision, not a full response.

Here's a support ticket and how it was resolved: [paste thread].

Turn this into a self-serve knowledge base article: a clear title phrased as the user's question, the fix as numbered steps, and a note on when this fix does NOT apply (so it doesn't get misapplied to a similar-looking but different issue).

Write a README for this project: [paste code/structure or repo description].

Include: what it does in one paragraph, install/setup steps that actually work from a clean environment, one minimal usage example, and a short "how this is structured" section — skip sections that would just be boilerplate for this project.

Generate API reference documentation from this code: [paste code/interface].

For each public function/endpoint: signature, one-line purpose, parameters with types and whether required, return value, and one realistic example call. Flag any function whose behavior isn't obvious from its name and signature alone.

Write a changelog entry from this diff/commit list: [paste].

Group by Added / Changed / Fixed / Removed. Write each entry from the user's perspective (what changed for them), not the implementation detail — unless the implementation detail is itself user-relevant (e.g. a breaking change).

Review this diff/code for [correctness | security | performance | readability] only — ignore everything else: [paste code].

For each issue: quote the exact line(s), explain the risk in one sentence, and give the minimal fix. Don't restyle code that isn't broken.

This is failing: [error/symptom]. Here's the relevant code and logs: [paste].

Don't propose a fix yet. First state your hypothesis for the root cause and exactly what evidence would confirm or rule it out. I'll give you that evidence, then you refine or confirm the hypothesis before we touch any code.

Write tests for this function/module: [paste code].

Cover: the happy path, each documented edge case, at least one case that should raise/throw, and one regression test for [specific bug, if any]. Use [testing framework]. Don't test implementation details — test behavior.

Refactor this code for [readability | to remove duplication | to reduce complexity] without changing external behavior: [paste code].

Before refactoring, list the current behaviors you're preserving (including edge cases and error handling) so it's clear nothing was silently dropped.

Write a pull request description from this diff: [paste diff or branch name + commits].

Include: a one-line summary, the "why" (not just the "what"), a bulleted list of changes grouped by concern, and a test plan the reviewer can actually follow.

Research [topic] and produce a brief structured as: TL;DR (3 sentences max), key findings (bulleted, each traceable to a source), open questions/disagreements between sources, and what you'd need to investigate next to be more confident.

Here's a dataset: [describe/paste sample]. Before I analyze it, check it for: missing values and their pattern (random vs. systematic), obvious outliers, duplicate records, and any column whose values don't match its apparent meaning. Report only what you find — don't fix anything yet.

Research the current landscape for [category/market], covering: the main players and what each is actually known for (not just their tagline), where they differ in a way that matters to a buyer, and any gap none of them are covering well.

Structure as a comparison, not a list of separate summaries.

Fact-check this draft against current, verifiable sources: [paste draft].

For each specific claim (a number, a date, a "the first to," a comparison): mark it as confirmed, outdated, unverifiable, or wrong — with the correction if you have one. Don't fact-check opinions or predictions, only checkable claims.

Write a blameless postmortem for this incident: [timeline/logs/what happened].

Structure: what happened (factual timeline only), impact (who/what was affected, for how long), root cause (not just the trigger — the underlying condition that allowed it), and 3 concrete follow-up actions with owners and a rough priority.

Write a step-by-step deployment runbook for [service/change], including: pre-flight checks, the exact deploy steps, how to verify it worked, and the rollback procedure if it didn't. Assume whoever runs this has never deployed this service before.

Review [system] for scaling risk given [expected growth/load, e.g. "3x current traffic in 6 months"].

Identify: the component most likely to break first, the specific signal that would give early warning, and the cheapest change that buys the most headroom — vs. what's a "real" scaling project we shouldn't pretend is a quick fix.

Write a procedure for rotating [credential/secret type] across [system(s)] with zero downtime.

Cover: the order services must be updated in so nothing loses access mid-rotation, how to verify the new secret works before revoking the old one, and how to confirm the old one is actually dead afterward (not just replaced in one config file).

Define the core gameplay loop for [game concept/genre].

Specify: the single action the player repeats most often, what makes that action feel good on its own (before any rewards), what it costs the player (time/resources/risk), and what it unlocks or escalates into after repeated plays. Keep the core loop to one sentence before expanding on it.

Review this game concept/design doc for engagement design: [paste].

Evaluate: the first-session hook (what happens in the first 60 seconds that earns a second session), the mid-game retention driver (why come back on day 3, not just day 1), and one honest flag for any mechanic that leans on pressure or guilt rather than genuine fun to keep players playing.

Design the first-session onboarding flow for [game concept], from install to the player's first meaningful decision.

Specify each screen/step, what it teaches (one concept per step, not several at once), and the exact point where control is handed fully to the player. Flag any step that could be cut without losing comprehension.

Design a difficulty/progression curve for [game concept] over the first [N] levels or minutes of play.

Define what gets harder (and what stays constant so the player has something stable to rely on), where the first real "wall" should appear, and how the game signals progress even between skill increases (cosmetic, narrative, or score-based).

Translate this content from [source language] to [target language]: [paste content].

Preserve: tone and formality level, any idioms (localize the meaning, don't translate literally), and formatting/placeholders (e.g. {name}, %s) exactly as-is. Flag anything that doesn't have a natural equivalent in the target language instead of forcing a bad translation.

Review this already-translated content for locale fit, not just translation accuracy: [paste source + translation].

Check: date/number/currency formats match the target locale's convention, no leftover source-language text or broken placeholders, and no phrasing that's grammatically correct but culturally off (overly formal/informal for context, awkward idiom, etc.).

Design a pipeline for translating a document that contains both regular text and text embedded inside images (scanned pages, screenshots, diagrams).

Specify: how text and image regions are detected and separated, what OCR step runs on the image regions before translation, how translated text is placed back (inline replacement vs. a parallel output), and how the pipeline flags low-confidence OCR output for manual review instead of translating garbage text silently.

Design a recovery sequence for [payment/invoice type] that expires or fails before completion.

Specify: how many follow-ups, spaced how far apart, what each one says differently from the last (don't just repeat "your invoice is pending"), the point at which it's abandoned rather than chased further, and what should trigger an immediate follow-up vs. a scheduled one (e.g. the customer returning to the site).

Here's [a sample of] transaction records from [payment processor] and the corresponding internal ledger entries: [paste/describe].

Check for: transactions present in one system but not the other, amount mismatches, and status mismatches (e.g. marked paid internally but still pending upstream). Report discrepancies only — don't guess at fixes without more context.

Here's a pricing rule: [describe the pricing formula/policy]. Here's how the underlying cost is actually determined: [describe cost source].

Identify every scenario where actual cost could exceed the price charged despite the policy looking safe on average (e.g. cost source lags reality, cost varies by routing/vendor, edge-case inputs). Rank by how likely each scenario is, not just how bad it would be.

Summarize this [Terms of Service / Privacy Policy / contract] in plain language: [paste document].

For each major section, one or two sentences on what it actually means for the person agreeing to it — especially anything that gives up a right, creates an obligation, or could surprise someone who didn't read the fine print.

Scan this contract for risk: [paste contract].

Flag: unusual or one-sided terms (compare to typical market terms where you can), ambiguous language that could be interpreted multiple ways, and any missing clause you'd normally expect for this contract type (e.g. no liability cap, no termination clause). This is not legal advice — flag for review, don't declare anything definitively safe.

Generate a compliance checklist for [regulation, e.g. GDPR/CCPA] as it applies to [business type/activity].

List concrete, checkable items (not general principles) — the kind a non-lawyer could go through and mark done/not done. Flag which items likely need an actual lawyer's sign-off rather than a checklist tick.

Write a job description for [role] at [company/team description].

Include: what the person will actually do in the first 90 days (not generic responsibilities), the 3-4 must-have qualifications vs. nice-to-haves clearly separated, and cut anything that's just filler ("fast-paced environment," "wear many hats") unless it's genuinely differentiating.

Write an interview question set for [role], focused on evaluating [specific skill/trait, e.g. "debugging under ambiguity"].

For each question: what a strong answer demonstrates, what a weak-but-plausible-sounding answer looks like (so the interviewer isn't fooled by confidence alone), and one natural follow-up to probe deeper.

Build a screening rubric for [role] based on this set of must-haves: [list].

Turn each into a scoreable criterion (not just present/absent) with a short description of what a 1, 3, and 5 look like, so two different screeners would score the same resume/answer similarly.

Here's what Hermes is currently used for: [list recurring tasks].

For each recurring task, tell me whether it's better served by (a) a one-off prompt, (b) a packaged skill, or (c) an MCP server connection — and why. Flag any task that's currently being done "by hand" through raw prompting that keeps failing the same way; that's the strongest signal it needs a proper skill or server instead.

Design an event-driven (not scheduled) backup system for [state to protect, e.g. "an agent's memory, skills, prompts, and config"].

Specify: the exact events that should trigger a backup (not a timer), where the backup goes (target repo/storage), what gets committed vs. excluded (secrets, tokens, caches), and how commits are scoped so a single logical change produces one clean commit instead of noise.

Write a prompt/procedure the agent runs periodically to verify its own backups are actually restorable — not just that a commit happened.

It should: confirm the latest backup commit matches current live state, spot-check that a sample of critical files can be read back out of the backup intact, and flag (don't silently fix) any drift between live state and the last backup.

Here's how backups currently work for [system]: [describe current setup].

Turn this into a runbook a future version of the agent (or a human) could follow cold: what's backed up, where, how often/on what trigger, where credentials for the backup destination are stored, and how to manually trigger a backup if the automated path fails.

Design a disaster-recovery process for rebuilding [system] on a brand-new host if the current one is lost, corrupted, or replaced — using as few manual steps as possible, ideally one.

Output as: (1) the single command/action a human runs to start recovery, (2) what a minimal bootstrap of the system does automatically after that, (3) what it restores from backup and in what order, (4) how it verifies the restore succeeded before declaring itself "recovered."

Write the initial goal/instruction that gets handed to a freshly installed, minimal version of the agent on a new host, whose entire job is to restore itself from its own backups.

It should know: which backup location(s) to pull from, in what order, how to re-establish any credentials it needs to keep working going forward, and what to report back once it believes it has fully restored itself.

Design a recovery drill: a safe way to actually test the disaster-recovery process above (e.g., on a throwaway VM) without touching the real system.

Specify what "success" looks like for the drill, what to measure (time to recover, any manual steps that weren't supposed to be manual), and how often the drill should be re-run so recovery doesn't quietly rot out of date.

Audit [project/repo] end to end. Cover: code quality hotspots, test coverage gaps, dependency health (outdated/vulnerable packages), documentation gaps, and anything that looks like it was a quick hack that never got cleaned up.

Rank findings by risk × effort-to-fix, not just severity alone, and separate "fix now" from "worth knowing about."

Audit [project/repo] for security issues, specifically: hardcoded secrets or tokens, overly broad permissions/scopes, unvalidated input reaching a sensitive operation, and any dependency with a known CVE.

For each finding, state the exploit scenario in one sentence — not just "this is bad practice."

Here's the current list of skills and MCP servers installed on [agent]: [list].

For each one: is it actually being used (check recent logs/history), does it overlap with another installed skill/server, and does it still match how the agent is used today? Recommend what to remove, not just what to add.

Audit the cost structure of [system/service] against its current pricing: [describe pricing model and cost inputs].

Identify any scenario where actual cost can exceed what's charged (not just the average case), how likely that scenario is, and what would close the gap — a pricing change, a cost control, or better monitoring to catch it early.