Marketing Runbook

Ask first

• Where do your drafts live? (a document tool, a folder)
• How do you mark one ready? (a label, a status, a file name)
• What is your style guide? (default built from your five best-performing past pieces)

Needs

• Read access to drafts and past pieces, and permission to write a copy, never to edit the original
• A list of where each type of claim can be checked (your own numbers, your published pages, a named public source)
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every hour, find drafts newly marked ready.
2. Build or load the style guide, using the best-post pattern run if you have it: how your best pieces open, how long they are, how you use numbers, and what you never do.
3. Check every factual claim, figure and quote against its source. If you run the customer-voice run with your own product on its list, take the confusions and complaints it found this week and mark where the draft answers each one. For each, say sourced, unsourced or contradicted, and give the source.
4. Write three titles, flag weak paragraphs and any departure from the style guide, and save it all as a marked-up copy. Never change the original.

Check

• Run it on a published piece; every figure is checked and a wrong one is caught
• Confirm the original file is unchanged
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on an hourly schedule, a marked-up copy next to each draft

Ask first

• Which channels do you use? (default a post, an email, a short video, a quote card, a thread)
• How long should each be? (default as your past pieces in that channel)
• Where do drafts go? (default a page in your docs)

Needs

• Read access to the long piece and your past posts for each channel, or paste them in
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Every hour, read your sitemap or blog feed for entries added since the last check that are over 800 words. A new entry is one whose address has not been processed before; keep a list of processed addresses. For each, find its main claim and its two or three strongest points.
2. For each channel, write a draft in the shape your past pieces in that channel use.
3. Check that every draft keeps the original claim and adds none. List what was cut from each.
4. Send each draft through the pre-publish edit run so cut-down versions get the same claim check. Leave the drafts. Never publish.

Check

• Add a test entry to a copy of the feed; it is picked up within the hour and an entry already processed is skipped
• Run it on an old piece; every draft's claim appears in the original
• Confirm no draft adds a figure that is not in the source
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code when a piece is published, drafts in my docs

Ask first

• What counts as a tactic? (default any change you make to get more visibility or leads)
• How long before you check? (default 4 weeks)
• Where are results? (analytics, server logs, the AI answer tracker)

Needs

• A list of tactics with start dates
• Read access to the results, or numbers pasted in on the check date
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. When a tactic starts, ask what would show it failed and what would show it worked, in numbers, and by when. Save both before the tactic begins.
2. On the check date, read the results and compare them to the saved failure and success lines.
3. Report passed, failed or undecided, with the figures. Never change the lines afterwards.
4. If undecided, say what extra time or data would settle it.

Check

• Run it on a tactic you ended; the verdict agrees with what you decided
• Confirm the failure line was saved before the results and never edited
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code when I start a tactic and on each check date, a message with the verdict

Ask first

• Where do test results live?
• What is the smallest result that counts as a win? (default a gap bigger than chance for the sample)

Needs

• Read access to results, or paste them in
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each day, look for tests that ended.
2. For each, state the versions, the numbers and the sample size.
3. Say whether the gap is bigger than chance for that sample. Name the test you used (a two-sided test of two proportions) and require at least 100 per version before calling a winner. Below that, say inconclusive.
4. Suggest one next test, and pass the winning line and that test to the content calendar run.
5. Offer a holdout and wait for a yes before doing anything: send the winner to everyone except a random 10% for two weeks, then report whether the lift held. Never send anything without the yes.

Check

• Run it on a finished test; numbers match the tool
• Confirm a tiny sample is called inconclusive
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a daily schedule, a message when a test ends

Ask first

• Which products do you depend on, and where does each publish its release notes? (a link per product; a company blog, a docs page or a GitHub repo all work)
• What should the note flag? (default anything that changes your workflows, triggers or automation)
• Where should it reach you? (default a push to your phone)

Needs

• A list file with one line per product: name, link, and the last version or date you have seen. The last part is filled in for you after the first check
• An assistant that can run daily, read a web page and keep that saved value
• For a page that loads its content with JavaScript: a browser you are signed in to, read as text. For a GitHub repo: its release feed, which needs no browser

Build

1. Each day, for every line on the list, read the page and find the newest entry. Work out whether anything is newer than the saved value.
2. On the first check of a product with no saved value, record the newest entry as the baseline and say nothing.
3. If something is newer, write at most six short lines on what changed, then one line starting "Affects you:" on the things you named. Send it only to yourself, and move the saved value forward only after it was sent.
4. If nothing is newer, send nothing.
5. If a page cannot be read three days in a row, tell the owner once. If its layout changes so no entry can be found, say so once and stop.

