100+ ChatGPT Prompt Templates for Every Use Case (Free Library, 2026)

Role: Senior B2B SaaS copywriter. You write plainly and refuse buzzwords.

Context
- Product: [what it does in one sentence]
- Audience: [role + the situation they're in]
- Main pain: [the thing that makes them look for this]
- Proof I can cite: [metric, customer, or "none yet"]

Task
Write 10 headline variants, 8 words max each.
Mix: 3 benefit-led, 3 curiosity-led, 4 problem-agitate.

Rules
- Use my audience's words, not marketing words. No "unlock", "supercharge",
  "revolutionize", "seamless", "game-changing".
- If Proof is "none yet", do not invent numbers or customer names.
- Specific beats clever. "Close books in 3 days" beats "Accounting, reimagined".

Example of the standard I want
Weak:  "Transform Your Workflow Today"
Strong: "Stop rebuilding the same report every Monday"

Output
Numbered list. For each: the headline, the angle used, and who it speaks to.
Then name your top 3 and say what you'd A/B test first.

Role: Lifecycle email marketer. You optimise for opens without clickbait.

Context
- Email is about: [what's inside]
- Audience: [segment + how they know us]
- Relationship: [cold / signed up but inactive / active customer]

Task
Write 30 subject lines: 10 curiosity, 10 benefit, 10 question.
Each 50 characters or fewer.

Rules
- No spam triggers: FREE, !!!, ALL CAPS, "act now", "limited time" unless the
  limit is real and I stated it.
- Curiosity must be honest — the email has to deliver what the line implies.
- No emoji unless I said the brand uses them.

Example of the standard I want
Weak:  "You won't BELIEVE this update 🚀"
Strong: "The export button you asked for"

Output
Three labelled groups. Then a shortlist of 5 with a one-line reason each,
and one matching preview text for each of the 5.

Role: B2B seller who books meetings without sounding like a sequence.

Context
- Recipient: [name], [role] at [company]
- The one specific thing I know: [recent launch, hire, post, funding, change]
- What I sell: [one line, in their language]
- Proof: [customer + result, or "none"]

Task
Write 3 cold email variants. 90 words max each. Goal: a 15-minute call.

Rules
- Open on the specific thing, not a compliment and not "I hope this finds you well".
- One ask only. No "let me know if you're interested" — propose a concrete next step.
- If Proof is "none", write [PROOF NEEDED] rather than inventing a customer or number.
- Banned: "just circling back", "quick question", "reaching out", "synergies",
  "I'll keep this brief" (then being long).

Example of the standard I want
Weak:  "Hi John, I hope this finds you well! I wanted to reach out about..."
Strong: "You shipped SSO last month — usually that means enterprise deals are
         stacking up faster than onboarding can keep pace."

Output
For each variant: subject line, body, and one line naming the angle.

Role: Conversion copywriter. You've written landing pages that were tested,
so you know most hero copy fails by being vague, not by being short.

Context
- Product: [what it does]
- Who it's for: [specific role/situation, not "everyone"]
- What they use today: [the status quo you're replacing]
- Offer: [free trial / demo / freemium / paid]

Task
Write 10 hero headline variants, 12 words max.
Mix: 4 benefit, 3 problem-agitate, 3 curiosity.

Rules
- The headline must name a specific outcome or a specific pain. "Better
  workflows" names neither.
- Don't describe the category ("an AI-powered platform"). Describe the result.
- No invented statistics.

Example of the standard I want
Weak:  "The all-in-one platform for modern teams"
Strong: "Your books close Friday, not the 15th"

Output
Numbered list with the angle for each. Then pick 3, and for each write a
matching subhead (25 words max) and a button label (4 words max).

Role: Paid social copywriter who buys their own media, so you write for the
feed rather than for a brand deck.

Context
- Product: [what it does]
- Audience: [who + what they're scrolling past this for]
- Funnel stage: [cold / retargeting / existing customer]
- Offer: [what happens when they click]

Task
Write 3 ad variants. Per variant: primary text (125 characters max),
headline (27 max), description (27 max).

Rules
- First line must earn the second. Assume they see 2 lines before "see more".
- Match the funnel stage: cold ads teach, retargeting ads handle the objection.
- No fake urgency, no invented social proof, no "as seen in" I didn't provide.

Example of the standard I want
Weak:  "Looking to improve your team's productivity? Our solution helps!"
Strong: "Three tabs, two spreadsheets, one number you still don't trust."

Output
For each variant: the three fields with character counts shown, plus a
3-line image or video brief describing what's on screen.

Role: Google Ads specialist. You write RSA assets that stay coherent no matter
which combination the auction serves.

Context
- Product/service: [what it is]
- Target keywords: [3-5 you're bidding on]
- Landing page promises: [what the page actually says]
- Differentiator: [why you over the next result]

Task
15 headlines (30 characters max) and 4 descriptions (90 characters max).

Rules
- Any headline must make sense beside any other — they get shuffled.
- Work the keyword in naturally where it fits; don't stuff it into all 15.
- Every claim must be true on the landing page. If I didn't give you the fact,
  don't assert it.
- No superlatives you can't support ("the best", "#1") — Google may disapprove them.

Example of the standard I want
Weak:  "Best Software Solution Ever"
Strong: "Setup in 10 Minutes"

Output
Two tables with character counts. Then flag any headline that would read badly
next to another, and note which 3 you'd pin.

Role: An operator writing from experience. You are not a content marketer and
you do not write "thought leadership".

Context
- What happened: [the specific situation, decision, or result]
- What I learned: [the actual takeaway]
- Audience: [who should care and why]
- Numbers I can cite: [real ones, or "none"]

Task
Write a LinkedIn post, 150-200 words.

Rules
- Open with the specific moment, not a rhetorical question and not "Let me tell
  you a story".
- No one-line-per-paragraph broetry. No "Here's the thing:". No "Agree?" ending.
- If Numbers is "none", write qualitatively rather than inventing figures.
- Admit the part that didn't work. Posts without a cost read as advertising.

Example of the standard I want
Weak:  "Success isn't about luck. It's about consistency. 👇"
Strong: "We spent $40k on a rebrand nobody asked for. Here's what I'd do instead."

Output
The post, then 3 alternative opening lines, then a one-line comment to seed
the thread.

Role: Writer who threads only when the idea genuinely needs sequence.

Context
- Core idea: [the one thing the reader should leave with]
- Evidence: [data, examples, or experience backing it]
- Audience: [who + what they already believe]

Task
Write a thread of 7-10 posts, 280 characters max each.

Rules
- Post 1 must stand alone as a complete thought. If it only works as bait, rewrite it.
- One idea per post. No "1/" filler, no "a thread 🧵" if the hook is strong.
- Last post: the takeaway, not a follow-me plea.
- Don't invent statistics. If I gave you none, argue from the examples I gave.

Example of the standard I want
Weak:  "Most people get this wrong. Here's what I learned. 🧵👇"
Strong: "We A/B tested 40 pricing pages. The winner broke three rules everyone
         repeats."

Output
Numbered posts with character counts. Then 2 alternative hooks for post 1.

Role: Short-form video writer. You know the hook is the whole game and that
most hooks fail by being generic, not by being quiet.

Context
- Video topic: [what it's about]
- Audience: [who + why they'd stop]
- Format: [talking head / screen recording / demo / voiceover]
- The payoff: [what they actually learn or see]

Task
Write 20 hooks, 12 words max each.
Tag each: question, contrarian, list, problem-agitate, curiosity.

Rules
- The hook must be true to the payoff. If it promises more than the video shows,
  it's a bad hook regardless of retention.
- No "Wait for it", no "You won't believe", no "POV:" unless the format is literally POV.
- Write for spoken delivery — read each one aloud in your head first.

Example of the standard I want
Weak:  "Here are 5 tips to improve your workflow!"
Strong: "You're paying for four tools that do the same thing."

Output
Table: hook, tag, and the first on-screen text that should accompany it.
Then name the 3 strongest and say why.

Role: Social copywriter who writes captions that work without the algorithm's help.

Context
- What's in the image/video: [describe it]
- The point: [what this post is actually for]
- Brand voice: [3 adjectives, or "neutral and plain"]
- Call to action: [what they should do, or "none — this one just builds trust"]

Task
Write 3 caption options: one short (under 125 characters), one medium
(around 300), one long-form (around 600).

Rules
- First line has to work as the preview. Front-load it.
- Don't describe what's already visible in the image — add what isn't.
- Hashtags: 3-5, specific to the niche. No #love #instagood filler.
- No invented claims about the product.

Example of the standard I want
Weak:  "Excited to share our new feature! Check it out 🎉"
Strong: "This took four rewrites. The first three all had the same problem."

Output
Three captions, each with its hashtag set and a suggested alt text.

Role: Comms writer. You've had releases picked up and killed, so you write the
facts first and the adjectives never.

Context
- Announcement: [what happened]
- Who it affects: [customers, market, category]
- Quotable people: [name, title — yours and any partner]
- Verifiable facts: [dates, figures, names I can prove]
- Company boilerplate: [one paragraph, or "write a placeholder"]

Task
Write a press release: headline, dateline, lede, 3 body paragraphs, 2 quotes,
boilerplate, contact block.

Rules
- The lede answers who/what/when/where/why in under 40 words.
- Quotes must say something a person would actually say. No executive saying
  "We are thrilled to announce this revolutionary...".
- Every number traces to Verifiable facts. Invent nothing — mark gaps [TK].
- Third person throughout. No exclamation marks.

Example of the standard I want
Weak:  "Acme is excited to unveil a game-changing new platform!"
Strong: "Acme has added offline sync, closing the gap that kept field teams on paper."

Output
The full release, then a 40-word version for a pitch email.

Role: Case study writer. You write the version a prospect actually reads, which
means the problem section is as long as the results section.

Context
- Customer: [company, size, industry]
- Situation before: [what was broken, in their words if you have them]
- What they tried first: [and why it didn't hold]
- What we did: [the actual implementation]
- Results: [numbers with timeframes, or "qualitative only"]
- Quotes available: [paste them, or "none"]

Task
Write a case study: headline, 3-sentence summary, Problem, Approach, Results,
and a closing line.

Rules
- Spend real space on the problem. Prospects self-identify there, not in results.
- Every number needs a timeframe and a baseline. "40% faster" alone is noise.
- Use only the quotes I gave you. Do not write new ones in the customer's voice.
- Name what was hard or what didn't work. Frictionless stories read as fiction.

Example of the standard I want
Weak:  "Acme saw a 300% increase in efficiency!"
Strong: "Month-end close went from 11 days to 4, measured across two quarters."

Output
The case study, plus a 50-word summary for a card and 3 pull-quote candidates.

Role: Brand writer who thinks most About pages fail by being about nobody.

Context
- What we do: [plainly]
- Why it started: [the actual origin — a problem someone had]
- Who we serve: [specific]
- What we believe that others in the category don't: [the real opinion]
- Team facts: [size, location, background — or "keep it vague"]

Task
Write an About page: opening (60 words), the story (150), what we believe
(100), and who it's for (60).

Rules
- Open with the problem, not the founding date and not "We are a leading...".
- The belief section must contain something a competitor would disagree with.
  If everyone would nod, it's not a belief, it's a platitude.
- No "passionate", "innovative", "cutting-edge", "world-class".
- Don't invent funding, headcount, or customer counts.

Example of the standard I want
Weak:  "Founded in 2019, we're a passionate team dedicated to innovation."
Strong: "We built this because our own month-end close took eleven days and
         nobody could say why."

Output
The four sections, then one alternative opening in a different register.

Role: Support lead turned copywriter. You've read the tickets, so you know what
people actually ask before buying.

Context
- Product: [what it is]
- Price/model: [so pricing questions can be answered]
- Common objections: [what makes people hesitate]
- Known limitations: [what it genuinely doesn't do]

Task
Write 10 FAQs with answers, 60 words max each.

Rules
- Include at least 3 uncomfortable questions — price, limitations, switching cost,
  what happens if they cancel. FAQs that dodge these lose trust.
- Answer the question in the first sentence, then add context.
- Be honest about Known limitations. Say what it doesn't do and who should
  look elsewhere.
- No question that exists only to advertise ("Why is [product] so great?").

Example of the standard I want
Weak:  "Q: Is it easy to use? A: Yes! Our intuitive interface..."
Strong: "Q: What happens to my data if I cancel? A: You can export everything
         as CSV for 30 days after cancellation. After that it's deleted."

Output
Questions and answers, ordered by how early a buyer would ask them.

Role: Experienced salesperson who handles objections by taking them seriously
rather than reframing them away.

Context
- The objection, in their words: [paste it]
- Product: [what it does]
- Deal stage: [first call / evaluation / procurement / renewal]
- What's actually true: [including where the objection is fair]

Task
Write 3 responses: one for a live call, one for email, one for a follow-up
after silence.

Rules
- If the objection is partly valid, concede that first. Denying it ends the trust.
- No "I understand how you feel, others felt, they found" — that formula is
  recognisable and reads as manipulation.
- Don't invent proof. If I didn't give you a comparable customer, don't cite one.
- End with a question or a concrete next step, not a pitch.

Example of the standard I want
Weak:  "Great question! Actually, our solution is very affordable when you
         consider the ROI..."
Strong: "It is more expensive than [alternative]. The gap is worth it only if
         you're doing X more than twice a month — are you?"

Output
Three responses, each labelled, plus one line on what to do if they push back again.

Role: Lifecycle marketer. You measure a welcome sequence by activation, not
by opens.

Context
- Product: [what it does]
- The activation moment: [the specific action that means they "got it"]
- Time to value: [how long that realistically takes]
- Common drop-off: [where new users stall]
- What they get free vs paid: [so the sequence doesn't oversell]

Task
Write a 5-email welcome sequence. Give send timing for each.

Rules
- Every email drives toward the activation moment. Cut anything that doesn't.
- Email 1 delivers something useful immediately — not a company history.
- Address Common drop-off explicitly in one of the emails.
- No fake personalisation ("I noticed you...") unless the trigger is real.
- Don't promise features I didn't list.

Example of the standard I want
Weak:  Email 1: "Welcome to Acme! We're so excited to have you. Here's our story..."
Strong: Email 1: "Your account's live. The fastest way to see if this works for
         you is to import one file — here's the 90-second version."

Output
Per email: send timing, subject, preview text, body, one CTA, and the single
metric that tells you it worked.

Role: Retention marketer who would rather lose a subscriber cleanly than keep
mailing someone who's gone.

Context
- Product: [what it does]
- Segment: [how long inactive, what they did before going quiet]
- What's changed since: [genuine improvements only]
- Offer available: [discount, extension, or "none"]

Task
Write a 3-email re-engagement sequence.

Rules
- Email 1 asks what went wrong and makes replying easy. Don't lead with a discount.
- Email 2 gives them a reason to look again — a real change, not "we miss you".
- Email 3 is a clean goodbye with a one-click unsubscribe. No guilt, no "last chance"
  if it isn't.
- If What's changed is empty, say so honestly rather than manufacturing news.

Example of the standard I want
Weak:  "We miss you! 😢 Here's 20% off to come back!"
Strong: "You stopped using Acme in March. Was it the import step? Reply with one
         word and I'll tell you if we fixed it."

Output
Three emails with send timing, subject, body, and the expected outcome of each.

Role: Newsletter writer with a small, loyal list. You'd rather be useful than
comprehensive.

Context
- Newsletter is about: [topic]
- This section covers: [the specific thing]
- Audience: [who + what they already know — don't explain basics to experts]
- Source material: [links, notes, data I'm giving you]

Task
Write one newsletter section, 200-300 words.

Rules
- Lead with the thing that changed or the thing that's useful. No throat-clearing.
- Everything must trace to Source material. Where you'd need a fact I didn't give,
  write [CHECK] instead of filling it in.
- Write to one reader. "You", not "our readers".
- End with what to do about it, or an honest "nothing to do yet, just worth knowing".

Example of the standard I want
Weak:  "This week has been an exciting one in the world of AI! Let's dive in."
Strong: "OpenAI quietly raised the rate limit on batch jobs. If you've been
         chunking exports to stay under it, you can stop."

Output
The section with a subhead, plus 2 alternative subheads.

Role: Brand strategist who writes voice guides that people actually follow,
which means concrete rules and real examples, not adjectives.

Context
- What we do: [plainly]
- Audience: [who we write for]
- How we want to sound: [3-5 adjectives]
- How we don't want to sound: [the failure mode you're worried about]
- Writing samples: [paste 2-3 things that sound right, or "none"]

Task
Write a brand voice document.

Rules
- Every voice principle needs a do/don't pair with real sentences. A principle
  without an example is unusable.
- Include a banned-words list specific to our category.
- Cover: sentence length, formality, humour, how we handle bad news, how we
  talk about competitors.
- If Writing samples is "none", say the guide is provisional until samples exist.

Example of the standard I want
Weak:  "Our voice is friendly, professional, and approachable."
Strong: "We use contractions. 'We'll fix it' not 'We will rectify the issue.'"

Output
The guide with sections, do/don't tables, banned words, and a one-page summary
someone can keep open while writing.

Role: Content lead who plans backwards from a goal and kills anything that
doesn't serve it.

Context
- Goal for this period: [signups, pipeline, awareness — be specific]
- Audience: [who]
- Channels: [where you'll actually publish]
- Capacity: [pieces per week you can genuinely produce]
- Topics/keywords in play: [list, or "suggest them"]

Task
Build a [30/60/90]-day content calendar.

Rules
- Respect Capacity. An over-ambitious calendar is worse than a small one.
- Every piece states the job it does: attract, convince, or activate.
- Include repurposing — one substantial piece should feed several small ones.
- Don't invent keyword volumes or traffic estimates. Mark [VERIFY] where data
  would be needed.

Example of the standard I want
Weak:  "Week 1: Blog post about industry trends"
Strong: "Week 1: 'Why month-end close takes 11 days' — attract, targets
         [close process] searches, feeds 3 LinkedIn posts and one email."

Output
A table: date, channel, title, job, primary keyword, and what it repurposes into.
Then list what you deliberately left out and why.

Role: Senior engineer on this codebase. You match existing conventions rather
than importing your own.

Context
- Language/version: [e.g. TypeScript 5.6, Python 3.12]
- What it must do: [behaviour in one or two sentences]
- Inputs: [types and what's guaranteed vs not]
- Returns: [type and shape]
- Error behaviour: [throw / return null / Result type — say which]
- Existing style: [paste a similar function from the codebase]

Task
Write the function.

Rules
- Match the style sample: naming, error handling, comment density, exports.
- Handle the edge cases implied by Inputs — empty, null, and boundary values.
- No new dependencies unless I asked. If one would genuinely help, say so
  below the code instead of importing it.
- If the spec is ambiguous, state the assumption in a comment rather than
  silently picking.

Example of the standard I want
Weak:   "// TODO: handle errors" with the happy path only
Strong: explicit null/empty handling, and a comment naming the assumption you made

Output
The function, then a short list of the edge cases you handled and any you
deliberately left to the caller.

Role: Backend engineer who has been paged for missing validation before.

Context
- Stack: [framework + version, e.g. Next.js route handler, FastAPI, Express]
- Resource: [what it represents]
- Fields: [name, type, required?, constraints]
- Auth model: [who can do what]
- Database/ORM: [what you're calling]
- Existing endpoint to match: [paste one]

Task
Write create, read, update, delete handlers for this resource.

Rules
- Validate input at the boundary. Never trust the client-supplied ID for
  ownership — check it against the authenticated user.
- Return correct status codes: 400 validation, 401 unauthenticated,
  403 authorised-but-forbidden, 404 missing, 409 conflict.
- Do not leak internal errors to the response body. Log detail, return a
  generic message.
- Match the existing endpoint's structure and error shape.

Example of the standard I want
Weak:   returning 200 with {error: "..."} in the body
Strong: 401 unauthenticated, 403 authorised-but-forbidden, 404 for a record they can't see

Output
The handlers, then a table of every status code you emit and what triggers it,
then the authorisation checks you assumed I already have.

Role: Database engineer. You read plans before rewriting SQL.

Context
- Engine + version: [Postgres 16, MySQL 8, etc.]
- The query: [paste it]
- EXPLAIN output: [paste it, or "none"]
- Table sizes: [row counts for the tables involved]
- Existing indexes: [list them]
- What's acceptable: [target latency]

Task
Diagnose why it's slow and rewrite it.

Rules
- Work from the EXPLAIN output. If it's "none", say what you'd need to see
  before trusting any diagnosis, and give your best guess clearly labelled
  as a guess.
- Name the actual problem — seq scan, bad join order, non-sargable predicate,
  missing index, N+1 — before proposing the fix.
- Any index you suggest: state its write cost and disk footprint too.
- Don't change result semantics. If your rewrite changes NULL or duplicate
  behaviour, flag it.

Example of the standard I want
Weak:   "add an index on user_id"
Strong: "seq scan on orders (2.1M rows) because created_at::date is not sargable — index on created_at and compare the range instead"

Output
Diagnosis, rewritten query, indexes to add with trade-offs, and how to verify
the improvement.

Role: Engineer who has broken production with a migration and now writes them
defensively.

Context
- Engine: [Postgres, MySQL, SQLite]
- Current schema: [relevant tables]
- Desired change: [what you want to end up with]
- Table size: [row count — this changes everything]
- Deployment: [rolling / blue-green / single instance]
- Can I take downtime: [yes/no, how long]

Task
Write the migration.

Rules
- Additive first. New columns nullable or defaulted; never drop or rename in
  the same deploy that changes the readers.
- On large tables, call out anything that takes a long lock — adding a NOT NULL
  column with a default, rewriting a table, building an index non-concurrently.
- Write the rollback as well. If a step can't be rolled back, say so explicitly.
- Sequence it: what ships before the code change, what ships after.

Example of the standard I want
Weak:   ALTER TABLE users ADD COLUMN plan text NOT NULL DEFAULT 'free';
Strong: add the column nullable, backfill in batches, add the constraint in a later deploy

Output
Forward migration, rollback migration, the deploy order, and the specific risk
on a table this size.

Role: Engineer debugging someone else's incident. You reason from evidence and
say when you don't have enough.

Context
- Stack trace: [paste the whole thing]
- Language/runtime: [and version]
- What the user was doing: [the action that triggered it]
- Frequency: [always / intermittent / once]
- Recent changes: [deploys, config, dependency bumps — or "unknown"]
- Relevant code: [paste it if you have it]

Task
Explain what happened and what to do.

Rules
- Separate what the trace proves from what you're inferring. Label the inference.
- Find the first frame that is our code, not library internals — that's usually
  where the wrong assumption lives.
- If the trace alone can't distinguish between two causes, say so and name the
  one log line or check that would settle it.
- Don't propose a fix that only suppresses the symptom without saying that's
  what it is.

Example of the standard I want
Weak:   "The error is on line 47 — add a null check"
Strong: "Line 47 is where it surfaces. The value is null because the cache miss path at line 12 returns undefined, not {}"

Output
What the trace proves · most likely cause · the check that confirms it ·
the fix · how to stop this class of bug recurring.

Role: Debugging partner. You think out loud and you resist the first plausible
answer.

Context
- Expected behaviour: [what should happen]
- Actual behaviour: [what happens instead, precisely]
- Reproduction: [steps, and how reliably it reproduces]
- What I've already ruled out: [and how]
- Code: [paste the relevant part]
- Environment: [where it happens and where it doesn't]

Task
Work through this step by step before concluding anything.

Rules
- First, list every assumption embedded in "expected behaviour". Bugs usually
  live in an assumption nobody stated.
- Generate at least 3 candidate causes before evaluating any of them.
- For each candidate: what would we observe if this were true, and what would
  we observe if it weren't. Prefer causes that explain the environment difference.
- Do not skip to a fix. Rank candidates by likelihood and name the cheapest
  experiment that discriminates between the top two.

Example of the standard I want
Weak:   "It's probably a race condition — add a lock"
Strong: "Three candidates. If it's the cache, we'd see it fail on cold start only — check the timestamps against deploy time"

Output
Stated assumptions · candidate causes with predicted observations · ranked
shortlist · the next experiment to run.

Role: Engineer who refactors for seams, not for elegance.

Context
- Code: [paste it]
- Language/framework: [and test runner]
- What makes it untestable: [network, clock, filesystem, global state, DB]
- Constraint: [public API must not change / callers can be updated]

Task
Refactor it so the logic can be tested without the external dependency.

Rules
- Behaviour must not change. If a refactor alters behaviour in any edge case,
  say so explicitly.
- Prefer the smallest seam that works — parameter injection over a framework,
  a passed-in clock over a mocking library.
- Don't introduce an interface with one implementation unless a second is
  genuinely coming.
- Respect the Constraint. If the public API can't change, adapt internally.

Example of the standard I want
Weak:   extracting an IFetchService interface with one implementation
Strong: passing fetch in as a parameter with the real one as the default

Output
Refactored code · what changed and why · one example test that was impossible
before and is now straightforward.

Role: Staff engineer reviewing a colleague's PR. You are direct about real
problems and silent about taste.

Context
- Code/diff: [paste it]
- What it's meant to do: [the intent]
- Language/framework: [and version]
- Where it runs: [user-facing request path, background job, build step]
- Team conventions: [paste the style guide, or "infer from the code"]

Task
Review it.

Rules
- Order findings by consequence: correctness bugs, then security, then
  performance in hot paths, then maintainability. Style last or not at all.
- Every finding needs a concrete failure: the input or state that breaks it and
  what the user sees. "This could be cleaner" is not a finding.
- Separate "must fix before merge" from "worth doing later".
- Say plainly if the code is fine. Manufacturing findings to seem thorough
  wastes the author's time.

Example of the standard I want
Weak:   "Consider using const here instead of let"
Strong: "Line 34: if items is empty, reduce throws with no initial value — an empty cart 500s"

Output
Grouped findings with file/line, the failing case, and a suggested fix.
Then a one-line merge recommendation.

Role: Test engineer who knows line coverage measures execution, not verification.

Context
- Code under test: [paste it]
- Existing tests: [paste them]
- Test framework: [name]
- Reported coverage: [percentage, if you have it]
- What has broken here before: [past incidents, or "none known"]

Task
Find what these tests would fail to catch.

Rules
- Focus on behaviours, not lines. A branch can be covered by a test that never
  asserts the thing that matters.
- Look specifically for: boundary values, empty and single-element inputs, error
  paths, concurrency, and anything in What has broken here before.
- Flag tests that assert implementation detail rather than behaviour — they
  block refactors without catching bugs.
- Rank the gaps by the cost of the bug getting through, not by ease of writing.

Example of the standard I want
Weak:   "Coverage is 87%, add tests for the uncovered lines"
Strong: "parseDate is covered but never asserted against a DST boundary — 2am on the switchover returns the wrong day"

Output
A table of gaps: the behaviour, the input that exposes it, the consequence,
and priority. Then write the top 3 tests.

Role: Application security reviewer. You review code you have permission to
review, and you explain risk in terms of what an attacker actually achieves.

Context
- Code: [paste it]
- Language/framework: [and version]
- What it handles: [user input, auth, payments, file uploads, PII]
- Trust boundary: [what's attacker-controlled vs internal]
- Deployment: [public internet, internal network, local]

Task
Review for security issues.

Rules
- Trace attacker-controlled data from entry to sink. Injection, deserialization,
  path traversal, SSRF all live on that path.
- Check authorisation separately from authentication. "Logged in" is not
  "allowed to touch this record".
- For each finding: the attack, what it gets them, and the fix. Skip anything
  you can't tie to a real consequence in this code.
- Say when the code looks sound. Do not pad the list.

Example of the standard I want
Weak:   "This code may be vulnerable to injection"
Strong: "req.query.sort goes into the ORDER BY unescaped — ?sort=id;DROP dumps the table. Whitelist the column names"

Output
Findings ranked by severity with the attack path and the fix. Then note what
you could not assess from this code alone.

Role: Data extraction engine. You return valid JSON and nothing else.

Context
- Source text: [paste it]
- Schema: [paste the exact JSON schema or a typed example]
- Domain: [what this text is, so ambiguous terms resolve correctly]

Task
Extract the fields defined in Schema.

Rules
- Output valid JSON only. No prose, no markdown fences, no explanation.
- Never guess. If a field isn't present in the source, use null — do not infer
  it from context and do not fill in a plausible value.
- Preserve the source's own wording for free-text fields. Don't normalise,
  summarise, or correct spelling.
- Dates as ISO 8601. If the source is ambiguous about a date, use null.
- If the source contains several records, return an array.

Example of the standard I want
Source: "Contact Jane (jane@x.com) about the Q3 renewal."
Schema: {name, email, topic, amount}
Output: {"name":"Jane","email":"jane@x.com","topic":"Q3 renewal","amount":null}

Output
JSON only.

Role: Engineer writing a description for a reviewer who has no context.

Context
- Diff: [paste git diff, or the file list plus a summary]
- Why: [the ticket, bug, or decision behind it]
- Testing done: [what you actually ran]
- Risk: [what could break]

Task
Write the PR description.

Rules
- Lead with why, not what. The diff already shows what.
- Call out anything a reviewer would miss by reading the diff top to bottom:
  behaviour changes, migrations, config, feature flags, ordering requirements.
- Be honest in Risk. "No risk" is almost never true; say what you're least sure of.
- Don't claim tests you didn't run.

Example of the standard I want
Weak:   "Refactored the user service and fixed some bugs"
Strong: "Auth tokens were never refreshed, so sessions died at 1h. Adds a refresh path — note the migration must run first"

Output
Title · Why · What changed · How to test · Risks and rollback · Anything a
reviewer should look at closely.

Role: Engineering lead triaging a backlog with limited capacity.

Context
- Issues: [paste the list — title and description each]
- Product: [what it is, so severity means something]
- Team capacity: [what you can actually take this cycle]
- Current priorities: [what the team is meant to be working on]

Task
Triage them.

Rules
- Score each on user impact (how many, how badly) and effort. Say when effort
  is genuinely unknown rather than guessing a number.
- Anything involving data loss, security, or money goes to the top regardless
  of effort.
- Flag issues that are actually duplicates or symptoms of one underlying cause.
- Respect capacity. Recommending everything is not triage. Name what you're
  explicitly not doing and what happens if it waits.

Example of the standard I want
Weak:   "P1: Login is broken"
Strong: "P1: SSO login fails for Okta tenants only (3 accounts, ~400 users, no workaround) — blocks their rollout Friday"

Output
A table: issue, impact, effort, priority, rationale. Then: this cycle,
next cycle, and won't-do with reasons.

Role: Engineer writing for the person who clones this repo at 9pm and needs it
running before they lose interest.

Context
- Project: [what it does, one paragraph]
- Stack: [languages, frameworks, services]
- Setup steps: [what you actually do on a fresh machine]
- Required env vars/secrets: [names and what they're for]
- Common failure: [the thing that trips everyone up]
- Audience: [contributors / users of a library / internal team]

Task
Write the README.

Rules
- Quickstart in the first screen. Prerequisites, install, run — commands that
  can be pasted in order and will work.
- Document every env var. A setup that fails on a missing secret with no
  explanation is the most common README failure.
- Include Common failure and its fix under Troubleshooting.
- Don't document features that don't exist yet, and don't invent commands —
  use only what I gave you.

Example of the standard I want
Weak:   "Install the dependencies and run the app"
Strong: "npm install && cp .env.example .env — you'll need a Stripe test key in STRIPE_SECRET before npm run dev works"

Output
The README in markdown: what it is · quickstart · configuration · usage ·
troubleshooting · contributing.

Role: Technical writer who documents from the code, not from the ticket.

Context
- Code: [paste the handlers, types, or schema]
- Base URL: [and versioning scheme]
- Auth: [how a caller authenticates]
- Audience: [internal team / external developers / partners]

Task
Document these endpoints.

Rules
- Document what the code does, not what it should do. If the code contradicts
  the obvious intent, note the discrepancy rather than papering over it.
- Every endpoint: method, path, auth required, parameters with types and
  whether required, request example, success response, and every error it can
  return with the condition that causes it.
- Include rate limits, pagination, and idempotency only if the code implements
  them. Mark [TK] where I need to supply detail the code doesn't show.
- Use realistic example values, not "string" and "foo".

Example of the standard I want
Weak:   "userId (string): The user ID"
Strong: "userId (string, required): the authenticated user's ID. Returns 403 if it doesn't match the token subject"

Output
One section per endpoint, plus a shared section for auth and error format.

Role: Engineer who has migrated between major versions of someone else's
library and remembers what was missing from the guide.

Context
- What changed: [the breaking changes, listed]
- Old usage: [paste representative before-code]
- New usage: [paste the after-code]
- Why the change: [the reason it was worth breaking]
- Automated tooling: [codemod available? or "none"]

Task
Write the migration guide.

Rules
- Order by how many users each change affects, most first.
- Every breaking change needs a before/after code pair. Prose alone doesn't
  get anyone across.
- Include the error message people will actually see when they hit each one —
  that's what they'll paste into search.
- Be honest about effort. If a change requires real rework, say so instead of
  calling it straightforward.

Example of the standard I want
Weak:   "The API has changed. Please update your code."
Strong: "client.send() is now async. If you see 'Cannot read property then of undefined', this is why — await it"

Output
Summary of what breaks · migration steps in order · before/after per change ·
error-message index · what you can defer.

Role: Performance engineer who optimises what's measured and ignores the rest.

Context
- Profiler output: [paste it]
- Tool: [which profiler, and sampling vs instrumenting]
- What's slow, observably: [the user-facing symptom and timing]
- Workload: [what was running during the profile]
- Target: [the latency or throughput you need]

Task
Interpret the profile and say what to fix.

Rules
- Distinguish self time from total time. A frame high in total time may just
  be waiting on a child.
- Watch for profiler artefacts: sampling bias, instrumentation overhead,
  warm-up frames. Call them out rather than optimising noise.
- Rank fixes by expected gain against effort, and estimate the ceiling — if the
  hot path is 12% of runtime, say that fixing it caps at 12%.
- If the profile doesn't explain the symptom, say so and name what to measure next.

Example of the standard I want
Weak:   "The bottleneck is in the render function"
Strong: "render is 68% total but 4% self — the cost is in serialize() beneath it. Fixing render itself caps you at 4%"

Output
What the profile shows · the real bottleneck · ranked fixes with expected gain ·
what to measure to confirm.

Role: Engineer converting legacy async code. You are careful about error
semantics because that's where these conversions go wrong.

Context
- Code: [paste it]
- Language/runtime: [and version]
- Callback convention: [error-first? custom? paste an example call]
- Callers: [can they be updated, or must the signature hold?]

Task
Convert to async/await.

Rules
- Preserve error behaviour exactly. Errors that were passed to a callback must
  become rejections; errors that were thrown synchronously must stay synchronous
  or be documented as changed.
- Preserve ordering and concurrency. Sequential callbacks must not silently
  become parallel, and vice versa.
- Handle the callback-called-twice case if the original could do it.
- If Callers can't be updated, keep a callback-compatible wrapper.

Example of the standard I want
Weak:   silently turning three sequential callbacks into Promise.all
Strong: keeping them sequential, and noting separately that two of them could be parallelised

Output
Converted code · the behaviour differences (if any) with the case that exposes
each · the wrapper, if one is needed.

Role: Backend engineer fixing a query-per-row problem without breaking the
calling code.

Context
- Code: [paste the loop and the query]
- ORM/framework: [and version]
- Query log: [paste a sample showing the repetition]
- Typical and worst-case row count: [numbers matter here]
- Relationships involved: [one-to-many, many-to-many, nested]

Task
Eliminate the N+1.

Rules
- Name the fix you're using — eager load, batch fetch by ID set, join, or
  dataloader — and why it fits this relationship.
- Watch for the cardinality trap: joining a one-to-many multiplies parent rows.
  If your fix does that, handle the deduplication.
- Check the fix doesn't create a different problem — over-fetching columns,
  loading a huge collection into memory, or an IN clause with 10,000 IDs.
- Preserve the shape the caller expects.

Example of the standard I want
Weak:   "Use eager loading to fix the N+1"
Strong: "401 queries → 2. Note the join multiplies parents, so dedupe by id or you'll render each order 4 times"

Output
Fixed code · query count before and after · the memory trade-off · how to
assert the count in a test so it doesn't regress.

Role: Engineer who treats a flaky test as a real bug until proven otherwise,
because it usually is one.

Context
- Test code: [paste it]
- Code under test: [paste it]
- Failure output: [paste it, ideally from more than one failure]
- Failure rate: [roughly how often]
- Where it flakes: [CI only? locally too? one machine?]
- Framework: [and whether tests run in parallel]

Task
Find why it's flaky.

Rules
- Work through the usual sources in order: timing and real sleeps, shared state
  between tests, test ordering, uncontrolled clock or randomness, network or
  filesystem, parallelism, and timezone or locale.
- Decide explicitly whether the flake indicates a real race in the code under
  test. If it does, say so — the test is the messenger, not the bug.
- Don't propose a retry wrapper or a longer sleep as the fix unless you've
  established the non-determinism is genuinely external.

Example of the standard I want
Weak:   "Add a retry or increase the timeout"
Strong: "The test asserts order on an unordered Promise.all — it's a real race in the code, not a flaky test"

Output
Most likely cause with the evidence for it · how to confirm it deterministically ·
the fix · whether the production code has a real bug.

Role: User researcher. You separate what the participant said from what you
concluded, and you never merge the two.

Context
- Transcript: [paste it]
- Who they are: [role, company size, how they use the product]
- What we were trying to learn: [the research question]
- What we already believe: [so you can flag confirmation bias]

Task
Synthesise this interview.

Rules
- Quote before you interpret. Every finding needs the participant's own words
  attached.
- Separate: what they said · what they did (past behaviour) · what they predicted
  they'd do. Predictions are the weakest evidence; label them as such.
- Flag anywhere the interviewer led the witness, and discount those answers.
- One interview is not a pattern. Do not write "users want" — write "this user said".
- Note what they didn't mention that you expected them to.

Example of the standard I want
Weak:   "Users want better reporting"
Strong: "This user said: 'I export to Excel because I can't get the columns I want.' That's a column-picker gap, not a reporting gap"

Output
Key findings with supporting quotes · behaviours vs stated preferences ·
contradictions · questions this raises for the next interview.

Role: Research lead doing cross-interview analysis. You are strict about how
many participants a claim rests on.

Context
- Transcripts or summaries: [paste them, labelled per participant]
- Participant details: [role, segment, so you can spot segment-specific patterns]
- Research question: [what you're trying to answer]

Task
Find the patterns across these interviews.

Rules
- Every theme gets a count: "4 of 7 participants". A theme mentioned once is an
  outlier, not a finding — list those separately as signals to watch.
- Check whether a pattern is really a segment artefact. If all four who raised it
  are enterprise, that's the finding.
- Report disconfirming evidence for each theme, not just supporting quotes.
- Say plainly where the sample is too small or too homogeneous to conclude anything.

Example of the standard I want
Weak:   "Users find onboarding confusing"
Strong: "5 of 8 stalled at the import step. All 5 were self-serve; neither enterprise participant hit it"

Output
Themes with participant counts and quotes · segment-specific findings ·
contradictions · outliers worth watching · what you can't yet conclude and why.

Role: Survey methodologist. You have seen enough leading questions to be
allergic to them.

Context
- What I need to learn: [the decision this data will inform]
- Audience: [who's receiving it and their relationship to us]
- Sample size expected: [roughly]
- Length limit: [how long they'll tolerate]
- Existing hypothesis: [so you can check I'm not just seeking confirmation]

Task
Design the survey.

Rules
- No leading questions, no double-barrelled questions, no assumed premises.
  "How much did our new feature improve your workflow?" fails all three.
- Behaviour questions before attitude questions — asking opinion first anchors
  everything after it.
- Balanced scales with a genuine neutral, and an escape option ("not applicable",
  "don't remember") so people don't guess.
- Sensitive or demographic questions last.
- Flag any question that won't survive a small sample.

Example of the standard I want
Weak:   "How much did our new dashboard improve your workflow?"
Strong: "In the last two weeks, how often did you open the dashboard? (Never / 1-2 / 3-5 / Daily / Don't remember)"

Output
The survey in order, with question type per item · what each question answers ·
questions you'd cut if the length limit binds · the analysis plan.

Role: Product strategist doing competitive analysis. You are useless to your
team if you flatter them, so you don't.

Context
- Competitor: [name]
- Their material: [paste pricing page, feature list, reviews, docs]
- Our product: [what we do]
- Our segment: [who we're actually competing for]
- Where we lose deals to them: [if you know]

Task
Tear down their offering against ours.

Rules
- Name what they do genuinely better. A teardown with no losses on our side is
  marketing, not analysis.
- Work only from Their material. Do not assert pricing, headcount, funding, or
  roadmap you can't see — mark those [UNVERIFIED].
- Distinguish a real capability gap from a positioning difference. Being aimed
  at a different buyer isn't a weakness.
- Identify who should genuinely choose them over us.

Example of the standard I want
Weak:   "Their UI is dated and their pricing is confusing"
Strong: "They beat us on audit logs and SOC2 evidence export. Anyone in a regulated industry should pick them today"

Output
Positioning summary · feature comparison with gaps both directions · their
strengths · their real weaknesses · who should pick them · what we'd need to
change to win that segment.

Role: Go-to-market strategist. You narrow ICPs using evidence, not aspiration.

Context
- Product: [what it does]
- Current customers: [who they actually are — sizes, roles, industries]
- Best customers: [who renews, expands, refers — and what they have in common]
- Worst fit: [who churns or never activates]
- Deal data: [win rates by segment, if you have it]

Task
Define the ICP.

Rules
- Build from Best customers, not from the market you'd like. If the data says
  a smaller segment, say the smaller segment.
- Include disqualifiers — who to actively avoid. An ICP without exclusions
  isn't operational.
- Name the trigger event that makes this buyer start looking. Without it the
  profile can't be used for targeting.
- Where you're inferring rather than reading from the data, label it.

Example of the standard I want
Weak:   "SMBs and mid-market companies that value efficiency"
Strong: "Finance leads at 50-200 person B2B SaaS, post-Series A, who just failed or barely survived an audit"

Output
ICP: firmographics, role, trigger, pain, current alternative · anti-ICP with
reasons · the two or three qualifying questions sales should ask on call one ·
what data would sharpen this.

Role: Copy researcher who mines customer language rather than inventing it.

Context
- Source material: [reviews, tickets, call transcripts, survey text — paste it]
- Where it came from: [so you can weight it — a churn survey reads differently
  from an onboarding NPS]
- Product: [what it is]
- What I'm writing: [landing page, ad, email]

Task
Extract the language patterns.

Rules
- Quote verbatim. The value is in their exact words — "it takes forever to close
  the books", not "users desire efficiency".
- Group by: the pain in their words · the outcome they wanted · the objection ·
  the trigger that made them look · what they compared us to.
- Note frequency. Something said once isn't voice-of-customer, it's one customer.
- Do not smooth the phrasing into marketing language. Awkward and specific beats
  polished and generic.
- Flag where the source skews — angry customers write more reviews than content ones.

Example of the standard I want
Weak:   "Customers want a faster, more efficient solution"
Strong: "'I've got three tabs open and I still don't trust the number' — said in some form by 11 of 40 reviews"

Output
Grouped verbatim quotes with counts · the phrases worth using directly in copy ·
the words they never use that we do · where this sample is biased.

Role: Analyst who is disciplined about causation and comfortable saying "we
can't tell from this".

Context
- Data: [paste the numbers, with the time period]
- What changed in that period: [releases, campaigns, pricing, seasonality]
- Baseline: [what normal looks like, and normal variance if you know it]
- The question: [what decision this feeds]

Task
Tell me what this data supports.

Rules
- Check the movement is outside normal variance before treating it as a signal.
  If you don't have variance data, say the analysis is provisional.
- Never assert causation from a correlation. List the plausible causes including
  seasonality, mix shift, and tracking changes.
- Watch for Simpson's paradox and composition effects — an aggregate can move
  while every segment moves the other way.
- State explicitly what this data cannot answer.

Example of the standard I want
Weak:   "Signups rose 20% after the redesign, so it worked"
Strong: "Signups rose 20%; a partner campaign also ran that week. Split by source before crediting the redesign"

Output
What the data shows · what it does not show · plausible explanations ranked ·
the one analysis or cut that would distinguish between them · the decision
you'd make now and your confidence in it.

Role: Technical SEO who fixes cannibalisation by consolidating, not by
sprinkling more keywords.

Context
- Pages: [URLs with title, H1, and target keyword each]
- Search Console data: [query, clicks, impressions, position per page — paste it]
- Site structure: [where these sit and what links to them]
- Business priority: [which page you'd rather rank]

Task
Identify cannibalisation and say what to do.

Rules
- Confirm it before diagnosing it. Real cannibalisation shows as the same query
  landing on different URLs over time, or two pages trading positions. Similar
  titles alone are not evidence.
- Distinguish genuine overlap from legitimately different intent — a comparison
  page and a how-to can share words without competing.
- For each conflict, choose one: consolidate and redirect, differentiate the
  intent, or canonicalise. Say which and why.
- Redirects lose something. Note what's at risk before recommending one.

Example of the standard I want
Weak:   "These two pages both mention 'prompt library' — cannibalisation"
Strong: "Both rank for [ai prompt library], trading positions 6-9 weekly since March. GSC shows the split"

Output
Confirmed conflicts with the evidence · recommended action per conflict ·
what to change on the surviving page · what to monitor after.

Role: Research assistant. You never cite a source you weren't given.

Context
- Sources: [paste them, numbered, with publication and date]
- Topic: [what I'm writing about]
- Angle: [the argument or question, if I have one]
- Audience: [expert or general — sets how much you explain]

Task
Synthesise these sources.

Rules
- Every claim maps to a numbered source. If a point needs support I didn't
  supply, write [NEEDS SOURCE] rather than filling it in from memory.
- Note where sources disagree and don't resolve it artificially — the
  disagreement is often the most useful part.
- Flag source quality: primary research, vendor content, opinion. A vendor blog
  and a peer-reviewed study should not be cited as equals.
- Check dates. Say when a source is old enough that it may no longer hold.

Example of the standard I want
Weak:   "Studies show structured prompts perform better"
Strong: "[3] found a 12% accuracy gain on their benchmark; [5] found none. [3] is vendor-published — weight accordingly"

Output
Synthesis organised by theme with inline source numbers · points of
disagreement · gaps where evidence is missing · a source-quality note.

Role: Content strategist who builds clusters around how people actually search
through a problem.

Context
- Core topic: [the pillar subject]
- Product: [so the cluster ties to something commercial]
- Audience: [and their level of expertise]
- Existing content: [what's already published — URLs and titles]
- Keywords in hand: [list, or "suggest them"]

Task
Build a topic cluster.

Rules
- One pillar page, then supporting pages grouped by search intent, not by
  keyword similarity.
- Map the internal linking explicitly: what links to the pillar, what links
  laterally, and why.
- Check Existing content first. Say what to update rather than duplicate —
  new pages that overlap old ones create the cannibalisation problem.
- Do not invent search volumes or difficulty scores. Mark [VERIFY] where a tool
  is needed.
- Mark which pieces can realistically convert and which are purely informational.

Example of the standard I want
Weak:   "Pillar: Prompt Engineering. Supporting: 10 prompt articles"
Strong: "Pillar: prompt frameworks. Supporting split by intent — 'what is CRAFT' (informational) vs 'CRAFT vs RTF' (comparison)"

Output
Pillar definition · supporting pages with intent and target query · internal
link map · update-vs-create decisions · suggested build order.

Role: Content strategist who treats a gap as an opportunity only when we can
credibly win it.

Context
- Our content: [URLs and topics]
- Competitor content: [theirs — paste what you have]
- Our authority: [domain strength, topical credibility, honestly assessed]
- Our capacity: [what we can produce]
- Commercial priority: [what actually drives revenue]

Task
Find the gaps worth filling.

Rules
- A gap is only an opportunity if we can plausibly rank and it serves our buyer.
  A high-volume topic we'd place 40th on is not an opportunity.
- Separate: topics we don't cover · topics we cover worse · topics where our
  angle could be genuinely better.
- Consider whether the query is already answered in the SERP by an AI summary.
  Some gaps aren't worth the traffic they used to be.
- Don't invent volume data — mark [VERIFY].

Example of the standard I want
Weak:   "They rank for 200 keywords we don't — big opportunity"
Strong: "Of 200, we could plausibly rank for 12. The rest need domain authority we won't have this year"

Output
Ranked opportunities with the reason we could win each · topics to improve
rather than create · what to skip and why · the first three to build.

Role: SEO analyst classifying intent from the query and the SERP, not from
the keyword's grammar.

Context
- Keywords: [paste the list]
- SERP observations: [what currently ranks for each, if you have it]
- Our product: [so commercial relevance can be judged]

Task
Classify each keyword by intent.

Rules
- Use: informational · commercial investigation · transactional · navigational.
- Where SERP observations exist, they beat your reading of the words. What
  Google already serves is the strongest available evidence of intent.
- Flag mixed-intent keywords — they need a page that serves both or they need
  splitting.
- For each, name the page type that fits: guide, comparison, listicle, product
  page, tool. A transactional keyword pointed at a blog post won't convert.
- Don't guess volume or difficulty.

Example of the standard I want
Weak:   "'best prompt manager' — commercial"
Strong: "'best prompt manager' — commercial investigation. SERP is 8 listicles, 0 product pages. Ours must be a comparison, not a landing page"

Output
Table: keyword · intent · confidence · page type · commercial value to us ·
note. Then group them into the pages you'd actually build.

Role: SEO content planner who expands around a query the way a curious reader
would, not the way a keyword tool would.

Context
- Seed query: [the main one]
- Known People Also Ask questions: [paste them, or "none — generate likely ones"]
- Existing article: [what it covers, so you don't duplicate]
- Audience expertise: [beginner or practitioner]

Task
Expand this into the question set worth answering.

Rules
- Group questions by the stage of understanding they belong to. Someone asking
  "what is X" and someone asking "X vs Y for enterprise" need different sections.
- Mark which belong in the existing article and which deserve their own page.
- Write the direct answer for each in 40-60 words — that's the shape that gets
  quoted in AI answers and featured snippets.
- If Known PAA is "none", say your generated questions are inferred and should
  be checked against a real SERP.

Example of the standard I want
Weak:   "What is prompt engineering? It's the practice of writing prompts."
Strong: "What is prompt engineering? Writing model instructions that specify role, context, task and output format, so the answer doesn't depend on how you phrased it that day."

Output
Grouped questions with a 40-60 word direct answer each · placement (existing
page / new page) · which are worth FAQ schema.

Role: SEO who formats for the feature being targeted, because feature
eligibility is mostly a formatting problem.

Context
- Target query: [the one]
- Current SERP: [what features appear — snippet, PAA, video, images, AI overview]
- Who holds the feature now: [and how their content is structured]
- Our page: [URL and current structure, or "not written yet"]

Task
Say how to structure the page to compete for the feature.

Rules
- Match the format of what currently holds it. A paragraph snippet and a list
  snippet need different markup — copying the wrong shape wins nothing.
- Direct answer within the first 60 words after the relevant heading, phrased
  as a complete statement that stands alone out of context.
- Recommend schema only where it genuinely applies. Marking up content as
  something it isn't risks a manual action.
- Be honest where the feature is dominated by an entity we can't outrank, or
  where an AI overview has absorbed the click.

Example of the standard I want
Weak:   "Add FAQ schema to try for a featured snippet"
Strong: "The snippet holder uses a numbered list under an H2 question. Match that shape — a paragraph won't be eligible"

Output
Target feature · required format · heading and answer structure · schema ·
realistic assessment of whether it's winnable.

Role: Analyst coding qualitative responses. You count before you conclude.

Context
- Responses: [paste them]
- The question asked: [exact wording — it shapes every answer]
- Respondent info: [segment, if you have it]
- Response rate: [how many of how many]
- What we're deciding: [what this feeds]

Task
Code and synthesise these responses.

Rules
- Build the themes from the responses, not from a list you brought. Then report
  counts per theme.
- Preserve verbatim examples for each theme, including the awkwardly worded ones.
- Note response bias: who answers an open-text question is not who received it.
  With a low response rate, say so before anyone quotes the percentages.
- Report the strength of feeling separately from frequency — three furious
  responses may matter more than twenty mild ones, and vice versa.
- Include the responses that don't fit any theme rather than forcing them in.

Example of the standard I want
Weak:   "Most respondents were satisfied"
Strong: "14 of 60 mentioned price unprompted; 3 of those were furious and specific. 9% response rate — treat as directional"

Output
Themes with counts and verbatim examples · intensity notes · unclassifiable
responses · sample-bias caveat · what you'd act on and what needs more data.

Role: Hiring manager who writes rubrics because unstructured interviews mostly
measure how much the panel liked the candidate.

Context
- Role: [title and level]
- What they'll actually do: [the first six months, concretely]
- Must-haves: [the things the job genuinely cannot be done without]
- Nice-to-haves: [separately]
- Team context: [size, seniority, what's missing today]

Task
Build a scoring rubric.

Rules
- Every criterion must be observable in the process. If you can't assess it in
  an interview or a work sample, it isn't a criterion — drop it or design a
  signal for it.
- Define what a 1, 3, and 5 look like in behavioural terms. "Strong communicator"
  is not a level; "explained a technical trade-off to a non-technical stakeholder
  without jargon" is.
- Only include Must-haves that are genuinely required. Years-of-experience floors
  and specific-tool requirements usually screen out good candidates for no gain.
- Exclude anything that proxies for age, background, school, or personal
  circumstances — "culture fit", "polish", "pedigree".
- Weight the criteria and say why.

Example of the standard I want
Weak:   "Communication: 5 = excellent communicator"
Strong: "Communication 5 = explained a technical trade-off to a non-technical stakeholder and changed their mind"

Output
Rubric table: criterion, weight, 1/3/5 anchors, and where in the process it's
assessed. Then the bar for an offer.

Role: Interviewer who asks about what people have done, not what they'd
hypothetically do.

Context
- Role: [title and level]
- Criteria to assess: [from the rubric]
- Interview length: [so the set is realistic]
- Format: [call, panel, technical, pairing]
- What the team struggles with: [so questions target real conditions]

Task
Write the interview question set.

Rules
- Behavioural over hypothetical. "Tell me about a time you shipped something
  you later regretted" beats "How would you handle a bad decision?".
- Every question maps to a criterion. If it maps to nothing, cut it.
- Give follow-up probes for each — the first answer is rehearsed, the third
  is real. Include a probe that gets at what they'd do differently.
- No brainteasers, no trivia, nothing that rewards interview practice over
  job ability.
- Nothing touching age, family, health, nationality, religion, or politics.
- Include what a strong and a weak answer sound like.

Example of the standard I want
Weak:   "How would you handle a disagreement with a teammate?"
Strong: "Tell me about a technical decision you lost. What was the argument, and what do you think now?"

Output
Questions grouped by criterion, each with probes and strong/weak answer
indicators, timed to fit the slot.

Role: Reviewer who grades take-homes against the brief, not against how you
would have done it.

Context
- The brief given: [paste exactly what candidates received]
- Time expectation: [what you told them]
- Role level: [what's fair to expect]
- What matters most: [correctness, design, communication, tests]
- Submission: [paste it, if reviewing now]

Task
Build the evaluation rubric [and apply it to the submission].

Rules
- Grade only against what the brief asked for. Penalising a missing thing you
  never requested is the most common take-home injustice.
- Respect the time expectation. If you said four hours, incomplete polish is not
  a finding.
- Separate must-have correctness from taste. Different-but-valid choices score full marks.
- Weight the README and the reasoning. How someone explains trade-offs predicts
  the job better than whether their tests are exhaustive.
- Note where the brief itself was ambiguous — that's on us, not the candidate.

Example of the standard I want
Weak:   marking down a submission for missing tests you never asked for
Strong: scoring against the brief, and noting separately that the brief should have asked for tests

Output
Rubric with weights and anchors · [scored assessment with evidence] · the
specific things to ask about in the follow-up conversation.

Role: Hiring manager writing up a debrief. You weight evidence over impressions.

Context
- Role and rubric: [the criteria and bar]
- Interviewer notes: [paste each, labelled by interviewer and stage]
- Candidate background: [brief]
- Alternatives: [other candidates in play, or "none"]

Task
Synthesise the feedback into a recommendation.

Rules
- Map every piece of feedback to a rubric criterion. Feedback that maps to
  nothing — "seemed nervous", "not sure about culture fit" — gets set aside
  explicitly, not quietly folded in.
- Show where interviewers disagreed and what evidence each was working from.
  Disagreement usually means they probed different things, not that one is wrong.
- Distinguish "we saw evidence they can't" from "we didn't get evidence either way".
  Those lead to different decisions — the second means a gap in the process.
- Watch for bias signals: comments about communication style, confidence, or
  background that aren't tied to job performance.

Example of the standard I want
Weak:   "Two interviewers weren't sure about culture fit"
Strong: "Neither maps to a rubric criterion. Setting aside. On system design, 3 of 4 saw evidence at the bar"

Output
Evidence per criterion · where the panel diverged and why · what wasn't assessed ·
recommendation with confidence · what to probe if there's another round.

Role: Hiring manager who knows references are coached and asks questions that
still produce signal.

Context
- Candidate: [name, role applied for]
- Reference's relationship: [manager, peer, report — this changes everything]
- What we're unsure about: [the specific concern from the process]
- What they claimed: [accomplishments to verify]

Task
Write the reference call script.

Rules
- Open by establishing the working relationship concretely — how long, how
  closely, in what capacity. A vague reference is a weak reference.
- Ask about specifics they'd have to know, not general impressions. "What was
  their actual role on [project]?" not "Were they a good team player?".
- For the concern, ask indirectly: "What kind of environment do they do their
  best work in?" surfaces more than "Are they good at X?".
- Include the calibration question: "Would you hire them again?" and listen to
  the hesitation, not just the answer.
- Nothing about health, family, age, or anything unrelated to job performance.

Example of the standard I want
Weak:   "Were they a good team player?"
Strong: "What was their actual scope on the migration — did they own it or contribute to it?"

Output
Call script in order, with what a concerning answer sounds like for each
question, and the two questions to prioritise if the call is short.

Role: Hiring manager writing the post you'd want to read. You know most job ads
fail by describing the company instead of the job.

Context
- Role: [title, level, team]
- What they'll actually do: [the real first six months]
- Must-haves: [genuinely required]
- Salary range: [state it — ads without it get worse candidates]
- Location/remote: [and any timezone requirement]
- What's hard about this job: [honestly]

Task
Write the job description.

Rules
- Lead with the work, not the company boilerplate. The first paragraph should
  let someone self-select.
- Requirements: only Must-haves. Long lists of "nice to have" framed as
  requirements measurably reduce applications from good candidates who
  self-screen out.
- Drop years-of-experience floors unless legally required. Describe the
  capability instead.
- Include What's hard about this job. It filters better than any requirement list.
- Neutral language. No "rockstar", "ninja", "work hard play hard", "like a family".
- Don't invent perks, funding, or team size I didn't give you.

Example of the standard I want
Weak:   "Rockstar engineer wanted! 5+ years required. We're like a family."
Strong: "You'll own billing reconciliation. It's the least glamorous system we have and the one most likely to page you."

Output
The job post · the interview process outlined for candidates · a shorter
version for a job board with a character limit.

Role: Manager writing a review the person can act on. Vague praise and vague
criticism are equally useless.

Context
- Their role and level: [and expectations for it]
- Review period: [dates]
- What they delivered: [projects, outcomes, with your notes]
- Feedback gathered: [peers, stakeholders]
- Goals set last period: [and what happened to each]
- Context outside their control: [reorgs, blockers, scope changes]

Task
Draft the review.

Rules
- Every point cites a specific instance. "Improve communication" helps nobody;
  "the API migration status wasn't visible to the mobile team until the week
  before launch" does.
- Account for Context outside their control. Judging someone on a goal that a
  reorg made impossible is the fastest way to lose them.
- Development areas need a next action, not just a label.
- Recency bias check: the review period is the whole period, not the last month.
- Don't inflate. A review everyone reads as "exceeds" makes the rating meaningless.

Example of the standard I want
Weak:   "Needs to improve communication with stakeholders"
Strong: "The API migration status wasn't visible to the mobile team until the week before launch — they replanned twice"

Output
Summary · achievements with evidence · development areas with specific next
steps · goals for next period · your rating with the reasoning behind it.

Role: Manager who treats the 1:1 as the report's meeting, not a status check.

Context
- Who: [their role, tenure, how they're doing]
- Since last time: [what's happened — theirs and yours]
- Open threads: [what you promised, what's unresolved]
- Anything sensitive: [performance concern, a change coming, a decision pending]
- Time available: [30 or 60 minutes]

Task
Build the agenda.

Rules
- Their topics first. If the agenda opens with your items, it's a status meeting.
- Status belongs in writing. Only surface it here if there's a decision or a blocker.
- Include a follow-up on every open thread, especially things you committed to.
  Unclosed manager promises are the fastest trust leak there is.
- Where there's something sensitive, say it early in the meeting, plainly.
  Burying it at the end is worse for both of you.
- Leave real space. A packed 1:1 agenda means nothing unplanned gets raised.

Example of the standard I want
Weak:   "1. Project status 2. Blockers 3. AOB"
Strong: "1. Your topics (15m) 2. The reorg — what I can and can't tell you yet (10m) 3. Close last week's promise on the conference budget"

Output
Agenda with time allocation · the questions to actually ask · what to close
from last time · what you're deliberately not covering.

Role: Facilitator running a blameless retrospective. You're after systems, not
culprits.

Context
- What we did: [the project or incident]
- Outcome: [what actually happened vs planned]
- Timeline: [key events and dates]
- Team: [size, roles, and how safe people feel speaking up]
- What's already been said: [any feedback gathered]

Task
Design the retrospective and draft the discussion prompts.

Rules
- Frame around systems and conditions. "Why did this seem like the right call
  with the information available?" beats "who approved this?".
- Build in a structure that surfaces quiet voices — silent written round before
  open discussion. Otherwise you get the two loudest opinions.
- Cover what went well with the same rigour as what didn't. Teams repeat
  successes they never examined by accident.
- Every action item needs an owner and a date, and there should be at most three.
  A retro producing twelve actions produces zero.
- Include the question of whether the goal itself was right.

Example of the standard I want
Weak:   "Why did the deploy fail? Who approved it?"
Strong: "What made this look like a safe deploy at the time? What would have had to be visible for us to catch it?"

Output
Retro structure with timings · discussion prompts · the format for surfacing
quiet input · how to turn output into at most three owned actions.

Role: Manager designing onboarding around a first contribution, not around
document-reading.

Context
- Role: [title, level, team]
- What they'll own: [eventually]
- Team setup: [size, remote or office, who else is new]
- Systems and access: [what they'll need]
- A good first task: [something real and small, or "suggest one"]
- Who's around: [buddy, manager availability]

Task
Write a 30/60/90 day onboarding plan.

Rules
- Ship something small in week one. Nothing builds confidence or exposes broken
  setup like a real change reaching production.
- Front-load access. Half of bad onboarding is waiting on permissions nobody
  requested in advance.
- Name who they meet and why. "Meet the team" is not a plan; "30 minutes with
  [person] on why the billing service is split" is.
- Set explicit expectations per phase — what "doing fine at 30 days" looks like,
  so neither of you is guessing.
- Include what to do if it isn't going well, and when to say so.

Example of the standard I want
Weak:   "Week 1: Read the docs and set up your environment"
Strong: "Day 2: ship a copy change to production. It's trivial, and it proves your access works before you need it"

Output
Pre-start checklist · week one by day · 30/60/90 milestones with success
criteria · people to meet with the reason · the first task and why it fits.

Role: Developmental editor. You care whether the story has an engine, not
whether the premise sounds cool.

Context
- Premise: [the idea in a sentence or two]
- Genre and tone: [and comparable works if useful]
- Protagonist: [who they are and what they want]
- What stands in the way: [the opposition]
- Length: [short story, novella, novel]
- Ending, if I know it: [or "open"]

Task
Write a synopsis, 400-600 words.

Rules
- The protagonist must want something concrete and be actively pursuing it.
  A character things happen to is the most common structural failure.
- Show cause and effect. Each turn should happen because of the last, not
  merely after it.
- Include the ending. A synopsis that withholds it can't be assessed.
- Don't resolve the conflict with a coincidence or an unearned change of heart.
- Keep my premise. Suggest changes separately rather than quietly writing a
  different story.

Example of the standard I want
Weak:   "She discovers the truth and everything changes"
Strong: "She finds the ledger, and now she has to decide whether to turn in the man who paid for her degree"

Output
Synopsis · the central dramatic question in one line · where the structure is
weakest and what would fix it.

Role: Character-focused editor. You build people from contradictions, not from
trait lists.

Context
- Character: [name, role in the story]
- What's established: [anything already written or decided]
- Story: [premise and setting]
- Their function: [what the plot needs from them]
- Where they feel flat: [if you know]

Task
Write a character bio.

Rules
- Give them a want and a need that conflict. That gap is where character comes from.
- Include a contradiction they don't notice about themselves. Consistent people
  read as constructs.
- Specifics over adjectives. Not "she's guarded" — what she does when someone
  asks her a direct question.
- Their voice: how they speak, what they avoid saying, what they say instead.
- Their history should explain a present behaviour, not just be backstory.
- Don't contradict What's established.

Example of the standard I want
Weak:   "Guarded, intelligent, fiercely loyal"
Strong: "Answers direct questions with a question. Has never once said 'I don't know' out loud"

Output
Want vs need · defining contradiction · voice and speech habits · formative
history and what it produces now · how they change, or why they can't ·
three lines of dialogue only they could say.

Role: Fiction writer. You write scenes that turn, and you cut the ones that don't.

Context
- What happens: [the events]
- Who's present: [and what each wants in this scene]
- Where and when: [setting]
- Point of view: [whose, and how close]
- Emotional shift: [where the reader starts and ends]
- Voice sample: [paste your prose so the style matches]

Task
Write the scene, [word count].

Rules
- Something must change. If the situation is identical at the end, the scene
  is exposition wearing a costume.
- Start late, end early. Skip the arriving and the settling.
- Dialogue does more than convey information — people talk past each other,
  avoid, and imply.
- Match the voice sample: sentence rhythm, how much interiority, how much description.
- No filter words — "she felt", "he noticed", "she realised" — when the direct
  image is stronger.
- Don't summarise emotion. Put it in behaviour.

Example of the standard I want
Weak:   "She felt nervous as she entered the room"
Strong: "She checked the door handle twice on the way in, though she'd already heard it lock"

Output
The scene, then one line naming what changed and one on what you'd cut if it
ran long.

Role: Structural editor reading for logic. You are looking for the places a
reader stops believing it.

Context
- The work: [paste the draft or a detailed outline]
- Genre: [so the rules of the world are clear]
- Established rules: [magic system, technology, world constraints]
- Where I'm worried: [if you have a hunch]

Task
Find the plot holes.

Rules
- Check: character motivation (would they actually do this?), timeline
  consistency, information flow (who knows what, when, and how), and whether
  the established rules are ever broken for convenience.
- The biggest category is the easy solution nobody takes. If a character could
  end the problem by making one phone call, say so.
- Separate genuine holes from things the reader will accept. Genre conventions
  cover a lot; don't flag what the form permits.
- For each, give the fix that costs the least rewriting.

Example of the standard I want
Weak:   "The ending felt a bit rushed"
Strong: "Chapter 9: she could call her brother — he's established as reachable and willing. Nothing stops her, so the isolation reads as authorial"

Output
Holes ranked by how much they'd break a reader's trust, each with: the problem,
where it shows, why it breaks, and the cheapest fix.

Role: Trusted critique partner. You are specific, you are kind about the person
and ruthless about the page, and you never soften a real problem into a
suggestion.

Context
- The work: [paste it]
- Draft stage: [first draft, revision, near-final — this sets the scope]
- What I'm worried about: [your own concerns]
- What I want feedback on: [and what's off the table]
- Intended audience: [who this is for]

Task
Give me a critique read.

Rules
- Match the stage. Line-editing a first draft is wasted work; ignoring prose in
  a near-final draft is negligent.
- Lead with what's working, specifically. "The dialogue in the kitchen scene"
  not "the writing is good" — the writer needs to know what to keep.
- Every problem gets a location and a reason it isn't landing. No "this section
  didn't work for me" without why.
- Distinguish craft problems from taste. Say which is which.
- Answer What I'm worried about directly, even if the answer is that they're
  right to worry.

Example of the standard I want
Weak:   "I really enjoyed this! The writing is strong."
Strong: "The kitchen argument works — nobody says what they mean and I still knew. Chapter 3 doesn't, because everyone states their position"

Output
Overall read · what's working and why · the two or three biggest problems in
order · line-level notes (only if the stage warrants) · what to fix first.

Role: Someone who has read a lot of slush and knows queries fail in the first
paragraph.

Context
- Book: [title, genre, word count]
- Premise: [the hook]
- Protagonist and stakes: [who wants what, what happens if they fail]
- Comparable titles: [recent, in-genre]
- My credentials: [publications, relevant expertise, or "none"]
- Agent: [name and why them specifically]

Task
Write the query letter, under 350 words.

Rules
- Hook first. Not the greeting, not the word count, not how much you admire
  their list — the story.
- The pitch is 150-200 words: protagonist, what they want, what's in the way,
  what it costs. Stakes must be concrete.
- Comps should be recent and realistic. Comparing to a mega-bestseller reads as
  naive.
- If credentials are "none", omit the paragraph entirely rather than padding it.
  No apologising for being unpublished.
- Don't ask a rhetorical question to open. Don't withhold the ending in a way
  that hides whether the book works.

Example of the standard I want
Weak:   "My novel is a thrilling page-turner that readers will love."
Strong: "When the flood takes the archive, Maren has three days to recover her sister's confession before the water does"

Output
The query · the one-line pitch on its own · a note on which part is weakest.

Role: Naming strategist. You generate names that survive the boring checks,
not names that sound good in a deck.

Context
- What it is: [product, company, feature]
- What it does: [plainly]
- Audience: [who says this name out loud]
- Feel: [3 adjectives]
- Names I like and dislike: [and why, if you know]
- Constraints: [length, .com needed, must work in other languages]

Task
Generate 30 name candidates across distinct approaches.

Rules
- Group by approach: descriptive, evocative, invented, compound, borrowed word,
  founder-style. One approach for 30 names is a failure of range.
- Every name must pass: easy to say aloud, easy to spell after hearing it,
  no unfortunate readings when run together in a URL.
- Do NOT claim a domain or trademark is available — you cannot check. Flag every
  name as [CHECK AVAILABILITY].
- Flag anything with an obvious meaning in another major language.
- Avoid the exhausted patterns: dropped vowels, -ly, -ify, Latin roots meaning "together".

Example of the standard I want
Weak:   "Optimizely, Innovatify, Synergix"
Strong: "Ledger, Marginal, Tuesday — grouped by approach, each marked [CHECK AVAILABILITY]"

Output
Names grouped by approach with a one-line rationale each · your top 5 with
reasoning · which to check first.

Role: Brand copywriter. You know most slogans fail by being true of any company
in the category.

Context
- Brand: [what it does]
- Audience: [who]
- The one thing that's different: [genuinely]
- Brand voice: [3 adjectives]
- Where it appears: [logo lockup, ads, packaging — sets the length]
- Slogans to avoid sounding like: [competitors]

Task
Write 20 slogan candidates.

Rules
- Apply the swap test: if a competitor's name works in front of it, the line
  says nothing. Discard those.
- 6 words or fewer for anything sitting under a logo.
- No claims we can't support and no invented superlatives.
- Range across registers: plain, confident, playful, understated. Don't hand back
  20 of the same tone.
- Say it out loud. Anything with an awkward stress pattern is out.

Example of the standard I want
Weak:  "Innovation for a better tomorrow"
Strong: "Your books, closed by Friday"

Output
20 candidates with tone labels · which ones survive the swap test · top 3 with
reasoning · one you'd argue for even though it's risky.

Role: Speechwriter. You write for the ear, which is a different job from
writing for the page.

Context
- Occasion: [what and where]
- Audience: [who, how many, what they expect]
- Length: [in minutes — roughly 130 words per minute]
- The one thing they should remember: [if only one thing survives]
- My speaking style: [paste something I've written or said]
- Anything I must include: [names, thanks, announcements]

Task
Write the speech.

Rules
- Short sentences. Anything a speaker would stumble over gets rewritten.
- Concrete stories over abstract points. One specific anecdote lands harder
  than three principles.
- Repeat the core message three times in different words — listeners can't
  scroll back.
- Build in breathing room and places to pause.
- No opening joke unless it's genuinely good and fits the occasion. No
  dictionary definitions. No "Webster's defines".
- Match my speaking style. If I'm plain, don't hand me rhetoric I'd never say.

Example of the standard I want
Weak:   "Webster's dictionary defines leadership as..."
Strong: "Three years ago this room had eleven people in it. I want to talk about what the other forty of you changed."

Output
The speech with [pause] and emphasis marks · estimated running time · the
opening and closing lines offered as alternatives to memorise.

Role: Writer who has heard enough bad toasts to know the failure modes: too
long, too many inside jokes, and too much about the speaker.

Context
- Who I'm toasting: [names and my relationship to them]
- How I know them: [and for how long]
- Specific stories I can tell: [with details]
- What I admire about them together: [genuinely]
- Audience: [who's in the room — family, colleagues, mixed]
- Length: [2-3 minutes is the ceiling]

Task
Write the toast.

Rules
- One story, told well, with specific detail. Three anecdotes is a speech, not
  a toast.
- It must be about them. A toast that's mostly about the speaker's feelings is
  the most common failure.
- Nothing that needs explaining to half the room. No jokes about exes, drinking,
  or anything that lands as a dig.
- Turn toward the couple in the last third and address them directly.
- End with a clear raise-your-glass line so people know when to lift.

Example of the standard I want
Weak:   "Sarah and Tom are perfect for each other. To the happy couple!"
Strong: "Tom once drove four hours to bring Sarah a charger. He'd known her nine days."

Output
The toast with timing marks · the story beat you'd cut if you're running long ·
the closing line.

Role: Writer helping someone speak about a person they've lost. You are gentle,
unhurried, and you do not reach for platitudes.

Context
- Who they were: [name, and their relationship to me]
- How I want them remembered: [the essence]
- Specific memories: [moments, habits, things they said]
- What they cared about: [work, people, causes, small things]
- Audience: [who's there]
- Tone: [how much lightness is right for this room]
- Length: [minutes]

Task
Write the eulogy.

Rules
- Specific memories over general praise. "He kept a list of everyone's birthdays
  in a notebook" says more than "he was thoughtful".
- Their voice should appear — something they'd say, the way they said it.
- Warmth and humour are allowed where the tone supports it. People want to
  recognise the person, not hear a saint described.
- Don't smooth them into someone they weren't. A small honest edge makes the
  love credible.
- No clichés about better places or everything happening for a reason.
- Write in short paragraphs — this will be read while grieving.

Example of the standard I want
Weak:   "He was a kind man who touched many lives and is in a better place"
Strong: "He kept everyone's birthdays in a notebook. He never mentioned it. You just got a call, every year."

Output
The eulogy with natural pause points · a shorter version in case the moment
asks for less · the closing lines.

Role: Children's writer who respects the reader. You don't moralise and you
don't write down.

Context
- Age: [this sets vocabulary, length, and sentence structure]
- Main character: [who, and what they want]
- The problem: [what's in the way]
- Setting: [where]
- Theme, if any: [what it's quietly about]
- Read aloud or read alone: [changes the rhythm]
- Length: [words or pages]

Task
Write the story.

Rules
- The child character solves it. An adult stepping in to fix the problem is the
  most common failure in children's writing.
- Match the age genuinely: sentence length, vocabulary, and how much abstraction
  the reader can hold.
- Show the lesson through what happens. Never state it, and never end with a
  character explaining the moral.
- If it's read aloud, mind the rhythm — read it in your head for stumbles.
- Repetition and pattern are tools at younger ages; use them deliberately.

Example of the standard I want
Weak:   "Then Mum came and fixed everything, and Ellie learned to be brave."
Strong: "Ellie counted to three. Then she opened the cupboard herself."

Output
The story · a note on the reading level you targeted · [page breaks with
illustration notes, if it's a picture book].

Role: Poet who takes form seriously and avoids the register that makes
non-readers of poetry wince.

Context
- Subject: [what it's about]
- Occasion: [if it's for something — a gift, a reading, a card]
- Form: [sonnet, free verse, haiku, villanelle, or "you choose and say why"]
- Tone: [and how formal]
- Images or details I want in it: [specifics you'd like used]
- Audience: [who reads it]

Task
Write the poem.

Rules
- Concrete images before abstraction. "Grief" does less work than the object
  that carries it.
- If a fixed form is chosen, keep it properly — meter and rhyme scheme intact.
  A near-sonnet reads as a mistake.
- Avoid the tired rhyme pairs and the greeting-card register unless that's
  explicitly what's wanted.
- Earn the ending. No sudden summarising last line that explains the poem.
- Use the details I gave you.

Example of the standard I want
Weak:   "My heart aches with love that never ends / like rivers flowing round the bend"
Strong: "You left the radio on in the kitchen. / I have not turned it off."

Output
The poem · a note on the form and why it suits the subject · one alternative
version of the closing lines.

Role: Comedy writer. You know that specificity is funnier than exaggeration and
that punching down isn't a style, it's a shortcut.

Context
- Topic: [what it's about]
- Audience: [who's in the room and what they have in common]
- Setting: [speech, standup, toast, social post, newsletter]
- Tone allowed: [dry, silly, self-deprecating, edgy — and how edgy]
- Shared references: [what this audience all knows]
- Off limits: [people, subjects, anything that would land wrong]

Task
Write 15 jokes.

Rules
- Specific beats broad. Name the actual thing.
- Self-deprecating or shared-experience angles land better than jokes at
  someone's expense — especially with a mixed room.
- Respect Off limits absolutely.
- Nothing that relies on a stereotype for the mechanism.
- Vary the form: one-liners, observations, callbacks, misdirection.
- Mark which need delivery and timing to work, since those are risky read cold.

Example of the standard I want
Weak:   "Marriage, am I right? Take my wife, please!"
Strong: "We've been remote for four years. My daughter thinks my job is 'saying you're on mute.'"

Output
15 jokes grouped by type, each labelled safe or risky for this room · the 5
strongest · one callback that ties two of them together.

Role: Brand copywriter who diagnoses before prescribing.

Context
- Current tagline: [paste it]
- What we do: [plainly]
- What isn't working: [vague? too long? says nothing? sounds like everyone?]
- Audience: [who]
- What's genuinely different about us: [the real thing]
- Constraints: [length, must keep a word, brand voice]

Task
Diagnose the current line, then rewrite it.

Rules
- Diagnose first and name the specific failure — swap test, abstraction,
  category description, unsupported claim, awkward rhythm.
- Then write 15 alternatives across registers.
- Every alternative must fail the swap test for competitors, i.e. it must only
  work for us.
- Respect Constraints. If a constraint is what's breaking the line, say so.
- Include one option that keeps the spirit of the original, for the case where
  there's brand equity worth preserving.

Example of the standard I want
Weak:   "Innovation, delivered." — works for literally anyone
Strong: "Closed by Friday." — only works if you do what we do

Output
Diagnosis of the current line · 15 alternatives with tone labels · top 3 with
reasoning · the one that's safest and the one you'd actually argue for.

Role: Operator who has been burned by a decision matrix with invented scores.

Context
- What we're buying: [the category]
- Options: [the vendors, with whatever material you have on each]
- Must-haves: [genuine dealbreakers]
- Nice-to-haves: [separately]
- Budget: [range, and whether it's hard]
- Switching cost: [what it takes to leave later]
- Who's affected: [teams, users]

Task
Build the decision matrix and recommend one.

Rules
- Weight the criteria before you score anything. Weighting afterwards is how
  people justify a decision they already made.
- Score only from the material provided. Where you don't have data, write
  [UNKNOWN] rather than estimating — an invented score outranks a real one
  in a matrix and nobody notices.
- Include exit cost and lock-in as scored criteria, not footnotes.
- Name what would change the recommendation. A matrix with no sensitivity is
  a decision pretending to be analysis.

Example of the standard I want
Weak:   scoring an unknown as 3/5 so the matrix looks complete
Strong: marking it [UNKNOWN] and listing it as a question for the vendor call

Output
Weighted matrix with sources · gaps marked UNKNOWN · recommendation with
reasoning · what would flip it · the questions to ask each vendor next.

Role: Someone writing for colleagues who will skim this on a phone between
other things.

Context
- What happened: [progress, decisions, blockers]
- Audience: [team, leadership, cross-functional partners]
- What they need from it: [awareness, a decision, an action]
- Last update: [so you only report the delta]
- Bad news: [anything slipping — say so here]

Task
Write the async update.

Rules
- Lead with what changed and anything needing a decision. Never bury a blocker
  in paragraph four.
- Bad news goes near the top, stated plainly, with what you're doing about it.
  Softened slippage reads as hidden slippage.
- Anything requiring action gets a named owner and a date. "Someone should look
  at this" means nobody will.
- Skimmable: headers, short paragraphs, bold only on the parts that matter.
- Don't pad with work that happened but doesn't matter to this audience.

Example of the standard I want
Weak:   "Good progress this week, a few small blockers, more soon"
Strong: "Launch slips to the 22nd. Cause: the vendor's sandbox has been down since Tuesday. I've escalated; decision needed on whether we ship without it"

Output
TL;DR (2 lines) · decisions needed with owners · progress · blockers and what
you're doing · what's next. Then a one-line Slack version.

Role: Chief of staff triaging someone else's inbox with their priorities in mind.

Context
- Emails: [paste subjects and summaries, or the threads themselves]
- My role: [so importance can be judged]
- Current priorities: [what actually matters this week]
- Who I can delegate to: [and what they handle]
- Time available for email today: [realistically]

Task
Triage these.

Rules
- Sort into: reply now, reply later with a deadline, delegate to a named person,
  and archive. Every email lands in exactly one.
- Judge against Current priorities, not against how urgent the sender made it
  sound. Someone else's urgency isn't your priority.
- For "reply now", draft the reply — usually two or three sentences.
- Flag anything with a real deadline, legal or financial implication, or a
  relationship cost if ignored.
- Respect the time available. If the "reply now" pile exceeds it, say what slips.

Example of the standard I want
Weak:   "Reply to everything marked urgent"
Strong: "Delegate to Priya (vendor renewal, her call) · reply now: the legal deadline Thursday · archive: 6 newsletters"

Output
Four groups with the reasoning · drafted replies for the urgent ones · what to
delegate and to whom · what you're archiving and why that's safe.

Role: Coach running a weekly review. You ask about patterns, not just about
completion.

Context
- What I planned: [this week's intentions]
- What actually happened: [including the unplanned]
- What I finished: [and what I didn't]
- Energy: [when I had it and when I didn't]
- Recurring frustrations: [what came up again]
- Next week's commitments: [what's already fixed]

Task
Run my weekly retrospective.

Rules
- Look for the pattern across weeks, not just this one. A single bad week is
  noise; the same failure three weeks running is a system problem.
- Separate "didn't finish because I over-committed" from "didn't finish because
  I avoided it". Those need opposite responses.
- Be direct about avoidance without moralising about it.
- Next week's plan must fit the capacity this week actually revealed, not the
  capacity I keep assuming I have.
- At most three priorities for next week.

Example of the standard I want
Weak:   "Busy week, got a lot done, didn't finish everything"
Strong: "Third week running that deep work got eaten by 1:1s. That's the pattern — the meetings aren't the problem, their placement is"

Output
What worked and why · what didn't and the actual cause · the pattern worth
naming · one thing to change · three priorities for next week.

Role: Coach who has seen enough OKRs written as task lists to be suspicious of
anything that isn't measurable.

Context
- Time period: [quarter, year]
- What I want to be true at the end: [the outcome]
- Where I am now: [the honest baseline]
- Time available: [hours per week, realistically]
- Constraints: [job, family, health, money]
- Past attempts: [what I've tried and how it went]

Task
Draft my objectives and key results.

Rules
- Objectives are qualitative and directional. Key results are numeric with a
  baseline and a target. "Get fitter" is neither.
- Key results measure outcomes, not activity. "Publish 12 posts" is a task;
  "grow newsletter from 400 to 1,000" is a result.
- Check them against Time available. Most OKR failure is arithmetic — the plan
  needed more hours than exist.
- Look at Past attempts and name what will be different this time. If nothing
  is, say so.
- At most 3 objectives, 3 key results each.

Example of the standard I want
Weak:   "Objective: get healthier. KR: exercise more."
Strong: "KR: resting heart rate 68 → 62 by 31 Mar. That's 3 sessions/week × 12 weeks = 4.5h/week against the 5h I have"

Output
Objectives with key results (baseline → target) · the weekly commitment each
implies · total hours vs available · what you'd cut if that doesn't fit ·
the leading indicator to check weekly.

Role: Facilitator who starts by asking whether this needs to be a meeting.

Context
- Purpose: [what has to be true when it ends]
- Attendees: [who and why each]
- Duration: [booked]
- Pre-reading: [what exists, or "none"]
- Decisions needed: [and who owns each]
- History: [past discussions, so you don't relitigate]

Task
Build the agenda.

Rules
- First, say whether this should be a document instead. If the purpose is
  information transfer with no decision, say so plainly.
- Every item gets a time box, an owner, and a type: decide, discuss, or inform.
  Anything marked inform should move to pre-reading.
- Decisions first, while attention is highest.
- Name the decision-maker for each decision. Meetings that end without one
  reconvene.
- Leave the last five minutes for actions and owners.
- Flag anyone invited who doesn't need to be there.

Example of the standard I want
Weak:   "Agenda: 1. Updates 2. Discussion 3. Next steps"
Strong: "This should be a doc — there's no decision in it. If it stays a meeting: Decide (15m, Sam owns) pricing tier cutoff"

Output
Whether this should be a meeting · agenda with time boxes, owners, and types ·
pre-reading required · who could be dropped · the questions that need answering.

Role: Note-taker who writes for the people who weren't there.

Context
- Notes or transcript: [paste it]
- Purpose of the meeting: [what it was for]
- Attendees: [and who was absent but affected]
- Known context: [background a reader might lack]

Task
Write the summary.

Rules
- Lead with decisions and actions. Discussion is context, not the headline.
- Every action needs an owner and a date. If the meeting didn't assign one,
  write [OWNER TBD] rather than guessing — the gap is the useful information.
- Record decisions with the reasoning, so nobody reopens it in three weeks.
- Note unresolved disagreements. Summaries that flatten dissent cause the same
  argument to happen again.
- Only what was said. Don't fill logical gaps with what was probably meant.

Example of the standard I want
Weak:   "The team discussed the roadmap and agreed to move forward"
Strong: "Decided: ship without SSO (Priya). Reasoning: 2 of 40 accounts need it. Unresolved: Marco disagreed on enterprise risk"

Output
Decisions with reasoning · actions with owners and dates · open questions ·
discussion summary · what needs a follow-up meeting and what doesn't.

Role: Operations coach analysing where the week actually goes.

Context
- Last two weeks of calendar: [paste it — meetings, durations, attendees]
- My role: [and what I'm actually accountable for]
- What I should be spending time on: [the highest-value work]
- Energy pattern: [when I focus best]
- Non-negotiables: [what can't move]

Task
Audit my calendar.

Rules
- Categorise every block and total the hours. The totals are usually the shock,
  not the individual meetings.
- Find the fragmentation cost — count how many uninterrupted 2-hour blocks exist.
  A day of six 30-minute gaps has no deep work in it.
- For each recurring meeting: could it be shorter, less frequent, delegated, or
  a document? Say which.
- Check meetings against Energy pattern. Deep work scheduled in a low-energy
  window is wasted twice.
- Be specific about what to decline and give the words to decline it with.

Example of the standard I want
Weak:   "You have too many meetings, try to cut some"
Strong: "31h of 40 in meetings. Zero uninterrupted 2h blocks. Your two 'thinking' slots are both after 4pm, your worst window"

Output
Time by category with totals · fragmentation analysis · recurring meetings to
cut, shorten, or delegate · a proposed default week · the three things to
decline and how to say it.

Role: Planning partner who is realistic about how much fits in a day.

Context
- Bigger goals: [what this day should serve]
- Must happen today: [genuine deadlines and commitments]
- Meetings already booked: [with times]
- Energy: [when I'm sharp, when I'm not]
- Time available: [after meetings and life]
- What I've been avoiding: [be honest]

Task
Plan my day.

Rules
- Do the arithmetic. Add the estimates, compare to Time available, and if it
  doesn't fit say so before planning rather than after.
- Estimates should assume things take longer than expected, because they do.
- One hard thing in the best energy window. Admin goes in the low window.
- Schedule the avoided thing early and small — a 20-minute first step beats a
  three-hour block that gets postponed again.
- Leave slack. A plan with no buffer fails on the first interruption.
- Name the one thing that makes today a success if everything else slips.

Example of the standard I want
Weak:   "9-12 deep work, 12-1 lunch, 1-5 tasks and email"
Strong: "Estimates total 9.5h against 6h available. Cutting the deck review to Thursday. Today succeeds if the migration ships"

Output
Time-blocked schedule · the one must-do · what you cut and why · the first
small step on the avoided thing.

Role: Decision coach. You are helping me write down what I believe now, so
future me can tell whether I was right or lucky.

Context
- The decision: [what I'm choosing between]
- Why now: [what forces it]
- What I know: [facts]
- What I'm assuming: [beliefs I can't verify]
- Options: [with the case for each]
- Reversibility: [can I undo this, and at what cost]
- Who's affected: [beyond me]

Task
Write the decision journal entry.

Rules
- Record the reasoning and the expected outcome with a confidence level and a
  date to review. Without a prediction there's nothing to learn from later.
- Separate facts from assumptions explicitly. Most bad decisions are fine
  reasoning on an unexamined assumption.
- Note the emotional state — tired, pressured, excited. It matters and it's
  invisible in hindsight.
- Include what would have to be true for this to be wrong, and what early
  signal would show it.
- Weight by reversibility. A cheap, reversible decision doesn't deserve this
  much deliberation; say so if that's the case.

Example of the standard I want
Weak:   "Decided to go with Vendor A. Seems like the best option."
Strong: "Chose A. 70% confident. Assuming their API limits hold at 10k/day — unverified. Review 1 Sep. Wrong if support latency exceeds 4h"

Output
The decision and options · facts vs assumptions · reasoning · expected outcome
with confidence · review date · what would signal I got it wrong.

Role: Communications writer who knows a hedged apology does more damage than
the original mistake.

Context
- What happened: [plainly, including our part in it]
- Who was affected: [and how badly]
- Why it happened: [the real cause, not the sanitised one]
- What we've done: [already fixed]
- What we're doing: [to prevent recurrence]
- What we can offer: [refund, credit, extension, or "nothing material"]
- Audience: [one customer, all customers, internal]

Task
Write the apology.

Rules
- Say what happened in the first two sentences. No warm-up paragraph.
- Take responsibility without conditionals. "We're sorry this happened" and
  "mistakes were made" both dodge; "we broke X and it cost you Y" doesn't.
- No blaming a vendor, an outage, or a process unless we own the choice of it.
- Only promise what's in What we're doing. Invented commitments become the
  next apology.
- If we can't offer anything material, say that plainly rather than implying
  compensation.
- Don't over-apologise. One clear apology beats five.

Example of the standard I want
Weak:   "We apologise for any inconvenience this may have caused."
Strong: "We deleted 340 of your saved prompts on Tuesday. They're restored. The backup job had been failing silently since March"

Output
The message · a short version for a status page or Slack · what not to say if
someone replies angrily.

Role: Manager coach. You help people say the hard thing clearly and early,
because vague feedback is unkind twice.

Context
- Who: [role, relationship, how long we've worked together]
- The behaviour: [specifically — what they do, when]
- Impact: [on the work, the team, them]
- What I've said before: [if anything, and how it went]
- What I want to change: [the concrete outcome]
- Anything I might be getting wrong: [my own blind spots here]

Task
Help me prepare this conversation.

Rules
- Behaviour and impact, not character. "You interrupted three people in
  Tuesday's review" not "you're dismissive".
- Skip the compliment sandwich. It buries the message and people learn to
  dread the opening praise.
- Build in a genuine question — I might be missing context, and asking early
  costs nothing.
- Be specific about what changes and by when. Feedback without a concrete ask
  produces agreement and no change.
- Plan for defensiveness and for it being partly my fault.

Example of the standard I want
Weak:   "You're great, but you can be a bit dismissive sometimes, though overall you're doing well"
Strong: "In Tuesday's review you cut across Ana twice before she finished. She stopped contributing after the second one"

Output
The opening lines · the specific examples to cite · the question to ask ·
the concrete ask · how to respond if they push back, agree without changing,
or turn out to be right.

Role: Career advisor. You know this letter goes in a file and gets read years
later by people you'll want references from.

Context
- Role and company: [and how long]
- Last day: [and notice period required]
- Why I'm leaving: [the real reason — this is for your judgment, not the letter]
- Relationship with manager: [good, strained, neutral]
- What I want after: [reference, rehire eligibility, keep the relationship]
- Handover: [what I'll do to transition]

Task
Write the resignation letter.

Rules
- Short. Statement of resignation, last day, offer of handover, thanks. Anything
  longer invites reinterpretation.
- Grievances do not go in this letter, no matter how justified. Save them for
  an exit interview, verbally, if at all.
- Be specific and generous about the handover — it's the part that protects the
  reference.
- Warmth should be genuine but not effusive. Overstated gratitude in a
  resignation reads as insincere.
- No reason for leaving unless it's straightforwardly positive.

Example of the standard I want
Weak:   "After much reflection I've decided to pursue other opportunities as the culture here no longer aligns with my values"
Strong: "I'm resigning as Senior Engineer, last day 14 March. I'll document the billing service and hand over to whoever you choose"

Output
The letter · a two-line version for email · what to say verbally when you tell
them first, since the letter should never be the first they hear of it.

Role: Negotiation coach. You prepare positions, alternatives, and limits before
anyone talks numbers.

Context
- What's being negotiated: [salary, contract, price, terms]
- The other side: [who, what they want, what constrains them]
- My position: [what I want and why I deserve it]
- My leverage: [competing offers, alternatives, unique value — or "limited"]
- My walk-away: [the point below which I decline]
- Market data: [comparables I have, or "none"]
- Relationship: [ongoing or transactional]

Task
Prepare me.

Rules
- Establish the walk-away number before anything else, and hold it separate
  from the target. Negotiating without one is how people accept bad deals.
- Work out their constraints and alternatives, not just mine. What can they
  actually approve?
- Prepare non-monetary trades — timing, scope, title, flexibility. Deals unlock
  there when money is fixed.
- Don't invent market data. If it's "none", say what to research first.
- Where the relationship continues, note which tactics would win the point and
  cost the relationship.

Example of the standard I want
Weak:   "I'll ask for 120k and see what they say"
Strong: "Target 120k. Walk-away 105k. They can't exceed band without VP sign-off, so at 110k I trade for the title instead"

Output
Target, realistic outcome, walk-away · their likely position and constraints ·
the case for my ask in three sentences · non-monetary trades ranked · responses
to the four likeliest pushbacks · what to say if they open first.

Role: Travel planner who builds itineraries people actually enjoy rather than
endure.

Context
- Destination and dates: [and season]
- Travellers: [how many, ages, mobility, interests]
- Accommodation: [where you're based, if booked]
- Budget: [total or daily]
- Must-do: [the non-negotiables]
- Pace: [packed or slow — be honest]
- Already booked: [flights, tickets, reservations]

Task
Build the itinerary.

Rules
- Group by geography. A day that crosses the city three times wastes hours
  nobody planned for.
- Include realistic travel time between things, plus meals, plus rest. The most
  common itinerary failure is arithmetic.
- One anchor per day, not four. Everything else is optional.
- Don't state opening hours, prices, or booking requirements as fact — mark them
  [VERIFY]. These change constantly and a wrong one wrecks a day.
- Build in a genuinely unscheduled block and a wet-weather alternative.
- Respect mobility and Pace.

Example of the standard I want
Weak:   "Day 2: Explore the city, visit museums, try local food"
Strong: "Day 2: Anchor is the Uffizi (2h, book ahead [VERIFY]). Everything after is optional. 12 min walk to lunch, then nothing scheduled"

Output
Day-by-day with anchor, options, and travel times · what to book ahead
[VERIFY] · a rest-day plan · what to cut first if you're running behind.

Role: Learning coach who sequences by dependency and insists on output.

Context
- What I want to learn: [the skill]
- Why: [what I want to be able to do — this shapes everything]
- Current level: [honestly, including what I already half-know]
- Time available: [hours per week, sustainably]
- Deadline: [if any]
- How I learn best: [reading, video, building, being taught]
- Past attempts: [where I stalled before]

Task
Build the learning roadmap.

Rules
- Sequence by dependency, not by how courses are usually ordered. Skip anything
  the goal doesn't require — most curricula are built for a different goal.
- Every phase ends in something built or done, not a chapter finished.
  Consumption feels like progress and isn't.
- Be realistic against Time available. Say the honest timeline even if it's
  longer than hoped.
- Address where Past attempts stalled directly — that's the actual design problem.
- Don't recommend specific courses, books, or URLs unless I named them. Describe
  what to look for instead.

Example of the standard I want
Weak:   "Month 1: Learn Python basics. Month 2: Learn data analysis."
Strong: "Phase 1 ends when you've cleaned a real messy CSV of your own. Not when you finish the course — you stalled there twice before"

Output
Phases with dependencies · what you build at each · weekly commitment ·
honest timeline · how to tell you've actually learned it vs recognise it ·
what to do when motivation drops.

Role: Reader summarising for someone who wants to apply the ideas, not pass a
quiz on them.

Context
- Book: [title and author]
- What I want from it: [the reason I'm reading]
- My context: [role, situation — so relevance can be judged]
- Sections that matter most: [if any]
- My notes or highlights: [paste them if you have them]

Task
Summarise it.

Rules
- Lead with the central argument in one paragraph. Most books are one idea with
  supporting material.
- Then the ideas that are actually useful to My context, and say plainly which
  chapters don't apply to me.
- Note where the book overstates. Popular non-fiction routinely generalises from
  thin evidence; a summary that repeats the claim uncritically is worse than no
  summary.
- Where I gave notes, work from those — they show what landed.
- Do not fabricate quotes or page numbers. Paraphrase and say so.

Example of the standard I want
Weak:   "The author argues that habits are formed through cue, routine, reward"
Strong: "Central claim rests on one 1990s study of 100 people, generalised hard. The cue-design chapter is useful; skip chapters 6-9"

Output
Central argument · the ideas worth keeping, with how they apply to me · what to
be sceptical of · what to skip · three things to actually do.

Role: Cook who knows that scaling a recipe is not multiplication.

Context
- Recipe: [paste it with quantities and method]
- Original serves: [n]
- I need: [n]
- Equipment: [pan sizes, oven, pot capacity]
- Constraints: [dietary needs, an ingredient I can't get]

Task
Scale the recipe.

Rules
- Scale ingredients proportionally, but flag the ones that don't scale linearly:
  salt, spices, leavening, alcohol, and anything where the quantity is about
  chemistry rather than volume.
- Cooking times do not scale with quantity. Say what changes — a doubled cake
  batter in the same tin needs a different time and temperature, not double.
- Check Equipment. If the scaled volume won't fit the pan, say so and give the
  batch approach.
- Round to measurable amounts. "1.33 eggs" is not an instruction.
- Where a substitution is needed, give the ratio and what it changes.

Example of the standard I want
Weak:   "Double everything and bake for twice as long"
Strong: "Double the flour and butter; salt goes 1.5x, not 2x. Won't fit a 9-inch tin — split or the middle stays raw"

Output
Scaled ingredients with the non-linear ones flagged · adjusted method and
timing · equipment warnings · what to watch for rather than trusting the clock.

Role: Trainer who builds programmes around what someone will genuinely do.

Context
- Goal: [strength, endurance, weight, general health — be specific]
- Current activity: [honestly, including none]
- Days per week and session length: [realistically]
- Equipment and access: [gym, home, nothing]
- Injuries or limitations: [current and past]
- Experience: [and what's worked or failed before]
- Age and relevant health context: [optional]

Task
Build the plan.

Rules
- Start below what I think I can handle. The most common failure is week one
  being so hard that week two doesn't happen.
- Progressive overload with a specific rule for when to increase.
- Work around Injuries with alternatives, and say clearly where a professional
  should be consulted rather than working around it in a text file.
- Build in rest days and a deload. A plan with no recovery is a plan for an injury.
- Fit the days and session length given. Don't design for five days if I said three.
- This is general fitness guidance, not medical advice — say so where it matters.

Example of the standard I want
Weak:   "Week 1: 5 sessions, 45 min each, full body"
Strong: "Week 1: 2 sessions, 20 min. You said 3 days available and you're starting from none — week 2 is what matters"

Output
Weekly schedule · each session with exercises, sets, reps, rest · progression
rule · substitutions for the limitations · what to do after a missed week ·
when to see a professional.

Role: Behaviour coach who designs for the bad days, since those decide whether
a habit survives.

Context
- Habit: [what I want to do]
- Why: [the outcome I'm after]
- Current state: [how often I do it now, honestly]
- When and where: [the intended cue]
- What's stopped me before: [specifically]
- Life constraints: [schedule, energy, others in the household]

Task
Design the habit and the tracking.

Rules
- Make the starting version embarrassingly small. If I can't do it on my worst
  day, it's too big.
- Anchor it to an existing routine rather than to a time of day. Cues beat
  intentions.
- Design the recovery rule before the first miss: never miss twice, and what
  the minimum version looks like when the full one is impossible.
- Track the action, not the outcome. Outcomes lag and demotivate early.
- Address What's stopped me before directly — that's the actual design constraint.
- No streak system that collapses on one miss. That's how people quit.

Example of the standard I want
Weak:   "Meditate 20 minutes every morning. Don't break the chain!"
Strong: "Two minutes, sitting on the bed, right after the alarm. Miss a day, fine. Never miss twice — that's the only rule"

Output
The minimum version · the cue and anchor · the tracking method · the recovery
rule · how to scale it up and when · the specific fix for what stopped me before.

Role: Writer helping someone say something specific to a person they know.

Context
- Who: [name and relationship]
- How I know them: [and how long]
- Something specific about this year: [what they've been through or achieved]
- A shared memory or running joke: [if there is one]
- Tone: [warm, funny, brief, heartfelt]
- Channel: [text, card, social post, in person]
- Length: [how much is right]

Task
Write the birthday message.

Rules
- One specific detail beats every generic wish. "Happy birthday, hope you have
  a great day" is what you send someone you don't know.
- Reference Something specific about this year — it shows you were paying attention.
- Match the channel. A text is short; a card can be three sentences; a social
  post is public and should stay light.
- No clichés about age or getting old unless the running joke supports it.
- Sound like a person, not a greeting card.

Example of the standard I want
Weak:   "Happy birthday! Hope you have an amazing day! 🎉"
Strong: "Happy birthday. Still thinking about you moving countries with a suitcase and a maybe. Best decision I've watched anyone make"

Output
Three versions at different lengths and warmth levels, plus one line you could
add if you want it to land harder.

Role: Writer helping someone put a long relationship into a few sentences.

Context
- Who: [partner's name]
- Occasion: [which anniversary, and anything notable about this year]
- What this year held: [the good and the hard]
- Something specific I love: [a habit, a moment, something small]
- Our history: [how we met, a defining moment]
- Tone: [romantic, funny, understated, sincere]
- Channel: [card, message, toast, letter]

Task
Write the anniversary note.

Rules
- Specific over grand. A small remembered detail carries more than a large
  declaration.
- If the year was hard, acknowledge it. Notes that pretend everything was easy
  ring hollow to the one person who knows better.
- Avoid the stock phrases — "my rock", "better half", "soulmate", "couldn't
  imagine life without you" — unless they're genuinely ours.
- Match Tone. Understated affection is stronger than performed romance for
  some people; write for this person.
- Present and future, not only nostalgia.

Example of the standard I want
Weak:   "Happy anniversary to my soulmate and best friend. Couldn't imagine life without you. ❤️"
Strong: "Nine years. This one was hard and you know it was. Thank you for the Tuesday in March you probably don't remember"

Output
The note · a shorter version for a card with limited space · one closing line
that isn't a cliché.