AI PROMPT LIBRARY

You are my front-end engineer. Build the page described below, and treat DESIGN.md as a hard contract, not a suggestion.

Design contract:
"""
{{PASTE_DESIGN_MD}}
"""

Page to build:
{{PAGE_DESCRIPTION}}

Rules:
- Read the contract first and restate the non-negotiables in one line before you write code.
- Reuse existing components from the repo before hand-r...

You are a senior {{LANGUAGE}} engineer. Implement the following spec.

Spec:
"""
{{SPEC}}
"""

Constraints:
- Use idiomatic {{LANGUAGE}}.
- Include type annotations.
- Handle the listed edge cases explicitly.
- Do not add features beyond the spec.

Output, in order:
1. The complete code in one block.
2. A short note on assumptions you made.
3. A list of test...

Translate the following code from {{SOURCE_LANGUAGE}} to {{TARGET_LANGUAGE}}.

Source:
```{{SOURCE_LANGUAGE}}
{{SOURCE_CODE}}
```

Requirements:
- Preserve behavior exactly, including error semantics.
- Use idiomatic {{TARGET_LANGUAGE}} (naming, std lib, error handling).
- Keep the public API shape unless an idiomatic change is clearly better.
- Note any pla...

Write a regex (flavor: {{FLAVOR}}) that matches:
- {{POSITIVE_EXAMPLES}}

And does NOT match:
- {{NEGATIVE_EXAMPLES}}

Output:
1. The regex.
2. A breakdown of each group with what it matches.
3. Two sample replacements showing capture groups.
4. Known limitations.

Build a CLI in {{LANGUAGE}} called `{{NAME}}`.

What it does:
{{DESCRIPTION}}

Requirements:
- Use {{ARG_PARSER}} (or std lib if unspecified).
- Subcommands: {{SUBCOMMANDS}}
- Print useful help text.
- Use non-zero exit codes on failure.
- Read config from {{CONFIG_PATH}} if it exists.

Return a single file plus a one-paragraph README snippet.

Explain this code as if reviewing it with a junior engineer.

```
{{CODE}}
```

For each meaningful block:
- What it does.
- Why it is written this way.
- Any non-obvious behavior or gotcha.

End with a one-paragraph summary of the function's intent.

I have a runtime error. Here is the stack trace:

```
{{STACK_TRACE}}
```

Relevant code:
```
{{CODE}}
```

Steps:
1. Identify the root cause, not just the symptom.
2. Explain why the error happens in plain language.
3. Provide the minimal code change to fix it.
4. Suggest a guard that prevents this class of error.

Act as a patient senior engineer. Ask me clarifying questions one at a time until you have enough information to form a hypothesis.

Bug:
"""
{{DESCRIPTION}}
"""

What I have already tried:
{{TRIED}}

Do not propose a fix until you have asked at least three sharpening questions.

This test is flaky:

```
{{TEST}}
```

Likely sources of nondeterminism: timing, ordering, shared state, network, randomness, time-of-day.

1. Rank the most likely causes for this test specifically.
2. For the top cause, show the minimal fix.
3. Suggest a CI guard (e.g. running the test 100 times) to confirm the fix held.

Hydration warning:
```
{{WARNING}}
```

Component:
```tsx
{{COMPONENT}}
```

Identify what differs between server and client render. Show the minimal fix. If the content is legitimately client-only, show the correct pattern with useEffect or dynamic import with ssr: false.

A workload that used to take {{OLD_TIME}} now takes {{NEW_TIME}}.

Recent changes:
{{DIFF_OR_PR_LIST}}

Code path under suspicion:
```
{{CODE}}
```

1. List the most likely causes, ranked.
2. For the top suspect, explain the failure mode.
3. Propose a measurement (benchmark or profile) that would confirm or rule it out.
4. Suggest the fix, including complexi...

Review this diff with the eye of a senior engineer.

```diff
{{DIFF}}
```