Check

• Put two products on the list with different layouts (one with version numbers, one with dates) and a saved value two releases back for one; run once with sending off and confirm the summary and the Affects you line
• Run again with the real saved values and confirm it says nothing

In my version

• A shell script on a daily schedule, 8am Pacific, summary by claude -p, push to my phone; my list holds several products

Ask first

• Which accounts may it read? (default your calendar, mail and texts)
• What counts as an outside meeting? (default timed, not declined, not a family or holiday entry, with an outside person or a video link)
• When should the two cards arrive? (default Sunday evening and Monday morning)
• Where should they land? (default a page you open daily; an email to you if none)
• Do you keep a task list and a fitness app? (default no; those sections are left out)
• How long is "gone quiet"? (default 90 days)

Needs

• Calendar for the week just ended and the week ahead.
• Mail and texts for the same weeks, to find meetings agreed but never booked. Connecting: "It reads for dates people agreed on; it never writes to anyone."
• Optional: a task list for overdue items, a fitness app for training load.
• A page that holds cards, keyed by week, and an archive with one row per week.
• If your assistant can only chat: paste next week's calendar and ask for clashes; paste last week's and ask for the counts.

Build

1. Read (Monday): the week just ended. Count outside meetings (the test above), people spoken to for the first time, messages sent per channel, and overdue tasks, each beside the figure for the week before.
2. Decide (Monday): add people who warmed and who went quiet for 90 days or more, work built, training load if available, and open loops split into owed by the person and owed to them. One sentence on the shape of the week, such as which days were heaviest.
3. Read (Sunday): the week ahead from the calendar, plus mail and texts from the last 30 days.
4. Decide (Sunday): overlaps; back-to-back runs with no travel gap; meetings agreed in mail or texts that are not in the calendar. Keep: "Thursday 3pm works, see you then" with no event. Drop: "let's find a time soon". Quote the sentence the date was read from.
5. Deliver: one card per week, keyed by the week's Monday, so a rebuild replaces the card and never brings back an item already ticked off. Fallback: an email to the person only. Nothing goes to anyone else.
6. Memory: the archive page, one row per week, and the ticked items. Two model calls a week.

Check

• Rebuild a past week with delivery off and compare the counts with your own calendar; each not-booked item quotes the message it came from.
• Run it twice: one card per week.
• Quiet run: a week with no clashes and nothing unbooked gives a Sunday card that says so; the Monday card always has counts.

In my version

• Q, my assistant, Sunday 8pm and Monday 6am Pacific, reading Google Calendar, Gmail and iMessage, with Asana for overdue tasks and Mettle, my training app, for load. Cards on Q's home screen; archive page one row per week. The Sunday card gives one line per day and the shape of the week.

Ask first

