Prompts

Translate the text below into clear English. Keep terms, code, and names. Give the translation first, then list three edits and why you made them. Mark anything you are unsure about. Do not invent facts. {text}

You are the interviewer for the role {role}. Ask one question at a time. After my answer, name what I missed, then ask the next question. After 8 questions, give a short verdict for this role: hire, hold, or no, and the evidence.

Review the change below. List only issues that make it wrong, slow, or hard to maintain. For each one, name the file, the severity (high, medium, low), and the fix. Do not rewrite the file. If nothing is wrong, say so.

Turn the notes below into a weekly report with three parts: done this week, not done and why, three items for next week. One sentence each. Keep the numbers. Do not add self-praise.

Write an Excel formula for this task: {task}. The columns are listed below. Put the formula first, then compute it on two sample rows. If you need another column, say so. Do not use a column I did not name.

Answer this with standard SQL: {question}. The schema is below. Write the query first, then name the tables it uses. Do not invent columns. If the question is vague, ask one question before you write SQL.

Write a JavaScript regular expression that matches {should match} and does not match {should not match}. Give the expression, then two strings that pass and two that fail.

Explain the code below to someone who just joined the repository. Start with three sentences on what it does, then walk the execution order. Name the inputs, the outputs, and how it fails. Do not change the code.

Write a commit message for the diff below. The first line is at most 72 characters and says what changed. After a blank line, say why. Do not write "update" or "fix bug".

Make this change: {task}. Touch only the lines the task needs. Do not reformat, rename, or rewrite neighboring code. When you finish, name the files you changed and how to verify the behavior stayed the same.

The defect is: {symptom}. First write the steps or the test that reproduces it. Do not change product code until that fails for the reason I described. Then make the smallest fix and say why that was the cause.

For this behavior, {behavior}, write a test that fails first. Show the failure, then write the implementation that makes it pass. Do not start with the implementation. After it passes, do not add features I did not ask for.

Read the files that bear on this task: {task}. List the facts you found and what is still unclear. Do not edit anything in this step. Wait until I confirm, then change the code.

Do not write code yet. For this goal, {goal}, give a short plan: files you would change, what you will not do, and how we will know it is done. If two approaches are equally reasonable, stop and ask which one I want.

Read the diff below and report only security issues: injection, broken access control, a secret in the tree, or unsafe deserialization. For each one, name the file and how it is triggered. If there are none, say so. Skip style comments.

Write 5 title tags and 5 meta descriptions for a page about {topic}. Keep each title within 60 characters and each description within 160. Use the words a person would search. Do not stuff keywords.

Write the hero for {product}: one outcome, one sentence under 40 words, and one button. The button must say what the click opens. No slogan. No row of three features.

Rewrite the text below so it sounds like a person talking to one specific reader. Cut filler and parallel slogans. Keep every fact, number, and file path. Then list the stock phrases you removed.

Write 10 titles for the piece below. Five state the outcome. Five include one concrete detail. Do not use "ultimate", "unlock", or "empower". Keep each title under 12 words.

Write 3 short ads for {product}. Each one speaks to one buyer and one job. Name the buyer, the trouble they have now, and what the click gives them. Do not stack adjectives.

Write a Xiaohongshu note about {topic}. The first line is the title. Keep the body under 300 Chinese characters. Include one concrete detail from use, and end with a question. Name 3 shots that would fit. Do not use hype slang.

Reply to the email below. Answer the request in the first sentence, then say what you need from them, then give a time. Be direct. Do not open with "I hope this email finds you well."

Turn the transcript below into notes. Keep decisions, owners, dates, and open questions. Cut the discussion. Flag any item that has no owner.

The target role is {role}. Rewrite the experience below into 5 resume lines. Start each with a verb and include a number or an artifact. Cut what the role does not need. Do not invent experience I did not write.

The role is above and the candidate notes are below. List the requirements they meet, the ones they miss, and the ones the notes never mention. Do not guess at personality. End with interview or not, and the evidence.

Plan 3 days in {city}. One thing each morning, afternoon, and evening, plus how to get between them. Mark anything that needs a booking. Do not add shopping I did not ask for. The budget is {budget}.

Write a short story under 800 words from this setup: {setup}. One main character, one thing they need to finish, and a change at the end. No chapters. Do not state a moral out loud.

Turn this plot into one scene: {plot}. Write only the slugline, the action, and the dialogue. The lines must be sayable. No camera jargon. No interior thoughts.