For each issue, output: file:line, severity (blocker / warning / nit), the problem, and a code-snippet fix.

Check specifically for:
- Logic errors and missing edge cases.
- Security: injection, XSS, missing auth, secret leakage.
- Performance: N+1, unnecessary re-renders, allocations...

Review the following code purely for naming and clarity. Do not change behavior.

```
{{CODE}}
```

For each name (variable, function, type, file):
- Is it accurate?
- Does it match the layer of abstraction?
- Suggest a better name with a one-line reason.

Also flag any comment that restates the code rather than explaining intent.

Critique this API surface. Audience: an engineer who has never seen it before.

```
{{API_CODE}}
```

Check:
1. Is each function name a verb that matches its effect?
2. Are required vs optional parameters clearly distinguished?
3. Are return types explicit and consistent?
4. Are errors thrown, returned, or swallowed? Pick one and stay consistent.
5. Could tw...

Skim this diff for security issues only. Do not comment on style.

```diff
{{DIFF}}
```

Look for: injection, hardcoded secrets, missing auth checks, missing rate limit, IDOR, unsafe deserialization, log lines that contain PII or tokens, CORS misconfigurations.

For each finding, give: severity, the line, the exploit shape in one sentence, and the fix.

Refactor this code for readability and maintainability. Preserve behavior exactly.

```
{{CODE}}
```

Rules:
- Do not change the public API.
- Do not change observable behavior.
- Explain each change inline as a comment.

Look for: long functions, repeated logic, deep nesting, magic values, unclear names, missing types.

Extract reusable stateful logic from this component into a custom hook.

```tsx
{{COMPONENT}}
```

Requirements:
- Hook name uses the `useXxx` pattern.
- Return a clean, minimal API.
- Add full TypeScript types.
- Component becomes a thin render layer.
- Add a one-line JSDoc explaining the hook's purpose.

I want to replace the legacy module `{{LEGACY_MODULE}}` with a new implementation `{{NEW_MODULE}}` without a big-bang rewrite.

Existing usage map:
{{CALLER_LIST}}

Plan a strangler-fig migration:
1. The thin facade or adapter that lets both implementations coexist.
2. The order in which to migrate callers, ranked by risk.
3. Feature-flag and rollback strate...

You are my mobile QA engineer. Drive a real browser at a 390x844 viewport and do a mobile pass over the routes below. Do not trust the desktop layout; phones break differently.

Routes:
{{ROUTE_LIST}}

For each route, check and report:
- Does anything overflow horizontally or force a sideways scroll?
- Are tap targets at least 44x44px and not overlapping?
- ...

Write unit tests in {{FRAMEWORK}} for:

```
{{CODE}}
```

Cover:
- Happy path with typical inputs.
- Edge cases: empty, zero, null, undefined, max values.
- Error cases that should throw.
- One snapshot test if the output is a complex object.

Name each test "should {behavior} when {condition}". Use describe/it blocks.

Add property-based tests in {{LIBRARY}} (fast-check, hypothesis, etc.) for:

```
{{CODE}}
```

Suggest 3-5 invariants the function must satisfy (idempotence, commutativity, inverse, monotonicity, length preservation, etc.). For each, write the test and explain why it holds.

Write a Playwright test (TypeScript) for the flow:

{{USER_FLOW}}

URL: {{URL}}