• Where are your server logs? (a hosting dashboard, a log export)
• Which crawlers count? (default the main AI assistants' crawlers, found by name in the logs)
• What is a new page? (default anything added to the sitemap in the last 6 weeks)

Needs

• Read access to the logs or a weekly export you paste in
• The list of pages and their go-live dates
• The AI answer tracker's log, or a short list of questions to ask
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each day, find pages that went live exactly 3 days, 14 days or 42 days ago. At 3 days check for a visit from the AI crawlers' names in the logs and record yes or no and the first date.
2. At 14 days check the answer tracker's log for any answer that cites the page. At 42 days check whether it appeared in an answer buyers saw: count it as seen if the page was cited in an answer to one of the frozen buyer questions in the AI answer tracker that week. The 14-day check asks whether any assistant ever cited the page; the 42-day check asks whether it is still being cited in answers to buyer questions, or, if you have no tracker, in an answer to three questions you ask each assistant about the page's topic. Record yes or no and the assistant.
3. For a page with no crawler visit after three days, check the likely reasons: not in the sitemap, blocked in the crawler rules file, behind a login prompt, or very slow.
4. Report the three steps for each page and suggest one fix for each stuck page. Pass stuck pages to the refresh run as candidates. Change nothing without a yes.

Check

• Run it on a page that went live a month ago; the steps match what the logs show
• Confirm a page blocked in the crawler rules file is named as blocked
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a daily 7am schedule, checking only the pages at their 3, 14 and 42 day marks, a table in my docs and a message when a page is stuck

Ask first

• Which metrics do you own? (default the five you look at most)
• What counts as unusual? (default beyond 15% of the four-week average)
• Where do the numbers live and what changed log should it read? (a sheet, an analytics tool; a launch or campaign calendar)

Needs

• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file
• Read access to the numbers, and a record of what shipped or ran each day
• If your assistant cannot read one of these, paste it into the chat when it asks. A thinner version still works

Build

1. Each Monday, pull the last week and the four-week average for each metric.
2. Flag any beyond the limit. For each, look at what else changed that week and name the most likely cause, marking it a guess.
3. If you keep a test log: after naming a likely cause for a flagged metric, hand it to the test-log run as a new entry with a failure line. This fires only on a metric beyond the limit, never on a quiet week.
4. End with one thing to check. If nothing moved, say so in one line.

Check

• Run it on a past week where you know why a number moved; the likely cause matches
• Confirm a guess is labelled as a guess
• Say whether the writing step ran for real or on sample text. Check that every quote and link on the page matches its source, and drop any that does not

In my version

• Claude Code on a Monday schedule, a note in my docs and a message

Ask first

• Which sources may it read? (default calendar, notes and your own sent messages)
• What should it avoid? (default anything about named customers, money or people who have not agreed)
• Where should the ideas arrive? (default a private message on Sunday evening)

Needs

• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file
• Read access to the sources and a record of what you posted before, so it does not repeat
• If your assistant cannot read one of these, paste it into the chat when it asks. A thinner version still works

Build

1. Each Sunday, read the week's calendar, notes and sent messages.
2. Find three moments that taught or surprised you. Skip anything private. If you have a customer-voice run, add one idea that answers a confusion or complaint it found this week.
3. For each, write a one-line hook and one line on why it is worth posting.
4. Never post. On a reply with a number, draft that one for you to edit.

Check

• Run it on last week; every idea points to something real in your notes
• Confirm no idea names a customer or a figure you marked private
• Say whether the writing step ran for real or on sample text. Check that every quote and link on the page matches its source, and drop any that does not

In my version

• Claude Code on a Sunday schedule, ideas sent as a private message

Ask first

• Which competitors, and which pages for each? (release notes, pricing, blog; a few each)
• What counts as worth telling you? (default anything on pricing, a new feature that overlaps yours, or a new customer named)
• Where should it land? (default a message and a page in your notes)

Needs

• An assistant that can run weekly, read web pages and keep a small store of what it has already shown you
• For a page that loads with JavaScript: a browser you are signed in to, read as text
• If your assistant cannot read one of these, paste it into the chat when it asks. A thinner version still works

Build

1. Each week, read each listed page and compare to the stored copy.
2. For every difference, write one line: who, what changed, why it matters to you, and the link.
3. Keep an item only if the link points to a page you actually opened. Store each item so it is never shown twice. If you run a content calendar, pass any pricing or feature change to it so a rival's move gets a response the following week.
4. If nothing changed, send nothing. If a page could not be read, say which one.

Check

• Run it once with the saved copy set a month back; every line has a competitor, a date and a link
• Run it again; confirm it says nothing
• Say whether the writing step ran for real or on sample text. Check that every quote and link on the page matches its source, and drop any that does not

In my version

• Claude Code on a Monday schedule, results as a message and a page in my notes

Ask first

• Which companies or products should it listen for? Give a name and, if the name is a common word, a few phrases that show a post is about them and a few that mean something else. (Several is fine.)
• Which sites for each? (default Hacker News, plus Reddit if the company has a community there, plus any review pages you name)
• Where should it reach you? (default a message from your assistant, only when something is new)

Needs

• A list file with one block per company. Adding a company is adding a block; removing one is deleting it. A broken file must be reported, never replaced by a default
• An assistant that can run on a schedule and keep a small store of what it has already shown you
• For sites with no open API: a browser you are signed in to, read as text. If a page shows a login wall or a challenge, stop and say so. Never work around one

Build

1. Each week, for every company on the list, fetch what is new from each of its sites. Hacker News has an open search API. Reddit is slow and gives little, so keep its queries few.
2. Keep only text that is about the right company. Drop job ads and other meanings of the name.
3. Store each item once with its link and date. Never report one twice.
4. Sort each into confusion, complaint, praise, comparison, price or news, with one plain sentence in your own words. The link comes from the page, never from the model.
5. If nothing is new, send nothing. If a site could not be read, say which one and try again later the same day, so a closed browser delays the report and does not lose it.

Check

• Run it once now over a past week with sending off; every line has a company, a site, a date and a link
• Add a second, unrelated company and confirm its posts are kept apart and the first company is not mixed in
• A quiet week sends no message

In my version

• Claude Code on a schedule: every hour on Mondays from 7:30am Pacific until the sources read, G2 and Glassdoor read in my own browser, results to a card and a text

Ask first

• What do buyers ask before they choose a product like yours? (default write 20 to 30 questions from your sales calls and search terms, then freeze the list for at least four weeks)
• Which assistants should it ask? (default the main three or four)
• What do you want to know each week? (default are we named, who else is named, what is said about us, which pages are cited)

Needs

• A way to put a question to each assistant and read the answer, by their own tools or by pasting answers in each week
• A log with one row per question per assistant per week: the question, the assistant, the date, the answer, the pages it cited and the brands it named
• The frozen question list. When you refresh it (at most every quarter), add questions drawn from the confusions your customer-voice run has found, so the tracker asks what buyers actually stumble on
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each Monday, ask every question in the list to every assistant, exactly as written. Never reword a frozen question.
2. Log each answer with the date, the assistant, the brands named in order and every page cited.
3. Compare with the last four weeks: how often we are named, our position among named brands, which pages are cited, and any statement about us that is wrong.
4. Report movement as a change against the previous weeks, not as a single score. Answers vary from run to run, so run each question twice and count a change only if both runs agree.
5. List every wrong statement with the page the assistant drew it from, and pass each to the refresh run as a candidate for a draft fix. Never edit a page without a yes.

Check

• Run it once now on five questions; every row has a date, an assistant and a list of cited pages
• Run one question twice; say how often the two answers differ, so you know how much movement to trust
• Confirm no frozen question was changed
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Monday schedule, answers pasted from each assistant when it cannot ask them itself, a page in my docs and a message

Ask first

• Which plans and which questions? (default one question per plan: "how much does X cost", plus "does X have a free plan")
• Which assistants? (default the main three or four)
• Where is the true price? (default your live price page)

Needs

• A way to put each question to each assistant and read the answer, or paste the answers in each week
• Your live price page, read fresh each week
• A log: plan, assistant, date, quoted price, cited page
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each Monday, ask each pricing question to each assistant, worded the same way every week.
2. Read your live price page and write down the true figure for each plan.
3. Compare every quoted figure with the true one. Mark each correct, wrong or out of date.
4. For each wrong or out-of-date figure, name the page the assistant cited, say whether it is yours or someone else's, and pass each of your own wrong pages to the refresh run so a misquoted price gets a draft fix within the month.
5. Send a message only if a figure is wrong. Never edit a page without a yes.

Check

• Run it once now; every quote has the assistant, the date and the page it cited
• Ask one question twice; say how often the answers differ, so you know how much to trust one run
• Confirm a correct figure is not flagged
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Monday schedule, a table in my docs and a message when a price is wrong

Ask first

• Which rivals? (default the ones named most often in the answer log)
• How many pages to draft each month? (default three)
• What may the drafts claim? (default only things on our own pages and published changelog)

Needs

• The AI answer tracker's log with the pages each answer cited
• Read access to the pages cited, and to our own pages for the facts
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each month, read the answer log and count how often each page was cited in answers that compare us with a rival.
2. Open the three or four most cited. Write what each says about us and mark every statement right, wrong or out of date against our own pages.
3. For the three that matter most, draft our own page answering the same question, using only facts on our pages. Mark any claim with no source as missing.
4. Send a short message with the single most-cited wrong statement. Send the drafts to the content calendar run and any wrong statement to the refresh run. Never publish.

Check

• Run it on last month's log; every cited page it lists appears in the log
• Confirm each draft claim is a fact on our own pages
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code monthly, a list and drafts in my docs

Ask first

• Where are your analytics and rankings?
• How big a drop counts? (default 20% over six months)
• Which pieces matter? (default the ten that bring the most traffic)

Needs

• Read access to analytics and rankings, or a monthly export you paste in
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. On the first of the month, compare each piece's traffic and position with six months ago.
2. List pieces that dropped past the limit, plus any page the AI answer tracker or the page funnel flagged as wrong or stuck.
3. For each of the three largest drops, find what changed: old figures, dead links, outdated claims, and what a competitor now covers. A competitor covers a topic when a page's main heading or its first 100 words are about it.
4. Draft the smallest update that fixes it. Send a short message with the biggest drop and its cause. Never publish.

Check

• Run it on last month; the biggest drop is a piece you suspected
• Confirm each dead link is really dead
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on the first of each month, a list and drafts in my docs

Ask first

• Which events count? (default any you list with a date and attendees)
• What is the result you care about? (default a stage moved, or usage up, within 8 weeks)
• How should comparison accounts be chosen? (default the same size and stage that did not attend)

Needs

• The attendee list and the account data, or a pasted export
• A list of events with dates
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Two and eight weeks after each event, take the attendees.
2. Pick a comparison group of the same size from accounts of similar size and stage that did not attend.
3. Count how many in each group moved a stage or grew usage over the same weeks.
4. Report both rates, the gap and both group sizes. If either group is under 30, say the result is too small to read.
5. Say what else changed in that window that could explain it. Send the suggested next step, such as a waitlist, to the test log so it gets a saved pass line before it runs.

Check

• Run it on a past event; the group sizes and rates match your data
• Confirm a result from fewer than 30 per group is labelled too small to read
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code twice per event, a note in my docs

Ask first

• Which campaigns and tools? (ads, email, social)
• What are your targets? (cost per result per campaign)
• Who sees the report? (default just you)

Needs

• Read access to your ad and email tools, or a pasted export
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each Monday, pull last week's spend and results for each campaign.
2. Work out cost per result and compare to its target.
3. Mark anything beyond 25% of target.
4. End with one change. Put that one change at the top of the weekly numbers message, so Monday brings one message to act on, and keep the full report on a page in your docs. If numbers are missing, say so and do not estimate.

Check

• Run it on last week; every figure matches the tool
• Confirm a missed target is flagged
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Monday schedule, a page in my docs

Ask first

• Where is your launch list? (a calendar, a task tool, a spreadsheet)
• Which channels? (email, social, blog)
• How many a week? (default five)

Needs

• Read access to the launch list and what you published
• A place to save the plan
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Each Friday, list launches and stories for next week.
2. Skip anything published in the last two weeks.
3. Place each on a day and channel with a draft headline. Use the latest content gap, the winning line from the last test readout, any confusion points from the customer voice run, and any page the page-funnel run found stuck, so each week answers something customers asked. If those runs are not set up, plan from your launch list alone.
4. Say what is missing from the plan. A gap is a theme with no published piece for two weeks, such as pricing, a launch or a customer story. Fill gaps first, then the launches.

Check

• Run it on last Friday; every item ties to a real launch or story
• Confirm nothing repeats a recent post
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a Friday schedule, a page in my docs

Ask first

• Which competitors? (three to five)
• Which parts of their site? (blog, help centre, guides)

Needs

• An assistant that can read web pages and keep a list of what it has seen
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Read the index of each competitor's blog and help pages and mine.
2. List topics each covers, then topics covered by others and not by me.
3. Rank gaps by how many rivals cover them, then by how much they overlap the frozen buyer questions from the AI answer tracker, if you have it. Show the top three. Link the pages.
4. Never claim a rival lacks a topic it did not check. Send the top gap as a short message and pass it to the content calendar run. Run on the first Monday of each month. A topic counts as covered when a page's main heading or its first 100 words are about it. Read at most 50 pages per competitor site, and skip any site that cannot be read, saying which.

Check

• Run it; every gap links to the rival page
• Confirm a topic you cover is not listed as a gap
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code on a monthly schedule, a page in my docs

Ask first

• Where do your posts and results live?
• How far back? (default 90 days)
• What must never appear? (default customer names and figures you marked private)

Needs

• Read access to your past posts with views or reactions, or a pasted export
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Collect the last 90 days of posts with their results.
2. Pick the best by results relative to your average. Name the pattern: opening, length, one number or none, call to action or not.
3. Check the pattern against your worst three, to be sure it is the pattern and not the topic.
4. Draft the next post in that shape on a topic from this week: the idea you picked from the post-ideas run, or, if you have none, ask which topic to use, with a default of this week's biggest launch. Say what to change. Never post. Pass the draft to the pre-publish edit run.

Check

• Run it on a past quarter; the best post is the one you would pick
• Confirm the pattern names something the worst posts lacked
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code every other Monday, a draft in my docs

Ask first

• Which calls are for a story? (default any you mark, or any call where the customer praised a result)
• What must never be used? (default budgets, names of people who have not agreed, and anything said off the record)

Needs

• Read access to your notes or a written-up recording of the call
• If your assistant cannot read one of these, paste it when it asks. A thinner version still works
• Any password or token is entered by you into your device's secure store, never pasted into a chat or saved in a plain file

Build

1. Read the call notes. Find the problem, what changed and the result, in the customer's own words, with the exact quote.
2. Write the story using their phrases, not ours. If your notes do not have a customer's exact words, mark that line as paraphrase and never present it as a quote.
3. List every quote, figure and name that needs their approval, and leave out anything said off the record.
4. Leave the draft in your docs. Never send it to the customer.

Check

• Run it on a call you remember; every quote appears in the notes word for word
• Confirm nothing from off the record is in it
• Say whether the writing step ran for real or on sample text. Check that every figure, quote and link matches its source, and drop any that does not

In my version

• Claude Code after each marked call, a draft in my docs