AI Prompts Library

Plan a migration from [CURRENT MODEL] to [TARGET MODEL] for a production workload.

Cover:

1. BEHAVIOURAL DELTAS to expect: tokenizer differences and their effect on cost, system prompt interpretation, refusal boundaries, structured output strictness, tool-calling format, streaming behaviour.
2. WHAT WILL SILENTLY BREAK: the changes that pass tests and fail in production. Be specific.
3. TOKEN COUNT IMPACT: different tokenizers mean the same text costs different amounts. Estimate the direction and rough size.
4. SHADOW TEST PLAN: how to run both models on real traffic and compare, including what to compare on and the sample size needed.
5. ROLLOUT: percentage stages, what metric gates each stage, and the rollback trigger.
6. WHAT TO DELETE AFTERWARDS: the workarounds for the old model's quirks that should not survive the migration.

Workload:
[DESCRIBE]

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]

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]

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]

Assess whether we should self-host [MODEL] instead of using a hosted API.

Cover, with numbers:

1. HARDWARE: minimum viable configuration at each quantisation level, and what quality you lose at each. VRAM, system RAM, and whether it fits on one node.
2. THROUGHPUT: realistic tokens per second on that hardware, at batch size 1 and under concurrency.
3. TOTAL COST OF OWNERSHIP: hardware or instance cost, power, and the engineering time to run it. Compare against the hosted API bill at my volume, and state the break-even request volume.
4. WHAT YOU GIVE UP: no managed uptime, no automatic model updates, you own the incident response.
5. WHAT YOU GAIN: data never leaves, fixed cost, no rate limits, ability to fine-tune.
6. VERDICT with the break-even point stated explicitly.

Volume:
[REQUESTS PER DAY, AVERAGE TOKENS]
Constraints:
[COMPLIANCE, TEAM SIZE, EXISTING INFRA]

Write a changelog entry from this diff. Write for someone deciding whether this release affects them, not for someone who already knows the codebase.

Rules:
- Group under Added, Changed, Fixed, Removed, Security. Omit empty groups.
- Lead each entry with the user-visible effect, then the mechanism. Never the reverse.
- For every fix, say what was broken and who it affected. A fix with no symptom is not a changelog entry.
- Name files and functions only when a reader would need them to act.
- Flag anything requiring migration or config changes with a bold BREAKING marker.
- Use plain hyphens, never em dashes.
- No marketing language. No 'we are excited to'.

If the diff contains a change whose user-visible effect you cannot determine, list it under a Needs Description heading rather than inventing one.

Diff:
[PASTE]

Review this AI feature spec before engineering starts. Most AI features fail on the same handful of unanswered questions.

Check each and report GAP or OK with a one-line justification:

1. What happens when the model is wrong? Is there a recovery path, or does the user just get a bad answer?
2. What does the user see while waiting?
3. How is quality measured after launch? Name the metric.
4. What is the cost per user per month at the projected volume?
5. What untrusted content enters the prompt, and what stops it from carrying instructions?
6. Which decisions does the model make that a human should approve?
7. What is the fallback if the provider has an outage?
8. Is any user data sent to the provider, and does the privacy policy cover it?
9. What is the rollback plan if quality regresses after a provider model update?

Then name the single largest risk and what would de-risk it cheapest.

Spec:
[PASTE]

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]

Create helpful 404 pages that clearly communicate a missing or unavailable page, reduce user frustration with friendly guidance, and redirect visitors toward useful destinations through concise messaging, recognizable visuals, search options, and clear navigation or return-home CTAs.

Create clear 500 error pages that explain a temporary server issue, reassure users that the problem is not their fault, reduce frustration with concise guidance, and help visitors continue their journey through retry actions, support links, status updates, or return-home CTAs.

Create engaging blog sections that organize articles clearly, highlight valuable insights, support content discovery, and guide readers toward deeper exploration with strong headlines, readable previews, relevant imagery, category labels, and clear article links.

Generate clear contact sections that make it easy for visitors to get in touch, organize contact details and forms effectively, build trust, and guide users with concise messaging, accessible fields, and clear next steps.