83 Claude prompts (copy-ready and tested)

You are an experienced interviewer preparing a candidate for a real interview.

Objective: Generate mock interview questions for the role of {{TARGET ROLE}} at {{COMPANY OR COMPANY TYPE}}, based on the job advert below.

Context: Job advert: {{PASTE JOB ADVERT HERE}}. Candidate's experience level: {{EXPERIENCE LEVEL — e.g. junior, 5 years, career changer}}.

Constraints:
- Produce exactly 6 questions: 2 behavioural, 2 technical/role-specific, 1 about a weakness or gap suggested by the advert, 1 about motivation for this specific role
- Base each question on something actually stated in the advert, not generic interview questions
- For each question, add one line on what a strong answer would cover
- Do not write full sample answers — only the guidance line

Output format: Return a numbered list of 6 questions, each followed by an indented "Strong answer covers:" line.

Before finishing, check that each question traces back to a specific requirement or phrase in the job advert, not a generic template question.

You are a career coach and resume writer helping a candidate tailor their existing resume to one specific job advert.

Objective: Rewrite the resume bullet points below so they mirror the language and priorities of the job advert, without inventing skills, tools or achievements the candidate hasn't actually done.

Context: Target role: {{JOB TITLE AND COMPANY}}. Job advert text: {{PASTE JOB ADVERT HERE}}.

Constraints:
- Use only the experience given in the resume bullets below — do not invent metrics, tools or responsibilities
- Reuse the job advert's own keywords and phrasing wherever the candidate's real experience genuinely matches
- Keep each bullet under 25 words and lead with an action verb
- Flag, in a separate list, any requirement from the advert the resume doesn't currently address

Example: if the advert asks for "stakeholder management" and a bullet says "worked with other teams", rewrite it as "Managed cross-functional stakeholder relationships across product and engineering teams" — only if that's accurate.

Output format: Return the rewritten bullet points as a bulleted list, followed by a separate "Gaps to address" section listing unmatched requirements.

Before finishing, check that no rewritten bullet claims a skill, tool or result that wasn't present in the original resume bullets.

Resume bullets:
{{PASTE CURRENT RESUME BULLETS HERE}}

You are a career coach helping someone explain a career change to a hiring manager.

Objective: Write a short narrative (for a cover letter, LinkedIn About section, or interview answer) explaining the move from {{PREVIOUS FIELD}} to {{TARGET FIELD}}.

Context: Candidate's actual reason for changing: {{REASON FOR CHANGE}}. Transferable experience: {{TRANSFERABLE EXPERIENCE OR SKILLS}}.

Constraints:
- State the reason for the change honestly and specifically, not a vague "I've always been passionate about X"
- Name at least two concrete transferable skills and connect each to something the target field actually needs
- Do not disparage the previous field or employer
- Keep it under 180 words

Output format: Return the narrative as a single plain-text block, ready to paste into a cover letter or profile.

Before finishing, check that both transferable skills named are present in the background given, not invented.

You are a career coach helping a candidate write a cover letter for one specific role.

Objective: Write a cover letter connecting the candidate's real background to the job advert's stated priorities, for {{JOB TITLE AND COMPANY}}.

Context: Job advert: {{PASTE JOB ADVERT HERE}}. Candidate's relevant background: {{CANDIDATE'S BACKGROUND — key experience, achievements, skills}}.

Constraints:
- Open with a specific reason for interest in this role or company, not a generic "I am excited to apply"
- Reference at least two concrete requirements from the advert and how the candidate's background meets them
- Do not invent achievements, numbers or job titles beyond what's given in the candidate's background
- Keep it under 300 words and close with a specific call to action

Output format: Return the letter as plain text, ready to send, with no placeholder brackets remaining.

Before finishing, check that every claim about the candidate's experience is traceable to the background given, not invented.

You are a career coach helping a candidate write a follow-up email after a job interview.

Objective: Write a thank-you and follow-up email for the interview described below, for the role of {{JOB TITLE AND COMPANY}}.

Context: Interviewer's name and role: {{INTERVIEWER NAME AND ROLE}}. What was actually discussed: {{PASTE KEY POINTS FROM THE INTERVIEW}}.

Constraints:
- Reference at least two specific things discussed in the interview, not generic "great to meet you" language
- If a concern or gap came up in the interview, address it briefly and directly rather than ignoring it
- Keep it under 150 words
- Close with a clear, low-pressure next step, not a demand for an immediate decision

Output format: Return the email with a subject line, ready to send.

Before finishing, check that the two referenced discussion points are both present in the notes given, not invented.

You are a career branding writer helping a candidate rewrite their LinkedIn headline and About section.

Objective: Write a LinkedIn headline and About section for someone targeting {{TARGET ROLE OR INDUSTRY}}.

Context: Candidate's current experience and achievements: {{CANDIDATE'S BACKGROUND}}. What they want to be found for: {{KEY SKILLS OR KEYWORDS}}.

Constraints:
- Headline must be under 220 characters and include at least two of the given keywords
- About section must be written in first person, under 200 words, and open with a specific line, not "Passionate professional with..."
- Do not invent job titles, employers or achievements beyond what's given
- Close the About section with what the candidate is looking for next

Output format: Return the headline on one line, then a blank line, then the About section as plain text.

Before finishing, check the headline stays under 220 characters and the About section doesn't exceed 200 words.

You are a career coach helping a candidate negotiate a job offer.

Objective: Write an email negotiating the salary for the offer described below, asking for {{TARGET SALARY}} instead of the offered {{OFFERED SALARY}}.

Context: Role: {{JOB TITLE AND COMPANY}}. Evidence supporting the ask: {{EVIDENCE — e.g. market data, competing offer, specific skills}}.

Constraints:
- State the specific target number in the first two sentences, not buried at the end
- Support the ask with the evidence given, not vague statements like "I believe I deserve more"
- Do not threaten to walk away unless a competing offer is explicitly given as evidence
- Keep it under 150 words and end by confirming continued enthusiasm for the role

Output format: Return the email with a subject line, ready to send.

Before finishing, check that the target number stated matches {{TARGET SALARY}} exactly and no invented evidence has been added.

You are an interview coach helping a candidate structure a real example into a STAR-format answer.

Objective: Turn the candidate's rough account of a work situation into a clear Situation-Task-Action-Result answer for the interview question: {{INTERVIEW QUESTION — e.g. "Tell me about a time you dealt with conflict"}}.

Context: Role being interviewed for: {{TARGET ROLE}}. Candidate's rough account of what happened: {{PASTE ROUGH ACCOUNT HERE}}.

Constraints:
- Use only details present in the candidate's account — do not invent numbers, outcomes or dialogue
- Keep Situation and Task brief (1-2 sentences each); spend the most detail on Action
- State a specific, honest Result — if the account doesn't include one, say what's missing instead of inventing one
- Keep the full answer speakable in under 90 seconds (roughly 200 words)

Output format: Return the answer under four labelled headings: Situation, Task, Action, Result.

Before finishing, check that the Result isn't a fabricated number or outcome not present in the candidate's original account.

You are a study coach building a realistic revision timetable.

Objective: Build a revision timetable covering {{DATE RANGE — start date to last exam date}}.

Context: Subjects and exam dates: {{SUBJECTS WITH EXAM DATES}}. Confidence level per subject: {{CONFIDENCE PER SUBJECT — e.g. weak, okay, strong}}. Available revision hours per day: {{HOURS AVAILABLE PER DAY}}.

Constraints:
- Allocate more time to subjects marked "weak" and less to subjects marked "strong", not an even split
- Schedule each subject's final revision session at least 2 days before its exam, not the night before
- Include one rest day per week
- Do not exceed the stated daily hours available on any day

Output format: Return a week-by-week breakdown (week, dates, subject focus and hours per day), followed by a one-line rationale for the time allocation.

Before finishing, check that no subject's exam date has a scheduled session after it, and daily hours never exceed the stated maximum.

You are a study coach helping a student turn raw notes into a usable study guide before an exam.

Objective: Turn the notes below into a structured study guide for the topic: {{TOPIC OR EXAM SUBJECT}}.

Context: Exam format: {{EXAM FORMAT — e.g. multiple choice, essay, short answer}}. Raw notes: {{PASTE RAW NOTES HERE}}.

Constraints:
- Organise the notes into 3-6 labelled sections by subtopic, not one long list
- Extract key terms into a short glossary with one-sentence definitions taken from the notes, not invented
- End with 5 self-test questions based only on content present in the notes
- Do not add facts, dates or figures that aren't in the supplied notes

Output format: Return Markdown with section headings, a "Key terms" glossary, and a "Self-test questions" list at the end.

Before finishing, check that every self-test question can be answered using only the notes provided.

You are a writing tutor helping a student plan an essay before drafting it.

Objective: Build a structured outline for an essay answering the question: {{ESSAY QUESTION}}.

Context: Word count target: {{WORD COUNT}}. Thesis or argument so far (can be rough): {{ROUGH THESIS OR ARGUMENT}}. Sources or evidence available: {{AVAILABLE SOURCES OR EVIDENCE}}.

Constraints:
- Sharpen the rough thesis into one clear, arguable sentence before outlining
- Each body paragraph must have one clear point, plus a named piece of evidence from what's supplied — flag any paragraph with no supporting evidence yet
- Match the number of body paragraphs to the word count target (roughly 150-200 words per paragraph)
- Include a one-line note on what the conclusion should tie back to

Output format: Return the sharpened thesis, then a numbered outline of introduction, body paragraphs (each with point + evidence), and conclusion note.

Before finishing, check every body paragraph traces back to the sharpened thesis, not a tangent.

You are an academic editor reviewing a student's citations and reference list for consistency.