The claim is: {claim}. Give the three strongest points for it, then the three strongest points against it. One sentence each, plus the fact it depends on. Do not declare a winner.

Teach me {topic}. Explain the core with one concrete example, then give me two questions. Do not start the next section until I answer. If I am wrong, point only to the step that failed.

I want to understand {question}. Do not give the answer. Ask one question at a time that narrows it down. Wait for my reply. Explain only when I say "give the answer."

Read the paper below. Summarize it in 8 sentences: problem, method, data, result, and the limits the authors state. After each sentence, name the section it came from. Do not add what the paper does not say.

Compare {option A} and {option B} for this goal: {goal}. Make a table of cost, what must change, and what happens if it fails. Every cell needs a reason. If you do not have one, write unknown. Do not guess.

Look at the interface below. Comment only on hierarchy, spacing, hit area, and focus. List three changes. For each, say what is wrong now and what it should look like after. Do not restyle the whole page.

Write an image prompt for {subject}. State what is in the frame, the light, the crop, and what must not appear. One paragraph, not a pile of keywords. Give two versions: square and wide.

Propose 12 names for {product}. Each one should work as a domain: short, sayable, no hyphens. Avoid generic words everyone already uses. After each name, one sentence on what it points to.

I want to say: {sentence}. Give a more natural version first, then name what was off (word choice, order, or tone). Then give a shorter line I can repeat.

I need to do this on {system}: {task}. List the commands, one per line, and say what each one changes. Do not pretend to be the terminal. Stop and ask before any destructive command.

Read the JavaScript below. List what each console call prints, in order. If it throws, name the error and the line. Do not change the code unless I ask you to fix it.

Split {system} into modules. For each one, write what it owns, what it does not own, and one interface it exposes. No more than 6 modules. Do not write the implementation.

Read the piece below. Write a summary in at most 40 words. Then list up to 8 ideas the text actually states, up to 5 exact quotes only when they appear, and one takeaway. If a section has nothing to extract, write "none". Do not invent quotes. {text}

Read the git diff below. Write a pull request in Markdown with these sections: Summary, Files changed, Reason, Impact, Test plan. For each file, say what changed. If the diff does not show a test, write that the test plan is missing. Do not rewrite the code.

Read the log below. List anomalies and issues that repeat. For each one, cite the line or timestamp that supports it. Then list only changes the log itself supports. If the cause is not in the log, say so. Do not guess a fix from outside the file.

Turn this product note into a Markdown PRD: Overview, Objectives, Audience, Features, Functional requirements, Non-functional requirements, Success metrics. Each requirement must be testable. Where a fact is missing, write "unknown". Do not add a feature the note does not mention. {note}

Write one user story for {feature}. Use three lines: As a {role} / I want / So that. Then list acceptance criteria as plain bullets a tester can check. Do not add a second story. Leave out any criterion the note does not support. {note}

Write a design note for {system}. Use these sections: Business goal, Context, Containers, Deployment, Risks, Questions and assumptions. Context, Containers, and Deployment each get one mermaid diagram and a table with name, type, and responsibility. For security, name only controls the description already states. If it states none, write that. Do not describe how to attack the system. {description}

Read the Terraform plan below. One sentence on what will change. Then list the critical creates, updates, and destroys. List cost and access changes only when the plan text shows them. If cost is absent, write "cost not shown". Do not invent prices or attack steps.

Read the diff below. First line: at most 100 characters, present tense, prefixed with one of feat, fix, docs, refactor, test, or chore. Then at most 6 bullets. Each bullet is one short present-tense clause about a behavior change. Skip files that only move whitespace.

Read the argument below. For each weak step, name the fallacy in plain words, quote the sentence, and say why that step does not prove the conclusion. A weak step does not make the conclusion false. If the argument holds, say so. Do not list a fallacy the text does not use.

Rewrite the prompt below so a model can follow it. Keep the same job. Add the output shape, the length, what to leave out, and a placeholder for the input. Put the input in a clearly marked block. Do not add a persona. Return only the rewritten prompt. {prompt}

Write a bug report for {symptom}. Use these fields: Title, Environment, Steps, Expected, Actual, Severity. The title names the component, the action, and the symptom. Steps are numbered and minimal. Severity is critical, high, medium, or low, with the impact on the person using it. If I did not give a field, write "unknown". Do not propose a code fix.

