Content marketing runs on repeating jobs: deciding what to publish, turning your expertise into articles, proving results with customer stories, reusing good work and updating what has aged. This pack has 48 prompts organised around those jobs, for content marketers and editors.
The pack is built around your own material. The drafting prompts (article, how-to and byline) tell the AI to use only the notes, quotes and figures you paste, and to leave a visible placeholder where something is missing. The calendar, rebalance, data report and pre-publish risk check prompts ask the model to show its working so you can check it. Where a prompt could invite made-up statistics, quotes or customer results, it says not to, and where a platform or law matters, it tells you to check the current source.
You will find an editorial calendar that adds up against your real hours, an evidence-based idea list, a pre-publish risk check for approvals and claims, a myth-busting plan, a brand voice profile built from your samples, a disclosure note for AI-assisted work, a case study interview guide and sign-off tracker, a map for reusing one piece in several formats, a spec for interactive content, and audit and refresh prompts for older content. Four worked examples, written with fictional inputs, show the output. This pack does not cover keyword research or SEO briefs, social post copy or email sequences; those sit in the SEO, social media and email marketing packs.
Editorial Strategy
Decide what content is for, who it serves and what to make next. These prompts work from your goals, your evidence and your capacity rather than from generic advice.
Best for: Aligning content to one business goal
You are a content strategist who works with small marketing teams. Be practical and honest about trade-offs.
Business and what it sells: {{BUSINESS_SUMMARY}}
The business goal content must support this year: {{BUSINESS_GOAL}}
Who we want to reach: {{TARGET_READER}}
Team and time available for content each week: {{TEAM_CAPACITY}}
Write a one-page content strategy:
1. The job content does for the business, in two sentences, tied to the goal above.
2. Who the content is for and what they need to believe or know before they buy. Mark anything you are guessing as [ASSUMPTION].
3. Three to four content themes, each with why it fits the goal.
4. The formats we can realistically sustain given the capacity above, and what we should say no to.
5. Three risks (for example, too many formats, no subject-matter expert time) with one mitigation each.
6. Five questions the team must answer before the plan is final.
Do not cite audience sizes, benchmarks or competitor results; if a number would help, tell me what to look up and where.
Output format: the six numbered headings, under 450 words in total.
Fill in: BUSINESS_SUMMARY BUSINESS_GOAL TARGET_READER TEAM_CAPACITY
Use at the start of a quarter or when a new person joins the team. Be specific about capacity; a plan sized for a bigger team is useless.
Best for: Choosing pillars you can back up
You are an editorial strategist. Help me choose content pillars that I can defend with real expertise.
What we sell: {{OFFER}}
Who buys it: {{BUYER}}
What our team genuinely knows or has done that others in our field have not (be specific): {{TEAM_EXPERTISE}}
Topics we are asked about most: {{COMMON_TOPICS}}
Propose three to five content pillars. For each:
- A plain-language name and a one-sentence promise to the reader.
- The point of view we could take on it, written as a statement someone could disagree with. Base it only on the expertise I listed; if the expertise is thin, say so.
- Three example article ideas that need our own experience or data to write well.
- What we would need to gather first (interviews, internal data, screenshots).
- One topic that looks related but should sit outside the pillar, and why.
Finish by telling me which pillar is weakest on evidence and what to do about it.
Output format: one short section per pillar using the five labels above, then a closing paragraph of no more than 80 words.
Fill in: OFFER BUYER TEAM_EXPERTISE COMMON_TOPICS
Do the expertise field properly: it is what stops the pillars being generic.
Best for: Finding what is missing from your library
You are a content strategist auditing a library against a buyer journey. Use only the list I give you.
Our content inventory, one item per line, pasted below:
{{CONTENT_INVENTORY}}
Buyer journey stages we care about: {{JOURNEY_STAGES}}
The audience's top questions, if I know them: {{TOP_QUESTIONS}}
1. Sort each item into one stage and one topic. Where the title is unclear, label it [UNCLEAR] rather than guessing.
2. Show a grid of stage by topic with the count of items in each cell.
3. Name the three biggest gaps (empty or thin cells) and the three most crowded cells.
4. For each gap, recommend one piece to make, in one sentence, and say whether it should be new or an update of an existing item from the list.
5. List items that look redundant with each other, by title.
Do not comment on search traffic or rankings; I have not given you that data.
Output format: the grid as a table, then the three lists as short bullets.
Fill in: CONTENT_INVENTORY JOURNEY_STAGES TOP_QUESTIONS
Export your CMS titles into a plain list first. Add stage hints for any titles that are vague.
Best for: Agreeing what good content means here
You are an editor writing the guiding principles for a content programme.
Organisation: {{ORGANISATION}}
Audience: {{AUDIENCE}}
What readers should be able to do after reading our content: {{READER_OUTCOME}}
Things we refuse to do in our content (if any): {{OFF_LIMITS}}
How we feel about AI-assisted drafting: {{AI_POLICY_NOTES}}
Write:
1. An editorial mission statement of no more than 40 words.
2. Five content principles, each as a rule a writer could apply (for example, what counts as enough evidence for a claim), with a one-line "what this looks like in practice" example.
3. Two principles about honesty: how we source claims, and how we handle corrections.
4. A short statement on AI assistance consistent with my notes. Do not invent a policy I have not described; if my notes are vague, write [DECIDE] where I must choose.
5. Three questions to ask before publishing anything.
Output format: numbered sections, plain language, one page.
Fill in: ORGANISATION AUDIENCE READER_OUTCOME OFF_LIMITS AI_POLICY_NOTES
Share it with the team before it goes anywhere public. Fill in the AI notes honestly, even if they are 'undecided'.
Best for: Measures that lead to decisions
You are a content measurement advisor. I want measures that connect to decisions, not a list of every metric.
Business goal content supports: {{BUSINESS_GOAL}}
Content types we publish: {{CONTENT_TYPES}}
Analytics and tools we actually have access to: {{AVAILABLE_TOOLS}}
Who reads the report: {{REPORT_AUDIENCE}}
Create a metrics map:
1. For each content type, one primary measure and up to two supporting ones, each tied to a stage (reach, engagement, lead, revenue influence). Use only measures my tools can produce; mark others [NOT AVAILABLE].
2. For each primary measure, what decision a change would lead to.
3. Which measures are easy to misread (for example, page views without context), and how to qualify them in a report.
4. A suggestion for how to set targets from our own past results rather than from other companies. Do not give industry benchmark numbers.
5. A list of what we cannot measure well today and a cheap workaround.
Output format: a table (Content type | Primary measure | Supporting | Decision it informs), then bullets for items 3 to 5.
Fill in: BUSINESS_GOAL CONTENT_TYPES AVAILABLE_TOOLS REPORT_AUDIENCE
Be honest about tools. A metric nobody can pull is worse than none.
Best for: Idea lists you can defend
You are an editor generating article ideas that a team could defend in a planning meeting.
Content pillar: {{CONTENT_PILLAR}}
Reader: {{TARGET_READER}}
Evidence for what readers want (support questions, sales objections, comments you have collected): {{READER_EVIDENCE}}
What we can credibly add from our own work: {{OUR_EXPERTISE}}
Formats we can produce: {{AVAILABLE_FORMATS}}
1. Generate fifteen article ideas for the pillar. For each give a working title, the format, and which item of my evidence or expertise it rests on (quote a few words). Do not propose an idea that rests on neither.
2. Mark each as Beginner, Intermediate or Advanced for the reader.
3. Group the ideas into three clusters and propose one flagship piece per cluster.
4. Point out five ideas that sound good but that we cannot do well without further input (data, expert time, a customer), and say what is missing.
5. Suggest three ways to link the ideas together as a reader's path from first question to decision.
Do not claim any idea is trending or will perform; performance is for us to test.
Output format: a table for item 1 (Title | Format | Evidence it rests on | Level), then the other items as short lists.
Fill in: CONTENT_PILLAR TARGET_READER READER_EVIDENCE OUR_EXPERTISE AVAILABLE_FORMATS
Work from real evidence. Ideas with no evidence behind them are the first ones to cut.
Calendars and Workflow
Plan the weeks, themes and handoffs. You get calendars that add up against your hours, a workflow with named roles, a way to recover from a slip, and briefs that give writers a clear angle and approved sources.
Best for: A calendar that adds up
You are an editorial planner. Build a calendar that fits the hours available, and show your arithmetic.
Number of weeks to plan: {{NUMBER_OF_WEEKS}}
Content pillars or themes: {{CONTENT_THEMES}}
Formats and the hours each takes us (from experience): {{FORMAT_HOUR_ESTIMATES}}
Total content hours available per week: {{HOURS_PER_WEEK}}
Fixed dates we must publish around (launches, events, holidays we already know): {{FIXED_DATES}}
1. Compute the total hours available over the period (weeks x hours per week).
2. Choose a mix of pieces whose total hours do not exceed that figure. Show each piece's hours and the running total.
3. Lay the pieces out week by week as a table: Week | Working title | Theme | Format | Hours | Owner (write [ASSIGN]) | Status.
4. Leave at least one slot per four weeks marked "buffer" for slippage.
5. Mark any fixed date you could not accommodate and why.
Use only the dates I gave. Do not add observances, trends or events you cannot confirm; if you think one might matter, list it under "Check before adding".
Output format: the arithmetic first, then the table, then the "Check before adding" list.
Fill in: NUMBER_OF_WEEKS CONTENT_THEMES FORMAT_HOUR_ESTIMATES HOURS_PER_WEEK FIXED_DATES
Give honest hour estimates. If you plan to the ceiling you will slip in week two.
Example output · Claude (example written by The Prompt Index)
Sample inputs: NUMBER_OF_WEEKS: 4; CONTENT_THEMES: getting new customers set up; reporting for small teams; FORMAT_HOUR_ESTIMATES: long article 8 hours, short article 4 hours, customer case study 8 hours, checklist 3 hours; HOURS_PER_WEEK: 8; FIXED_DATES: product release on the Thursday of week 3, so no publishing that day.
**1. Hours available**
4 weeks x 8 hours = 32 hours.
**2. Chosen mix and running total**
- Long article: 8 hours (total 8)
- Short article: 4 hours (total 12)
- Checklist: 3 hours (total 15)
- Customer case study: 8 hours (total 23)
- Short article: 4 hours (total 27)
- Buffer: 4 hours (total 31)
31 hours planned out of 32, leaving 1 hour unallocated.
**3. Calendar**
| Week | Working title | Theme | Format | Hours | Owner | Status |
|---|---|---|---|---|---|---|
| 1 | A practical plan for a customer's first week | Getting new customers set up | Long article | 8 | [ASSIGN] | Not started |
| 2 | What to check before you start your first report | Reporting for small teams | Short article | 4 | [ASSIGN] | Not started |
| 2 | First-week set-up checklist | Getting new customers set up | Checklist | 3 | [ASSIGN] | Not started |
| 3 | Customer story: from set-up to a first report | Reporting for small teams | Customer case study | 8 | [ASSIGN] | Needs a real customer who agrees |
| 4 | A short guide to reading your first report | Reporting for small teams | Short article | 4 | [ASSIGN] | Not started |
| 4 | Buffer for slippage | n/a | Buffer | 4 | [ASSIGN] | Reserved |
Weekly hours: week 1 = 8, week 2 = 4 + 3 = 7, week 3 = 8, week 4 = 4 + 4 = 8.
**Check before adding**
- Fixed date: the release on the Thursday of week 3 is accommodated; publish the case study on another day that week. The buffer is the 4-hour slot in week 4.
- Nothing else: I added no observances or events beyond the date you gave.
Best for: Monthly themes with clear purpose
You are a content strategist planning themes, not individual posts.
Quarter and its business priorities: {{QUARTER_PRIORITIES}}
Product or company events in the quarter that content should support: {{KNOWN_EVENTS}}
Reader questions or topics we have evidence for: {{EVIDENCED_TOPICS}}
Team skills and subject-matter experts available: {{SME_AVAILABLE}}
Propose three monthly themes, one per month. For each give:
- The theme name and the reader problem it addresses.
- The business priority or event it supports.
- Two flagship pieces and four supporting pieces by working title and format, each tied to evidence I supplied or marked [ASSUMPTION].
- The subject-matter expert time needed, in hours, as an estimate to confirm.
- A sentence on how the theme builds on the previous month.
Then list two themes you considered and rejected, with reasons. Do not rely on trends I have not named.
Output format: one short block per month, then the rejected themes as two bullets.
Fill in: QUARTER_PRIORITIES KNOWN_EVENTS EVIDENCED_TOPICS SME_AVAILABLE
Works best when the evidence field contains real support tickets or search questions, not guesses.
Best for: A workflow people can follow
You are a managing editor designing a production workflow for a small team.
Content types we produce: {{CONTENT_TYPES}}
People and roles on the team (including freelancers and experts): {{TEAM_ROLES}}
Where our process breaks down today: {{CURRENT_PROBLEMS}}
Approvals we need before publishing (legal, product, client): {{APPROVALS_NEEDED}}
Design a workflow with:
1. The stages from idea to published to reviewed, with a clear "done" definition for each.
2. Who is responsible, who approves, and who is consulted at each stage (as a table, using only roles I listed; write [HIRE OR ASSIGN] for gaps).
3. A realistic turnaround for each stage, expressed as a range for me to confirm against our own history.
4. The three most likely bottlenecks given my problems, and a fix for each.
5. A one-line AI-use checkpoint where it matters: who checks AI-assisted drafts for facts and tone before they move on.
Keep it simple enough to fit on one page and to be used by someone new in their first week.
Output format: a stage table, a roles table, then the bottleneck list.
Fill in: CONTENT_TYPES TEAM_ROLES CURRENT_PROBLEMS APPROVALS_NEEDED
Describe real breakdowns, such as late expert reviews. Generic problems produce a generic process.
Best for: Resetting the plan with no drama
You are an editorial lead helping a team recover from a slipped schedule without burning everyone out.
Original calendar (pasted, with dates and status):
{{CURRENT_CALENDAR}}
What went wrong: {{WHAT_SLIPPED}}
Pieces with a hard external deadline: {{HARD_DEADLINES}}
Hours available per week from now: {{HOURS_PER_WEEK}}
1. Sort every item into: Keep as planned, Move (with a new proposed week), Shrink (a lighter format that still serves the purpose), Drop.
2. Protect the hard-deadline items first and say what that costs elsewhere.
3. Show the revised hours per week and confirm none exceeds the available hours. Show the arithmetic.
4. Write a short, honest note (under 100 words) I can send to stakeholders explaining the change without blame or spin.
5. Name one process change that would reduce the chance of the same slip.
Do not invent new deadlines or commitments; mark any date you propose as [PROPOSED].
Output format: a revised calendar table, the hours check, the stakeholder note, the process change.
Fill in: CURRENT_CALENDAR WHAT_SLIPPED HARD_DEADLINES HOURS_PER_WEEK
Paste the calendar as it stands today with honest statuses.
Best for: Briefs that cut revision rounds
You are a managing editor writing an assignment brief for a writer, freelance or in-house. The brief covers angle, sources, voice and logistics only.
Working title: {{WORKING_TITLE}}
Reader and what they need from this piece: {{READER_NEED}}
The point of view or argument the piece should take: {{ANGLE}}
Sources and experts the writer can use (links, names, documents): {{APPROVED_SOURCES}}
Final deadline: {{DEADLINE}}
People the writer should interview: {{INTERVIEW_LIST}}
Write an editorial brief of about one page, with no keyword, ranking or search-result content, in these parts:
1. The piece in two sentences: who it is for and what changes for them.
2. The angle, and one thing the piece must not become.
3. Suggested structure as five to seven headings, each with a note on what it should establish.
4. Sources: list only those I provided. State that every statistic or quote must come from a named source the writer can link, and that nothing may be invented or approximated from memory.
5. Voice reminders, and whether AI tools may be used and how to disclose that to the editor.
6. Interviews: who to speak to, what to ask each of them, and when quotes must be sent back for approval.
7. Deadlines: first draft, expert review, edit and final dates, using only the deadline I gave; mark any date you add [PROPOSED].
8. What "done" looks like: the editor's checklist of five items.
Output format: the eight numbered parts in a clean layout the writer can paste into an email.
Fill in: WORKING_TITLE READER_NEED ANGLE APPROVED_SOURCES DEADLINE INTERVIEW_LIST
Keep the source list short and real. In practice a few good sources beat a long vague list.
Move from expertise to a finished piece: outlines, drafts built from your notes, how-tos, myth-busting, data stories, honest headlines, a pre-publish risk check, a structural edit and a line edit.
Best for: Structure that follows your evidence
You are a senior editor turning raw material into an outline. Use only the material below; add no facts of your own.
Working title: {{WORKING_TITLE}}
The question the reader brings: {{READER_QUESTION}}
Raw notes, quotes and source excerpts (pasted):
{{RAW_NOTES}}
Target length in words: {{TARGET_WORDS}}
1. State the single main point of the piece in one sentence.
2. Propose an outline with headings. Under each, list which of my notes or excerpts support it, referring to them by a short quote or label, and an approximate word count; the counts should total close to the target. Show the sum.
3. Flag sections where I have no supporting material as [NEEDS EVIDENCE] and suggest what kind of evidence would fix it.
4. Flag notes that do not fit and suggest cutting or saving them.
5. Suggest where an example, a diagram or a pull quote would help.
Output format: a numbered outline with sub-bullets for support, then two short lists: gaps and leftovers.
Fill in: WORKING_TITLE READER_QUESTION RAW_NOTES TARGET_WORDS
The outline is only as good as your notes. Add source labels such as [S1] so the model can refer to them.
Best for: A first draft that stays inside your facts
You are a writer drafting for me in my voice. This is a first draft that I will edit and fact-check.
Outline: {{ARTICLE_OUTLINE}}
My notes, quotes and sources (pasted; this is the only factual material you may use):
{{SOURCE_NOTES}}
Voice description or a short sample of my writing: {{VOICE_SAMPLE}}
Reader: {{TARGET_READER}}
Write the draft section by section, following the outline.
- Use only facts, figures, quotes and examples found in my notes. Do not add statistics, studies, customer results, named examples or quotations from anywhere else.
- Where the outline needs something my notes do not contain, insert a bracketed placeholder such as [NEEDS EXAMPLE: customer story about onboarding] and carry on.
- Write quotes exactly as given and attribute them as I attributed them.
- Prefer short sentences and concrete verbs; avoid filler openers and stock phrases.
- Keep paragraphs to four sentences or fewer.
End with a list titled "To check before publishing" containing every placeholder and every number or claim in the draft, so I can verify each.
Output format: the draft with headings, then the "To check before publishing" list.
Fill in: ARTICLE_OUTLINE SOURCE_NOTES VOICE_SAMPLE TARGET_READER
If you will publish AI-assisted text, record it in your disclosure note (see the disclosure prompt in this pack).
Best for: Openings without clickbait
You are a feature editor. Write openings for the piece below that are accurate and specific, not teasing.
The piece's main point: {{MAIN_POINT}}
The reader: {{TARGET_READER}}
Details, examples or facts I can honestly use in an opening (only these): {{OPENING_MATERIAL}}
Tone I want: {{TONE}}
Write four introductions of 60 to 90 words each, using different approaches:
1. Starts from a specific situation the reader will recognise, built from my material.
2. Starts from the problem and why it matters now (without a made-up statistic).
3. Starts from a surprising or counter-intuitive point that is true according to my material.
4. Starts directly with the answer, then promises the detail.
After each, one line on what it does well and what it risks. Then say which you would choose and why.
Do not open with a question that has an obvious answer, a dictionary definition, or a sweeping claim about how fast the world is changing. Do not claim facts beyond my material.
Output format: four labelled openings with their one-line notes, then the recommendation.
Fill in: MAIN_POINT TARGET_READER OPENING_MATERIAL TONE
Give it real material to work with. Openings built on nothing sound like everyone else's.
Best for: Guides readers keep using
You are a content architect designing a comprehensive guide that people can use as a reference.
Guide topic: {{GUIDE_TOPIC}}
Reader's starting knowledge: {{READER_LEVEL}}
What we know first-hand about the topic (processes, mistakes, templates, data we own): {{FIRST_HAND_KNOWLEDGE}}
Existing content we can link to or fold in: {{EXISTING_CONTENT}}
Design the guide:
1. The reader's outcome in one sentence.
2. A table of contents with chapters and sub-sections, ordered so each builds on the last.
3. For each chapter: its purpose, the first-hand material it will use, what a reader will be able to do afterwards, and a suggested element (checklist, worked example, template, diagram).
4. Chapters where we lack first-hand knowledge, marked [SME NEEDED] or [RESEARCH NEEDED].
5. What to leave out so the guide stays focused, and where to link to other pieces instead.
6. A sensible update plan: which parts will go out of date and how often to review them (say what to check, not a fixed date).
Output format: the table of contents first, then a table with the columns in item 3.
Fill in: GUIDE_TOPIC READER_LEVEL FIRST_HAND_KNOWLEDGE EXISTING_CONTENT
A guide pays back over years, so spend the planning time. Plan from what you know first-hand.
Best for: How-to pieces that actually work
You are a technical-minded editor writing a how-to from a practitioner's real steps.
What the reader will accomplish: {{READER_GOAL}}
The steps I actually performed, in my own words (pasted, messy is fine):
{{MY_STEPS}}
Tools or versions involved: {{TOOLS_USED}}
Prerequisites: {{PREREQUISITES}}
Reader's skill level: {{READER_LEVEL}}
1. Turn my steps into a numbered how-to with one action per step, starting each with a verb.
2. Add a "Before you start" list built only from the prerequisites I gave. If a step seems to need something I did not mention, flag it as [CONFIRM].
3. Add "What you should see" notes only where my steps describe the result. Do not invent screens, buttons, menu names or outputs.
4. Add a short "If it goes wrong" section using only problems I mentioned; otherwise leave a [ADD COMMON PROBLEMS] marker.
5. Point out any step that skipped a stage so I can test the guide from scratch before publishing.
Write for the stated skill level and keep sentences short.
Output format: Before you start, Steps, What you should see, If it goes wrong, then the list of flagged gaps.
Fill in: READER_GOAL MY_STEPS TOOLS_USED PREREQUISITES READER_LEVEL
Follow your own guide once, cold, before publishing. Tools change; note the versions you used.
Best for: Original data without overclaiming
You are a data-literate editor. Turn the figures I provide into a readable narrative without overstating them.
Study or dataset description (how it was collected, sample size, dates): {{DATA_DESCRIPTION}}
The figures (pasted as a table):
{{DATA_TABLE}}
The question this report should answer: {{REPORT_QUESTION}}
Audience: {{AUDIENCE}}
1. Recompute any percentage, total or change you plan to cite from the raw figures and show the calculation. If my table contains an inconsistency, point it out instead of choosing silently.
2. Write the key findings in order of importance, each as one plain sentence plus the supporting figure.
3. Add a "What this does not show" paragraph covering sample size, how respondents were chosen, and any causal claim the data cannot support.
4. Suggest two charts, naming the exact columns to plot.
5. Draft a methodology box from the description only; mark missing details as [ADD METHOD DETAIL].
Use cautious wording ("in our sample", "respondents reported"). Do not generalise beyond the sample or add outside statistics.
Output format: calculations, findings, limitations, chart suggestions, methodology box.
Fill in: DATA_DESCRIPTION DATA_TABLE REPORT_QUESTION AUDIENCE
Only use data you own and can show. Have someone re-check each calculation before publication.
Best for: Honest, clear titles
You are a copy editor who rejects clickbait. Write titles that promise exactly what the piece delivers.
Draft or summary of the piece (paste the full text if possible):
{{PIECE_TEXT}}
The reader: {{TARGET_READER}}
Where it will appear (blog, newsletter, partner site): {{PLACEMENT}}
Title length guidance for the placement, which I have checked: {{TITLE_LENGTH_LIMIT}}
1. Write ten title options in at least four different styles (plain statement, how-to, number-led only if the piece really contains that many items, question).
2. For each, one line: what it promises, and whether the piece delivers on it fully, partly or not. Be strict.
3. Pick the best three and explain why, including any reason a reader might feel misled.
4. Suggest subheads for the piece, rewritten so a skimmer gets the argument from the headings alone.
5. Offer two alternatives for a summary line (under 25 words).
Do not use superlatives or numbers that the piece does not support.
Output format: a table for items 1 and 2 (Title | Style | Promise | Delivered?), then picks, subheads, summaries.
Fill in: PIECE_TEXT TARGET_READER PLACEMENT TITLE_LENGTH_LIMIT
Paste the finished piece so the delivery check is real. Check length limits on your own platform.
Best for: Verification and brand-risk review before publishing
You are a brand-risk and compliance reviewer for marketing content. Before this article goes live, find what needs someone's approval or sign-off and what could create brand, legal or reputational risk. This is not keyword or metadata work (the SEO pack covers that). You cannot browse; do not call a statement true or false from memory.
Marketing article draft (paste in full):
{{DRAFT_TEXT}}
Sources and notes I already have (links, documents, interview notes, customer-confirmed figures):
{{KNOWN_SOURCES}}
Who signs off product or legal claims (write NONE if nobody is named): {{SIGNOFF_OWNER}}
1. Extract every item that carries risk: quotations, named customers or companies, "first/best/only" and other superlatives, competitor comparisons, causal statements, product claims, statements about what a law or study says, and any number or date.
2. Build a table: # | Item (quoted briefly) | Risk type (approval, legal, brand, accuracy) | Source I already have (or NONE) | Action and owner | Risk if wrong (low, medium, high).
3. Compare quotes and figures with my sources word for word. Recompute any percentage or total from the base numbers and show the working.
4. Flag customer or partner quotes and named-company mentions needing written approval, and claims the sign-off owner must approve. If no owner was given, say so and write [ASSIGN].
5. List wording that sounds more certain than the evidence allows, with a softer alternative.
Output format: the table, then the recomputations, the approvals list and the softer-wording list.
Fill in: DRAFT_TEXT KNOWN_SOURCES SIGNOFF_OWNER
Treat the table as a to-do list. Do not let the AI be the source of any fact in the piece.
Example output · Claude (example written by The Prompt Index)
Sample inputs: DRAFT_TEXT: "Our 2025 survey of 120 customers found that most reported saving time on reporting. Maria Lopez, operations lead at Harbour Dental, said: 'We stopped chasing spreadsheets.' Under the UK rules, small firms must keep invoices for six years. Our tool is the fastest on the market."; KNOWN_SOURCES: survey export file (120 rows); interview notes with Maria Lopez; SIGNOFF_OWNER: NONE.
| # | Item (quoted briefly) | Risk type | Source I already have | Action and owner | Risk if wrong |
|---|---|---|---|---|---|
| 1 | "2025 survey" | Accuracy | Survey export | Confirm the survey dates fall in 2025 (owner: [ASSIGN]) | Low |
| 2 | "survey of 120 customers" | Accuracy | Survey export (120 rows) | Count complete responses, and check the rows are customers, not duplicates or test entries (owner: [OWNER?]) | Medium |
| 3 | "most reported saving time" | Accuracy, brand | Survey export | Find the exact question and the share who answered yes; "most" needs more than half of respondents, and "saving time" must match the question wording (owner: [OWNER?]) | Medium |
| 4 | "We stopped chasing spreadsheets." | Approval, accuracy | Interview notes | Compare the wording with the notes (and the recording, if one exists); confirm Ms Lopez approved the quote, her job title and the company name (owner: [OWNER?]; approver: Maria Lopez) | Medium |
| 5 | "small firms must keep invoices for six years" | Legal | NONE | Look for the official government guidance on record-keeping; check which firms and which jurisdiction it applies to (owner: [OWNER?], no sign-off owner given) | High |
| 6 | "the fastest on the market" | Legal, brand | NONE | Needs a published, reproducible comparison; otherwise remove it (owner: [OWNER?], no sign-off owner given) | High |
**Recomputations**
- "120 customers": the export has 120 rows; whether each row is a valid response is the check in row 2.
- "most": the yes-count is not in the material I was given, so I cannot recompute it. Once you have it, divide it by 120; more than 60 yes answers would be needed for "most" of 120.
**Approvals**
- Maria Lopez must approve the quote, and Harbour Dental the use of its name.
- No sign-off owner was given for the legal statement (row 5) or the comparison (row 6): [ASSIGN].
**Wording that sounds more certain than the evidence allows**
- "most reported saving time": softer: "in our survey, [N] of 120 respondents said they saved time on reporting" (fill N from the export).
- "the fastest on the market": softer: describe a specific measured result you can show, or drop the claim.
- "Under the UK rules": name the rule and the audience it applies to once you have checked the official source.
Best for: Cuts and structure before polish
You are a ruthless but respectful developmental editor. Edit for the reader, not for my ego.
Draft (pasted):
{{DRAFT_TEXT}}
Intended reader: {{TARGET_READER}}
Goal of the piece: {{PIECE_GOAL}}
Target word count: {{TARGET_WORDS}}
1. Say in one sentence what the draft currently argues, and whether that matches my goal.
2. Give a section-by-section assessment: keep, tighten, move or cut, with one reason each.
3. List up to ten specific cuts (repetition, throat-clearing, unsupported claims) by quoting the first few words, with the saving in words. Show the total saved against the target.
4. Rewrite the first and last paragraphs more tightly and show them next to the originals.
5. List jargon the reader may not know and either define or replace.
6. Point out any claim without support and mark it [SUPPORT NEEDED] instead of rewriting it.
Preserve my voice; do not add new facts or flourishes.
Output format: the six headed sections, with item 3 as a table.
Fill in: DRAFT_TEXT TARGET_READER PIECE_GOAL TARGET_WORDS
Run this before a line edit. Fix structure first and wording second.
Best for: Corrections that stay fair
You are an editor planning a myth-busting article that corrects a common belief fairly.
The belief or myth in our field: {{COMMON_MYTH}}
Who holds it and why it is understandable: {{WHO_BELIEVES_IT}}
What we know first-hand that contradicts it: {{FIRST_HAND_EVIDENCE}}
Sources I already have (links, studies, documents): {{KNOWN_SOURCES}}
1. State the myth in the words readers would use, then state the more accurate version in one sentence. If my evidence only supports part of the correction, say which part.
2. Give the kernel of truth in the myth, so the article does not sneer at readers.
3. Outline the article: opening, why people believe it, what really happens (resting only on my first-hand evidence and sources), what to do instead, and a short caveats section.
4. List each claim that needs a primary source I have not supplied, marked [SOURCE NEEDED], with the type of source to find.
5. Warn me about any statement that could be read as an accusation against a named person or company.
6. Offer three headline options that name the belief without overpromising.
Do not supply studies, statistics or quotes from memory.
Output format: numbered sections 1 to 6.
Fill in: COMMON_MYTH WHO_BELIEVES_IT FIRST_HAND_EVIDENCE KNOWN_SOURCES
Be honest about how strong your evidence is. A weak correction does more harm than the myth.
Best for: Cleaner sentences, same meaning
You are a line editor. Improve the sentences without changing the meaning or adding facts.
Draft (paste):
{{DRAFT_TEXT}}
Reader: {{TARGET_READER}}
Voice notes or style rules to follow: {{STYLE_RULES}}
1. Mark sentences that are over 30 words (adjust to your style), passive constructions that hide who acts, stacked prepositions, and vague words (such as "very", "really", "things"). Quote each in a table: # | Original | Problem | Suggested rewrite.
2. Rewrite the three densest paragraphs in full and show them beside the originals.
3. List inconsistent terms, spellings, capitalisation and number formats, with the form I should pick (follow my rules, otherwise note the options).
4. List jargon or abbreviations not explained for this reader.
5. Give a readability summary in plain words (long sentences, long paragraphs, heavy sections) without quoting any score from a tool you cannot run.
Do not change quotes, figures, names or claims. Where a sentence needs a fact I have not given, mark it [CHECK].
Output format: the table, the three paragraph comparisons, then the three short lists.
Fill in: DRAFT_TEXT TARGET_READER STYLE_RULES
Run after the structural edit. Read the result aloud before you accept changes.
Thought Leadership, Voice and Style
Write a position you can defend, draft a byline from an interview transcript, and capture your brand voice from real samples. Build a style guide, apply it, and put accurate AI-assistance wording and team rules in place.
Best for: A position you can defend
You are an editor who helps practitioners write thought leadership that says something. Generic trend commentary is not the goal.
My role and years in the field: {{MY_ROLE}}
Something I have seen, tried or got wrong that most people in my field would not say aloud: {{MY_OBSERVATION}}
Audience I want to influence: {{TARGET_AUDIENCE}}
What I would like them to do or think differently: {{DESIRED_SHIFT}}
1. State the position in one sentence a reader could disagree with.
2. Build the argument in three steps, each resting on my observation. Where a step needs outside evidence, mark [EVIDENCE NEEDED] and say what kind.
3. Give the strongest counterargument and a fair reply to it.
4. List what I must not claim because I cannot support it from experience alone.
5. Write an outline for an 800-word piece with an opening, three sections and an ending that tells the reader what to do.
6. Suggest the single story from my experience that should carry the piece, and the questions you need answered to tell it accurately.
Do not invent anecdotes, client names or statistics.
Output format: numbered sections 1 to 6.
Fill in: MY_ROLE MY_OBSERVATION TARGET_AUDIENCE DESIRED_SHIFT
Be candid in the observation field. The more specific and uncomfortable it is, the better the piece.
Best for: Opinion pieces that survive pushback
You are a debate coach and editor. Help me make an opinion piece fair as well as persuasive.
My position: {{MY_POSITION}}
Audience: {{AUDIENCE}}
Context: {{CONTEXT}}
Evidence I can legitimately cite (pasted, with sources): {{MY_EVIDENCE}}
1. Restate my position in its strongest, most precise form, and note any part that is overbroad.
2. List the three best arguments against it, written the way a thoughtful opponent would put them, not as straw men.
3. For each, tell me whether my evidence answers it, partly answers it, or does not, and what I could say honestly in response, including conceding a point.
4. Identify claims in my position that need evidence I have not supplied. Do not supply invented evidence.
5. Suggest a structure for the piece that addresses the strongest objection in the body, not in the last paragraph.
6. List any phrases that could read as unfair to a named person or group.
Output format: sections 1 to 6; for item 3 use a table (Objection | My evidence | Honest reply or concession).
Fill in: MY_POSITION AUDIENCE CONTEXT MY_EVIDENCE
Use for pieces that take a side. If the piece names real people or companies, get a second read.
Best for: Bylines that reflect the speaker
You are a ghostwriter. Draft a first-person article from the transcript below that keeps the speaker's real views and voice.
Transcript or notes (pasted):
{{TRANSCRIPT}}
Speaker name: {{SPEAKER_NAME}}
Speaker role: {{SPEAKER_ROLE}}
Target publication: {{PUBLICATION}}
Audience: {{AUDIENCE}}
Word limit: {{WORD_LIMIT}}
Rules:
- Use only what the speaker said in the transcript. Do not add statistics, examples, company results or opinions that are not there. Where an argument has a gap, insert [ASK SPEAKER: ...] with the question to put to them.
- Keep their distinctive phrases and rhythm where they help; clean up filler words.
- Write in the first person, and open with the speaker's strongest point, not their background.
- Present each number or claim exactly as stated and list it at the end under "Confirm with speaker".
- Stay within the word limit; give the word count of the draft.
End with a note listing any places where you smoothed over hesitation or contradiction, so the speaker can restore their intent.
Output format: the article, then "Confirm with speaker", then "Smoothed passages".
Fill in: TRANSCRIPT SPEAKER_NAME SPEAKER_ROLE PUBLICATION AUDIENCE WORD_LIMIT
Send the draft to the named author for approval and edits before it goes anywhere.
Best for: A voice guide based on your writing
You are a brand editor who builds voice guidance from evidence, not adjectives.
Samples of our best writing (paste three to six short pieces, each labelled):
{{WRITING_SAMPLES}}
Who we write for: {{AUDIENCE}}
Words or tones we want to avoid: {{AVOID_LIST}}
1. Describe the voice as it actually appears in the samples: sentence length, formality, use of "you" and "we", humour, jargon, rhythm. Support each point with a short quote from a sample.
2. Name where the samples are inconsistent with each other.
3. Give six voice traits as "We are X, but not Y" pairs, each with a before-and-after rewrite of a sentence taken from the samples.
4. Provide a short list of words and phrases we use, and ones we should stop using, based on the samples and my avoid list.
5. Write a 120-word paragraph about a topic of my choice, [TOPIC TO BE CHOSEN], in this voice, to test whether it feels right.
Do not describe a voice that is not in the samples; if the samples are too few to tell, say so.
Output format: sections 1 to 5, with item 3 as a table.
Fill in: WRITING_SAMPLES AUDIENCE AVOID_LIST
Use samples people actually liked, not the ones you wish you had written.
Best for: One consistent set of rules
You are a managing editor drafting a practical style guide for writers and freelancers.
Organisation: {{ORGANISATION}}
Audience: {{AUDIENCE}}
Reference style we already follow, if any (for example a published dictionary or style manual): {{BASE_STYLE_REFERENCE}}
Our voice notes: {{VOICE_NOTES}}
Disagreements or recurring edits we want to settle: {{RECURRING_EDITS}}
Draft a style guide of no more than two pages, in these sections:
1. Voice and tone, with three do and don't examples.
2. Spelling and regional conventions. State a convention only if I named one; otherwise write [DECIDE] and list the options.
3. Punctuation, capitalisation, headings, numbers and dates: one rule per line, with an example. Settle each recurring edit I listed, flagging each as a decision for me to confirm.
4. Product, brand and term usage: a glossary table with Term | Use | Do not use.
5. Sourcing and linking rules: how to cite a statistic, what makes a source acceptable, how to label sponsored or AI-assisted content.
6. Accessibility basics for text, headings and image descriptions.
7. A short "when in doubt" rule.
Output format: the seven headed sections, plain and scannable.
Fill in: ORGANISATION AUDIENCE BASE_STYLE_REFERENCE VOICE_NOTES RECURRING_EDITS
Treat the first version as a draft for your editors to challenge. Rules nobody agrees with will not be followed.
Best for: Consistent copy, less back-and-forth
You are a copy editor who applies a style guide exactly as written.
Our style guide rules (paste):
{{STYLE_RULES}}
Draft to check (paste):
{{DRAFT_TEXT}}
1. List every place where the draft breaks a rule, quoting the offending words, naming the rule, and giving the corrected version, in a table: # | Quote | Rule | Fix.
2. Do not enforce any preference not in the rules. If you notice something that may be an error but is not covered, list it separately under "Not covered by our rules" and do not change it.
3. Give counts of issues by rule so the editor can see recurring problems.
4. Provide the corrected draft only if I ask; instead, summarise the three most common problems and how the writer can avoid them next time.
5. State anything in the rules that contradicts itself or is ambiguous, with the example from the draft that exposed it.
Keep your tone constructive and short.
Output format: the table, the counts, the three-problem summary, then the ambiguity list.
Fill in: STYLE_RULES DRAFT_TEXT
Handy for onboarding freelancers. The ambiguity list is a free way to improve the guide.
Best for: Honest, plain disclosure wording
You are an editor helping a publisher be honest about how AI tools were used in content.
How we used AI on this piece or programme, in plain facts (for example brainstorming, outlining, first draft, editing, translation, image creation): {{HOW_AI_WAS_USED}}
What humans did (research, interviews, fact-checking, final edit, approval): {{WHAT_HUMANS_DID}}
Where the note will appear (article footer, about page, policy page): {{WHERE_IT_APPEARS}}
Any rules from the platform, client or publication we must follow (paste their wording): {{EXTERNAL_RULES}}
Write:
1. A short disclosure line for a single article, no more than 40 words, that states only what I told you.
2. A longer policy paragraph for our about or policy page.
3. A version for a client or contributor agreement, written as plain-language bullet points for them to confirm.
4. Three things this wording does not cover that I should decide, such as what happens to private data pasted into tools.
5. Note any place where my description is vague, so the wording does not overclaim or underclaim.
Do not state that content was "written by humans" or "AI-free" unless my facts say so. Tell me to check current disclosure rules for my platform, publisher and region, and to take advice for anything contractual.
Output format: the three texts, labelled, then the decisions list.
Fill in: HOW_AI_WAS_USED WHAT_HUMANS_DID WHERE_IT_APPEARS EXTERNAL_RULES
Disclosure rules vary by platform and country. Check the current ones and keep the note accurate.
Best for: A usable AI policy for the team
You are an editorial lead drafting internal guidelines for AI use. This is a draft policy for my team to discuss, not legal advice.
Team and the content we produce: {{TEAM_DESCRIPTION}}
Tools we currently use or consider: {{AI_TOOLS}}
Data we handle that is sensitive (client info, unreleased products, personal data): {{SENSITIVE_DATA}}
Standards we want to uphold: {{QUALITY_STANDARDS}}
Draft guidelines with:
1. Approved uses and uses that need approval first, in two short lists.
2. What must never be pasted into an AI tool, based on my sensitive-data description.
3. Verification: every fact, number and quote in AI-assisted text must be checked against a named source by a person; who signs off.
4. Attribution and disclosure: when and how we tell readers and clients about AI assistance.
5. Originality: no passing off the AI's output as customer data or expert quotes, and no invented sources.
6. How to log AI use on a piece so it can be audited later.
7. A review date and an owner for the policy. Write [DECIDE] wherever I need to choose.
Remind the team to check the data terms of each tool before using it with company data.
Output format: seven headed sections, short bullet rules.
Fill in: TEAM_DESCRIPTION AI_TOOLS SENSITIVE_DATA QUALITY_STANDARDS
Run it past your legal or data protection contact before adopting it.
Case Studies and Customer Proof
Plan a customer interview, request written approval for quotes, keep a sign-off tracker for every figure, quote and logo, and write a results section that does not overclaim.
Best for: Interviews that capture real results
You are a B2B customer marketing writer preparing a case study interview with a business customer. Capture their real story, with results their company will sign off.
Customer role: {{CUSTOMER_ROLE}}
Company type: {{COMPANY_TYPE}}
What they used from us: {{PRODUCT_USED}}
For how long: {{USAGE_DURATION}}
What we think the headline result might be (unconfirmed): {{HYPOTHESIS}}
Interview length in minutes: {{INTERVIEW_MINUTES}}
Create:
1. A short opening script that explains the purpose, asks permission to record, and states that nothing will be published without their written approval.
2. Twelve to fifteen questions in four blocks: the situation before, why they chose to change, how it went (including difficulties), and the results.
3. For results, questions that ask for the before and after in their own measure, how it was measured, over what period, and what else changed at the same time. Never ask them to confirm my hypothesis; ask neutrally.
4. A question about what they would tell a peer, and one about any limits or things that did not work.
5. A closing script that explains the review and approval process, including that their communications or legal team may need to approve quotes, metrics and the use of their company name and logo.
Output format: the opening script, timed question blocks, closing script.
Fill in: CUSTOMER_ROLE COMPANY_TYPE PRODUCT_USED USAGE_DURATION HYPOTHESIS INTERVIEW_MINUTES
Never promise results in advance. Let the customer define the numbers.
Best for: Getting permission cleanly
You are a customer marketing manager writing a clear, respectful approval request.
Customer contact name: {{CONTACT_NAME}}
Their role: {{CONTACT_ROLE}}
What we want to publish: {{WHAT_TO_PUBLISH}}
Where it will appear: {{WHERE_PUBLISHED}}
The exact text to approve (paste the quote or the full draft):
{{TEXT_TO_APPROVE}}
Date we would like a reply by: {{REPLY_BY_DATE}}
Write an email that:
1. Thanks them for specific help they gave, without exaggeration.
2. States what we want to publish, where, and for how long, in plain terms, and says they can edit or decline without any effect on the relationship.
3. Includes the exact text for approval below the email body, ready for them to mark up.
4. Explains how to approve (reply with "approved" or send changes), and that we will not publish until we have their written agreement.
5. Offers an anonymised version as an alternative.
6. Ends with a short, non-pushy reminder of the reply date.
Add a note for me listing what to check with our legal or privacy contact (for example consent rules for using names, images or logos) and what to record in our files.
Output format: subject line, email body, the approval text block, then my internal note.
Fill in: CONTACT_NAME CONTACT_ROLE WHAT_TO_PUBLISH WHERE_PUBLISHED TEXT_TO_APPROVE REPLY_BY_DATE
Keep a record of the approval. Rules on consent vary by region, so check yours.
Best for: Sober results that still persuade
You are an editor who writes results sections buyers can trust.
Confirmed results from the customer (figures, period, how measured): {{CONFIRMED_RESULTS}}
What else changed for them in that period, from the interview: {{OTHER_CHANGES}}
What the customer said about the result in their own words: {{CUSTOMER_QUOTE}}
Write three versions of a results section of about 120 words each:
1. Plain and factual: figures first, with period and method.
2. Narrative: the result told as part of the customer's story, quoting them.
3. Skimmable: three bullets and one sentence of context.
Rules: state only the supplied figures; do not round up; do not imply that every customer gets the same outcome; mention the other changes if they affect interpretation; do not use words like "dramatic" or "game-changing" unless the customer used them, in which case attribute them.
Then list in two lines the caveat a sceptical reader would ask about, and where in the text you answered it.
Output format: three labelled versions, then the caveat note.
Fill in: CONFIRMED_RESULTS OTHER_CHANGES CUSTOMER_QUOTE
Pick the version that fits the page. Keep the caveats in the text.
Best for: Approvals nobody can dispute
You are a customer marketing coordinator running the approvals for a B2B case study. Your job is to make sure nothing is published without the right person agreeing in writing.
Case study draft (paste):
{{CASE_STUDY_DRAFT}}
Approvers on the customer side (names and roles): {{CUSTOMER_APPROVERS}}
Approvers on our side (names and roles): {{OUR_APPROVERS}}
Target publication date: {{TARGET_PUBLISH_DATE}}
1. List every item that needs approval: each quote, each figure with its period and measurement method, the customer's name, logo and any image, claims about our product, and any statement about a third party.
2. Table: # | Item (quoted briefly) | Who must approve | What exactly they are approving | Status (Not sent) | Evidence to keep.
3. Mark any item whose approver is not named in my lists as [ASSIGN].
4. Flag figures whose source or period is missing from the draft; these cannot go to sign-off until clarified.
5. Suggest the order in which to send items, and what to do if the customer's team asks for changes to a quote or metric.
6. Work back from the target date only to list the stages (send, chase, final check, publish). Do not invent dates.
Output format: the table, then short lists for items 4 to 6.
Fill in: CASE_STUDY_DRAFT CUSTOMER_APPROVERS OUR_APPROVERS TARGET_PUBLISH_DATE
Keep the approvals in writing and store them with the final version. Check any contractual rules on using a customer's name.
Example output · Claude (example written by The Prompt Index)
Sample inputs: CASE_STUDY_DRAFT: a case study about a three-dentist practice (name withheld) containing two quotes ("Friday afternoons used to disappear into spreadsheets." and "Nobody argues about whose numbers are right any more."), the figures "about 6 hours a month (October to December)" and "about 2 hours a month (February to June)" from the practice manager's time log, "a reduction of roughly two-thirds", "set-up took two afternoons", and a note that the first data import was fiddly; CUSTOMER_APPROVERS: Sam (practice manager), Dr Okafor (practice owner); OUR_APPROVERS: Priya (customer marketing lead), Tom (product lead); TARGET_PUBLISH_DATE: the 20th of next month.
| # | Item | Who must approve | What exactly they approve | Status | Evidence to keep |
|---|---|---|---|---|---|
| 1 | Quote: "Friday afternoons used to disappear into spreadsheets." | The person quoted: not named in the draft, [ASSIGN] | Exact wording and attribution as "practice manager" or other role | Not sent | Written reply |
| 2 | Quote: "Nobody argues about whose numbers are right any more." | The person quoted: not named in the draft, [ASSIGN] | Exact wording and attribution | Not sent | Written reply |
| 3 | Figure: about 6 hours a month (October to December) | Sam (owns the time log); Dr Okafor for company use | The figure, period and method (time log) | Not sent | Time log extract or written confirmation |
| 4 | Figure: about 2 hours a month (February to June) | Sam; Dr Okafor | The figure, period and method | Not sent | Same as above |
| 5 | "a reduction of roughly two-thirds" | Priya checks the arithmetic; Sam confirms | That it is calculated from the two rounded figures above | Not sent | Priya's working note |
| 6 | "Set-up took two afternoons" | Tom (our claim); Sam (customer confirms) | That the statement is accurate | Not sent | Written confirmation from both |
| 7 | Note that the first import was fiddly | Dr Okafor; Tom | Wording and whether the practice is happy to be associated with it | Not sent | Written reply |
| 8 | Customer identity (name withheld) | Dr Okafor | That the practice stays unnamed, or agrees to a named version | Not sent | Written reply |
**Figures missing a source or period**
None: both figures state a period and the time-log method. No logo or image appears in the draft.
**Order to send**
Send the figures (rows 3 to 5) first, because the narrative depends on them. Then the quotes, then the remaining items. If the customer asks to change a quote or figure, update the draft, re-run the number checks, and send the changed item back for fresh written approval.
**Stages working back from the 20th of next month**
Send items, chase, final check of the revised draft, publish. No dates are assigned; you choose them.
Repurposing Long-Form Content
Plan how one strong piece becomes a talk, a slide outline, a checklist, a short series, a data visual brief or an interactive quiz or calculator.
Best for: Planning reuse before making anything
You are a content strategist who reuses good work without recycling it badly.
The pillar piece (paste the full text or a detailed summary):
{{PILLAR_PIECE}}
Original audience: {{ORIGINAL_AUDIENCE}}
Formats we can produce with our skills and time: {{AVAILABLE_FORMATS}}
Channels where our audience actually is (from our own data): {{OWNED_CHANNELS}}
1. Break the piece into its distinct ideas, claims and assets (data, examples, steps, quotes). Number them.
2. For each of up to eight derived formats, say which numbered items it uses, who it serves, what must change for that audience (not just shorter), and the estimated effort as low, medium or high.
3. Rank the derived pieces by value for effort, with a reason that rests on my inputs, not general claims.
4. Say what NOT to repurpose and why (for example, a claim that needs context or an outdated section).
5. Suggest an order and spacing that avoids repeating the same message back-to-back.
6. Note rights to check before reuse: quotes, images, customer material, and contributor agreements.
Do not write the derived pieces here.
Output format: a numbered inventory, then a table (Format | Items used | Audience | Changes | Effort), then the other notes.
Fill in: PILLAR_PIECE ORIGINAL_AUDIENCE AVAILABLE_FORMATS OWNED_CHANNELS
Run it once the pillar piece is finished and fact-checked. Other prompts in this section write each format.
Best for: From article to session plan
You are a speaker coach turning a written article into a talk people will sit through.
Article (paste):
{{ARTICLE_TEXT}}
Audience: {{AUDIENCE}}
What they hope to leave with: {{AUDIENCE_GOAL}}
Talk length in minutes: {{TALK_MINUTES}}
Format (live webinar, conference session, internal training): {{TALK_FORMAT}}
1. State the one takeaway in a sentence the audience could repeat.
2. Make a timed outline whose minutes add up to the talk length; show the sum. Include opening, three to four sections, a moment for audience interaction and a close.
3. For each section, list what to say in three bullets using only the article's material, and what visual or demo to show.
4. Mark where the article's written logic must change for speech (shorter sentences, repeating the key point, signposting).
5. Suggest two audience questions to plan for and honest answers that point back to the article. If an answer needs facts the article does not contain, write [PREPARE].
6. Provide a one-line description for the registration page that promises only what the talk covers.
Output format: the timed outline as a table (Minutes | Section | Key points | Visual), then the rest as short lists.
Fill in: ARTICLE_TEXT AUDIENCE AUDIENCE_GOAL TALK_MINUTES TALK_FORMAT
Rehearse out loud once and adjust the timings. Written text is slower than speech.
Best for: A clear deck from a long piece
You are a presentation designer. Turn the article into a slide outline that carries one idea per slide.
Article (paste):
{{ARTICLE_TEXT}}
Audience: {{AUDIENCE}}
Where it will be used (sales call, conference, internal): {{USE_CASE}}
Number of slides allowed: {{SLIDE_COUNT}}
For each slide, give:
- Slide number and a headline that states the point, not just the topic.
- Up to three short on-slide bullets or one visual idea (chart, diagram, quote).
- Speaker notes of 1 to 3 sentences using only the article's material.
- The article passage it comes from, quoted in a few words.
Rules: exactly the number of slides allowed, including title and closing slides; no statistic or claim that is not in the article; mark any slide where the visual needs data we must pull from the source as [NEED DATA]; do not put paragraphs of text on slides.
Finish with a list of article points you left out and why.
Output format: a numbered slide list with the four labelled parts, then the left-out list.
Fill in: ARTICLE_TEXT AUDIENCE USE_CASE SLIDE_COUNT
Our Slide Studio tool can build a deck from the outline once you are happy with it.
Best for: A useful one-pager from a long guide
You are a content designer who makes practical one-page tools from longer writing.
Source guide or article (paste):
{{SOURCE_GUIDE}}
Reader and the moment they would use this: {{READER_MOMENT}}
Format wanted (checklist, worksheet, template, cheat sheet): {{TOOL_FORMAT}}
1. Say what job the tool does for the reader at that moment, in one sentence.
2. Extract only the actions and decisions from the guide that serve that job; ignore the rest. List what you left out.
3. Write the tool itself: a title, a one-line instruction, then items with checkboxes or fields. Make each item a concrete action with a clear test of completion.
4. Fit it to a single page and state the item count.
5. Add a footer line pointing back to the full guide, with [LINK] as the placeholder.
6. List any item whose accuracy depends on facts that may change, so we can review it periodically.
Do not add advice that is not in the source.
Output format: the finished tool, followed by the left-out list and the review list.
Fill in: SOURCE_GUIDE READER_MOMENT TOOL_FORMAT
If you gate it behind an email form, make sure your consent wording is right (check the rules where you operate).
Best for: A series that works piece by piece
You are an editor planning a series from one long guide.
Long guide (paste):
{{LONG_GUIDE}}
Reader: {{TARGET_READER}}
Number of articles in the series: {{ARTICLE_COUNT}}
Target length of each: {{WORDS_PER_ARTICLE}}
1. Divide the guide into the stated number of articles. Each must stand alone and also point to the next. Give each a working title, a one-sentence promise, and the sections of the guide it draws from.
2. Estimate the word count of the source material assigned to each and compare it with the target length. Flag articles that are too thin or too heavy and propose a fix. Show the numbers.
3. For each, name what must be added so it is not just a slice (a new example, a recap, a different opening).
4. Suggest how each article links to the others and to the original guide, using [LINK] placeholders.
5. Recommend a publication order and explain it from the reader's point of view.
Do not invent new content; list any additions as to-do items for the writer.
Output format: a table (Article | Promise | Source sections | Est. words vs target | Additions), then order and linking notes.
Fill in: LONG_GUIDE TARGET_READER ARTICLE_COUNT WORDS_PER_ARTICLE
Good when a guide is too long to be read in one go and parts of it deserve their own life.
Best for: A brief a designer can use
You are a content producer writing a brief for a designer. The visual must show only what the article's data supports.
Article or data source (paste):
{{ARTICLE_DATA}}
Audience: {{AUDIENCE}}
Where the visual will appear: {{PLACEMENT}}
Brand style notes for the designer: {{BRAND_STYLE}}
Write a brief with:
1. The one message the visual should deliver, as a headline.
2. The exact data points to show, copied from the source with the original wording, units and period. Note any calculation I must verify and show the working.
3. A suggested layout in sections, and the chart type for each data point with a reason.
4. All text to appear on the visual, final wording, with character counts for headline and labels.
5. A line for the source credit and the date of the data.
6. Accessibility needs: a text description of the visual (alt text, within the length your CMS or platform allows; check it) and a note on colour contrast.
7. What the visual must not imply, such as cause where there is only correlation.
Output format: the seven numbered parts, ready to send to a designer.
Fill in: ARTICLE_DATA AUDIENCE PLACEMENT BRAND_STYLE
Send the designer the underlying data file as well as the brief.
Best for: A buildable spec for interactive content
You are a content strategist specifying an interactive piece that a developer or no-code tool can build.
Topic and what the reader wants to find out: {{READER_QUESTION}}
Reader: {{TARGET_READER}}
Interactive format (quiz, calculator, self-assessment, checklist scorer): {{INTERACTIVE_FORMAT}}
The rules, formulas or criteria that decide each result (these must be ours or from a cited source): {{RESULT_RULES}}
Where results should lead the reader next: {{NEXT_STEP}}
1. State the purpose in one sentence and what the reader gets at the end.
2. Draft the questions or inputs (no more than ten), with answer options.
3. Specify how answers map to results using only my rules. If my rules are incomplete, list the gaps as [DECIDE] instead of inventing scoring.
4. Write the copy for each result screen (about 60 words each) that describes what the result means without diagnosing or promising outcomes.
5. List what data you would collect, what you would not, and the consent and privacy questions to ask our legal or data contact.
6. Give an accessibility checklist for the interactive and a plan to test it with five real readers.
Output format: a spec with the six numbered parts.
Fill in: READER_QUESTION TARGET_READER INTERACTIVE_FORMAT RESULT_RULES NEXT_STEP
Do not publish scoring you cannot explain. Test it with real readers before launch.
Audits, Refreshes and Distribution
Decide what to keep, update, merge or retire. Find stale statements, plan the promotion of a piece, brief colleagues, review monthly numbers honestly and learn from a result.
Best for: Decisions about what to keep
You are a content auditor. Help me decide what to keep, update, merge or retire, using criteria I control.
Inventory, one item per line (titles, URL slugs, dates and any metrics I have):
{{CONTENT_INVENTORY}}
My criteria and what matters most to the business: {{AUDIT_CRITERIA}}
Time I have for updates per month, in hours: {{UPDATE_HOURS}}
1. Propose a scoring rubric of five criteria, each scored 0 to 2, using my criteria and only the data I provided. Define each score in a sentence.
2. Score every item. If data is missing, write "?" instead of guessing and list what is needed.
3. Assign each item a decision: Keep, Update, Merge (with which item), Retire, or Investigate.
4. Show the count of items per decision and the estimated update hours using ranges I should check; confirm the total against my time budget.
5. Give the order in which to tackle the Update items, highest value first, with the reason.
6. Flag retire decisions that need redirects or checks for incoming links, and tell me to check these with whoever manages the site.
Output format: a table (Item | Scores | Total | Decision | Reason), then the counts, plan and flags.
Fill in: CONTENT_INVENTORY AUDIT_CRITERIA UPDATE_HOURS
Include publish dates and metrics if you can. Decisions about retiring pages should be reviewed by a person.
Best for: Updating an article with evidence
You are an editor specialising in updating older articles. Base your advice on what I paste.
Current article (paste):
{{ARTICLE_TEXT}}
Date published: {{PUBLISHED_DATE}}
Date last updated: {{UPDATED_DATE}}
What I see in its performance (for example views, time on page, conversions, comments): {{PERFORMANCE_NOTES}}
What I know has changed since it was written: {{WHAT_HAS_CHANGED}}
1. Diagnose in plain terms what is probably wrong, listing hypotheses ranked by how well the evidence supports them. Do not claim to know why it underperforms.
2. List sections to keep, rewrite, cut or add, with reasons.
3. Identify statements that may be out of date and need re-checking, listed as questions with the type of source to check. Do not replace them with figures from memory.
4. Suggest an improved title and opening paragraph consistent with what the article truly covers.
5. Suggest what to add that only we can offer: first-hand experience, our data, an expert review.
6. Propose a short "Updated on [DATE]" note and a way to explain what changed.
7. Give a plan for judging whether the refresh worked, using the same measures as the baseline.
Output format: seven numbered sections.
Fill in: ARTICLE_TEXT PUBLISHED_DATE UPDATED_DATE PERFORMANCE_NOTES WHAT_HAS_CHANGED
Measure for a few weeks after the update, using the same figures you started with.
Best for: Spotting what has gone out of date
You are an editorial fact-checker whose job is to find what may have gone stale. You cannot browse and must not supply current facts from memory.
Article (paste):
{{ARTICLE_TEXT}}
Date originally written: {{ORIGINAL_DATE}}
Today's date: {{TODAY_DATE}}
1. Extract every statement that could have changed: statistics, rankings, prices, product features, software versions, laws and regulations, company facts, job titles, tool names, links and "latest" or "new" claims.
2. Table: # | Statement | Why it might be stale | Type of source to check (official help page, original study, company filing) | Priority.
3. List every external link or reference in the text and mark which need testing.
4. Identify phrases that signal time ("this year", "recently", "currently") and suggest evergreen replacements.
5. Provide a short rewrite approach for any section that depends mostly on stale information.
Do not state what the current facts are. Output only the checking list and wording suggestions.
Output format: the table, the link list, the phrase list, then the rewrite notes.
Fill in: ARTICLE_TEXT ORIGINAL_DATE TODAY_DATE
Always check the facts yourself against a primary source. The AI cannot confirm what is current.
Best for: Fewer, stronger pieces
You are a content editor who merges overlapping posts into one stronger piece.
Posts to consolidate (paste each in full, labelled Post 1, Post 2, and so on):
{{POSTS_TEXT}}
Reader and the main question the merged piece should answer: {{MAIN_QUESTION}}
Which post is the best-performing, if I know: {{BEST_POST}}
1. Map what each post covers in a table: Topic | Post 1 | Post 2 | and so on, marking depth (none, light, deep).
2. Identify contradictions between the posts and say which version I should verify before choosing.
3. Propose a structure for the merged piece with headings, noting the source post for each section.
4. List content to drop because it is duplicated or weak, with a quote of the first few words.
5. Write the merged introduction and a transition paragraph, using only the posts' material.
6. Recommend which URL should survive, which should point to it, and what I must check about redirects and internal links with the person who manages the site.
7. List what to tell readers if comments or shares exist on retired posts.
Output format: sections 1 to 7; do not rewrite the whole piece.
Fill in: POSTS_TEXT MAIN_QUESTION BEST_POST
Merging works when posts target the same reader question. Check redirects before publishing the result.
Best for: Reach the right readers
You are a content distribution strategist. Plan how one piece reaches the people it is for. Do not write the posts or emails; other prompts and tools do that.
The piece and its main point: {{PIECE_SUMMARY}}
Who it is for: {{TARGET_READER}}
Channels we own or can access (list, with audience size if known): {{AVAILABLE_CHANNELS}}
People and organisations who might genuinely find it useful: {{POSSIBLE_PARTNERS}}
Time we can spend on promotion: {{PROMOTION_HOURS}}
1. Sort channels into owned, earned and paid-or-partner, and choose the three that best fit this reader. Justify from my inputs.
2. For each chosen channel, state the goal, the angle that suits it, the one action to take, and the effort in hours.
3. A sequence across two weeks: what happens on publication day, then follow-ups. Confirm total hours do not exceed my budget.
4. Three people or organisations from my list, and what specifically would make this piece useful to them. Do not claim they will share it.
5. What to measure for each channel and when to check.
6. What to do if nothing happens in the first week.
Output format: a table for items 2 and 3, then bullets for 4 to 6.
Fill in: PIECE_SUMMARY TARGET_READER AVAILABLE_CHANNELS POSSIBLE_PARTNERS PROMOTION_HOURS
Use your own audience data to choose channels. A short plan done fully beats a long one done halfway.
Example output · Claude (example written by The Prompt Index)
Sample inputs: PIECE_SUMMARY: a guide to setting up month-end reporting in one afternoon; TARGET_READER: practice managers at small clinics; AVAILABLE_CHANNELS: company blog, customer email list, LinkedIn company page, monthly user community call; POSSIBLE_PARTNERS: a practice-management association newsletter (we know the editor), a bookkeeper who has referred customers; PROMOTION_HOURS: 6.
**1. Channel choice**
- Owned: company blog (where the guide lives), customer email list, LinkedIn company page, community call.
- Earned and partner: the association newsletter, the bookkeeper.
- Paid: none listed.
Best fit for practice managers: the customer email list (they already know us), the community call (they can ask questions), and the LinkedIn page. The blog is the destination for all three.
**2. Plan by channel**
| Channel | Goal | Angle | One action | Hours |
|---|---|---|---|---|
| Customer email list | Get existing customers to read it | "Do it in an afternoon" | Send one email pointing to the guide | 2 |
| Community call | Hear real questions | Walk through the guide's steps live | Present the steps people find hardest and take questions | 1.5 |
| LinkedIn company page | Reach practice managers beyond customers | One practical step from the guide | Publish a post linking to the guide | 1.5 |
Channel total: 2 + 1.5 + 1.5 = 5 hours. The remaining 1 hour goes to partner notes (item 4), making 6 hours in all, within the budget.
**3. Two-week sequence**
| When | What happens | Hours |
|---|---|---|
| Publication day | Guide goes live; email and LinkedIn post go out | 3.5 |
| Days 2 to 3 | Send the two partner notes | 1 |
| Week 2 | Present on the next community call [CONFIRM DATE: you did not give one] | 1.5 |
Total: 3.5 + 1 + 1.5 = 6 hours.
**4. People and organisations**
- Association newsletter editor: ask whether the guide would help their readers, and offer a short summary written for them. This does not assume they will run it.
- The bookkeeper: offer the guide as something to share with clients who ask about reporting.
- A third partner: [ADD - you listed only two].
**5. What to measure**
- Email: clicks to the guide, one week after sending.
- LinkedIn: clicks to the guide, one week after posting.
- Community call: number of questions about the guide, and the topics.
- Partners: whether they replied and what they said.
**6. If nothing happens in week one**
Reread the angle against what practice managers actually ask, change the email subject line, and try it on the next send.
Best for: Getting colleagues to use your content
You are a content marketer writing an internal note so colleagues can use a new piece.
The piece: {{PIECE_TITLE}}
Where it lives: {{PIECE_LINK}}
What it covers in plain terms: {{PIECE_SUMMARY}}
Which customer questions or sales situations it helps with: {{SALES_SITUATIONS}}
Claims in it that colleagues must not exaggerate (limits, caveats): {{CAVEATS}}
Write an internal announcement of no more than 200 words that includes:
1. What it is, who made it, and why it exists, in two sentences.
2. Three situations where a colleague might share it, each with a one-line suggestion for what to say.
3. What it does not claim, using my caveats, so nobody oversells it.
4. Where to find the underlying sources if a customer asks.
5. How to send feedback or tell us about a question the piece misses.
Then add a two-line version suitable for a team chat message.
Do not add metrics, customer names or promises that I did not provide.
Output format: the announcement, then the two-line message.
Fill in: PIECE_TITLE PIECE_LINK PIECE_SUMMARY SALES_SITUATIONS CAVEATS
In practice colleagues often do not know a piece exists; a short note helps.
Best for: Learning from one result, carefully
You are a facilitator running a blameless review of one piece of content.
The piece (paste or summarise):
{{PIECE_SUMMARY}}
What happened (results versus what we expected): {{RESULTS_SUMMARY}}
What we did to make and promote it: {{WHAT_WE_DID}}
What else was going on at the time: {{CONTEXT}}
1. Restate the facts without judgement and list what we do not know.
2. List possible explanations across five areas: topic, angle, quality, packaging (title, format), and distribution. Rate each as "supported by what you told me", "possible" or "no evidence".
3. Separate what we controlled from what we did not.
4. Suggest cheap checks that could distinguish between the top three explanations (for example comparing with a similar past piece).
5. Write down three lessons phrased as hypotheses to test, not as rules.
6. Suggest one decision to make this week and one to postpone until we have more evidence.
Avoid blame. Output format: numbered sections, concise bullets.
Fill in: PIECE_SUMMARY RESULTS_SUMMARY WHAT_WE_DID CONTEXT
Do this for successes too. Lucky wins teach as little as bad luck does if you misread them.