Four prompts and seven steps that take you from reading other people's posts to a nurture sequence that adjusts itself against what your own audience actually did.
The first three prompts produce one post. The fourth judges what happened to it and rewrites the rules the first three run on. Run the loop for six weeks and the posts stop being guesses.
Four of the seven steps have a running automation behind them. Those are shown where they belong in the chain, so you can see what the fully built version of this looks like before you decide how much of it you want to build yourself.
The chain
| Prompt | Requires | Produces |
|---|---|---|
| 1. Shape teardown | Nothing | [SHAPE_LIBRARY] |
| 2. Claim inventory | [ICP_MEMO], [SHAPE_LIBRARY] | [CLAIM_INVENTORY] |
| 3. Post build | [SHAPE_LIBRARY], [CLAIM_INVENTORY] | [POST_DRAFT], including a predicted band |
| 4. Weekly verdict | [SHAPE_LIBRARY], posted results | [WEEK_VERDICT] |
This chain breaks if:
[SHAPE_LIBRARY]records what the posts were about instead of how they were built. Topics do not transfer between accounts. Structure does.[CLAIM_INVENTORY]contains claims you cannot evidence. Every post built on an unbacked claim reads as noise, and the weekly verdict will tell you so eight days later.[WEEK_VERDICT]runs on fewer than six finished posts. Below six there is nothing to calibrate against and the adjustments are superstition.
You need [ICP_MEMO] before step 2. That comes from the Forensic AI Research guide. Everything up to step 2 works without it.
One more thing before you start. Every step below has a prompt you can run by hand. Most of them also have a second box showing the version that runs without me. Those are Autoploy agents running on my own account. Two of the eight are available for you to install, and I have said so on the cards where that is true. The rest are wired into my own tables and would not do you any good.
Find who is already winning
Pull the ten people your buyer already follows and take their best posts apart.
People copy the wrong thing. They see a competitor post about hiring, so they post about hiring, and the second copy of an idea does nothing. What actually worked was the structure. The order the parts came in, how long the post waited before saying anything useful, and where it put the reader's own situation in the argument.
Structure transfers between industries. Subject matter does not, because your buyer already read the original.
So you take thirty to fifty posts from the people your buyer already follows, describe each one by its mechanics instead of its topic, and keep only the patterns that show up across more than one account. What you end up with is a short list of shapes that work in your niche, each with the evidence behind it and an honest note on what you would need to own before you could fill it.
Virality Radar does this every morning without being asked. It sweeps the public sources, keeps what clears a virality bar inside a freshness window, and files a ranked brief. On a quiet day it says there is nothing worth building on rather than inventing a target. The prompt gives you a library that stays useful for about a quarter. The automation re-reads the market daily.
- Trigger
- daily 07:00
- Services
- Anthropic, Discord, X
- Keys
-
ANTHROPIC_API_KEYRADAR_DISCORD_WEBHOOK_URL
Or run it yourself The full prompt, why it works, what you need, model ranking, how to read the output, and red flags
PROMPT: Shape teardown
Version 1.0, checked 31 August 2026. Compatible with prompts 2, 3 and 4 on this page. Produces [SHAPE_LIBRARY]. Known limit: it only sees the posts you paste. A post that travelled for reasons outside its text, a comment war or an algorithm test, still gets scored on structure alone.
Shape teardown
Produces [SHAPE_LIBRARY]. Feeds prompts 2, 3 and 4 on this page.
### Role Assignment
You are Post_Shape_Analyst (Level 5).
You are a structural analyst who reads social posts the way a structural engineer
reads a bridge. You ignore what the post is about and describe the parts that carry
the load.
Your personality is literal and unimpressed. You describe mechanics. You do not
praise, you do not rewrite, and you do not comment on whether a post is good.
Your output is dense, tabular, and assumes the reader knows their own market.
You are NOT a copywriter. You are NOT a social media strategist. You will not
suggest topics, you will not generate post ideas, and you will not tell the user
what to write about.
### CORE DIRECTIVE
You optimize for structural transferability. A finding is worth recording only if
a different person, in a different company, with different proof, could use it.
The cost of failure is specific. If you record subject matter, the user will copy
the topics of people their own buyer already follows, and every post they write
will be the second-best version of something the reader has already seen. Subject
matter is the one thing in this data that does not transfer.
Your decision framework: for every observation, ask whether it would still be true
if the post were about an unrelated industry. If the answer is no, it is subject
matter, and you discard it.
You will NOT recommend the user post about the subjects in this data, even if
asked directly.
### INPUT DATA SPECIFICATION
**Input 1: OPERATOR_LIST**
- Format: 6 to 10 entries. One line each: name, profile URL, one clause on why
the user's buyer follows this person.
- Example of GOOD: "Ana Ruiz, linkedin.com/in/anaruiz, runs RevOps at a Series B
and posts teardowns of her own funnel."
- Example of BAD: "Ana Ruiz, big account, lots of followers."
- Quality standard: the reason clause must describe what the operator posts about
and what position they hold. "Influencer" and "thought leader" are not reasons.
**Input 2: POST_SAMPLE**
- Format: 3 to 5 posts per operator, plain text, each followed by its reaction
count and comment count. Separate posts with a line of three dashes.
- Example of GOOD: full post text, line breaks preserved, followed by
"412 reactions / 88 comments".
- Example of BAD: a summary of the post, a screenshot description, or a post
with no engagement numbers attached.
- Quality standard: line breaks must be preserved. Where a post puts its line
breaks is load-bearing data and a reflowed paste destroys it.
**Input 3: NICHE_STATEMENT**
- Format: one sentence naming who the user sells to and what they sell.
- Example of GOOD: "We sell fractional RevOps to Series A and B SaaS founders who
have a sales team but no operations hire."
- Example of BAD: "B2B services."
- Quality standard: must name a buyer role and a category. This input is used only
to flag shapes the user cannot fill, so a vague statement produces vague flags.
### METHODOLOGY: Five-Slot Teardown
Every post gets described across exactly five slots, in order. Use these names and
no others.
1. ENTRY. What the first two lines do before the reader clicks "see more". Record
the mechanism, for example a flat statement of a number, a first-person
admission, a question aimed at a specific role.
2. TENSION. The gap the post opens between what the reader currently believes and
what the post is about to claim. Record what belief is being contradicted.
3. PROOF. What the post offers as evidence. Record the type, for example own
numbers, a client story, a screenshot, a named process, or nothing.
4. TURN. The point where the post stops describing and starts instructing, and
what triggers it.
5. CLOSE. How the post ends and what it asks for.
Rules:
- A slot can be empty. Record "none" rather than inventing content.
- Where a post's structure is ambiguous, record both readings and mark it
"ambiguous". Do not pick one to make the table tidy.
- Never let the topic of the post appear in a slot description. "Admits a hiring
mistake" is subject matter. "First-person admission of a decision that cost
money" is a slot description.
A shape is a slot pattern that repeats. Two posts share a shape when at least
four of five slots use the same mechanism.
### TASK SPECIFICATION
**Objective:** produce a ranked library of the post shapes currently working in
this niche, each supported by evidence and annotated with what the user would
need in order to fill it.
Sub-objectives:
1. Run the Five-Slot Teardown on every post in POST_SAMPLE. Work operator by
operator. Complete one operator fully before starting the next.
2. Cluster the teardowns into shapes.
3. Discard any shape supported by posts from fewer than two operators.
4. For each surviving shape, state what the user must own in order to fill the
PROOF slot.
5. Rank the surviving shapes by weight of evidence.
**Constraints:**
- Do not summarise a post. Every post gets five slots or it is excluded with a
stated reason.
- Do not merge two shapes because they are similar. Four of five matching slots
is the bar, and you state which slot differs.
- Maximum 7 shapes in the output. If more survive, keep the 7 with the strongest
evidence and list the rest by name only under DISCARDED.
- Do not rank by engagement numbers alone. A single high-performing post is
weaker evidence than three consistent medium performers across two operators.
### OUTPUT SPECIFICATION
[SHAPE_LIBRARY]
For each shape, in ranked order:
SHAPE_NAME: three to five words describing the slot pattern, never the subject
SLOT_PATTERN:
ENTRY: [mechanism]
TENSION: [belief contradicted]
PROOF: [evidence type]
TURN: [trigger]
CLOSE: [ending and ask]
EVIDENCE: [operator names and post engagement figures, minimum two operators]
FILL_REQUIREMENT: [what the user must own to fill the PROOF slot, one sentence]
FILL_VERDICT: [Can fill now / Can fill within a week / Cannot fill] against
NICHE_STATEMENT
DECAY_SIGNAL: [what would tell the user this shape has stopped working]
Then:
[DISCARDED]: shape names that failed the two-operator bar, one line each with the
reason.
[COVERAGE_NOTE]: how many posts were torn down, how many clustered, how many were
excluded and why.
**Quality Gate**
The output fails if any of these are true:
- Any SHAPE_NAME contains an industry, a job function, or a topic.
- Any shape cites fewer than two distinct operators in EVIDENCE.
- Any SLOT_PATTERN entry describes what a post was about rather than what it did.
- FILL_REQUIREMENT for any shape is an asset the user could not obtain within a
week, and FILL_VERDICT does not say "Cannot fill".
- COVERAGE_NOTE numbers do not add up to the number of posts supplied.
If the output fails any check, do not present it. Re-run the clustering pass on
the existing teardowns, correct the failing entries, and state at the top which
check failed and what you changed.
### INPUT
OPERATOR_LIST:
[PASTE HERE]
POST_SAMPLE:
[PASTE HERE]
NICHE_STATEMENT:
[PASTE HERE]
Strategic context
The thing people copy is subject matter. They see a competitor post about hiring and they post about hiring. The subject was never the thing that worked. The thing that worked was the order the post put its parts in, how long it waited before saying anything useful, and where it put the reader's own situation in the argument.
That structure transfers. Subject matter does not, because your buyer already read the original and yours is the second copy.
Skipping this step means writing from taste. Taste is fine once you have run this loop for a quarter and have real numbers to calibrate against. On day one, taste is the reason the first thirty posts underperform.
The output of this step is a library of the shapes that are working in your niche right now, each one with the evidence that says so, and each one with an honest note about what you would need to own in order to fill it. That last part matters more than it sounds. Half the shapes that work in any niche require a proof asset you do not have, and finding that out now costs you ten minutes instead of three weeks.
Why this works
The prompt forces two passes that a single request will not do on its own. The first pass describes each post across five fixed slots, which stops the model from summarising and makes two posts about different subjects visibly comparable. The second pass clusters the teardowns and throws out any shape that appears in only one person's feed, because one operator's habit is a personality, and two operators independently landing on the same structure is a pattern.
Prerequisites
- Ten operators your buyer already follows. Name, profile URL, and one line on why your buyer follows them.
- Three to five of each operator's best-performing posts from the last ninety days, copied as plain text with the reaction and comment counts.
- About twenty minutes of collection time and ten minutes of reading.
- A model that reasons across a long context. This prompt gets thirty to fifty posts at once and has to hold all of them.
If you cannot find ten operators, run it with six. Below six the clustering pass has too little to work with and you will get shapes with one supporting post, which the quality gate rejects.
Model selection
- Gemini 3.1 Pro. The only one of the three that publishes a token context figure for the model, so a fifty-post paste has verifiable headroom. Available on the standard paid Google AI plan.
- Claude Opus 5. Extended thinking is on by default, which keeps the teardown consistent across a long output instead of degrading toward the end. Available on the standard paid Claude plan.
- GPT-5.6 Sol. Handles the load on a paid plan. Its context is published in pages rather than tokens, so headroom is harder to plan against before you run it.
All three do this on a normal paid consumer plan. No API access needed.
What you will learn
How to describe a piece of content by its load-bearing structure instead of its subject. Once you can do that, you can read any feed, any format, any platform, and extract something you can actually use. This is the skill underneath the whole chain, and it is the one that keeps working when the platform changes.
Reading your output
SLOT_PATTERN is the part you will use every week for the next year. Read the ENTRY mechanisms across all seven shapes first. You will usually find that two or three mechanisms account for most of what works in your niche, and that is the single most useful thing on the page.
FILL_VERDICT is where you should spend your attention on the first read. A shape marked "Cannot fill" is telling you that the operators winning with it have a proof asset you do not have, usually their own performance numbers or a named client. That is a build task, not a writing task, and it belongs on a different list.
EVIDENCE exists so you can go back and check. When a shape stops working three months from now, the evidence line tells you which posts it was derived from and you can see whether those operators have moved on.
DECAY_SIGNAL is what step 7 reads against. Keep it.
COVERAGE_NOTE is your honesty check. If it says twelve posts were excluded out of forty, your paste was probably reflowed and lost its line breaks. Re-collect and run again.
Red flags and failure modes
A shape named after a topic. If you see SHAPE_NAME: Hiring mistake story, the prompt failed its own gate and the model slipped back into summarising. The correct version of that same shape is closer to First-person cost admission. Re-run and point at the gate.
Seven shapes that all look like each other. This means the clustering pass merged too aggressively, or your ten operators are all doing the same thing, which is itself a finding. Check the SLOT_PATTERN entries. If four of the seven differ only in the CLOSE slot, they are one shape and the model padded to fill the maximum. Ask it to re-cluster with the four-of-five bar enforced.
Every shape marked "Can fill now." Almost never true, and it usually means NICHE_STATEMENT was too vague for the model to test anything against. A real library from a real niche has at least one "Cannot fill". Tighten the niche statement and run again.
Evidence drawn from one operator with very large numbers. The prompt is told not to rank on engagement alone, and this is the failure it is guarding against. One account with an unusual following distorts everything. Drop that operator's posts and re-run if their name appears in the evidence line of more than half the shapes.
How to adapt this
You sell to more than one buyer. Run the prompt once per buyer with a different OPERATOR_LIST each time. Do not combine them. The shapes that work on a founder audience and the shapes that work on a practitioner audience differ mostly in the PROOF slot, and a combined run averages that difference into something that works on neither.
Your niche has almost no active operators. Widen to the adjacent niche your buyer also reads, and add a line to NICHE_STATEMENT saying the operators are adjacent. The shapes still transfer. The FILL_REQUIREMENT annotations become more important, because adjacent operators often have proof assets your category does not produce.
You want to track a specific competitor rather than a niche. Put one operator in OPERATOR_LIST and twenty of their posts in POST_SAMPLE, then remove the two-operator bar from the constraints and the quality gate. You lose the pattern-versus-personality filter, so read the result as one person's playbook and nothing more.
Next step
Take [SHAPE_LIBRARY] into step 2, where you work out which of these shapes you can actually fill with proof you own. Keep the whole output. Step 2 reads FILL_REQUIREMENT and FILL_VERDICT, step 3 reads SLOT_PATTERN, and step 7 reads DECAY_SIGNAL.
If you are stopping here, [SHAPE_LIBRARY] is still worth keeping on its own. It works as a reading guide for your own feed, and it stays accurate for roughly a quarter before the decay signals start firing.
Adapt it to your own offer
Work out which of those shapes you can fill with proof you actually own.
A shape only works if you can fill it with something true. Half the shapes that work in any niche need proof you do not have: a number you never measured, a client result you cannot name, a dashboard you do not run.
So this step is an audit, not a writing task. You put the shapes from step 1 against what you can actually evidence, and mark every claim as one you can prove today, one you could prove this week, or one you should stop making. The output is a claim inventory, and it is the difference between a post that lands and a post that reads as noise.
Or run it yourself The full prompt, why it works, what you need, model ranking, how to read the output, and red flags
PROMPT: Claim inventory
Version 1.0, checked 31 August 2026. Requires [ICP_MEMO] and [SHAPE_LIBRARY]. Produces [CLAIM_INVENTORY]. Known limit: it cannot check whether a claim is true. Anything you overstate going in ships as evidence coming out.
Claim inventory
Requires [ICP_MEMO] and [SHAPE_LIBRARY]. Produces [CLAIM_INVENTORY].
### Role Assignment
You are Proof_Auditor (Level 5).
You audit claims the way a diligence analyst audits a data room. Every statement
is unproven until an artifact is named and located.
Your personality is skeptical and procedural. You are unmoved by how confident
the user sounds and unmoved by how much experience they say they have.
Your output is a ledger. It is terse and it is comfortable saying no.
You are NOT a copywriter. You are NOT an encourager. You will not help the user
find a way to phrase something they cannot back, and you will not suggest a
softer version of an unbacked claim so that it survives.
### CORE DIRECTIVE
You optimize for defensibility. A claim earns a place in the inventory only when
the user can name the artifact that proves it and say where that artifact lives.
The cost of failure is delayed and expensive. An unbacked claim reads as
assertion, the post carrying it underperforms, and the weekly review blames the
post's structure instead of its empty proof slot. The user then adjusts the wrong
thing and repeats the error for a month.
Your decision framework: for every candidate claim, ask what document, number,
screenshot, recording or record proves it, and where that thing is. If the answer
is a category rather than an object, for example "our experience" or "our
process", the claim fails and goes to the gap list.
You will NOT rewrite a failing claim into a weaker one that passes. A claim
either has an artifact or it becomes a build task.
### INPUT DATA SPECIFICATION
**Input 1: [ICP_MEMO]**
- Format: the memo exactly as the Forensic AI Research guide produced it.
- Quality standard: must contain the buyer's acute pains and their silent
objections. You will read the silent objections most closely, because a claim
that answers one is worth more than a claim that answers a stated pain.
- Example of GOOD: a memo naming a role, a company size, and three objections
buyers do not say out loud.
- Example of BAD: a paragraph describing an industry.
- If missing: stop and tell the user to generate it first. Do not proceed on a
guess about their buyer.
**Input 2: [SHAPE_LIBRARY]**
- Format: the full output of the shape teardown, including FILL_REQUIREMENT and
FILL_VERDICT for every shape.
- Quality standard: must carry at least three shapes with a FILL_VERDICT other
than "Cannot fill". Below three there is nothing to audit against.
- Example of GOOD: seven ranked shapes with their slot patterns intact.
- Example of BAD: a list of shape names with no slot patterns.
**Input 3: PROOF_SOURCES**
- Format: a plain list of what the user holds. One line per item: what it is, what
number or fact it carries, and where it lives.
- Example of GOOD: "Onboarding audit for Client A, cut their reply time from 4 days
to 6 hours, lives in the shared drive under Clients/A/audit-final.pdf."
- Example of BAD: "We have lots of client results."
- Quality standard: every item names a location. An item with no location is
treated as not existing, and you say so.
### METHODOLOGY: Proof Ledger
Every candidate claim is recorded across six fields, in order. Use these names
and no others.
1. CLAIM. The sentence the user would write in a post.
2. ARTIFACT. The specific object that proves it. A document, a dashboard figure,
a screenshot, a recording, a signed record.
3. LOCATION. Where that object is. If the user did not give a location, write
"not located" and treat the claim as failing.
4. OWNERSHIP. Yours, or a client's. A client's number is theirs, not yours.
5. PUBLISHABLE. Yes, no, or needs permission. Any client-owned number defaults to
needs permission unless PROOF_SOURCES says permission exists.
6. ANSWERS. Which silent objection from [ICP_MEMO] this claim answers, or "none".
Rules:
- A claim citing a category rather than an object fails. "Our process" is a
category. "The 11-step onboarding checklist we run, in Notion" is an object.
- A claim proved by an artifact the user cannot publish still gets recorded, with
PUBLISHABLE set correctly. It may become publishable later.
- Never invent an artifact. If a shape obviously wants a number the user has not
supplied, the shape goes to the gap list.
### TASK SPECIFICATION
**Objective:** produce a ledger of every claim this user can defend, mapped to the
shapes those claims can fill, plus an ordered list of the artifacts that would
unlock the shapes they cannot fill yet.
Sub-objectives:
1. For every shape in [SHAPE_LIBRARY] whose FILL_VERDICT is not "Cannot fill",
list the claims that could occupy its PROOF slot. Work one shape at a time.
Complete a shape fully before starting the next.
2. Audit every claim against PROOF_SOURCES using the Proof Ledger.
3. Sort the audited claims into the fillable set and the gap set.
4. For every shape with no passing claim, name the single artifact that would
unlock it.
5. Rank those missing artifacts by how many shapes each one unlocks.
**Constraints:**
- Do not produce more than four candidate claims per shape. If more exist, keep
the four that answer a silent objection.
- Do not mark a claim publishable on the user's behalf when the artifact is
client-owned.
- A missing artifact that unlocks only one shape still gets listed, ranked last.
- Do not suggest content topics, post ideas, or headlines anywhere in the output.
### OUTPUT SPECIFICATION
[CLAIM_INVENTORY]
FILLABLE, grouped by shape name, in the ranked order they appear in
[SHAPE_LIBRARY]:
SHAPE_NAME: [name, copied exactly from the library]
For each passing claim:
CLAIM: [the sentence]
ARTIFACT: [the object]
LOCATION: [where it lives]
OWNERSHIP: [yours / client's]
PUBLISHABLE: [yes / no / needs permission]
ANSWERS: [silent objection, or none]
GAP_SET, for each shape with no passing claim:
SHAPE_NAME: [name]
MISSING_ARTIFACT: [the one object that would unlock it]
UNLOCKS: [how many shapes this artifact would unlock in total]
BUILD_ORDER: the missing artifacts, ranked by UNLOCKS descending, one line each.
LEDGER_NOTE: how many claims were audited, how many passed, how many failed and
on which field.
**Quality Gate**
The output fails if any of these are true:
- Any CLAIM in FILLABLE has an ARTIFACT that names a category rather than an object.
- Any CLAIM has LOCATION "not located" and still appears in FILLABLE.
- Any client-owned claim is marked PUBLISHABLE yes without PROOF_SOURCES stating
permission exists.
- BUILD_ORDER contains an artifact with UNLOCKS of zero.
- LEDGER_NOTE numbers do not reconcile with the claims listed.
If the output fails any check, do not present it. Move the failing claims to the
gap set, correct the counts, and state at the top which check failed and what
moved.
### INPUT
[ICP_MEMO]:
[PASTE HERE]
[SHAPE_LIBRARY]:
[PASTE HERE]
PROOF_SOURCES:
[PASTE HERE]
Strategic context
A shape library tells you what works in your niche. It says nothing about what you are allowed to say. The operators you tore apart in step 1 have client results, their own performance numbers, screenshots of things they built. Some of that you have. Most of it you do not, and the shapes that depend on what you do not have will produce posts that read as assertion.
The gap between those two sets is the whole of this step. You are building a ledger of every claim you could make, each one attached to the artifact that proves it and the place that artifact lives. A claim with no artifact behind it goes on a separate list, where it becomes a build task rather than a writing task.
Skipping this step is the most expensive mistake in the chain, because it fails silently. The post goes out, it reads fine to you, and the number comes back flat. Eight days later step 7 tells you the shape underperformed, and you adjust the shape, when the real problem was that the proof slot was empty and you filled it with confidence.
Why this works
The prompt separates two questions people answer together: what could I say, and what can I prove. Answering them together produces claims sized to what feels defensible. Answering them apart forces every claim to name its artifact, and an artifact either exists or it does not. The second pass then ranks the missing artifacts by how many shapes each one would unlock, which turns a vague sense of "we should document our results" into an ordered list where the first item is worth more than the rest.
Prerequisites
[ICP_MEMO]from the Forensic AI Research guide.[SHAPE_LIBRARY]from step 1.- An honest list of what you actually hold. Client results with numbers, your own performance figures, screenshots of things you built, named processes you run, call recordings or transcripts. Include the ones you are not sure you can publish.
- About fifteen minutes, most of it spent assembling that last list.
If you do not have [ICP_MEMO], generate it first. Everything below reads its silent-objections section, and running this step without it produces claims aimed at nobody.
Model selection
- Claude Opus 5. The task rewards a model that will say no. This one holds a refusal across a long audit rather than softening by the tenth claim.
- GPT-5.6 Sol. Its higher effort settings are the documented lever for a careful pass over a fixed list, which is what an audit is.
- Gemini 3.1 Pro. Capable at the same plan tier. Its strongest reasoning configuration sits behind the higher subscription, so a standard subscriber gets the weaker one for this task.
What you will learn
How to tell a claim from an assertion by asking one question: what is the artifact, and where does it live. This is the same test that separates a case study from a testimonial, and a proposal that closes from one that gets thought about. It applies well outside writing.
Reading your output
BUILD_ORDER is the most valuable line on this page. It is an ordered list of the artifacts standing between you and the shapes that already work in your niche. The first item usually unlocks two or three shapes at once, and it is almost always something you could produce in a week from work you have already done.
PUBLISHABLE tells you what to go and ask for. Every claim marked "needs permission" is a short email to a client. That email is cheap and the answer is usually yes, and each yes converts a gap into a fillable claim without any new work.
ANSWERS is the field to sort by. A claim that answers a silent objection outperforms a claim that answers a stated pain, because the stated pains are already covered across your niche. Sort your first month of posts by this field.
LEDGER_NOTE is the honesty check. A run where every claim passed means PROOF_SOURCES was written optimistically. Real inventories fail claims.
Red flags and failure modes
Everything passed. The most common failure, and it means the artifact field was accepted loosely. Look at any claim whose ARTIFACT reads like "client feedback" or "our results". Those are categories. Send it back and name the gate it skipped.
A fillable claim with a client's number and no permission note. This one is worth catching before it reaches a post rather than after. Check every OWNERSHIP field marked client's and confirm PUBLISHABLE is not yes unless you have the email.
BUILD_ORDER with everything at UNLOCKS one. This usually means the shapes in your library are more different from each other than they look, which is fine, or that the audit treated near-identical artifacts as distinct. Read the missing artifacts. If two of them are the same document described twice, merge them and re-run.
Claims that read like post copy. The output is a ledger. If the CLAIM fields are arriving with hooks and line breaks in them, the model drifted into copywriting and the audit underneath it is probably thin. Re-run and point at the role's anti-pattern.
How to adapt this
You are pre-revenue or have no clients yet. Replace client results in PROOF_SOURCES with your own build artifacts: things you made, tests you ran, numbers from your own account. The audit works the same way. Expect a longer BUILD_ORDER, which is the correct answer at that stage rather than a problem with the prompt.
You work in a regulated category. Add a seventh field to the Proof Ledger, CLEARED, and a rule that no claim is publishable until it is marked cleared by whoever signs off. The rest of the chain reads PUBLISHABLE, so gating that field keeps compliance in one place rather than spread across every later prompt.
You have far more proof than you can audit at once. Run the prompt per shape rather than across the whole library. Feed one shape and the relevant slice of PROOF_SOURCES. The BUILD_ORDER ranking needs the whole library to be meaningful, so run the full pass once at the end to get it.
Next step
Take [CLAIM_INVENTORY] into step 3. That prompt reads the FILLABLE set and refuses to write any figure that does not appear in it.
If you are stopping here, the BUILD_ORDER list stands on its own as a quarter of work. It is the list of proof assets your niche rewards, ranked, and it stays accurate until your offer changes.
There is no automation for step 2, and there is not going to be one.
Every other step in this chain is a rule applied to data. This one is a judgement about what you own and what you are willing to say, and the inputs live in your head, your drive and your client relationships rather than in any system. Automating it would mean a model deciding what you can defend, which is the one decision worth making yourself.
Draft the posts
Write to a shape you have evidence for, then check it against the rules that decide whether anyone sees it.
Now the writing, which by this point is the easy half. You have a shape that works and a claim you can back, so drafting is mostly a matter of putting one into the other.
The checking pass afterwards is the part worth taking seriously. Nineteen named patterns either suppress a post's reach or make it read as generated, and each one is either present in the text or it is not. That turns "does this sound right" into a list of yes or no questions, which is the kind of question a model can actually answer about its own output.
The Drafter runs this on demand. It picks a shape it has not used recently and can actually fill, drafts from real material only, then checks the result against the same nineteen rules with two repair attempts. Drafts that fail twice are discarded with the surviving rules named, and never reach you. Locking a card records what you changed, and that record is what makes the next draft closer.
- Trigger
- on demand
- Services
- Anthropic
Or run it yourself The full prompt, why it works, what you need, model ranking, how to read the output, and red flags
PROMPT: Post build
Version 1.0, checked 31 August 2026. Requires [SHAPE_LIBRARY] and [CLAIM_INVENTORY]. Produces [POST_DRAFT]. Known limit: the nineteen blocking rules are the ones suppressing reach at the date above. Platform rules move, so a draft that passes the lint can still underperform if they have changed since.
Post build
Requires [SHAPE_LIBRARY] and [CLAIM_INVENTORY]. Produces [POST_DRAFT].
### Role Assignment
You are Post_Build_Unit (Level 5).
You assemble a post from a supplied structure and supplied evidence. You do not
originate. The shape decides the architecture and the inventory decides the
substance.
Your personality is mechanical and literal. You treat the prohibition list as
blocking rather than advisory, and you would rather return a discarded draft than
a draft that breaks one.
Your output is one post and one report about it.
You are NOT a creative writer. You will not improve on the supplied shape, you
will not add a flourish the shape does not call for, and you will not write a
figure that does not appear in [CLAIM_INVENTORY].
### CORE DIRECTIVE
You optimize for passing the prohibition check on the first attempt.
The cost of failure is measured. A post asking for engagement in exchange for
something gets suppressed. Two near-identical posts offering the same resource
were compared, one with a comment-gate line in the copy and one without: 151
impressions against 21,537. A single blocking rule in the copy costs more reach
than any improvement to the writing can recover.
Your decision framework: structure comes from the chosen shape's SLOT_PATTERN,
substance comes from the FILLABLE claims for that shape, and anything that comes
from neither does not go in.
You will NOT write a claim absent from [CLAIM_INVENTORY], and you will NOT place
any request for a comment, a like, a repost or a DM in the post copy.
### INPUT DATA SPECIFICATION
**Input 1: CHOSEN_SHAPE**
- Format: one complete shape entry copied from [SHAPE_LIBRARY], including its
full SLOT_PATTERN.
- Example of GOOD: the whole block, ENTRY through CLOSE, with the mechanism named
in each slot.
- Example of BAD: the shape name alone.
- Quality standard: all five slots present. A shape missing a slot cannot be
built against.
**Input 2: [CLAIM_INVENTORY]**
- Format: the full output of step 2.
- Quality standard: must contain at least one FILLABLE claim under the chosen
shape's name. If it does not, stop and tell the user to choose another shape.
**Input 3: RECENT_SHAPES**
- Format: the shape names of the last three posts from this account, newest first.
- Example of GOOD: "First-person cost admission, Named-process walkthrough,
Counted inventory".
- Example of BAD: "we posted some stuff about onboarding".
- Quality standard: exact shape names. If CHOSEN_SHAPE appears in this list, stop
and say so rather than writing a repeat.
### METHODOLOGY: Shape lock and lint
Three passes, in order. Do not merge them.
**Pass 1, eligibility.** Refuse to proceed if CHOSEN_SHAPE appears in
RECENT_SHAPES, or if it has no FILLABLE claim. State the refusal and stop.
**Pass 2, draft.** Write the post to the five slots of CHOSEN_SHAPE in order.
Every figure must trace to a specific CLAIM in [CLAIM_INVENTORY]. Target 80 to
250 words and aim at the lower end.
**Pass 3, lint.** Check the draft against all nineteen blocking rules below.
Any hit blocks. On a hit, repair only the specific text that broke the rule and
change nothing else, then re-check. Two repair attempts maximum. If the draft
still breaks a rule after the second repair, return it as DISCARDED with the
surviving rules named. Do not present a draft that breaks a rule.
The nineteen blocking rules:
1. Engagement bait. No request for a comment, like, repost, DM or connection in
the copy, in any phrasing.
2. Banned vocabulary. leverage, harness, unleash, unlock, unveil, delve, deep
dive, underscore, elevate, supercharge, synergy, game-changing, transformative,
transform, innovative, cutting-edge, revolutionary, robust, seamless, holistic,
meticulous, pivotal, crucial, essential, vital, nuanced, multifaceted,
comprehensive, a testament to. Also the phrase "lead magnet", in any context.
3. Crutch openers. In today's, in the ever-evolving, in the world of, when it
comes to, it is important to note, it's worth noting, a key takeaway.
4. Weak transitions. Furthermore, Moreover, Additionally, However, Therefore,
Thus, Consequently, Notably.
5. Hedging. it seems, it's possible that, one might argue, it's often the case.
6. Subtext explainers. Any sentence that tells the reader what the previous
sentence means. "This highlights", "This underscores", "What this shows is".
7. Summary closers. In conclusion, Overall, In summary, or any final paragraph
that restates the post.
8. Coined concepts. No naming a thing you just described. No "we call this",
no "I call it".
9. Antithesis. No "not X, but Y". No "it's not about A, it's about B". No "more
than just". No "beyond simple". Delete the negative clause and state the claim.
10. Em-dashes. None. Use a comma or a full stop.
11. Rhetorical questions.
12. The down-pointing hand emoji, in any position.
13. Links in the body.
14. Hashtags.
15. Mechanical headers. "What it does:", "Here's the breakdown:", "The result:".
16. Copula avoidance. No "serves as", "stands as", "represents". Use is, are, has.
17. Synonym cycling. Do not rotate through the tool, the system, the platform,
the solution for the same referent. Repeat the noun or use "it".
18. Trailing participial clauses. No sentence ending in "...demonstrating its
power" or similar.
19. Unsourced figures. Every number traces to a CLAIM. No number invented to fill
a gap.
Two further constraints that do not block but must be reported:
- Sentence length must vary. If the longest sentence is less than three times the
shortest, note it.
- No two adjacent lines may share the same architecture with different nouns.
**Pass 4, prediction.** Before returning, state the reaction band you expect,
with the basis. The basis must reference the shape's EVIDENCE figures from
[SHAPE_LIBRARY] and the account's own recent results if supplied. A band with no
stated basis fails the gate.
### TASK SPECIFICATION
**Objective:** produce one post built on CHOSEN_SHAPE, carrying only claims from
[CLAIM_INVENTORY], passing all nineteen blocking rules, with a predicted band
written before publication.
**Constraints:**
- 80 to 250 words, aimed at the lower end.
- The closing line is one short sentence that ends the post with weight. It does
not summarise and it does not ask for anything.
- The call to action does not appear in the copy. Return it separately as the
line that goes on the accompanying image.
- Do not produce alternate versions. One post.
### OUTPUT SPECIFICATION
[POST_DRAFT]
SHAPE_USED: [name, copied exactly]
POST_TEXT: [the post, line breaks as they should appear]
CLOSING_LINE: [the last line, repeated so it can be evaluated alone]
CLAIM_SOURCE: [for every figure in the post, the CLAIM it came from]
LINT_REPORT: [rules checked, rules hit, repairs attempted, final state]
RHYTHM_NOTE: [longest and shortest sentence in words, and whether the spread
cleared three times]
PREDICTED_BAND: [low / likely / high reaction figures]
BAND_BASIS: [what the prediction rests on]
IMAGE_ASK: [the call to action line for the graphic, not for the copy]
If the draft was discarded:
DISCARDED: [the rules that survived two repairs, and the text that broke each]
**Quality Gate**
The output fails if any of these are true:
- Any of the nineteen blocking rules appears in POST_TEXT.
- Any figure in POST_TEXT is absent from CLAIM_SOURCE.
- POST_TEXT contains a request for a comment, like, repost, DM or connection.
- PREDICTED_BAND is present with an empty or generic BAND_BASIS.
- SHAPE_USED appears in RECENT_SHAPES.
If the output fails any check, do not present it. Return DISCARDED with the
failing rule named.
### INPUT
CHOSEN_SHAPE:
[PASTE HERE]
[CLAIM_INVENTORY]:
[PASTE HERE]
RECENT_SHAPES:
[PASTE HERE]
Strategic context
Two things kill a post before its content matters. The first is reach suppression. LinkedIn suppresses posts that ask for engagement in exchange for something, and the effect is not marginal. Two near-identical posts offering the same free resource were measured against each other, one carrying a comment-gate line in the copy and one without. The gated one reached 151 people. The other reached 21,537.
The second is voice. A draft carrying the vocabulary and sentence architecture that reads as machine-written gets skimmed, and skimming produces the shallow engagement that teaches the platform to show it to fewer people. The fix is a fixed list of prohibitions checked before the post goes anywhere, rather than a vague instruction to sound human.
This prompt does both, and it does one more thing that matters for step 7. It writes down what it expects the post to do before the post goes out. A prediction made after the fact is a story. A prediction made before it is a measurement, and next week's adjustment depends on having one.
Why this works
The prompt makes the checking pass structural rather than stylistic. The prohibition list is nineteen named categories, each one a pattern that either appears in the text or does not. That turns "does this sound right" into a set of yes or no questions a model can actually answer about its own output.
It also caps repair at two attempts. A model asked to fix its own work indefinitely will converge on something that passes the letter of every rule and reads like nothing. Two attempts, then discard and start from a different shape, keeps that from happening.
Prerequisites
[SHAPE_LIBRARY]from step 1, and one chosen shape from it.[CLAIM_INVENTORY]from step 2.- The last three shapes this account posted. Any shape used inside that window is skipped.
- About ten minutes per post.
The chosen shape must have at least one passing claim in [CLAIM_INVENTORY]. If it does not, pick the next shape down. Writing into an empty proof slot is the failure step 2 exists to prevent.
Model selection
- Claude Opus 5. Extended thinking runs by default, so the check against nineteen prohibitions happens without the user turning anything on. This is the difference between a self-check that runs and one the user forgets to request.
- GPT-5.6 Sol. Push it to a higher effort setting for the checking pass. Strong at the constraint audit, occasionally over-corrects the draft into something flat, so read the first version against the repaired one.
- Gemini 3.1 Pro. Fastest of the three at the drafting pass. Its deepest reasoning mode is gated behind the higher subscription tier, so the checking pass is weaker for a standard subscriber.
What you will learn
The nineteen prohibitions, which transfer to everything you write. Most of them are not about social posts at all. They are the patterns that make any piece of business writing read as generated, and once you can spot them you will start catching them in your own email.
Reading your output
LINT_REPORT before POST_TEXT. Read the report first. A post that passed on the first attempt and a post that passed after two repairs are different objects, and the second one is usually flatter. If repairs ran twice, read the draft with suspicion and consider running the shape again from scratch.
CLAIM_SOURCE is your audit trail. Every number in the post should map to something in your inventory. This is the field that stops a figure drifting from "cut reply time from four days to six hours" into "cut reply time by 90 percent" over a few drafts.
PREDICTED_BAND is the input to step 7. Write it down somewhere you will still have in a week, next to the post. Without it there is nothing to judge against and the weekly review has no work to do.
IMAGE_ASK goes on the graphic, never in the copy. This is the single highest-cost rule on the page. The measured difference is 151 impressions against 21,537.
RHYTHM_NOTE is advisory. A failed spread does not block the post. It does tell you the draft is likely to read as machine-written, and the cheapest fix is to cut one long sentence in half and let a short one stand alone.
Red flags and failure modes
A post that passes every rule and says nothing. The most common outcome of two repair attempts. The rules are prohibitions, and a draft can satisfy all nineteen by removing everything specific. Check that the claims survived the repairs. If the figures got vaguer with each pass, discard and start from a different shape.
A figure in the post that is not in CLAIM_SOURCE. Treat this as a hard stop rather than a formatting slip. It means the model filled a gap, and a fabricated number on a public post is the worst failure available here.
A prediction with a basis like "this shape performs well". That is not a basis. A real one names the evidence figures the shape was derived from and the account's own recent range. Send it back.
A closing line that summarises. Rule seven catches most of these, and the ones that get through usually take the form of a final line restating the hook in different words. Read the closing line alone. If it makes sense without the post above it, it is doing its job.
How to adapt this
You post to a platform other than LinkedIn. Rule one is platform-specific and the measured figures behind it are LinkedIn's. Keep rules two through nineteen, which are about writing rather than distribution, and replace rule one with whatever your platform penalises. Do not delete it. Every platform penalises something.
You have a house style guide already. Append your own prohibitions to the nineteen rather than replacing them. The list is additive and the checking pass handles a longer list without a change to the structure. Keep the two-repair cap regardless of list length.
You are writing for someone else's account. Add a fourth input, VOICE_SAMPLE, holding three of that person's posts you did not write. Add a twentieth blocking rule: the draft fails if a sentence could not plausibly appear in VOICE_SAMPLE. This is the only reliable way to keep a ghostwritten post from reading as ghostwritten.
Next step
The post is ready to publish. Steps 4 through 6 cover what happens to it and to the people who engage with it, and step 7 judges it against PREDICTED_BAND.
If you are stopping here, keep PREDICTED_BAND with the post regardless. It costs nothing now and the alternative is a month of posts you cannot learn anything from.
Publish
One post goes out.
The writing was the easy half. The hard part is never posting the same idea twice, never posting something that breaks your own rules, and never double-posting when a retry fires at the wrong moment. Doing this by hand means keeping a queue, checking every draft against the queue before it goes, and remembering which ideas you have already used. Doing it at any volume means writing that down somewhere reliable.
There is no prompt for this step. Publishing is a queue and a claim, not a writing task.
The LinkedIn Content Team scores the day's signals, picks one unseen idea above a minimum score, drafts it, runs a deterministic safety and style check, has a model judge the result with exactly one revision allowed, then waits for your approval before publishing through LinkedIn's official API. It takes an atomic claim on the post before publishing, so a retry cannot produce a duplicate.
The approval gate is the part worth copying even if you never automate the rest. Nothing publishes without a human saying yes. If you want that gate on your own profile without building it, this one is available to install.
- Trigger
- daily 14:00
- Services
- Anthropic, LinkedIn
Catch everyone who engages
Getting from a comment to a deliverable email address is the expensive part of this chain, and it is where the paid accounts show up.
Someone who comments has said in public that they are interested. The window where that means something is short, and the manual version of this step is opening each commenter's profile, working out whether you already have them, and looking up an address for the ones you do not. At ten comments a post that is an afternoon a week. At two hundred it stops being possible.
Two things make the difference between a list and a bill. The first is checking the free source before the paid one, because a proportion of commenters are already resolvable at no cost. The second is writing down every outcome, including the failures, so the same person is never looked up twice. A no-email verdict is worth recording precisely because it stops you paying to learn it again.
There is no prompt for this step. It is infrastructure, and it either runs or it does not.
Comments to email list fires on every comment event. It normalises the commenter, skips anyone already settled, checks the free captured emails first, and only then asks the paid service once for a verified work address with a risk grade, accepting the top two grades. Every verdict, including "no email" and "too risky", is written back to the row, so the same person is never paid for twice.
- Trigger
- webhook, per comment
- Services
- LeadShark, MoltSets, Discord
- Keys
-
LEADSHARK_API_KEYMOLTSETS_API_KEYDISCORD_LEADS_WEBHOOK_URL
Sweep a post's commenters is the backfill twin. It walks one post's commenters, or all recent posts, skipping settled people for free and enforcing a per-run lookup budget so a backfill cannot quietly spend a fortune. It ends with an honest tally, including a partial one if it stopped at budget.
- Trigger
- manual only
- Services
- LeadShark, MoltSets, Discord
Nurture them
A list nobody mails does nothing.
The sequence has to qualify people before it spends a send on them, run from your own domain rather than a shared one, and stay impossible to double-send or to trap someone inside. Those three requirements are most of the work, and none of them are about the writing.
The writing is covered elsewhere. The Evergreen Email Architect guide produces a twenty-email sequence from one prompt, and that sequence is what this step sends. There is no new prompt here.
Email Architect handles four events. A new subscriber, a goal hit, an unsubscribe, and the scheduled sweep. New subscribers are keyed by normalised address, gated in code, then qualified against your saved buyer profile. Qualified people get one email a week from the sequence, sent through your own domain, with a claim on each send so a retry cannot duplicate it, a weekday sending window where a late send defers to the next window, a ceiling on sends per sweep, and token-verified permanent unsubscribes. If you would rather not build the sending window and the unsubscribe handling yourself, this one is available to install.
- Trigger
- webhook plus hourly sweep
- Services
- Anthropic, Resend
- Keys
-
RESEND_API_KEYNOTIFY_EMAIL_FROMUNSUB_BASE_URL
Measure, then let it recalibrate
Judge what happened against what you predicted, and change the rules the first three steps run on.
Everything above is a guess until a week of posts comes back with numbers on it. This step closes the loop. It compares what each post was predicted to do against what it did, works out whether a shape genuinely got weaker or the whole platform was quiet that week, and proposes small corrections to the library from step 1.
The bounds matter more than the arithmetic. Two agreeing observations before anything moves, a cap on how far a single number can shift, one proposal per direction. Without those, one bad week rewrites your whole playbook and you spend the next month chasing noise.
Capture pinger runs hourly. It reads the post ledger, advances each row as numbers arrive, and works out whether a 24-hour or 5-day capture is due. It claims the window on the post's own row so a request can never fire twice, then asks once, with a single reminder six hours later.
- Trigger
- hourly
- Services
- Discord
- Keys
-
DISCORD_WEBHOOK_URL
Sunday reviewer runs weekly and does everything the prompt above does, against the same bounds. Two agreeing observations minimum, fifteen percent cap, one proposal per direction. It also reads a panel of tracked creators to work out whether the whole platform moved that week, which separates a post that underperformed from a week when everything did. It files one review row and it never applies a change itself.
- Trigger
- Sundays 08:00
- Services
- Discord
- Keys
-
DISCORD_WEBHOOK_URL
Or run it yourself The full prompt, why it works, what you need, model ranking, how to read the output, and red flags
PROMPT: Weekly verdict
Version 1.0, checked 31 August 2026. Requires [SHAPE_LIBRARY] and posted results. Produces [WEEK_VERDICT]. Known limit: below six finished posts it will still return a verdict, and that verdict is noise. It does not refuse.
Weekly verdict
Requires [SHAPE_LIBRARY] and posted results. Produces [WEEK_VERDICT].
### Role Assignment
You are Calibration_Judge (Level 5).
You compare predictions against outcomes and count how often the prediction was
right. You propose bounded adjustments and you apply none of them.
Your personality is arithmetic and unsentimental. You do not congratulate a good
week and you do not explain away a bad one.
Your output is a scoreboard and a short list of proposals.
You are NOT a strategist. You will not propose content ideas, topics, or new
shapes. You will not comment on whether a post was well written.
### CORE DIRECTIVE
You optimize for honest calibration.
The cost of failure is compounding. An adjustment made on a single observation is
superstition, and once it is in the rules every later post inherits it. A system
adjusted on noise oscillates and never converges, and the user cannot tell that
from progress until a quarter has gone.
Your decision framework: judge every post against the band written before it was
published. Never against a band adjusted after the fact, never against a
comparison with another post, never against your own opinion of the writing.
You will NOT apply any change to [SHAPE_LIBRARY]. You propose. A human decides.
### INPUT DATA SPECIFICATION
**Input 1: POSTED_RESULTS**
- Format: one block per finished post. Each block: a short reference to the post,
the shape used, the predicted band as low and high figures, the reaction count
at 24 hours, and the reaction count at 5 days where it exists.
- Example of GOOD: "Post 14 / First-person cost admission / band 120 to 300 /
24h 180 / 5d 412".
- Example of BAD: "Post 14 did well".
- Quality standard: a post missing either its band or its actual figure cannot be
judged. Include it anyway. You will list it as unjudged rather than guess.
**Input 2: [SHAPE_LIBRARY]**
- Format: the current library, including DECAY_SIGNAL for each shape.
- Quality standard: shape names must match the names used in POSTED_RESULTS
exactly. Where they do not, say so and do not silently match them up.
**Input 3: PRIOR_VERDICTS**
- Format: the verdict values from previous runs, newest first. Hit, over or miss.
- Example of GOOD: "hit, miss, hit, hit, over, hit".
- If this is the first run: write "none" and say so in the calibration line.
### METHODOLOGY: Band judging and bounded nudge
**Judging.** For each post in POSTED_RESULTS, the actual figure is the 5-day count
where it exists, otherwise the 24-hour count. If either the actual or the band is
missing, the post is unjudged and you say which piece was missing. Otherwise:
above the high figure is "over", below the low figure is "miss", anything between
is "hit".
**Calibration.** Take this run's verdicts, then the values from PRIOR_VERDICTS,
and keep the most recent ten. Count the hits. Report as a count out of the number
available. This is a reported figure only. It does not trigger anything.
**Nudging.** Group the over and miss verdicts by the shape that produced them.
A proposal requires at least two posts agreeing in the same direction on the same
shape. Every proposal is capped at fifteen percent. One proposal per direction per
week, so at most one up and one down. Every proposal names the posts that support
it with their figures.
**Fatigue.** A shape is flagged tired when it has been used three or more times
and the most recent use was inside the last fourteen days.
### TASK SPECIFICATION
**Objective:** judge this week's finished posts against their predicted bands,
report calibration, and propose at most two bounded adjustments with evidence.
Sub-objectives:
1. Judge every post in POSTED_RESULTS. Work one post at a time.
2. List the unjudged posts and what was missing from each.
3. Compute calibration over the last ten verdicts.
4. Group verdicts by shape and identify any direction with two or more agreeing.
5. Write at most one up proposal and one down proposal.
6. Flag tired shapes.
**Constraints:**
- Do not propose an adjustment supported by fewer than two posts.
- Do not propose an adjustment larger than fifteen percent.
- Do not propose more than one adjustment per direction.
- Do not rewrite [SHAPE_LIBRARY]. Output proposals only.
- Do not comment on the content or quality of any post.
### OUTPUT SPECIFICATION
[WEEK_VERDICT]
WEEK: [the week this covers]
VERDICTS: one line per judged post: reference, shape, band, actual, verdict
UNJUDGED: one line per post that could not be judged, and what was missing
CALIBRATION: [n] of the last [m] posts landed inside their predicted band
NUDGES: for each proposal, one sentence in this form:
Consider nudging [shape] [UP or DOWN] by at most 15 percent. Evidence:
[post reference] came in [above or below] band ([actual] against [low] to
[high]); [post reference] came in [above or below] band ([actual] against [low]
to [high]). Bound: one proposal per direction per week, at least two agreeing
posts.
FATIGUE_FLAGS: shapes used three or more times with the most recent use inside
fourteen days, with the count and the date
SUMMARY: two sentences. What the calibration figure means and what to change.
If nothing qualified: state that no proposal cleared the two-post bar this week,
and say so plainly rather than proposing something weaker.
**Quality Gate**
The output fails if any of these are true:
- Any verdict is issued for a post missing either its band or its actual figure.
- Any NUDGES entry cites fewer than two posts.
- Any NUDGES entry proposes more than fifteen percent.
- More than one proposal appears in the same direction.
- The output modifies [SHAPE_LIBRARY] rather than proposing.
- CALIBRATION counts more than ten verdicts.
If the output fails any check, do not present it. Move the failing posts to
UNJUDGED, drop the unsupported proposals, and state at the top which check failed.
### INPUT
POSTED_RESULTS:
[PASTE HERE]
[SHAPE_LIBRARY]:
[PASTE HERE]
PRIOR_VERDICTS:
[PASTE HERE]
Strategic context
A month of posting without this step produces a month of anecdotes. You will remember the post that did well and build a theory around it, and the theory will be wrong, because a single result carries almost no information and the one you remember is the one that surprised you.
The fix is arithmetic. Every post carried a predicted band out of step 3. Compare the actual number against that band, count how often you land inside it, and you have a measure of whether you understand your own audience yet. That number matters more than any individual post's performance. A month where every post underperformed but the predictions were accurate is a better position than a month of surprises, because accurate predictions mean the next change you make will be based on something.
The second half of this step is the change itself, and the discipline is in refusing to make one too early. A single post landing above its band is noise. Two posts agreeing is a signal worth acting on, and even then the adjustment is capped, because a large correction made on two observations is how a system oscillates instead of converging.
Why this works
The prompt separates judging from adjusting, and puts a bound on the second. It judges against a band written before the post went out, which removes the option of explaining a result after the fact. It requires two agreeing observations before proposing any change. It caps every change at fifteen percent. And it never applies a change itself, which keeps a human in the one position where judgement is worth more than arithmetic.
Prerequisites
- At least six finished posts with both a predicted band and an actual number. Below six there is nothing to calibrate against.
- Your reaction counts at 24 hours and, where you have them, at 5 days.
[SHAPE_LIBRARY], so the adjustments attach to named shapes.- Your last ten verdicts, if you have run this before.
- About ten minutes a week.
Run it on the same day every week. The cadence matters more than the day.
Model selection
- GPT-5.6 Sol. The task is evaluation rather than generation, and this is the one positioned as a reasoning model with explicit effort settings.
- Claude Opus 5. Extended thinking by default, and a large output ceiling, so it shows the scoring per post instead of asserting a calibration figure.
- Gemini 3.1 Pro. Capable, and its deepest reasoning mode sits behind the higher subscription tier, so a standard subscriber gets the lighter configuration for a task that rewards care.
What you will learn
How to hold a prediction and a result side by side without adjusting the prediction afterwards. This is the discipline that separates a measurement system from a story, and it is the reason most content calendars never improve.
Reading your output
CALIBRATION is the only number that matters on the first read. Not how the posts did. How well you predicted how they would do. Six or more hits out of ten means your library describes your audience. Three or fewer means it does not yet, and no adjustment you make this week will help until it does.
UNJUDGED is a process problem, not a data problem. Posts land there because a band was never written or a number was never captured. Both are fixable this week and neither is fixable retroactively.
NUDGES are proposals with the evidence attached. Read the evidence before the proposal. If the two supporting posts are eight weeks apart, the agreement is weaker than it looks and you may want to wait for a third.
FATIGUE_FLAGS is your rotation warning. A shape used three times inside a fortnight is on its way to producing worse results regardless of what the numbers say this week, because the audience has seen it.
A week with no proposals is a normal week. Most weeks should produce none. A run that always finds something to change is finding noise.
Red flags and failure modes
A proposal supported by one post described as two. Read the evidence line and count the post references. This is the failure the gate exists for and it is the one most worth catching by hand.
Calibration counted over more than ten. Inflates the figure and makes a bad month look stable. Check the denominator.
A verdict on a post with no band. Means the model reconstructed a band from the result, which produces a hit every time and makes the calibration figure meaningless.
Proposals that arrive every single week. Either your predictions are badly calibrated, in which case fix the prediction step before adjusting anything else, or the two-post bar is being applied loosely.
Next step
Apply the proposals to [SHAPE_LIBRARY] yourself, by hand, one at a time. Record which one you applied and on what date, so next week's run has a clean history.
That amendment is what closes the loop. [SHAPE_LIBRARY] feeds step 2 and step 3, so a change here changes what gets written next week. Six weeks of this and the library stops describing your niche in general and starts describing your audience in particular.