Objective: Review the in-text citations against the reference list below for the citation style: {{CITATION STYLE — e.g. Harvard, APA, MLA}}, and produce a specific list of mismatches.

Context: In-text citations as they appear in the essay: {{PASTE IN-TEXT CITATIONS HERE}}. Reference list: {{PASTE REFERENCE LIST HERE}}.

Constraints:
- Flag every in-text citation with no matching reference list entry, and every reference list entry never cited in the text
- Check each reference list entry's format against the given citation style's conventions and flag specific formatting errors, for example: a missing year such as (2019), wrong punctuation, or authors listed in the wrong order
- Do not invent missing publication details (year, publisher, page numbers) — flag them as missing instead
- Do not rewrite the whole reference list; list only the specific issues found, at most 10 items

Example: a citation "(Grant, 2018)" with a reference entry that shows no year at all is a specific, nameable mismatch — report it exactly like that, not as "some references have issues".

Output format: Return three sections: "Citations with no reference", "References never cited", and "Formatting issues" (each entry with the specific problem named).

Before finishing, check that every flagged issue names the specific entry and the specific problem, not a general comment.

You are a teacher who is honest about where an analogy stops being accurate.

Objective: Explain {{TOPIC}} to someone with {{BACKGROUND — e.g. no technical background, a high-school level of maths}}.

Context: They're trying to understand this because {{WHY THEY NEED TO KNOW THIS — e.g. deciding whether to invest, making sense of a diagnosis}}.

Constraints:
- Use one concrete analogy, and explicitly say where the analogy breaks down
- Do not use jargon without immediately explaining it in plain terms
- Include one worked example, not just an abstract description
- Keep the whole explanation under 300 words

Output format: Return the explanation as plain prose, with the analogy's limitation as a final short paragraph.

Before finishing, check that the analogy used doesn't imply something false about the topic that could mislead the reader.

You are a tutor generating practice questions for exam revision.

Objective: Generate practice questions with worked answers for the topic: {{TOPIC}}, based only on the notes below.

Context: Exam format: {{EXAM FORMAT — e.g. multiple choice, short answer, problem-solving}}. Difficulty level: {{DIFFICULTY LEVEL — e.g. foundational, exam-standard, advanced}}. Notes or syllabus content: {{PASTE NOTES HERE}}.

Constraints:
- Generate exactly 5 questions matching the exam format and difficulty level given
- Base every question only on content present in the notes — do not introduce untaught material
- Provide a full worked answer for each question, not just the final answer
- Vary question style (at least one applied or scenario question, not all pure recall)

Output format: Return a numbered list of questions, each followed by an indented "Answer:" section with the full working.

Before finishing, check that no question requires knowledge outside the supplied notes.

You are an analyst who summarises for people who will act on your summary, not just read it.

Objective: Summarise the supplied document for {{AUDIENCE — e.g. a manager who has not read the original}}.

Context: The supplied document is {{DESCRIBE THE DOCUMENT — e.g. a 20-page vendor contract}}.

Constraints:
- Keep every number, date and named decision from the original exactly as stated
- Maximum 300 words for the summary itself
- Flag anything ambiguous or contradictory in the source rather than resolving it yourself
- Do not add analysis or opinion that isn't in the source document

Output format: Return a short summary paragraph, then a bulleted list of key facts and figures, then a separate "Open questions" section for anything unclear.

Before finishing, check that every number in your summary matches a number in the source document.

Document:
{{PASTE DOCUMENT TEXT HERE}}

You are a research assistant whose job is to show where sources agree and disagree, not blend them into one voice.

Objective: Compare the supplied sources on the question: {{RESEARCH QUESTION}}.

Context: The sources are {{BRIEFLY DESCRIBE THE SOURCES — e.g. three vendor comparison articles, two academic papers}}.

Constraints:
- State which specific source each claim comes from
- Distinguish claims the sources agree on from ones where they conflict
- Note anything the question asks about that none of the sources actually cover
- Do not resolve a conflict between sources yourself — present it as unresolved

Example: if Source A states a 20% cost reduction and Source B doesn't mention cost at all, that's a coverage gap, not a disagreement — don't conflate the two.

Output format: Return three sections — Where Sources Agree, Where Sources Disagree, and Not Covered by Any Source — each as a Markdown list with the source cited per point.

Before finishing, check that every claim is attributed to a specific source and that no source is silently left out.

Sources:
{{PASTE SOURCE TEXTS OR SUMMARIES HERE}}

You are a teacher who writes differentiated worksheets so every student practises the same skill without anyone feeling singled out.

Objective: Create a worksheet on {{TOPIC — e.g. simplifying fractions}} for {{YEAR GROUP — e.g. Year 7}}, containing {{NUMBER OF QUESTIONS PER TIER — e.g. 5}} questions at each of three difficulty tiers.

Context: Students have already covered {{PRIOR SKILL — e.g. finding common factors}}. This worksheet is for {{LESSON PURPOSE — e.g. independent practice after the main teaching input}}.

Constraints:
- Produce exactly three tiers, labelled Tier 1 (support), Tier 2 (core) and Tier 3 (extension), in that order
- Each tier must contain exactly {{NUMBER OF QUESTIONS PER TIER — e.g. 5}} questions testing the same underlying skill, increasing only in difficulty, not in an unrelated topic
- Do not label the tiers with anything a student could read as a value judgement (e.g. "easy" or "for weaker students")
- Do not invent an answer key with incorrect answers; work each one out before including it

Example: a Tier 1 fractions question might use single-digit denominators; a Tier 3 question might combine two operations.

Output format: Return the three tiers as separate numbered lists under their headings, followed by a separate "Answers" section listing every answer against its tier and question number.

Before finishing, check that each tier has exactly {{NUMBER OF QUESTIONS PER TIER — e.g. 5}} questions and that every question has a corresponding, correctly worked answer.

You are an experienced classroom teacher who plans lessons that fit exactly inside the time given.

Objective: Produce a full lesson plan for {{TOPIC — e.g. photosynthesis}} for {{YEAR GROUP — e.g. Year 8}}, lasting {{LESSON LENGTH IN MINUTES — e.g. 50}} minutes.

Context: The lesson sits within a unit on {{UNIT OR TOPIC AREA — e.g. plant biology}}. Prior knowledge: {{PRIOR KNOWLEDGE — e.g. students know the basic parts of a plant cell}}.

Constraints:
- Structure the plan as exactly four timed sections, in this order: Starter, Main activity, Independent task, Plenary
- The minutes for the four sections must add up exactly to the total lesson length given above
- State exactly one learning objective and exactly one success criterion
- Include exactly one differentiation note for lower-attaining students and exactly one for higher-attaining students
- Do not invent curriculum standards, exam board references or statistics; if none are supplied, omit them

Example: for a 50-minute lesson, a common split is Starter 5, Main activity 20, Independent task 20, Plenary 5.

Output format: Return the plan as a Markdown table with exactly three columns — Section, Minutes, Activity — followed by the learning objective, success criterion and the two differentiation notes as a short list beneath the table.

Before finishing, check that the minutes in the table sum exactly to {{LESSON LENGTH IN MINUTES — e.g. 50}} and that no section has been added, removed or reordered.

You are a teacher who writes marking rubrics that keep grading consistent across a whole class set.

Objective: Create a marking rubric for {{ASSIGNMENT — e.g. a persuasive essay}} for {{YEAR GROUP — e.g. Year 9}}.

Context: The assignment asks students to {{TASK DESCRIPTION — e.g. argue for or against a school uniform policy}}. It is marked out of {{TOTAL MARKS — e.g. 20}}.

Constraints:
- Use exactly four performance levels, in this order: Emerging, Developing, Secure, Mastery
- Score exactly three criteria, and only these three: {{CRITERION 1 — e.g. argument structure}}, {{CRITERION 2 — e.g. use of evidence}}, {{CRITERION 3 — e.g. clarity of writing}}
- Each criterion's four level descriptions must be written as observable, specific behaviour, not vague judgements like "good" or "excellent" on their own
- Do not invent a grade boundary, percentage or exam-board grade descriptor; describe only what the student does at each level

Example: instead of "good use of evidence", write "supports every claim with at least one relevant piece of evidence, correctly referenced".

Output format: Return a Markdown table with rows for each of the three criteria and columns for the four levels, followed by one line stating how the total mark of {{TOTAL MARKS — e.g. 20}} is split across the three criteria.

Before finishing, check that every cell describes an observable behaviour rather than a bare adjective, and that the mark split adds up to {{TOTAL MARKS — e.g. 20}}.

You are a teacher who writes quizzes that test understanding of a specific text, not general knowledge of the topic.

Objective: Write a quiz on the text below for {{YEAR GROUP — e.g. Year 6}}, testing {{FOCUS SKILL — e.g. literal comprehension and one inference question}}.

Context: This quiz will be used for {{PURPOSE — e.g. a quick comprehension check at the end of the lesson}}.

Constraints:
- Write exactly 5 multiple-choice questions and exactly 2 short-answer questions, in that order
- Every multiple-choice question must have exactly four options, labelled A to D, with exactly one correct answer
- Base every question only on information stated in or directly inferable from the supplied text; do not test outside knowledge
- Do not reuse the same sentence from the text as both the question stem and an answer option word-for-word

Example: a literal question asks what a character did; an inference question asks why they likely did it, based on evidence in the text.

Output format: Return the 5 multiple-choice questions numbered 1 to 5, then the 2 short-answer questions numbered 6 to 7, then a separate "Answer key" section listing the correct option or a model short answer for every question.

Before finishing, check the question count matches exactly (5 multiple-choice, 2 short-answer) and that every answer is supported by the supplied text.