Requirements:
- Test both viewports: mobile (390x844) and desktop (1280x800).
- Use `getByRole` and `getByText` over CSS selectors.
- Assert on visible state, not implementation details.
- Add a `test.describe` per viewport.
- Include one negative test (the flow rejects invalid ...

Review these snapshot tests:

```
{{SNAPSHOTS}}
```

For each snapshot, decide: keep, narrow (assert on a subset), or replace with a behavior assertion. Justify each call. Flag any snapshot that exists only to detect "something changed" without anyone reading it.

Generate a README.md for this project.

Name: {{NAME}}
One-line description: {{DESCRIPTION}}
Tech stack: {{STACK}}

Public API or entry point:
```
{{CODE}}
```

Sections:
1. Title and one-paragraph description.
2. Features (bullets).
3. Quick start: prerequisites, install, basic usage.
4. Configuration (table of env vars or options).
5. API reference if it i...

Add JSDoc to every exported function, type, and constant in:

```
{{MODULE}}
```

Each block must include:
- @param and @returns with types.
- @example with a realistic snippet.
- @throws if it can throw.

Do not restate the type signature in prose. Focus on intent and edge cases.

Write a changelog entry for version {{VERSION}} ({{DATE}}).

Raw notes:
{{NOTES}}

Use Keep a Changelog conventions:
### Added / ### Changed / ### Fixed / ### Removed / ### Security

Rules:
- Lead with user impact, not technical detail.
- Mark breaking changes with **BREAKING:**.
- 1-2 lines per item.
- Group related changes.

You are documenting the architecture of `{{SERVICE}}`.

Inputs (paste each):
- Top-level directory tree.
- Entry points and main dependencies.
- The 3-5 most important files.

Produce:
1. A one-paragraph plain-English description of what the service does.
2. A component diagram in mermaid.
3. The request lifecycle for the most common operation.
4. Where stat...

Draft a design doc for: {{FEATURE}}

Context: {{CONTEXT}}
Constraints: {{CONSTRAINTS}}

Sections:
1. Problem statement.
2. Goals and non-goals (be explicit about non-goals).
3. Proposed design.
4. Alternatives considered (at least two), with trade-offs.
5. Data model and API changes.
6. Failure modes.
7. Rollout plan and rollback.
8. Open questions.

Compare {{OPTION_A}} vs {{OPTION_B}} for the use case: {{USE_CASE}}.

Constraints to weigh: latency, cost, operational complexity, team familiarity, observability, vendor lock-in.

Output a table with one row per dimension and a column per option, plus a final recommendation with the single most important reason. State your assumptions.

You are a senior software architect with 20 years of experience across web, infra, and data systems. Your job is to help the user make a sound technical decision.

Rules:
- Ask one clarifying question at a time before recommending.
- Surface trade-offs, not just answers.
- Push back on premature optimization.
- If a constraint is missing, ask before assuming...

Schema:
```sql
{{SCHEMA}}
```

Question: {{QUESTION}}

Write the SQL query.
Then:
1. Explain how the query answers the question.
2. Note any assumptions you made about the data.
3. Suggest one index that would speed it up if it is slow.

Here is an EXPLAIN ANALYZE for a slow query:

```
{{PLAN}}
```

Query:
```sql
{{QUERY}}
```

1. Identify the most expensive node.
2. Explain why it is expensive in plain language.
3. Suggest the most effective fix (index, rewrite, denormalize, materialized view).
4. Predict the new shape of the plan after the fix.

Design a database schema for: {{FEATURE}}

Requirements: {{REQUIREMENTS}}
Workload: {{READ_OR_WRITE_HEAVY}}

Provide:
1. Tables with columns, types, constraints, defaults.
2. Primary keys (prefer UUID or nanoid).
3. Foreign keys with ON DELETE behavior.
4. Indexes for the top 3 query patterns.
5. TypeScript types in {{ORM}} format.
6. 3-5 seed rows per table...

Here is a sample of a dataset (head):

```
{{CSV_HEAD}}
```

Row count: {{ROW_COUNT}}
Question I want to answer: {{QUESTION}}

Produce:
1. Inferred schema with types and likely meaning of each column.
2. Data quality concerns to check (nulls, duplicates, outliers, type drift).
3. The 5 most useful aggregations for this question.
4. A short Python (pandas) or...

You are my database engineer. We are applying the migration below to a live Postgres database that real users depend on. Optimize for zero downtime and a clean rollback, not speed.

Migration intent:
{{WHAT_CHANGES}}

Non-negotiables: the migration is idempotent so a re-run is safe, it is reversible or has an explicit documented reason it cannot be, long-loc...

You are my release engineer. A deploy is misbehaving and I need a diagnosis, not a guess. Work from evidence.

Symptom:
{{WHAT_IS_WRONG}}

Context I can give you: build logs, the failing command, the platform (Vercel, Coolify, Docker, other), the expected commit versus what is live, and env var names.

Diagnose in this order:
1. Is the right commit even depl...

Write a production Dockerfile for a {{STACK}} app.

Requirements:
- Multi-stage (deps, build, run).
- Non-root user.
- Healthcheck.
- Final image under {{SIZE_LIMIT}}.
- Build-time args for env vars.
- Copy only what is needed into the final stage.

Also produce:
- A .dockerignore.
- The build and run commands.
- Any framework config change required (e.g. st...

Write a GitHub Actions workflow for a {{STACK}} project.

Triggers: push to main, pull requests.
Steps: install ({{PKG_MANAGER}} with caching), lint, type check, test, build, deploy to {{TARGET}} on main only.

Include:
- Concurrency group to cancel redundant runs.
- Job-level permissions.
- Env vars from GitHub Secrets.
- Cache for node_modules and build ou...

Draft a blameless postmortem from these incident notes:

"""
{{NOTES}}
"""

Sections:
1. Summary (one paragraph: what, when, impact).
2. Timeline (UTC).
3. Root cause (technical) and contributing factors (process, comms).
4. What went well.
5. What went poorly.
6. Action items, each with: owner, severity, due date.

Tone: factual, no blame on individuals.

Set up runtime env validation for a {{STACK}} app.

Variables:
{{VARS}}

Requirements:
- Use Zod (or equivalent) at build and runtime.
- Separate server-only and public (NEXT_PUBLIC_) groups.
- Fail fast with a clear error.
- Export a typed env object.
- Provide a .env.example.

Audit this route handler against OWASP Top 10.

```
{{HANDLER}}
```

For each of the 10 categories, output: applicable (yes/no), findings, severity, fix. End with a summary score (A-F) and the top 3 priorities.

Threat model this feature using STRIDE.

Feature:
"""
{{FEATURE}}
"""

Trust boundaries:
{{BOUNDARIES}}

For each STRIDE category (Spoofing, Tampering, Repudiation, Information disclosure, DoS, Elevation of privilege):
1. List concrete threats specific to this feature.
2. Rate likelihood and impact.
3. Propose a mitigation, ranked by cost.

Scan this diff for likely secrets.

```diff
{{DIFF}}
```

Look for: API keys, JWTs, private keys, passwords, connection strings, OAuth client secrets, hardcoded tokens, .env values inlined into code.

For each finding: line, kind, what to do (rotate, move to secrets manager, gitignore, redact in history).

You are my technical content engineer. Write a decision-intent post that helps a developer choose, and stays fair to every option covered.

Topic: {{TOPIC}} (for example "X vs Y", "best tool for Z", "X pricing explained", "alternatives to X")
Audience: {{WHO_IS_READING}}

Rules:
- Root every factual claim in a primary source: official docs, changelogs, relea...

Write a technical blog post.

Topic: {{TOPIC}}
Audience: {{AUDIENCE}}
Length: {{WORDCOUNT}} words
Voice: clear, specific, no filler.

Structure:
1. Hook (2-3 sentences with a relatable problem or surprising fact).
2. Why this matters now.
3. Main content with code or concrete examples for every claim.
4. "How to use this today" section.
5. Conclusion: one ta...

Rewrite this for concision. Keep meaning, voice, and any technical detail intact.

"""
{{TEXT}}
"""

Cut filler, hedge words, and redundancies. Prefer active voice. Keep proper nouns and numbers exactly. Output only the rewrite.

Explain {{CONCEPT}} to {{AUDIENCE}}.

Constraints:
- No jargon. If a technical term is unavoidable, define it in one sentence.
- Use one analogy that holds up under follow-up questions.
- End with one sentence on why it matters to them specifically.

Convert this article into an X thread.

"""
{{ARTICLE}}
"""

Rules:
- 7-10 tweets.
- Hook tweet stands alone (no question).
- One key idea per tweet.
- Under 280 chars per tweet.
- No hashtags.
- Number tweets (1/, 2/, ...).
- Last tweet: a clear CTA.

Write 5 hero variants for a landing page.

Product: {{PRODUCT}}
Audience: {{AUDIENCE}}
Outcome they want: {{OUTCOME}}
Wedge that makes us different: {{WEDGE}}

For each variant, output:
- Headline (under 10 words).
- Sub-headline (under 25 words).
- Primary CTA label (2-3 words).
- The single emotion or status it targets.

No buzzwords. No "revolutionize". C...

Write a launch post for: {{FEATURE}}.

Audience: {{AUDIENCE}}
Length: under 250 words.

Structure:
1. The problem in one sentence.
2. What we shipped, plainly described.
3. The single best thing it lets the user do now.
4. How to try it (one link or one command).
5. What is coming next (optional, one line).

No filler. No "we are excited to announce". Show, ...

Help me write a positioning statement for {{PRODUCT}}.

Use the format:
"For [target customer] who [need or pain], [product name] is a [category] that [key benefit]. Unlike [primary alternative], we [differentiator]."

Then critique your own first draft and produce a tighter v2. End with the 3 sharpest questions a skeptical investor would ask about it.

Write a cold email.

Sender: {{SENDER}}
Recipient: {{RECIPIENT}}
Why I am reaching out: {{REASON}}
Specific thing I noticed about them: {{HOOK}}
The single ask: {{ASK}}

Rules:
- Under 100 words.
- Subject line under 7 words, no clickbait.
- One specific reference (not flattery).
- One question, not three.
- Plain text, no fluff.

Write a short reply declining this:

"""
{{INBOUND}}
"""

Tone: warm, professional, not apologetic to the point of weakness.

Include:
1. Thank them in one sentence.
2. The clear no.
3. The reason (brief, honest, no over-explaining).
4. An offer (a referral, future revisit, or pointer) if appropriate.
5. A clean sign-off.

Write a follow-up to this thread.

Original message:
"""
{{ORIGINAL}}
"""

Days since last reply: {{DAYS}}.

Rules:
- Under 60 words.
- Add new value (a link, a one-line update, a sharper question), not just "checking in".
- One ask only.
- Make it easy to reply with a yes or no.

Write a 1-page PRD.

Feature: {{FEATURE}}
User: {{USER}}
Problem: {{PROBLEM}}

Sections:
1. Why now.
2. User story (one paragraph from the user's POV).
3. Scope (in / out).
4. Success metric (one primary, one guardrail).
5. Risks.
6. Open questions.

Be opinionated. Avoid scope creep.

Score these items with RICE (Reach, Impact, Confidence, Effort).

Items:
{{ITEMS}}

For each item: assign R, I, C, E with a one-sentence justification, then compute Score = (R x I x C) / E. Sort descending. Flag any score that is sensitive to a single weak assumption.

Write an interview script for understanding {{TOPIC}} from {{PERSONA}} users.

Constraints (Mom Test rules):
- Ask about specific past behavior, not opinions or hypotheticals.
- No pitching the product.
- 6-8 questions, ordered from broad to specific.

For each question, note the bias it is designed to avoid.

Draft OKRs for {{TEAM}} for {{QUARTER}}.

Strategic goal: {{GOAL}}
Constraints: {{CONSTRAINTS}}

Rules:
- 1 Objective, 3-5 Key Results.
- Objective is qualitative and inspirational.
- Each KR is a number with a metric and a target.
- No "ship X" KRs (that is a task, not an outcome).
- Each KR should be ambitious enough that 70% is success.

Produce a structured deep dive on {{TOPIC}}.

Output:
1. One-paragraph executive summary.
2. The 5 concepts a practitioner must understand.
3. Current state of the art (what is settled, what is contested).
4. The 3 best primary sources (papers, repos, talks) with one-line summaries.
5. Open questions in the field.
6. A suggested 1-week learning path.

Distin...

Summarize this paper.

"""
{{PAPER_OR_LINK}}
"""

Output:
1. The single claim of the paper in one sentence.
2. The method, in plain language.
3. The key result with the actual numbers.
4. The strongest piece of evidence.
5. The limitation that most worries the authors.
6. Why a working engineer should care.

Compare {{TOOL_A}}, {{TOOL_B}}, and {{TOOL_C}} for the use case: {{USE_CASE}}.

Dimensions: developer experience, performance, ecosystem, learning curve, license, maintenance health, vendor risk.

Output a table, then a recommendation for the stated use case with the single most important reason. State your assumptions and your last-known-data date.

Teach me {{CONCEPT}} using the Feynman technique.

Process:
1. Explain it to me as if I am 12.
2. Ask me to explain it back to you.
3. Identify the gap or hand-wave in my explanation.
4. Re-teach just that gap with a new analogy.
5. Quiz me with one applied question.

Wait for my response between steps. Do not move on until I am clear.

Turn these notes into Anki-style flashcards.

"""
{{NOTES}}
"""

Rules:
- One concept per card.
- Front: a question or cloze.
- Back: a 1-2 sentence answer.
- Avoid yes/no questions.
- Tag each card with the topic.

Output as a markdown table: Front | Back | Tags.

Build me a learning roadmap.

I want to learn: {{GOAL}}
What I already know: {{BACKGROUND}}
Time available: {{HOURS_PER_WEEK}}
Time horizon: {{WEEKS}}

Output:
1. Milestones, each with a deliverable I can show.
2. Weekly plan with topics and resources (free preferred).
3. The 3 pitfalls to avoid given my background.
4. A self-check at each milestone.

Decision: {{DECISION}}
Context: {{CONTEXT}}

Output four lists:
1. Pros (with the strongest first).
2. Cons.
3. What could go wrong (and how we would notice).
4. What I am not yet considering that someone smarter would.

Then: a one-line recommendation and the single piece of new information that would flip it.

Action being considered: {{ACTION}}

Walk through three layers of consequences:
1. First-order: the direct effects.
2. Second-order: what people and systems do in response.
3. Third-order: longer-term equilibrium.

For each, separate likely from possible. Flag any second- or third-order effect that would be hard to reverse.

Run a pre-mortem.

Plan:
"""
{{PLAN}}
"""

Imagine it is 6 months from now and the plan has failed badly. Write the autopsy.

Output:
1. The failure mode (one paragraph).
2. The 5 contributing causes, ranked by likelihood.
3. The earliest signal we could have seen.
4. The cheapest mitigation per cause.

You are the orchestrator of a small agent fleet. Your job is to split the task below into independent units, run workers in parallel, and merge their results. You do not do the leaf work yourself.

Task:
{{TASK}}

Operate in phases:
1. DECOMPOSE. Break the task into the smallest set of units that do not depend on each other. State each unit as a self-contain...

You are a worker agent running one scoped unit inside a larger job. Stay in your lane and return a tight result.

Your goal:
{{ONE_SPECIFIC_GOAL}}

You own these inputs or files, and nothing else:
{{FILES_OR_INPUTS}}

Rules:
- Do only this unit. Do not refactor, rename, or touch files outside your ownership.
- If you discover work that belongs to another uni...

You are hardening an agent loop so that model refusals, malformed tool calls, and slow responses are handled as normal control flow instead of crashing the run.

Given the loop below (or my description of it), add handling for these cases:
"""
{{LOOP_OR_DESCRIPTION}}
"""

Handle each explicitly:
- Refusal: the model declines or returns a safety response. Do ...

You are a research agent. Your job is to investigate a topic and produce a structured report.

Topic: {{TOPIC}}

Process:
1. Decompose the topic into 3-5 research questions.
2. For each question, gather information using the tools available.
3. Cross-reference at least two sources.
4. Note contradictions and gaps.
5. Synthesize.

Output:
## Executive Summary...

You can use tools to answer the user's question. For each step, output:

Thought: what you are reasoning about right now.
Action: the tool to call, with arguments.
Observation: the tool result (filled in by the runtime).

Continue until you can produce:
Final Answer: your answer to the user.

Rules:
- Never invent observations.
- If a tool fails, reflect and...

Solve the task below in two passes.

Pass 1: produce your best draft answer.
Pass 2: critique your own draft as a senior reviewer would, listing every weakness, error, and missing consideration. Then produce a v2 that fixes them.

Output both passes, clearly labeled.

Task:
{{TASK}}

You operate in two modes.

PLAN mode:
- Read the task.
- Produce a numbered plan with the smallest set of steps that solves it.
- Each step has a clear success check.
- Stop. Do not execute.

EXECUTE mode (after the user approves the plan):
- Run each step in order.
- After each step, state whether the success check passed.
- If a step fails, stop and propos...

Write a tool definition (JSON Schema) for the following function so an LLM agent can call it via function calling.

Function:
```
{{FUNCTION_SIGNATURE_AND_DOCS}}
```

Output:
1. The JSON tool spec (name, description, parameters with types, required fields, enums).
2. A clear when-to-use line in the description (the model uses this to decide).
3. A when-NOT-t...

You are writing a SKILL.md that follows the Agent Skills standard, so a future agent can execute this workflow cold without me in the room.

The workflow to capture:
{{DESCRIBE_WHAT_YOU_JUST_DID}}

Write a SKILL.md with:
- Frontmatter: a "name" in kebab-case and a one-sentence "description" that states the trigger, since that description is all an agent sees...

You are a prompt engineer. Improve this prompt without changing its intent.

"""
{{PROMPT}}
"""

Apply:
- Make the role explicit.
- Add the audience and goal.
- Spell out the output format.
- Add success criteria the model can self-check against.
- Mark variables clearly with {{VARIABLES}}.
- Remove ambiguity.

Output: the improved prompt and a short list of...

Build a rubric for evaluating answers to this kind of task: {{TASK_TYPE}}.

Output a table with:
- Criterion (e.g. correctness, faithfulness, completeness, format adherence).
- Definition.
- Score levels: 0, 1, 2 with anchor descriptions.
- How to test it (manual check, regex, LLM-as-judge).

End with a sample weighted score and how you would aggregate.

Generate a balanced set of 5 few-shot examples for this task.

Task: {{TASK}}
Output format: {{FORMAT}}

Rules:
- Cover the typical case, two harder edge cases, and one tricky negative.
- Inputs vary in length and style.
- Outputs match the format exactly.
- No example should be ambiguous.

Output as Input / Output pairs, ready to drop into a system prompt.

# Role
You are {{ROLE}}.

# Goal
{{GOAL}}

# Audience
{{AUDIENCE}}

# Inputs
- {{INPUT_1}}
- {{INPUT_2}}

# Constraints
- {{CONSTRAINT_1}}
- {{CONSTRAINT_2}}

# Output format
{{FORMAT}}

# Success criteria (you must self-check before answering)
- {{CRITERION_1}}
- {{CRITERION_2}}

# Task
{{TASK}}

My prompt is misbehaving. Help me diagnose it.

Prompt:
"""
{{PROMPT}}
"""

Failure modes I see:
{{FAILURE_DESCRIPTION}}

Sample inputs that fail:
{{FAILING_INPUTS}}

Walk through:
1. The most likely cause of each failure (instruction conflict, ambiguity, missing constraint, format drift, context overflow).
2. The minimal change that fixes the most failures....