For {behavior}, write a test plan in three groups: unit, integration, end to end. Each case is one sentence in the form given / when / then, and it checks one behavior. Put most cases in unit. Name at most 2 end-to-end cases, and only for a path a person takes. Do not write the test code. Do not use a fixed wait.

Turn {feature} into requirements a tester can check. Each line uses one shape: WHEN [event], THE SYSTEM SHALL [behavior]; or WHILE [state], THE SYSTEM SHALL [behavior]; or IF [unwanted condition], THEN THE SYSTEM SHALL [response]. Then list edge cases the note does not already cover, and mark each one "proposed". Do not write a design or code.

Record one decision about {choice}. Sections: Decision, Context, Options, Rationale, Impact, Review. Options are only the ones I named. If I named one, write that alternatives were not provided. Rationale states the trade-off. Review states what would make us reopen it. Do not invent a metric.

Read the diff below. List only the docs a reader would need updated: README, changelog, API reference, config example, or migration note. For each one, name the section and the fact in the diff that makes it stale. If the diff has no change a user would notice, say no doc update is required. Do not draft a feature the diff does not contain.

The examples come first, then the new input. Answer in the same shape as the examples. Use only labels that appear in the examples. If the new input fits none of them, write "no fit" and name the closest example. Do not invent a label. {examples} New input: {input}

Answer {question} three times. Each path uses a different method, stays under 80 words, and ends with a line that starts "Answer:". Then say whether the three answers agree. If they agree, give that answer. If they do not, list the disagreement. Do not blend them into a new number.

Write about {topic}. Use only these sections, in this order: {sections}. Stay under {limit} words in total. If a section needs a fact I did not give, write "unknown" there. Do not add a section, a slogan, or a fact from outside my note.

Write about {topic}. Leave out everything in this list: {exclude}. Do not name those items, and do not describe them under another name. Then remove any sentence that still touches the list. If nothing remains, say the exclusion removed the answer.

Find a skill that can generate a PowerPoint from a markdown outline, then install it.

Grill me on this migration plan. Do not let me skip rollback, data size, or owner gaps.

Redesign this marketing homepage. Follow Frontend Design. No purple gradients, no three-card feature row.

Open the staging dashboard, log in with the env credentials, and list the failing jobs from the last hour.

Audit src/app/dashboard/page.tsx against Vercel React Best Practices. Fix the top three issues.

Check this landing page against Web Design Guidelines. List failures with file paths.

Create a skill that turns a GitHub issue into a test-first implementation plan.

Merge these three PDFs, set a real document title, and extract the table on page 4.

Turn this one-pager into a 10-slide investor deck. Keep one idea per slide.

Merge these three CSVs on sku, drop duplicate rows, and write inventory.xlsx.

Design an MCP server for our internal ticket API. Three tools max. Show the schema first.

The checkout total is wrong only for EUR. Diagnose. Do not patch until you can reproduce it.

Propose a module map for this billing folder. Name the seams and the tests each seam needs.

Model refunds for this shop. List illegal state pairs before you write a function.

Compare Agent Skills and MCP for a coding agent. Cite primary docs. Note what is still unclear.

Edit this README. Cut the AI tells. Keep every command and file path exactly as written.

Teach me Astro content collections. Quiz me before the next lesson. Save progress in ./notes.

Remember that we use trailingSlash never and English as the default locale. Write it into agent notes.

Rewrite this component in Vue 3 composition API. Match our local vue version. No Vuex.

Audit /guides/install-agent-skills for title length, canonical, and a single h1.

Rewrite the hero. One outcome. No buzzwords. CTA must say what the click opens.

Turn this outline into a Word brief with Heading styles, a title page, and comments on open questions.

Start the dev server, then Playwright-test the checkout flow for an empty cart and a logged-in user.

Add an orders table with RLS so users only see their own rows. Show the migration and policies.

Refactor this settings page to compound components. Stop threading theme and title through five layers.

Build a profile screen in Expo. Use a FlatList for posts. No web-only div layout.

Add Checkout for a one-time purchase. Verify the webhook signature and store payment state idempotently.

Create a Neon branch for this PR, run migrations on the branch, and point the preview env at it.

Build a 15-second product intro in Remotion. Title card, three feature beats, end logo. 1080p.

The flaky test fails one in five runs. Use Systematic Debugging. Do not patch until you can reproduce it.

Add rate limiting with TDD. Show the failing test first, then the implementation.

Redesign this settings page. Fix hierarchy, spacing, and focus states. No stock purple gradient.

I need auth on this API. If anything is underspecified, ask me before you invent a scheme.