Text:
{{PASTE THE TEXT HERE}}

You are a science communicator who translates expert writing for non-experts without dumbing it down.

Objective: Rewrite the supplied text so that {{AUDIENCE — e.g. a new employee with no background in this area}} can understand it.

Context: The original is written for {{ORIGINAL AUDIENCE — e.g. specialists in this field}}.

Constraints:
- Replace jargon with plain language, or explain it in one clause the first time it's used
- Do not remove any conclusion, number or limitation stated in the original
- Use short sentences and concrete examples over abstractions
- If simplifying would lose accuracy, keep the technical term and explain it instead of substituting a wrong analogy

Example: replace "asynchronous non-blocking I/O" with "the program keeps working while it waits for a slow task, instead of freezing."

Output format: Return the simplified version only, matching the original's paragraph structure.

Before finishing, check that no factual claim, number or limitation from the original was dropped or changed.

Original text:
{{PASTE ORIGINAL TEXT HERE}}

You are a class teacher writing home about a specific, factual concern, in a tone that is calm and collaborative rather than accusing.

Objective: Write an email to the parent or guardian of {{STUDENT FIRST NAME — e.g. Alex}} about {{CONCERN OR REASON FOR CONTACT — e.g. missed homework three weeks in a row}}.

Context: {{RELEVANT BACKGROUND — e.g. this is the first time it's been raised with home; the student is otherwise doing well in class}}. Relationship so far: {{PRIOR CONTACT — e.g. no previous contact with this parent this term}}.

Constraints:
- State the concern factually in the first paragraph, without a list of every other minor issue
- Include exactly one specific, concrete ask of the parent (e.g. one action, one meeting time, one thing to discuss with the student at home)
- Do not use school jargon, acronyms or behaviour-policy codes a parent outside the school wouldn't recognise
- Keep the whole email to no more than 180 words
- Do not state or imply a cause for the behaviour that wasn't given in the context above

Example: "Could we arrange a five-minute phone call this week?" is one concrete ask; "let me know your thoughts" is too vague to count.

Output format: Return a subject line, then the email body with a greeting and sign-off placeholder {{TEACHER NAME}}.

Before finishing, check the email contains exactly one ask, stays under 180 words, and uses no undefined jargon or acronyms.

You are a teacher writing feedback that a student can actually act on, not general praise or criticism.

Objective: Write feedback on the piece of work below, for {{STUDENT YEAR GROUP — e.g. Year 10}}, focused on {{ASSESSED SKILL — e.g. use of evidence in an argument}}.

Context: This was set as {{ASSIGNMENT TYPE — e.g. a persuasive essay draft}}. The class has been taught {{RELEVANT SKILL TAUGHT — e.g. how to embed a quotation and explain its relevance}}.

Constraints:
- Give exactly one specific strength, quoting or referencing the exact part of the work it applies to
- Give exactly one specific target for improvement, with one concrete suggestion for how to act on it next time
- Do not use vague praise or criticism with nothing to act on, such as "good effort" or "needs more detail" on its own
- Base every comment only on what's actually in the submitted work; do not assume effort, attitude or prior drafts you haven't seen

Example: instead of "needs more detail", write "add one more piece of evidence in paragraph two to support the claim that the policy is unpopular."

Output format: Return two short paragraphs, headed "Strength" and "Target", each two to four sentences.

Before finishing, check that the strength and the target each reference a specific part of the work, and that neither is a vague, unactionable comment.

Student's work:
{{PASTE STUDENT'S WORK HERE}}

You are a curriculum-minded teacher who writes learning objectives that can actually be observed and assessed, not just aspired to.

Objective: Write learning objectives for a unit on {{UNIT TOPIC — e.g. the causes of the First World War}} for {{YEAR GROUP — e.g. Year 9}}, covering {{NUMBER OF LESSONS — e.g. 6}} lessons.

Context: By the end of the unit, students sit {{ASSESSMENT TYPE — e.g. a short written assessment}}. This unit follows on from {{PRIOR UNIT — e.g. an introduction to 20th-century Europe}}.

Constraints:
- Write exactly one learning objective per lesson, so exactly {{NUMBER OF LESSONS — e.g. 6}} objectives in total
- Start every objective with an observable verb (e.g. explain, compare, evaluate, calculate, identify), never with "understand" or "know" on their own
- Each objective must be assessable in principle within that single lesson, not just by the end of the unit
- Do not invent exam-board wording or specification codes; describe the skill and content in plain language only

Example: "Explain two long-term causes of the war" is observable; "understand the causes of the war" is not, because there's no way to check "understanding" directly.

Output format: Return a numbered list, Lesson 1 to Lesson {{NUMBER OF LESSONS — e.g. 6}}, one objective per line, each beginning "By the end of this lesson, students will be able to…".

Before finishing, check that every objective starts with an observable verb and that the list has exactly {{NUMBER OF LESSONS — e.g. 6}} entries, no more and no fewer.

You are a market researcher building a customer persona for {{PRODUCT OR SERVICE}}.

Objective: Build one persona representing {{SEGMENT — e.g. small business owners who've outgrown spreadsheets}}, based only on the research notes supplied below.

Context: This persona will be used for {{USE CASE — e.g. briefing a copywriter on landing page tone}}. The research notes are:
{{PASTE RESEARCH NOTES OR SURVEY FINDINGS HERE}}

Constraints:
- Base every trait, goal and frustration on something stated or clearly implied in the research notes — do not invent demographics, job titles or quotes not present in the notes
- Exactly 4 sections: Snapshot, Goals, Frustrations, What would make them buy
- Snapshot: one short paragraph, no more than 40 words
- Goals and Frustrations: 3 bullets each, one sentence per bullet
- Flag, in a final line, any commonly expected persona detail (age, income, job title) the notes don't actually support

Output format: Return the 4 sections as Markdown headings with the content below each, followed by the flagged-gaps line.

Before finishing, check every claim traces back to the research notes and that Goals and Frustrations each have exactly 3 bullets.

You are a market analyst who is careful to separate evidence from assumption.

Objective: Write a research brief on {{MARKET OR QUESTION — e.g. demand for X among Y}}.

Context: What's already known or supplied: {{EXISTING DATA OR CONTEXT}}. What you're trying to decide based on this: {{THE ACTUAL DECISION THIS INFORMS}}.

Constraints:
- Clearly mark any claim you're not certain about as an assumption, not a fact
- Do not cite specific statistics unless they were supplied in the context — describe general patterns instead
- Include at least one factor that could invalidate the brief's conclusion
- Keep the brief to 400–600 words

Output format: Return sections for Summary, What We Know, Assumptions, Risks to This Analysis, and Recommendation.

Before finishing, check that every statistic mentioned was actually supplied in the context, and that assumptions are labelled as such, not stated as fact.

You are a product marketing manager building a launch plan for {{PRODUCT OR FEATURE}}.

Objective: Build a launch plan covering the {{TIMEFRAME — e.g. 4 weeks before launch day to 2 weeks after}} around launch day, {{LAUNCH DATE}}.

Context: The team available is {{TEAM — e.g. one marketer, one designer, part-time support from engineering}}. The primary channel for this launch is {{PRIMARY CHANNEL — e.g. email list of 12,000 subscribers}}.

Constraints:
- Exactly 3 phases: Pre-launch, Launch day, Post-launch
- Each phase: 3–5 actions, each stated as a single task with a relative timing (e.g. "3 days before launch")
- Every action must be realistic for the stated team size — do not assign more than 2 parallel workstreams to a one-person team
- No action may fall after the end of the stated timeframe

Output format: Return the 3 phases as Markdown headings, each with its actions as a bulleted list, timing stated at the start of each bullet.

Before finishing, check each phase has 3–5 actions, no action falls outside the stated timeframe, and no phase overloads the team size given.

You are writing as {{BRAND OR PERSON'S}} social media voice, not as a generic corporate account.

Objective: Write a post for {{PLATFORM — e.g. LinkedIn, X, Instagram}} announcing or discussing {{TOPIC}}.

Context: The audience follows this account for {{WHY THEY FOLLOW — e.g. practical advice, behind-the-scenes updates}}. The tone is usually {{TONE — e.g. direct and a little informal}}.

Constraints:
- Match {{PLATFORM}}'s typical length and formatting conventions
- No more than one exclamation mark in the entire post
- Do not use generic openers like "Exciting news!" or "We're thrilled to announce"
- Include one specific, concrete detail rather than a vague claim

Output format: Return the post text only, plus up to 3 relevant hashtags on a separate line if the platform commonly uses them.

Before finishing, check the post against the constraints above, especially the banned generic openers.

You are a positioning strategist writing a value proposition for {{PRODUCT OR SERVICE}}.

Objective: Write one value proposition statement plus supporting proof points aimed at {{TARGET CUSTOMER}}.

Context: The main alternative customers currently use is {{ALTERNATIVE — e.g. doing it manually in spreadsheets, a competitor product}}. The real, defensible difference is {{DIFFERENTIATOR — e.g. it syncs automatically, no manual export needed}}.

Constraints:
- Value proposition statement: one sentence, under 30 words, names the customer and the outcome, not just the feature
- Exactly 3 supporting proof points, each one sentence, each tied directly to the stated differentiator
- Do not use the words "innovative", "revolutionary", "seamless" or "cutting-edge"
- Do not claim a ranking, award or statistic that wasn't supplied

Output format: Return the statement as a single bolded line, followed by the 3 proof points as a bulleted list.

Before finishing, check the statement is one sentence under 30 words, there are exactly 3 proof points, and none of the banned words appear.

You are a direct-response copywriter who is paid on results, not on how clever the copy sounds.

Objective: Write {{NUMBER — e.g. 3}} ad variations for {{PRODUCT}} targeting {{AUDIENCE}} on {{PLATFORM — e.g. Google Search, Instagram, LinkedIn}}.

Context: The core offer or benefit is {{THE SPECIFIC OFFER OR BENEFIT}}. The proof point (a number, result or guarantee) is {{PROOF POINT}}.

Constraints:
- Every variation must reference the specific proof point, not a generic claim
- Avoid superlatives that aren't backed by the proof point ("best," "revolutionary")
- Match {{PLATFORM}}'s typical character limits for headline and body
- Include one clear call to action per variation

Example proof point: "rated 4.8 out of 5 by over 2,000 customers" — specific enough to build a headline around.

Output format: Return each variation numbered, with headline and body labelled separately.

Before finishing, check that removing the product name from each variation would still make it obviously about this specific offer, not any competitor's.

You are an email marketer writing a promotional campaign for {{BRAND OR PRODUCT}}.

Objective: Write one promotional email announcing {{OFFER OR ANNOUNCEMENT}} to subscribers.

Context: The audience is {{AUDIENCE — e.g. existing customers who bought once, six months ago}}. The single most important benefit to lead with is {{KEY BENEFIT}}. The call to action is {{CALL TO ACTION — e.g. Shop the sale, Book a demo}}.

Constraints:
- Subject line: under 50 characters, no more than one exclamation mark
- Body: 100–180 words, plain paragraphs, no more than 3 short paragraphs
- Exactly one call-to-action, stated once in the body and once as a closing line
- Do not claim a discount percentage, deadline or stock level unless it is given above

Output format: Return "Subject:" on its own line, then a blank line, then the email body.

Before finishing, check the body is within 100–180 words, contains exactly one call to action, and states no unsupplied numbers or deadlines.

You are a conversion copywriter writing landing page copy for {{PRODUCT OR SERVICE}}.

Objective: Write the hero section and three supporting sections for a landing page whose single goal is {{PRIMARY GOAL — e.g. get a free trial signup}}.

Context: The visitor arrives from {{TRAFFIC SOURCE — e.g. a paid search ad for "team scheduling software"}}, so they already know roughly what the product does. The strongest proof point available is {{PROOF POINT — e.g. used by 40 independent coffee shops}}.

Constraints:
- Headline: under 12 words, states the outcome, not the feature
- Subheadline: under 25 words
- Exactly 3 supporting sections, each with a heading under 8 words and 1–2 sentences of body copy
- One call-to-action button label, repeated identically at the top and bottom
- Do not state a customer count, rating or statistic other than the proof point supplied

Output format: Return Markdown with a "# Headline", a subheadline line, the CTA button label on its own line, then three "##" supporting sections, then the CTA button label again on its own line.

Before finishing, check there are exactly 3 supporting sections, the CTA label is identical in both places it appears, and no statistic beyond the supplied proof point is used.

You are an SEO strategist grouping keywords for content planning.

Objective: Analyse the keyword list below and organise it into clusters by shared search intent, suitable for one page per cluster.

Context: The site covers {{SITE TOPIC — e.g. a project management tool for small agencies}}. Example: a cluster labelled "buying-stage decision" would group transactional keywords like "software pricing" together, separate from an informational cluster like "how to manage projects". Keywords:
{{PASTE KEYWORD LIST HERE, ONE PER LINE}}

Constraints:
- Use only the keywords supplied — do not add keywords you think should exist
- Do not state or estimate search volume, difficulty or ranking potential; none of that data was supplied
- Each cluster needs a short label and the intent type (informational, commercial, navigational or transactional)
- Flag any keyword that doesn't clearly fit an intent as "unclear" rather than forcing it into a cluster

Output format: Return each cluster as a Markdown heading with its intent type, followed by its keywords as a bulleted list, then a final "Unclear" section for anything that didn't fit.

Before finishing, check every supplied keyword appears exactly once across the clusters and the unclear section combined, and that no search volume or ranking figures were stated.

You are an SEO editor rewriting an existing page to better match search intent.

Objective: Rewrite the opening section of the page below so it matches what a searcher looking for {{TARGET KEYWORD}} actually wants to find first.

Context: The likely search intent is {{INTENT — e.g. wants a direct answer before reading further}}. The current opening section is:
{{PASTE CURRENT OPENING SECTION HERE}}

Constraints:
- Use only facts present in the current opening section — do not add statistics, claims or examples not already there
- New opening: 80–120 words
- Answer or address the core intent within the first 2 sentences
- Do not change the page's stated facts, only their order and framing

Output format: Return the rewritten opening as a single block of prose, followed by a one-sentence note on what was reordered and why.

Before finishing, check the rewrite is 80–120 words, addresses the intent within the first 2 sentences, and introduces no fact not present in the original.

You are an SEO specialist suggesting internal links for a published page.

Objective: Suggest internal links from the page below to other pages on the site, using only the page list supplied.

Context: The page's topic is {{PAGE TOPIC}}. The page content is:
{{PASTE PAGE CONTENT OR SUMMARY HERE}}
Other pages on the site available to link to:
{{PASTE LIST OF SITE PAGES WITH URLS, ONE PER LINE}}

Constraints:
- Only suggest links to pages in the supplied list — do not invent a page or URL that wasn't given
- Maximum 5 suggestions, ranked by relevance
- For each: give the anchor text (using words that would naturally appear in the page content), the target URL, and a one-sentence reason it's relevant
- Do not suggest linking a page to itself

Output format: Return a numbered list of up to 5 suggestions, each with anchor text, target URL and reason on separate lines.

Before finishing, check every suggested URL appears in the supplied page list, there are no more than 5 suggestions, and no suggestion links the page to itself.

You are a technical SEO specialist suggesting structured data for a page.

Objective: Build a JSON-LD schema block for the page described below, using the schema type {{SCHEMA TYPE — e.g. Product, Article, FAQPage, Recipe}}.

Context: Page content and facts:
{{PASTE PAGE CONTENT OR KEY FACTS HERE}}
Example: if a price of £28 is stated above, populate the `offers.price` field; if no rating is stated, leave `aggregateRating` out entirely rather than guessing a number.

Constraints:
- Only populate schema fields supported by facts stated above — do not invent a price, rating, author name or date not given
- Leave unsupported fields out entirely rather than filling them with a placeholder
- Use only properties that are valid for the stated schema type per schema.org
- List, after the code block, which commonly used fields for this schema type were left out and why

Output format: Return the JSON-LD as a fenced code block, followed by a "Fields omitted" list.

Before finishing, check every field in the JSON-LD is traceable to a stated fact, and that the omitted-fields list accounts for the commonly expected fields not included.

You are an experienced content writer. Write a blog post about {{TOPIC}}.

Audience: {{AUDIENCE — e.g. small business owners in the UK}}
Goal: {{GOAL — e.g. help them decide whether X is worth it}}
Tone: clear, practical British English. No hype, no filler phrases.

Structure:
1. A hook that names the reader's actual problem in the first two sentences
2. 3–5 H2 sections, each answering one specific question
3. A short, honest conclusion with one clear next step

Constraints:
- 900–1,200 words
- Short paragraphs (max 3 sentences)
- Include one concrete example or mini case study per section
- If you are unsure of a fact, say so rather than inventing it

Before finishing, check the draft against every constraint above and confirm the word count.

You are an SEO writer producing an FAQ section for a page about {{TOPIC}}.

Objective: Write 5 frequently asked questions and answers suitable for adding to a page about {{TOPIC}}, using only the source facts supplied below.

Context: The page is aimed at {{AUDIENCE — e.g. first-time buyers researching before purchase}}. Source facts:
{{PASTE SOURCE FACTS OR PRODUCT DETAILS HERE}}

Constraints:
- Exactly 5 questions, phrased the way a searcher would actually type them
- Each answer: 2–3 sentences, under 60 words
- Every answer must be supported by the source facts supplied — do not add facts, prices or specifications not given
- If a commonly asked question can't be answered from the source facts, state that instead of guessing

Output format: Return each question as a Markdown "###" heading followed by its answer as a short paragraph.

Before finishing, check there are exactly 5 questions, each answer is under 60 words, and every claim in every answer traces back to the source facts supplied.

You are an SEO content strategist writing a brief for a freelance writer.

Objective: Write a content brief for a page targeting {{TARGET KEYWORD}}, to be handed directly to a writer.

Context: Search intent is {{INTENT — e.g. comparing options before buying, learning a concept}}. The page should be about {{TARGET WORD COUNT}} words. Any notes on competitor pages already ranking: {{COMPETITOR NOTES — e.g. top results are all listicles with pricing tables}}.

Constraints:
- Exactly one H1 suggestion and 4–6 H2 suggestions, each under 10 words
- State the target word count once, matching the figure supplied
- Include a 1-sentence brief for what each H2 section should cover
- Do not state a search volume, keyword difficulty or competitor domain authority; none of that data was supplied

Output format: Return Markdown with "Target keyword", "Search intent" and "Target word count" as single lines, then the H1, then the H2 list with its one-sentence briefs.

Before finishing, check there are 4–6 H2 suggestions, the stated word count matches what was supplied, and no invented SEO metrics appear.

You are a social media strategist planning a content calendar for {{BRAND OR ACCOUNT}}.

Objective: Build a 7-day content calendar for {{PLATFORM — e.g. Instagram, LinkedIn}} covering the week of {{WEEK START DATE}}.

Context: The posting cadence is {{POSTING FREQUENCY — e.g. one post per day, 3 posts per week}}. The themes to draw from are {{THEMES — e.g. product tips, behind-the-scenes, customer stories}}. Any fixed date to work around: {{FIXED EVENT OR NONE}}.

Constraints:
- Exactly 7 rows, one per day of the week starting on the stated date, in date order
- Only fill a day with a post idea if it matches the stated posting frequency — mark other days "No post scheduled"
- Each post idea: a specific one-sentence concept, not a generic label like "engagement post"
- Rotate through the stated themes; do not repeat the same theme on two consecutive scheduled days

Output format: Return a Markdown table with columns Date, Day, Theme, Post idea.

Before finishing, check there are exactly 7 rows in date order, the number of filled rows matches the stated posting frequency, and no theme repeats on consecutive scheduled days.

You are the community manager for {{BRAND OR ACCOUNT}}, replying to comments on a recent post.

Objective: Draft a reply to each comment listed below.

Context: The post was about {{POST TOPIC}}. The brand voice is {{TONE — e.g. warm and conversational, direct and a little informal}}. Facts available to answer questions: {{FACTS OR PRODUCT DETAILS — e.g. price, availability, shipping times}}.

Constraints:
- One reply per comment, matched to that specific comment's content — no reply may be reused word-for-word on a different comment
- Each reply: under 30 words
- If a comment asks a factual question not covered by the supplied facts, the reply must say the answer will be followed up rather than guessing
- Do not use "Thank you for reaching out!" or "We appreciate your feedback!" as an opener

Output format: Return each original comment followed by its reply, as a numbered list.

Before finishing, check every reply is under 30 words, no two replies are identical, and any unanswerable factual question gets a follow-up response rather than a guess.

You are a social media editor repurposing existing content, not writing new material from scratch.

Objective: Create {{NUMBER OF POSTS — e.g. 3}} social posts for {{PLATFORM — e.g. LinkedIn, X, Instagram}} from the blog post below.

Context: The blog post is:
{{PASTE BLOG POST TEXT OR SUMMARY HERE}}
Example: a post drawn from a section about avoiding soap would focus only on that point, not restate the whole article.

Constraints:
- Use only points, facts and examples present in the blog post — do not add a new statistic, example or claim
- Each post must focus on one distinct point from the post — no two posts repeat the same point
- Match {{PLATFORM}}'s typical length and formatting conventions
- Each post must work as a standalone piece, understandable without having read the original blog post

Output format: Return each post as a numbered entry, with a one-line note on which part of the blog post it's drawn from.

Before finishing, check the post count matches the number requested, no two posts repeat the same point, and every claim traces back to the supplied blog post.

You are a social media content writer scripting a carousel post for {{PLATFORM — e.g. Instagram, LinkedIn}}.

Objective: Write a slide-by-slide script for a carousel post about {{TOPIC}}.

Context: The audience is {{AUDIENCE}}. The one main point the carousel needs to land is {{KEY TAKEAWAY}}.

Constraints:
- Exactly 6 slides: 1 hook slide, 4 content slides, 1 closing slide with a call to action
- Each slide: under 20 words on-slide text, plus one optional one-sentence caption note for context
- Content slides must each cover a distinct point — no two slides repeat the same idea in different words
- The hook slide must not be a question ending in "?" — use a direct, specific statement instead

Output format: Return a numbered list, one entry per slide, with "Slide text:" and "Caption note:" as labelled lines.

Before finishing, check there are exactly 6 slides, no slide's on-slide text exceeds 20 words, and the hook slide is a statement, not a question.

You are a short-form video scriptwriter for {{PLATFORM — e.g. TikTok, Instagram Reels, YouTube Shorts}}.

Objective: Write a hook and script for a {{VIDEO LENGTH — e.g. 30-second}} video about {{TOPIC}}.

Context: The audience is {{AUDIENCE}}. The one thing viewers should do after watching is {{DESIRED ACTION — e.g. save the video, try the tip themselves}}.

Constraints:
- Hook: under 8 words, delivered in the first 2 seconds, must not be a question
- Script broken into timed beats that add up to no more than the stated video length
- Each beat: timestamp range, on-screen action, and spoken line
- End with a single on-screen text call to action matching the desired action, shown in the final 3 seconds

Output format: Return the hook on its own line, then the beats as a numbered list with "Time:", "On-screen:" and "Line:" labelled fields, then the closing CTA.

Before finishing, check the hook is under 8 words and not a question, the beats' timestamps don't exceed the stated video length, and the closing CTA appears in the final 3 seconds.

You are a copywriter writing a short social media bio.

Objective: Write a bio for {{PLATFORM — e.g. Instagram, X, LinkedIn}} for {{PERSON OR BRAND}}.

Context: What they actually do: {{WHAT THEY DO}}. What they want visitors to do next: {{DESIRED ACTION — e.g. visit the link, follow for weekly tips}}. Any fact worth including: {{OPTIONAL FACT — e.g. based in Leeds, 10 years in the trade, or none}}.

Constraints:
- Fit within {{PLATFORM}}'s bio character limit
- Do not use "passionate about", "thought leader", "guru" or "enthusiast"
- Include the desired next action, stated plainly, not as a vague "link in bio"
- Only include the optional fact if one was actually supplied — do not invent a location, credential or number

Output format: Return the bio as plain text, followed by its character count on a separate line.

Before finishing, check the character count fits the stated platform limit, none of the banned words appear, and no fact was included beyond what was supplied.

You are a social media copywriter writing caption options for one post.

Objective: Write 3 distinct caption variations for a {{PLATFORM — e.g. Instagram, LinkedIn, X}} post about {{POST TOPIC}}.

Context: The image or video shows {{VISUAL DESCRIPTION}}. The brand voice is {{TONE — e.g. warm and conversational, direct and confident}}.

Constraints:
- Exactly 3 captions, each using a genuinely different angle: one direct/informative, one question-led, one story-led
- Each caption: under 50 words, matching {{PLATFORM}}'s typical caption length
- No more than one exclamation mark per caption
- Do not repeat the same opening 3 words across the 3 captions

Output format: Return each caption as a numbered entry labelled with its angle (Direct, Question-led, Story-led).

Before finishing, check there are exactly 3 captions, each under 50 words, each uses a genuinely different angle, and no two captions share the same opening 3 words.

You are a senior engineer planning a refactor before writing any code.

Objective: Build a staged refactor plan for the code below, written in {{LANGUAGE}}, with the goal: {{REFACTOR GOAL — e.g. reduce duplication, improve testability, split a large function}}.

Context: Current test coverage: {{TEST COVERAGE — e.g. none, partial, full}}. Constraints on the refactor: {{CONSTRAINTS — e.g. can't change the public API, must ship incrementally}}.

Constraints:
- Split the plan into stages ordered from lowest to highest risk; each stage must be independently shippable
- For each stage, state what changes and what must NOT change (behaviour preservation)
- If test coverage is not "full", recommend which tests to add before the riskiest stage, not after
- Flag any stage that would require a change to the public API given the constraints

Output format: Return a numbered list of stages, each with "Changes", "Must not change", and where relevant "Tests to add first".

Before finishing, check that no stage depends on a later stage being completed first.

Code:
```
{{PASTE CODE HERE}}
```

You are a principal engineer reviewing a pull request for the developers who'll merge and maintain it.

Objective: Review the code below for correctness, security and maintainability.

Context: {{Language/framework, and what this code is supposed to do}}

Constraints:
- Separate findings into Critical, Important and Minor — do not mix severities
- For each finding, give the specific line or block, not a general comment
- Do not suggest a rewrite unless the current approach is actually wrong
- Only flag style issues if they violate the project's stated conventions

Example: a missing null check on user input is Critical; an inconsistent variable name is Minor.

Output format: Return findings as a Markdown list grouped by severity, then one sentence saying whether you'd approve, request changes, or need more context.

Before answering, verify each Critical finding would actually cause a bug or vulnerability, not just a stylistic preference.

Code:
```
{{PASTE CODE HERE}}
```

You are a senior Python developer. Debug the code below.

Follow this process strictly:
1. State what the code is trying to do (one sentence)
2. Identify the exact line(s) causing the problem and explain why
3. Explain the root cause, not just the symptom
4. Provide the corrected code in full
5. List anything else in the code that will cause problems later

Rules:
- Do not rewrite working parts unnecessarily
- Keep the original style and naming
- If the error message or expected behaviour is missing, ask before guessing

Before answering, verify your proposed fix actually resolves the stated error and does not introduce new ones.

Error message (if any): {{ERROR}}
Expected behaviour: {{WHAT SHOULD HAPPEN}}

Code:
```python
{{PASTE CODE HERE}}
```

You are a senior engineer helping a colleague understand code they didn't write before they modify it.

Objective: Explain what the code below does, written in {{LANGUAGE}}.

Context: Why I need to understand it: {{REASON — e.g. about to fix a bug, adding a feature, reviewing a PR}}.

Constraints:
- Start with a one-paragraph summary of what the code does overall, in plain language
- Then walk through it in logical sections (not line by line), explaining what each section does and why it likely exists
- Explicitly flag anything that looks risky, unusual, or likely to break if changed carelessly
- Do not guess at business intent you can't infer from the code — say "unclear from the code" instead

Output format: Return a "Summary" section, a "Walkthrough" section with subheadings, and a "Risks and unknowns" section.

Before finishing, check that every claim about what the code does is traceable to a specific line or block, not assumed.

Code:
```
{{PASTE CODE HERE}}
```

You are a senior engineer writing a commit message and PR description for review by teammates.

Objective: Write a commit message and PR description for the change below.

Context: What problem this change solves: {{WHAT PROBLEM THIS SOLVES}}. Anything reviewers should pay special attention to: {{REVIEWER FOCUS — e.g. edge case, performance, breaking change}}.

Constraints:
- Commit message subject line under 50 characters, imperative mood (e.g. "Fix", not "Fixed" or "Fixes")
- PR description must explain why the change was made, not just restate the diff
- List what was NOT changed if that's relevant context (e.g. "does not touch the API layer")
- Do not invent testing that wasn't described — if no testing is mentioned, say "testing not specified" instead

Output format: Return the commit message (subject + body), then a separate "PR description" section with "What changed", "Why", and "Reviewer notes".

Before finishing, check the subject line is under 50 characters and in imperative mood.

Diff or change summary:
{{PASTE DIFF OR CHANGE SUMMARY HERE}}

You are a technical writer producing reference documentation for other developers who'll use this code.

Objective: Write documentation for the function or module below, written in {{LANGUAGE}}.

Context: Where this documentation will be used: {{DOCUMENTATION TARGET — e.g. README, internal wiki, docstring}}.

Constraints:
- Document only behaviour visible in the code — do not invent parameters, return types or side effects not present
- Include: purpose, parameters (with types), return value, at least one documented edge case or error condition, and one usage example
- Flag any parameter or return path whose behaviour is ambiguous from the code as "needs confirmation"
- Match the output format to the documentation target (Markdown for README/wiki, docstring format for inline)

Output format: Return the documentation formatted for {{DOCUMENTATION TARGET}}, with a short usage example in a fenced code block.

Before finishing, check every documented parameter and return value against the code, and confirm no invented behaviour was added.

Code:
```
{{PASTE CODE HERE}}
```

You are a senior software engineer writing tests for the developers who'll maintain this code after you.

Objective: Write unit tests for the function below using {{TEST FRAMEWORK — e.g. Jest, pytest, JUnit}}.

Context: {{Paste any existing test file's style/conventions here, or say "no existing tests"}}

Constraints:
- Cover the happy path, at least two edge cases, and one invalid-input case
- Do not test implementation details — test observable behaviour only
- Use descriptive test names that state the expected behaviour, not the method name
- Do not mock anything that isn't an external dependency

Example: it("returns an empty array when given zero items", ...) — a name describing behaviour, not it("test1").

Output format: Return the test file in a single fenced code block, followed by a short bullet list explaining what each test group covers.

Before finishing, check that every test would actually fail if the corresponding bug were introduced.

Function:
```
{{PASTE FUNCTION HERE}}
```

You are a data analyst who documents a schema without inventing meaning the schema doesn't actually confirm.

Objective: Build a data dictionary for the table(s) below, for {{INTENDED READER — e.g. new analysts joining the team}}.

Context: {{TABLE SCHEMAS — paste the table name, columns, types and any sample values}}. Additional notes: {{ADDITIONAL NOTES — e.g. business rules or known quirks worth flagging}}.

Constraints:
- Produce exactly one row per column supplied; do not merge two columns into one row or add a row for a column that wasn't given
- For each column, state its name, data type, a plain-English description, and whether it can be blank or null
- If a column's purpose is genuinely unclear from its name, type and any sample values, write "Purpose unclear — confirm with data owner" rather than guessing
- Do not state a column's likely source system, update frequency or ownership unless that information was given in the additional notes

Example: a column named `cust_flag` with values 0 and 1 and no further context should be marked as unclear, not guessed to mean "is a returning customer".

Output format: Return a Markdown table with columns Column, Type, Description, Nullable, one row per supplied column, in the order the columns were given.

Before finishing, check the row count matches the number of columns supplied exactly, and that no description states something the schema and notes don't actually support.

You are a data analyst who plans data cleaning as a sequence of checkable steps before touching any analysis.

Objective: Produce a cleaning plan for the dataset described below, to prepare it for {{INTENDED ANALYSIS — e.g. a monthly revenue trend report}}.

Context: {{DATASET DESCRIPTION — e.g. a CSV export of orders with columns order_id, date, customer_email, region, amount}}. Known issues: {{KNOWN ISSUES — e.g. some dates are text, some emails are duplicated, a few amounts are negative}}.

Constraints:
- Produce exactly one numbered step per known issue listed above, in the order the issues were listed, plus exactly one final step for a post-clean validation check
- Each step must name the specific column affected and the exact action to take on it
- Do not propose deleting a row or column unless the known issue explicitly makes that row unusable; prefer a fix over a deletion where one exists
- Do not invent an issue that wasn't listed in the known issues above

Example: "convert the date column from text to a date type, using the format found in the source" is a specific step; "clean up the dates" is not.

Output format: Return a numbered list of steps, each one to two sentences, ending with the validation step described above.

Before finishing, check that the number of steps equals the number of known issues plus one, and that every step names a specific column.

You are a data analyst who designs pivot tables that answer one specific question, not a general-purpose summary of everything in the sheet.

Objective: Design a pivot table that answers: {{BUSINESS QUESTION — e.g. which region had the highest average order value each quarter?}}

Context: {{AVAILABLE COLUMNS — e.g. order_date, region, product_category, order_value, customer_id}}.

Constraints:
- Specify exactly one field (or one derived field, named explicitly) for Rows, exactly one for Columns, and exactly one for Values, plus its aggregation (sum, average, count)
- Only use columns named in the available columns above; if a needed field must be derived (e.g. quarter from a date), say so explicitly and describe how
- Do not propose more than one pivot table; if the question genuinely needs two views, say so as a limitation instead of adding a second table
- State one filter to apply, if the question implies one, or state explicitly that no filter is needed

Example: "average order value by region and quarter" needs Rows: region, Columns: quarter (derived from order_date), Values: average of order_value.

Output format: Return four labelled lines — Rows, Columns, Values, Filter — followed by one sentence stating what the finished pivot table would show.

Before finishing, check that every field referenced is either in the available columns or explicitly marked as derived, with the derivation explained.

You are a spreadsheet specialist who explains formulas clearly to someone who didn't write them.

Objective: Explain what the following formula does: {{PASTE THE FORMULA}}

Context: This formula is used in {{SHEET CONTEXT — e.g. a monthly finance report, referencing an Orders table}}. The reader's spreadsheet level: {{READER LEVEL — e.g. comfortable with basic formulas like SUM and IF, new to array formulas}}.

Constraints:
- Break the formula down function by function, in the order they execute (innermost first), not just paraphrasing the whole thing in one go
- Use plain language pitched at the stated reader level; do not assume knowledge of a function not already implied by the reader level
- Do not guess at what a referenced range or named range contains beyond what's stated in the context; say so explicitly if it's unclear
- Identify exactly one edge case (e.g. a blank cell, a text value where a number is expected, a zero) most likely to make this formula error or return a wrong result

Example: for a nested IF inside a SUM, explain the innermost IF first, then how SUM aggregates its results.

Output format: Return a numbered breakdown of each function used, followed by a separate "Watch out for" section naming the one edge case.

Before finishing, check that the breakdown order matches execution order (innermost first) and that exactly one edge case has been identified, not several.

You are a data visualisation specialist who recommends exactly one chart for a specific question, not a general tour of chart types.

Objective: Recommend the best chart type to answer: {{QUESTION THE CHART SHOULD ANSWER — e.g. how has monthly revenue changed across three product lines over the last year?}}

Context: Data available: {{DATA DESCRIPTION — e.g. monthly revenue totals for three product lines over 12 months}}. Audience: {{AUDIENCE — e.g. a non-technical leadership team in a five-minute update}}.

Constraints:
- Recommend exactly one chart type, not a shortlist of options
- State the exact axis or encoding mapping (what goes on the x-axis, y-axis, and how categories are distinguished, e.g. colour or separate lines)
- Name exactly one commonly suggested alternative chart type for this kind of data, and state one concrete reason it's worse for this specific question
- Do not recommend a 3D chart, a dual-axis chart, or a pie chart with more than 5 categories under any circumstances

Example: for a trend across categories over time, a multi-line chart is usually right; a stacked bar chart is a common alternative that's worse here because it obscures each line's individual trend.

Output format: Return four labelled lines — Recommended chart, Axis mapping, Rejected alternative, Why it's worse — in that order.

Before finishing, check the recommendation doesn't fall into a banned chart type and that the rejected alternative is genuinely a common choice for this kind of data, not a straw man.

You are a data analyst who turns stakeholder questions into SQL, flagging ambiguity instead of silently guessing at it.

Objective: Write a {{DIALECT — e.g. PostgreSQL, BigQuery, Snowflake}} query that answers: {{BUSINESS QUESTION — e.g. which product categories had declining sales quarter over quarter this year?}}

Context: {{TABLE SCHEMAS — paste the relevant tables, columns and types}}.

Constraints:
- Use only the tables and columns given in the schema above; never invent a table or column name that wasn't supplied
- If the business question is ambiguous (e.g. "declining" could mean several different comparisons), resolve it with exactly one stated assumption, not several competing interpretations
- Use explicit column names, never SELECT *, and add a one-line comment above any non-obvious join, window function or subquery
- Handle NULLs explicitly wherever the result could otherwise silently exclude or miscount rows

Example: "top customers" is ambiguous between "most orders" and "most revenue"; state which one you're answering and why.

Output format: Return the query in a single fenced SQL code block, followed by exactly one sentence stating the assumption made (or "No ambiguity to resolve" if none was needed).

Before answering, check every referenced column exists in the given schema and that only one assumption has been stated, not a list of possibilities.

You are a spreadsheet specialist who writes formulas that work first time, referencing only the columns you're given.

Objective: Write a {{SPREADSHEET APPLICATION — e.g. Excel, Google Sheets}} formula that {{DESCRIBE THE CALCULATION}}.

Context: {{COLUMN LAYOUT — e.g. column A has order date, column B has region, column C has revenue}}.

Constraints:
- Reference only the columns named in the context above; do not invent a column that wasn't given
- Return exactly one formula, not several alternative versions
- Handle blank or zero values explicitly if the result could otherwise divide by zero or return an error
- Use functions compatible with the named application only; do not mix Excel-only and Sheets-only functions

Example: "the average revenue per region, ignoring blank rows" is specific enough to write directly; "some kind of summary of sales" is not.

Output format: Return the formula in a single fenced code block, followed by exactly one sentence explaining what it does in plain English.

Before answering, check the formula only references columns named in the context and would not error on a blank input cell.

You are a business advisor helping a founder structure a business plan.

Objective: Build a business plan outline for {{BUSINESS IDEA}}.

Context: Target customer: {{TARGET CUSTOMER}}. What makes it different: {{DIFFERENTIATOR}}. Stage: {{STAGE — e.g. pre-launch, first year of trading}}.

Constraints:
- Use exactly six sections, headed exactly "Summary", "Problem", "Solution", "Market", "Operations" and "Finances"
- Write one paragraph of 25–45 words under each heading — no bullet points, no empty headings
- Base every paragraph only on the details given above — do not invent revenue figures, competitor names or customer numbers
- Keep the whole outline under 280 words

Output format: Return the six headings in order, each followed by its one paragraph.

Before finishing, check there are exactly six sections with those exact headings, each paragraph is between 25 and 45 words, and no invented figures or names appear.

You are a small-business owner planning the coming work week.

Objective: Turn the task list below into a five-day weekly plan for {{BUSINESS NAME}}.

Context: The single most important goal this week is {{TOP GOAL}}. Any fixed commitment (meetings, deliveries, deadlines): {{FIXED COMMITMENTS — or none}}.

Constraints:
- Plan exactly five days, Monday to Friday, each with exactly one top task
- Every task from the list below must appear on exactly one day — do not drop any, do not invent new ones
- If a day has a fixed commitment, name it before the top task
- Keep each day's entry to one line under 25 words

Output format: Return each day as "Day: entry", one per line.

Before finishing, check all five weekdays appear once each, every listed task is placed on exactly one day, and no task from the list has been dropped or invented.

Task list:
{{TASK LIST}}

You are a small-business owner drafting an internal policy for staff.

Objective: Draft a policy document on {{POLICY TOPIC — e.g. remote work, expenses, annual leave}}.

Context: The business is {{BUSINESS TYPE AND SIZE}}. The key rule to set is {{KEY RULE}}. Any exception to note: {{EXCEPTION — or none}}.

Constraints:
- Use exactly four labelled parts: "Purpose", "Who this applies to", "The policy" and "Exceptions"
- Keep the whole document between 130 and 200 words
- State the key rule as a plain, specific sentence, not a vague guideline
- Do not state or imply this document has been checked by a solicitor or complies with specific legislation — flag instead that legal review is recommended

Output format: Return the four labelled parts in order, each as a short paragraph.

Before finishing, check there are exactly four labelled parts, the total is between 130 and 200 words, and no claim of legal compliance or solicitor review appears.

You are a small-business owner writing a proposal for a prospective client.

Objective: Write a proposal for {{PROJECT OR SERVICE}} for {{CLIENT NAME}}.

Context: The outcome the client cares about most is {{KEY OUTCOME}}. The budget or fee is {{PRICE OR BUDGET}}. The timeline is {{TIMELINE}}.

Constraints:
- Use exactly four sections, headed exactly "Overview", "Approach", "Timeline" and "Investment"
- Keep the whole proposal between 150 and 220 words
- End with exactly one call-to-action sentence, and do not repeat it elsewhere
- Do not invent client details, deadlines or figures beyond what is given above

Output format: Return the four headed sections in order, followed by the single call-to-action sentence on its own line.

Before finishing, check there are exactly four sections with those exact headings, the total word count is between 150 and 220, and only one call-to-action sentence appears.

You are a business analyst who has to defend this case to a sceptical finance team.

Objective: Write a one-page business case for {{THE PROPOSAL — e.g. adopting a new tool, hiring a role, changing a process}}.

Context: The problem this solves is {{THE ACTUAL PROBLEM}}. The rough cost or investment required is {{COST OR EFFORT}}.

Constraints:
- State the cost of doing nothing, not just the benefit of acting
- Every benefit claimed needs a rough number attached, even if it's an estimate labelled as such
- Include at least one real risk or downside — a business case with no risks is not credible
- Maximum one page (roughly 400 words)

Output format: Return sections for Problem, Proposed Solution, Cost, Expected Benefit, Risk, and Recommendation, each 2–4 sentences.

Before finishing, check that every benefit has a number or an explicitly labelled estimate attached, and that a real risk is stated.

You are a small-business owner negotiating terms with a supplier.

Objective: Write an email to {{SUPPLIER NAME}} asking for {{WHAT YOU WANT — e.g. a lower unit price, longer payment terms}}.

Context: Current terms: {{CURRENT TERMS}}. Reason for the ask: {{REASON}}. What you can offer in return, if anything: {{WHAT YOU CAN OFFER — e.g. a larger order, longer contract, or none}}.

Constraints:
- Make exactly one specific ask, stated once, not a list of several requests
- Keep the email between 90 and 150 words
- Only mention an offer in return if one was actually given above — do not invent order volumes or contract lengths
- Tone must be firm but collaborative, not apologetic and not confrontational

Output format: Return "Subject:" on its own line, then a blank line, then the email body.

Before finishing, check exactly one ask appears, the body is between 90 and 150 words, and no invented offer or figure appears.

You are a small-business owner writing a payment reminder to a client.

Objective: Write a reminder email about an overdue invoice to {{CLIENT NAME}}.

Context: Invoice number: {{INVOICE NUMBER}}. Amount: {{AMOUNT}}. Original due date: {{DUE DATE}}. Days overdue: {{DAYS OVERDUE}}.

Constraints:
- In the email body, state the invoice number, amount and due date exactly once each, in the first paragraph only (the subject line may also name the invoice number)
- Keep the whole email between 60 and 120 words
- Use a polite, matter-of-fact tone — no threats, no exclamation marks, no late fee unless one was given above
- End with one clear, single-sentence request for payment or contact

Output format: Return "Subject:" on its own line, then a blank line, then the email body.

Before finishing, check the invoice number, amount and due date each appear exactly once in the body, the body is between 60 and 120 words, and exactly one closing request appears.

You are a small-business owner writing the copy for your website's pricing page.

Objective: Write pricing page copy for {{BUSINESS OR PRODUCT}} presenting {{NUMBER OF TIERS — e.g. three}} pricing tiers.

Context: The tiers and what each includes: {{TIERS AND WHAT'S INCLUDED}}. The audience is {{AUDIENCE — e.g. first-time buyers comparing options}}.

Constraints:
- Present exactly three tiers, each with a name, price and one benefit-led headline sentence under 20 words
- Under each tier, list exactly three included features as short bullet points
- Do not invent a discount, "most popular" label or feature that wasn't given above
- Keep the whole page under 200 words

Output format: Return each tier as a heading with its price, the headline sentence, then exactly three bullet points, in ascending price order.

Before finishing, check there are exactly three tiers, each with exactly three bullet points, and no invented discount or feature appears.

You are a sales rep preparing responses to a common objection.

Objective: Draft responses to this objection about {{PRODUCT OR SERVICE}}: {{OBJECTION — quote it directly}}.

Context: What's actually true about this concern: {{TRUTH ABOUT THE CONCERN}}. Anything the product genuinely cannot do here: {{LIMITATION — or none}}.

Constraints:
- Provide exactly three different response options, each taking a distinct angle (e.g. reframe, evidence, question back)
- Keep each response under 60 words
- Acknowledge the objection as valid before responding to it — do not dismiss or minimise the concern
- Do not claim the limitation doesn't exist if one was given above

Output format: Return each response as "Option [number]: [angle name]" followed by the response text.

Before finishing, check there are exactly three response options, each under 60 words, and none dismiss the objection outright or hide a stated limitation.

You are helping draft a professional reply to a difficult email.

Objective: Write a reply that addresses {{THE PERSON'S}} concern about {{WHAT THEY'RE UNHAPPY ABOUT}} while staying calm and factual.

Context: Your relationship to this person is {{RELATIONSHIP — e.g. client, colleague, manager}}. What you can actually offer or commit to: {{WHAT YOU CAN OFFER}}.

Constraints:
- Acknowledge their concern in the first two sentences, specifically, not generically
- Do not apologise for things that were not actually your fault
- Do not promise anything beyond what was stated you can offer
- Keep it under 150 words

Output format: Return the email with a subject line, ready to send.

Before finishing, check that nothing in the reply commits to something beyond what was stated as available.

Their email:
{{PASTE THEIR EMAIL HERE}}

You are a customer support agent replying to a complaint or refund request.

Objective: Reply to this complaint about {{PRODUCT OR ORDER}}: {{COMPLAINT — quote or summarise it}}.

Context: The decision on this request: {{DECISION — e.g. full refund approved, partial refund, refund declined and why}}. Company policy relevant here, if any: {{RELEVANT POLICY — or none}}.

Constraints:
- Acknowledge the specific issue described, not a generic "sorry for the inconvenience"
- Say the word "sorry" or "apologise" exactly once
- State the decision plainly in one sentence, with no hedging, whatever it is
- Keep the whole reply between 70 and 130 words

Output format: Return the reply as plain text, ready to send.

Before finishing, check "sorry" or "apologise" appears exactly once, the decision is stated in one plain sentence, and the reply is between 70 and 130 words.

You are a sales or support rep summarising a call for the CRM record.

Objective: Summarise the call below with {{CONTACT NAME}} at {{COMPANY OR ACCOUNT}}.

Context: Purpose of the call: {{PURPOSE OF CALL}}.

Constraints:
- Use exactly three sections, headed exactly "Summary", "Key points" and "Next steps"
- "Summary" is one sentence; "Key points" is exactly three bullet points; "Next steps" is exactly two bullet points, each naming an owner
- Base every point only on the call notes below — do not infer a commitment or figure that wasn't stated
- Keep the whole summary under 130 words

Output format: Return the three headed sections in order.

Before finishing, check there are exactly three sections with those exact headings, exactly three key points and exactly two next steps each with a named owner, and nothing is inferred beyond the notes.

Call notes:
{{CALL NOTES}}

You are a sales rep writing a first-touch cold outreach email.

Objective: Write a cold email to {{PROSPECT NAME AND ROLE}} at {{COMPANY}} introducing {{YOUR PRODUCT OR SERVICE}}.

Context: A specific, relevant fact about the prospect or their company: {{RELEVANT FACT}}. The problem your product solves for them: {{PROBLEM SOLVED}}.

Constraints:
- Open with the relevant fact given above, not a generic greeting
- Keep the whole email between 60 and 100 words
- Make exactly one, low-effort ask (e.g. a reply, not a 30-minute call) stated once
- Do not claim a specific result, statistic or client name that wasn't given above

Output format: Return "Subject:" on its own line, then a blank line, then the email body.

Before finishing, check the email opens with the given fact, is between 60 and 100 words, and contains exactly one ask.

You are a sales rep writing a follow-up sequence after a prospect went quiet.

Objective: Write a follow-up sequence to {{PROSPECT NAME}} after {{LAST CONTACT — e.g. a demo, a first cold email, no reply in two weeks}}.

Context: What was offered or discussed: {{WHAT WAS DISCUSSED}}. Anything new worth mentioning since then: {{NEW INFORMATION — or none}}.

Constraints:
- Write exactly three emails, spaced 3 days, 7 days and 14 days after the last contact
- Each email must take a different angle (e.g. add value, ask a direct question, polite close-out) and not repeat the previous email's wording
- Keep each email between 30 and 70 words
- The third email must offer to close the loop if there's no response, without sounding curt

Output format: Return each email as "Email [number] — Day [X]:" followed by "Subject:" and the body.

Before finishing, check there are exactly three emails at the stated intervals, each is between 30 and 70 words, each takes a distinct angle, and the third offers a polite close-out.

You are a support team lead writing a knowledge-base article for customers.

Objective: Write a knowledge-base article explaining how to {{TASK OR FIX — e.g. reset a password, resolve a sync error}}.

Context: Who runs into this: {{WHO RUNS INTO THIS}}. The steps that actually resolve it: {{STEPS THAT RESOLVE IT}}.

Constraints:
- Open with one sentence stating what the article covers and who it's for
- Present the fix as exactly three numbered steps, each one short imperative sentence
- Close with exactly one sentence on what to do if the steps don't resolve it
- Keep the whole article between 70 and 130 words

Output format: Return the opening sentence, then "Steps:" with the three numbered steps, then the closing sentence.

Before finishing, check there are exactly three numbered steps, exactly one closing "if this doesn't work" sentence, and the total is between 70 and 130 words.

You are a customer support lead writing a reusable reply macro for a common issue.

Objective: Write a support macro for agents to use when {{SITUATION — e.g. a customer reports a late delivery}}.

Context: What actually caused this, if known: {{CAUSE — or unknown}}. What the business will do about it: {{RESOLUTION OFFERED}}.

Constraints:
- Keep the macro between 50 and 90 words
- Include exactly one placeholder, written as [CUSTOMER NAME], for the agent to personalise — no other placeholders
- State the resolution plainly in one sentence; do not promise a timeframe or compensation beyond what was given above
- Tone must be warm and direct, not corporate or overly formal

Output format: Return the macro as plain text, ready to paste into a support tool.

Before finishing, check the macro is between 50 and 90 words, contains exactly one placeholder, [CUSTOMER NAME], and promises nothing beyond the resolution given above.

You are a fiction editor helping a writer develop a character.

Objective: Build a character profile for {{CHARACTER NAME}} in {{STORY OR PROJECT}}.

Context: Their role in the story: {{ROLE IN STORY}}. One fact already decided about them: {{KNOWN FACT}}.

Constraints:
- Use exactly four labelled parts: "Want", "Flaw", "Contradiction" and "Telling detail"
- Each part is one to two sentences, under 40 words
- "Flaw" must be a specific behaviour that causes real problems, not a vague trait like "stubborn" alone
- "Contradiction" must show the character wanting two things that can't both be true at once

Output format: Return the four labelled parts in order.

Before finishing, check there are exactly four labelled parts, each under 40 words, the flaw is a specific behaviour rather than a vague trait, and the contradiction shows two genuinely conflicting wants.

You are a fiction editor helping a writer structure a short story.

Objective: Build a five-beat outline for a short story about {{STORY PREMISE}}.

Context: Main character: {{MAIN CHARACTER}}. What they want: {{WHAT THEY WANT}}. What's in their way: {{OBSTACLE}}.

Constraints:
- Use exactly five beats, headed exactly "Setup", "Inciting incident", "Rising complication", "Turning point" and "Resolution"
- Each beat is exactly one sentence, under 35 words
- Keep stakes concrete and specific to the premise given — no vague phrases like "everything changes" or "nothing would be the same"
- Do not introduce a new named character not mentioned above

Output format: Return the five headed beats in order, each with its one sentence.

Before finishing, check there are exactly five beats with those exact headings, each is one sentence under 35 words, and no vague stakes phrases or new named characters appear.

You are a line editor improving a passage for clarity without changing its meaning.

Objective: Edit the passage below for clarity.

Context: Intended audience: {{AUDIENCE}}. Anything about the writer's voice to preserve: {{VOICE TO PRESERVE — e.g. informal, first person, dry humour}}.

Constraints:
- Do not change facts, opinions or the overall argument — only clarity, structure and wordiness
- Cut filler words and redundant phrases, but do not shorten the passage by more than 20%
- Preserve the voice described above; do not flatten it into generic neutral prose
- List exactly three specific changes made, with a one-line reason for each

Output format: Return the edited passage first, then "Changes made:" followed by exactly three numbered points.

Before finishing, check the edited passage keeps the original meaning, is no more than 20% shorter than the original, and exactly three changes are listed with reasons.

Passage:
{{PASSAGE TO EDIT}}

You are a copywriter adapting existing text into a specific brand voice.

Objective: Rewrite the passage below in {{BRAND NAME}}'s voice.

Context: The three voice traits that define this brand: {{VOICE TRAIT 1}}, {{VOICE TRAIT 2}}, {{VOICE TRAIT 3}}. A phrase or word this brand never uses: {{BANNED WORD OR PHRASE — or none}}.

Constraints:
- Do not change any fact, number or claim in the original passage — only tone and phrasing
- Apply all three named voice traits; after the rewrite, name which sentence demonstrates each one
- Do not use the banned word or phrase if one was given above
- Keep the rewrite within 20% of the original passage's word count, either direction

Output format: Return the rewritten passage first, then "Trait check:" with exactly three lines, one per trait, naming the sentence that demonstrates it.

Before finishing, check no fact or number has changed, all three voice traits are demonstrated and named, the banned phrase doesn't appear, and the word count is within 20% of the original.

Passage:
{{PASSAGE TO REWRITE}}

You are an operations lead who turns meeting notes into things that actually get done.

Objective: Extract clear action items from the supplied meeting notes.

Context: This was a meeting about {{MEETING TOPIC}} with {{WHO ATTENDED — roles, not necessarily names}}.

Constraints:
- Every action item needs an owner and a deadline — if either is missing from the notes, write "not specified" rather than guessing one
- Do not invent decisions that weren't actually made in the notes
- Separate decisions made from actions still pending from open questions
- Keep each action item to one sentence

Output format: Return three sections — Decisions Made, Action Items (owner and deadline per item), and Open Questions — as Markdown lists.

Before finishing, check that every action item and decision traces back to something actually stated in the notes below.

Meeting notes:
{{PASTE MEETING NOTES HERE}}

You are a writer drafting an issue of a personal newsletter.

Objective: Write a newsletter issue for {{NEWSLETTER NAME}} covering {{TOPIC OR UPDATE}}.

Context: The regular tone of this newsletter: {{TONE — e.g. warm and conversational, dry and observational}}. One specific thing worth mentioning: {{SPECIFIC DETAIL}}.

Constraints:
- Use exactly three sections: a short opening hook, one main story or update, and one closing thought or recommendation
- Keep the whole issue between 120 and 200 words
- Include the specific detail given above naturally, not as a bolted-on final line
- End with exactly one sign-off line addressed to the reader directly

Output format: Return the three sections as plain paragraphs, followed by the sign-off line on its own.

Before finishing, check there are exactly three sections, the total is between 120 and 200 words, the specific detail appears naturally within a section, and exactly one sign-off line closes the issue.

You are a writer drafting headline options for a piece.

Objective: Write headline variations for a piece about {{TOPIC}}.

Context: The piece's main point: {{MAIN POINT}}. Where it will run: {{PUBLICATION OR PLATFORM}}.

Constraints:
- Write exactly five headlines, each under 100 characters
- Each headline must take a genuinely different angle (e.g. direct claim, question, number-led, curiosity gap, contrarian) — label the angle used
- Do not use a colon-plus-subtitle structure in more than one headline
- Do not state a statistic or fact not given above

Output format: Return each headline as "[Angle]: headline text", one per line, five lines total.

Before finishing, check there are exactly five headlines, each under 100 characters, each with a genuinely distinct angle, and no more than one uses a colon-plus-subtitle structure.