LinkedIn automation, run for you
Section 1The Brief, the Goal, and the 3 Gates
Most outbound stacks are a person sitting between every step. Brief the ICP, review it, brief the list build, review it, brief the copy, review it.
Fable 5 in goal mode collapses that. One brief, one run, three deliberate stops.
That is the only reason this system is 22 skills rather than 40. Fewer, bigger, chained.
Why fewer skills, not more
A forty-skill library assumes a human picks the next one each time. That is the right design when you are invoking things by hand.
Goal mode changes the unit. The model keeps working until the goal is met rather than stopping at the end of a turn, so the skills become stages of one job rather than tools on a shelf.
Practically that means each skill here does more, writes its output to a file the next one reads, and declares what would make it stop.
The business workflows benchmark is the reason this is now viable. It went from 17.1% to 31.4%, which measures whether a model can reliably run a real pipeline end to end. At 17% you supervise every step. At 31% you supervise the gates.
How lead generation actually changed
Writing became free. Sending did not.
Anyone can produce a thousand personalised-looking messages in an afternoon. So the bottleneck moved from production to reach.
Recommended LinkedIn limits are still 20 connection requests a day and roughly 100 messages a week, account-wide rather than per campaign. Email thresholds tightened rather than loosened.
Three consequences the whole system is built around:
- Ordering beats volume. A 400-row list is five weeks of your entire budget. Which 20 you contact Monday decides the quarter.
- Filtering moved before enrichment. Enrichment is per-lookup. Enriching 1,000 rows to find 600 were never going to buy is the standard way this gets expensive.
- Personalisation is table stakes. Everyone references a recent post now. A dated, verifiable signal the prospect can check is what still works, because it cannot be generated from a profile alone.
The one brief
The only thing you write. Everything downstream reads it.
# Outbound Brief
## What we sell
One line, in the words a customer would use:
What a meeting is actually for:
Price band, and the minimum engagement:
## Evidence
CRM export of closed-won, last 12 months: [path or access]
Proof we can use publicly, with permission:
Copy of ours that already worked, pasted in full:
## Constraints
Connected sending accounts:
Other campaigns already running on them:
Qualification framework we use:
Anything legal needs to review before sending:
## Voice
Three adjectives:
Two phrases we would never say:
## Banned
<never_use_these>
Claims we cannot evidence:
Numbers nobody approved:
</never_use_these>
The "other campaigns already running" line is the one people leave blank and it is load-bearing. Send limits are account-wide, so a skill that does not know what else is running will propose a volume that gets the account restricted.
The goal to run
Take ownership of this entire task from start to finish.
Read outbound/brief.md.
GOAL: a launch-ready outbound system, every output written into
outbound/.
Run the 22 skills in order. Each reads what the previous one wrote.
STOP AND WAIT FOR ME at three points only:
GATE 1 After the ICP is derived, before any list building
GATE 2 After the list is graded, before any copy is written
GATE 3 After the sequence spec, before anything is built in the
sender
Between those, keep working. Make intermediate decisions and note
them rather than checking in.
Before you finish, review the whole set as a skeptical buyer in the
target market. Find the five biggest weaknesses. Fix the important
ones. Then verify the result accomplishes the original goal.
HARD RULES for the whole run:
- Never invent a number, client name or result. Only what is in
brief.md.
- If a stage cannot complete honestly, stop and name what is
missing.
- Grade the list before it leaves stage 2. Below B, rebuild rather
than proceed.
- Never propose a send volume above the account ceiling.
End with: the three things I need to review, the daily send split,
and every assumption you made.
Why three gates and not six
Each gate sits where a wrong decision compounds rather than stays local.
Gate 1, after the ICP. Everything downstream inherits it. A wrong ICP produces a perfect list of the wrong people, and you find out six weeks later.
Gate 2, after the grade. This is where you either spend send capacity or do not. A C-grade list that gets through costs a month.
Gate 3, before the sender. The last point where nothing has reached a human being.
Everything between those points is reversible by editing a file. Adding a fourth gate buys you nothing and costs you the reason to run it unattended at all.
The effort dial
Fable 5.1 got 25 to 45% cheaper. Running everything at maximum effort hands that straight back.
| Effort | Skills |
|---|---|
| Low | 03 filter-pass, 17 reply-classifier, 18 crm-hygiene, 19 source-tagger |
| Medium | 08 opener-writer, 09 merge-prompt-writer, 10 voice-note-scripter, 11 message-self-check, 14 call-prep, 20 follow-up-sequencer |
| High | 01 icp-derivation, 06 signal-finder, 07 intent-scorer, 12 sequence-builder, 21 pipeline-diagnostic |
| Max | 04 list-grader, 13 qualification-engine, 16 pain-quantifier |
filter-pass at low effort is the biggest single saving. It touches every row, so it is the highest-volume call in the chain and has the least reasoning in it.
sequence-builder at low effort is the most expensive mistake. A bad sequence design costs more in wasted sends than the tokens ever saved.
The model split: build the system once with Fable 5, which is the expensive reasoning and happens once. Run the weekly operation on a cheaper model, because the figuring out already happened and lives in files.
Install all 22
mkdir -p outbound/{research,copy,report}
mkdir -p .claude/skills/{icp-derivation,persona-research,filter-pass,list-grader,account-tiering,signal-finder,intent-scorer}
mkdir -p .claude/skills/{opener-writer,merge-prompt-writer,voice-note-scripter,message-self-check,sequence-builder}
mkdir -p .claude/skills/{qualification-engine,call-prep,objection-handler,pain-quantifier,next-step-closer}
mkdir -p .claude/skills/{reply-classifier,crm-hygiene,source-tagger,follow-up-sequencer,pipeline-diagnostic}
22 folders, four groups. The groups are the run order.
Section 2Skills 01 to 07: ICP, Persona, List, Signals, Intent
Skills 01 to 07. Gate 1 sits after 02, gate 2 after 07.
Every skill writes to a named file. The next one reads it. That chain is what makes the run unattended.
01. icp-derivation
---
name: icp-derivation
description: Derive the ICP from closed-won evidence. First skill in
the chain. High effort.
---
Read outbound/brief.md. Pull the CRM export.
Per closed-won deal, last 12 months: company size, industry, tech
stack if visible, buyer job title, deal size, days to close, and the
trigger that started it.
WRITE outbound/research/icp.md:
1. Three attributes correlating with fast closes
2. Three correlating with long or lost deals
3. Exact job titles that actually signed, not the ones targeted
4. Size band with the highest win rate
5. The searchable filter string
6. The gap between the stated ICP and the actual one
7. Who this is explicitly NOT for
FAIL CLOSED IF fewer than 10 closed-won deals exist. Report the
count and stop. Do not derive a pattern from three customers.
FAIL CLOSED IF the export lacks job titles or company size. Name
the missing field rather than inferring it.
POINT 6 is the output that justifies the gate. Telling a team their
real buyer is a different title from the one on their site changes
everything downstream.
>>> GATE 1. Stop here. Wait for approval before list building.
02. persona-research
---
name: persona-research
description: Build the buyer persona and capture their actual
language. Runs alongside 01, before gate 1.
---
FOR the top two job titles from icp.md:
- What they are measured on quarterly
- What they are trying to do, in their words
- What they have already tried that failed
- Who else approves their decisions
- Where they actually spend attention
- What makes them ignore outbound
EVERY field needs a source: a post, a job description, a review, a
call transcript. Anything unsourced is marked UNKNOWN.
THEN the voice-of-customer pass. Sources in priority order:
1. Their own posts and comments
2. Comments under competitor posts
3. Relevant forums and communities
4. Review sites for competing products
5. Your own call transcripts
OUTPUT to outbound/research/voice.md:
- Twelve verbatim phrases, quoted exactly
- Five words they use that we do not
- Three objections they raise unprompted
- What they say they already tried, and what did not work
NEVER paraphrase into marketing language. If they said "I can't
tell what any of it is doing", record that, not "attribution
challenges".
This file is why the copy later does not sound generated. Twelve
real phrases beat any persona document.
03. filter-pass
---
name: filter-pass
description: Build the raw list, then filter it before any
enrichment. Lowest effort, cheapest model.
---
BUILD FIRST. Sources, highest intent first:
1. Commenters and likers on a relevant post, ours or a rival's
2. Attendees of a relevant event
3. Members of a relevant group
4. Search matching the ICP filter string
5. Job boards, for companies hiring the role our offer supports
Capture: name, headline, company, size, location, LinkedIn URL,
source. Write to outbound/research/prospects.csv with a linkedin_url
column. That header is required by the import later.
THEN FILTER. Per row: KEEP, DROP or UNSURE with a 12-word reason.
DROP: fails the title or size band, hits a disqualifier, competitor,
too small for the price band.
UNSURE: ambiguous headline. Do not guess.
KEEP and UNSURE to filtered.csv. DROP to dropped.csv, so the filter
is auditable when someone asks why a company was excluded.
Report the drop rate. Below 40% usually means the search was too
narrow rather than the list being unusually good.
ENRICH NOTHING before this step. Enrichment is per-lookup and most
of a raw list was never going to buy.
04. list-grader
Max effort. This is the gate that decides whether send capacity gets spent.
---
name: list-grader
description: Grade the filtered list A to F. Nothing proceeds below B.
---
Eight dimensions, 1 to 10:
1 ICP fit against icp.md
2 Title accuracy: decision makers or influencers
3 Affordability against the price band in brief.md
4 Data completeness
5 Deduplication, within the list and against any active campaign
6 Recency of activity
7 Reachability: how many are already 1st degree
8 Signal strength: how many carry a tier 1 or 2 trigger
A 9.0+ proceed B 7.5+ proceed C 6.0+ fix the two lowest first
D 4.5+ rebuild the list F below rebuild the ICP, not the list
FAIL CLOSED below B. Name the two lowest dimensions and the fix for
each. Do not pass a failing list downstream.
DIMENSION 7 changes the campaign shape, not the quality. Mostly 1st
degree can be messaged directly. Mostly cold needs connection
requests first, which is a different daily budget entirely.
DIMENSION 8 predicts reply rate better than any other. A B-grade
list where most rows carry a signal beats an A-grade list with none.
An F grade usually means the offer is too broad, not that the list
is bad. Send it back to gate 1.
05. account-tiering
---
name: account-tiering
description: Split the graded list into tiers with different effort
budgets.
---
TIER 1 Exact ICP match, high deal potential, observable trigger.
One-to-one: custom research, personalised first touch,
multi-threaded from the start.
TIER 2 ICP match, no current trigger. One-to-few: segment-level
personalisation, standard sequence.
TIER 3 Adjacent fit. One-to-many: no research, template sequence,
contacted only when capacity allows.
OUTPUT the count per tier, the effort budget per tier, and the share
of the daily send allocation each gets.
If tier 1 exceeds 20% of the list, the criteria are too loose. Tier
1 should be small enough to research each account by hand.
THE ALLOCATION is the point. At 20 requests a day, tier 1 should
take the majority even though it is the smallest group.
06. signal-finder
---
name: signal-finder
description: Find a dated, verifiable reason to contact each lead now.
High effort.
---
ONE signal per lead, ranked by proximity to a budget decision.
TIER 1, budget is already moving
- Hiring for the role our offer replaces or supports
- Raised in the last 90 days
- New leader in post, last 60 days
- Publicly named the exact problem, last 30 days
TIER 2, the problem is visible
- Site or content shows the specific gap
- Commented on a competitor's post
- Expanding into a new market
- Competitor of an existing customer
TIER 3, fit only
EVERY signal verifiable and DATED. Record the date and the URL,
because it appears in the first message and they will check it.
FAIL CLOSED on any signal you cannot date. Write NONE rather than
an undated trigger.
Never stretch an attribute into a trigger. "Works at a SaaS company"
is fit, not intent, and using it as intent is the single most
common reason outbound reads as automated.
Add signal, tier, date and source_url columns to filtered.csv.
07. intent-scorer
---
name: intent-scorer
description: Combine signals into one score so the list can be
ordered. The last skill before copy.
---
SCORE each lead:
Signal tier 1 to 3
Engagement depth 1 to 3
ICP fit 1 to 3
Recency of signal 1 to 3 (30 days = 3, 90 days = 1)
Sum, maximum 12.
10 to 12 Contact this week, tier 1 treatment
7 to 9 This month, standard sequence
4 to 6 Hold, watch for a second signal
Below 4 No outreach
RECENCY is weighted equally with fit deliberately. A perfect-fit
lead with a 90-day-old signal converts worse than an adjacent-fit
lead who posted about the problem last week.
Sort descending. This order IS the campaign.
OUTPUT the count per band and how many weeks of send budget the
top band represents at the ceiling in brief.md.
>>> GATE 2. Stop here. Wait for approval before any copy is written.
The top source in skill 03 is post engagers because Prosp imports commenters and likers directly from any post URL, including future reactions as they arrive. A post that keeps performing keeps feeding the list without anyone touching it.
And the whole scoring chain exists because importing is free while sending is capped. Import everyone, then use add tag nodes and a check data in column condition to route only the top band into the sending branch. The rest stay in the workspace for when there is an offer that fits them.
Section 3Skills 08 to 17: Copy, Sequence, Qualification, Discovery
Skills 08 to 17. Gate 3 sits after 12, before anything is built in the sender.
The distinction that matters: the model writes the structure and the logic. The per-lead variation happens at send time, against live profile data.
08. opener-writer
---
name: opener-writer
description: Write the first message from a signal. Medium effort.
---
Read voice.md. Match the phrases in it, not a generic register.
STRUCTURE
Line 1 the signal, dated and specific
Line 2 the inference drawn from it
Line 3 the question
RULES
- Under 300 characters
- Line one references the signal SPECIFICALLY, not its category
- One ask, answerable in under ten words
- Never mention the product in message one
- No compliments, no "hope this finds you well"
- No em dashes
ONE PER TIER
Tier 1 lead with the signal. It is recent and they know it.
Tier 2 lead with the observable problem. There is no event.
Tier 3 lead with the segment pattern. Claim no personalisation you
cannot back.
BANNED, burnt:
"I came across your profile"
"I help [vertical] with [service]"
"Are you open to a quick chat"
"Quick question for you"
09. merge-prompt-writer
The handoff skill. This is how personalisation scales without a thousand drafts.
---
name: merge-prompt-writer
description: Convert message copy into prompts that personalise per
lead at send time.
---
SYNTAX, keep the two distinct:
{{double curly}} the platform's own profile data
[square brackets] instructions to the AI
Variables: first name, last name, headline, biography, job title,
company, last post. Plus any custom variable imported from the CSV,
so the signal column from skill 06 is usable here.
RULES
- ONLY the opening line varies. Keep the ask identical across leads
so results are comparable and failure is diagnosable.
- State length explicitly, in characters.
- Say what to do when a variable is empty. Never allow "Hi ,".
- Ban the burnt openers inside the prompt itself.
- One instruction per bracket. Compound instructions get
half-followed.
SHAPE
Hi {{first name}},
[One sentence referencing {{signal}}. Specific about the actual
detail, not the category. Under 90 characters. If {{signal}} is
empty use {{headline}}. Never open with "I came across".]
[Then this line unchanged:] Worth a quick look at how [X] handle
this?
Write to outbound/copy/merge-prompts.md.
10. voice-note-scripter
---
name: voice-note-scripter
description: Script a voice note for the sequence.
---
Under 20 seconds. Roughly 50 words. Count them.
STRUCTURE
- Their name
- The ONE thing everyone on this segment shares, because one
recording goes to all of them
- The reason for reaching out, one sentence
- The ask, phrased so a yes is easy
WRITE FOR SPEECH
- Contractions throughout
- Sentences that run out of breath naturally
- One filler word. Real speech has them. Two sounds like acting.
- No lists. Nobody says "three things" out loud.
NEVER alone. Always a written message immediately before or after.
Output the script, the word count, and the estimated seconds.
Worth the extra step: across 1000+ Prosp campaigns, voice notes average around a 47% reply rate against roughly 8% for written messages, largely because under 1% of LinkedIn outreach uses them. Cloning needs a 30 second minimum recording, ideally of the actual script being sent.
11. message-self-check
---
name: message-self-check
description: Check every drafted message before it enters the
sequence spec.
---
SEVEN CHECKS. Five must pass.
[ ] Under 300 characters
[ ] One question only
[ ] References something specific and dated, not a category
[ ] No banned opener
[ ] No claim absent from the proof list in brief.md
[ ] Register matches the phrases in voice.md
[ ] No em dashes
Report pass or fail per check WITH the evidence. Do not summarise as
"looks good".
Fewer than five passing means rewrite, not send. A message failing
three checks will not be rescued by the follow-up.
Run this as a fresh reviewer, not as the writer. A model reviewing
its own output defends it.
12. sequence-builder
High effort. Never run this low.
---
name: sequence-builder
description: Turn the copy into a node-by-node spec ready to build.
Last skill before the gate.
---
Output a node list, not prose. Per node: action, delay before it,
exact copy, exit condition.
STANDARD SHAPE
1 Import from source
2 Condition: lead is 1st level
3 YES branch: message, using the merge prompt
4 NO branch: connection request, then message on acceptance
5 Wait 3 days. Voice note, paired with a written message.
6 Wait 4 days. Follow-up, different angle, no link.
7 Add tag by source, signal tier and intent band
RULES
- Four touches maximum. After that the answer is no.
- Reply stops the sequence for that lead, always.
- A connection request auto-detects acceptance over two weeks, so
NO WAIT NODE after one. This is the most common unnecessary node.
- Every touch a different angle. Never "just following up".
- Any voice note pairs with a written message.
STATE the daily send split against the ceiling in brief.md,
allocated by tier.
FAIL CLOSED if the requested volume exceeds the ceiling. State the
ceiling and the required split rather than writing the sequence.
>>> GATE 3. Stop here. Nothing gets built in the sender until
approved.
The spec maps node for node onto the Prosp builder. Actions: connection request, message, voice note, InMail, message to open profile, comment on last post, reply comment, like last post, visit profile, wait X days, add tag. Conditions: has LinkedIn URL, lead is 1st level, opened message, lead is open profile, check data in column.
The ceiling the skill fails closed against is real: 20 connection requests a day and roughly 100 messages a week, account-wide rather than per campaign. Three campaigns at 20 each means 60 attempts a day and a restricted account, and builder defaults sit above the recommended limits so they need lowering rather than accepting.
13. qualification-engine
Max effort. Merges framework application with the disqualification check, because doing them separately means the second one never runs.
---
name: qualification-engine
description: Apply the framework AND actively look for reasons to
kill the deal. Runs on every reply that becomes a conversation.
---
PART ONE. Apply the framework named in brief.md. Per element: what
we know, the evidence, confidence 1 to 10. Below 6 is a gap, not a
fact. Never fill an element by inference.
A deal with four UNKNOWNs is not a late-stage deal regardless of how
long it has been open.
PART TWO. Look for reasons to disqualify:
- Do they hit any disqualifier from icp.md
- Economic buyer identified, or only a champion
- A compelling event with a date, or only interest
- Can they afford the entry price
- An incumbent contract nobody has checked
- Anything moved in the last 14 days
RETURN exactly one:
QUALIFIED All checks pass. State the compelling event.
AT RISK Named gaps, with the question that resolves each.
DISQUALIFY The specific reason and the honest message to send.
A clean DISQUALIFY is a SUCCESS. It returns send capacity, calendar
time and forecast accuracy.
NEVER soften a DISQUALIFY into AT RISK because pipeline looks thin.
That is how a quarter gets missed twice.
Part two exists because nobody else in the process is incentivised
to run it.
14. call-prep
---
name: call-prep
description: Prepare the discovery brief. Run the morning of, not the
night before.
---
PULL: the signal, the thread, the CRM record, the qualification
output.
ONE PAGE:
WHAT WE KNOW
Per framework element, what the record contains, with the source.
WHAT WE DO NOT KNOW, RANKED
The five gaps that would most change the recommendation, ranked by
how much they change it. These become the questions.
THE FIVE QUESTIONS
One per gap. Open, short, answerable without preparation. Never ask
something the record already answers.
WHO ELSE
What to ask to surface other decision makers without making it
obvious you are asking.
LIKELY OBJECTIONS
Two, from brief.md. With the honest answer, not a rebuttal.
DISQUALIFIERS
What would make this a bad deal. If you hear these, say so on the
call rather than progressing it.
Under one page. A brief you cannot read in three minutes will not be
read.
15. objection-handler
---
name: objection-handler
description: Draft a response to a named objection.
---
Read the objections in brief.md first. If it is there, use the
agreed response rather than inventing one.
NAME IT PRECISELY before answering. "Not interested" is not an
objection, it is an absence of one. Ask what is behind it.
THREE MOVES
1. Agree with the part that is true. There always is one.
2. Add the thing they do not know. One fact, not three.
3. Ask a question that moves it forward or closes it out.
RULES
- One objection per message. Pick the real one.
- Never answer a price objection with features. Ask what it is
being compared against.
- "We already use [competitor]" is information, not rejection.
- If they say no twice, stop.
Never invent a number or comparison to answer an objection. If the
honest answer is "we are not a fit for that", say it. That reply
gets referrals; a stretched one gets a bad implementation.
16. pain-quantifier
Max effort. The skill that turns a conversation into a business case.
---
name: pain-quantifier
description: Attach a number to the problem, using their arithmetic.
---
A problem without a cost is a preference. A cost they calculated
themselves is a business case.
WALK IT THROUGH WITH THEM
1. How often does this happen? Per week, per month.
2. How many people are involved each time?
3. How long does it take them?
4. What is that in loaded cost, or delayed revenue?
5. What does that annualise to?
Use THEIR numbers at every step. If they do not know one, ask for
their estimate and label it as an estimate in the output.
OUTPUT the arithmetic, shown, with the source of each input and
whether it was measured or estimated.
NEVER supply a number they did not. Never substitute an industry
benchmark for their figure. A business case built on your
assumptions collapses the first time their finance team checks it.
If the quantified cost is smaller than the price, SAY SO. Finding
out now beats finding out at proposal.
17. next-step-closer
---
name: next-step-closer
description: Decide whether to ask for the meeting, then draft it.
---
Decide IF before HOW.
ASK NOW WHEN
- They asked something needing more than 400 characters to answer
- They named a problem we solve
- They asked about price, timeline or implementation
- Two substantive messages have gone each way
DO NOT ASK YET WHEN
- They replied with one line
- They have not named a problem
- It is still the first exchange
Ask one more question that gets them to name the problem.
HOW
- Name the length and the agenda. "15 minutes, three questions, no
deck."
- Offer the link AND two concrete times.
- Say what happens on the call, one line.
- Never "let me know what works". Decision fatigue kills bookings.
Under 350 characters including the link.
After sending, TAG the lead so the sequence does not follow up on
someone who already booked. The most avoidable bad impression in
the whole system.
Section 4Skills 18 to 22: Replies, CRM, Follow-Up, Diagnostic, Templates
Skills 18 to 22. These run weekly, after the one-time build is done.
This is the half that runs on a cheaper model, because the figuring out already happened and lives in files.
18. reply-classifier
Lowest effort. Runs on every reply, daily.
---
name: reply-classifier
description: Classify every inbound reply and route it.
---
Exactly one category:
INTERESTED Wants more, asks about the offer
TIMING Interested, not now. Capture the date named.
OBJECTION Price, fit, incumbent, capacity
WRONG_PERSON Not their remit. Ask who owns it.
NOT_INTERESTED Clear no. Thank them, stop, never pitch again.
AUTO_REPLY Out of office. Reschedule to their return date.
ESCALATE Anything below 8 confidence
Per reply: category, confidence 1 to 10, the sentence that decided
it, the recommended next action.
Below 8 confidence, always ESCALATE. Do not guess at tone. Sarcasm,
brevity and politeness all read the same in text.
ROUTE: INTERESTED to 17, OBJECTION to 15, everything else to a
human.
Never auto-send to NOT_INTERESTED. A human closes that loop.
19. crm-hygiene
---
name: crm-hygiene
description: Keep the record usable. Weekly. Cheapest model.
---
CHECK AND FIX:
- Incomplete records: which required fields are empty, per record
- Field normalisation: job titles, company names, country codes
- Duplicates, within the CRM and against active campaigns
- Stale records: no activity in 90 days, flagged not deleted
- Orphaned contacts with no account
- Records with no lead source
OUTPUT the counts, the fixes applied, and anything needing a human
decision.
NEVER delete. Flag and report. A deleted record with history is a
loss you cannot undo, and stale is not the same as wrong.
20. source-tagger
Small skill, outsized effect. Without it, skill 22 cannot answer the only question that matters.
---
name: source-tagger
description: Set lead source so attribution survives to reporting.
---
THE RULE: lead source names the CAMPAIGN, never the channel.
"LinkedIn" tells you nothing in three months.
"q3-saas-founders-job-post-trigger" tells you which signal type
produced the revenue.
SET, per lead:
- lead_source: the campaign name, in convention
- signal_type: which tier 1 or 2 trigger brought them in
- source_post: the post URL, where applicable
- first_touch_date
- tier: 1, 2 or 3 from skill 05
- intent_band: from skill 07
THE SIGNAL_TYPE FIELD is what lets the diagnostic answer which
trigger produced closed deals. Without it that question is
unanswerable, and you keep running signals that do not convert
because nothing tells you they do not.
21. follow-up-sequencer
---
name: follow-up-sequencer
description: Build the follow-up after a reply goes quiet, and catch
leads who re-engage.
---
PART ONE, the follow-up. Establish three things first:
1. The trigger that enrols someone
2. The EXIT event that removes them
3. The one action it exists to cause
No exit event, no sequence. One that keeps chasing someone who
already booked is worse than none.
Day 3 One line. "Any questions on X?" No new information.
Day 7 One thing that was not in the last message.
Day 14 The close-out. "Assuming this isn't a priority right now,
which is fine. Want me to check back in Q[X]?"
Day 21 Mark cold. Stop.
THE DAY 14 MESSAGE outperforms the other two combined, because
permission to say no removes the pressure that was stopping them
replying.
PART TWO, re-entry. Scan weekly for anyone marked Contacted or Cold
who has since viewed the profile, engaged with a post, changed job,
or appeared in a funding or hiring announcement.
A JOB CHANGE is the strongest. They arrive with ninety days to show
a change, no loyalty to the incumbent, and you already have a
relationship.
Route re-entries into a fresh sequence referencing the NEW signal,
never the old thread.
Most systems miss these entirely because the lead is already marked
Contacted and never re-enters.
Part two runs off lead states: Not Contacted, In Campaign, Contacted, Not Accepted after 14 days with auto-withdraw, Replied which stops the campaign, Duplicate, Blacklist, Failed. Prosp exposes those plus 12 webhook events including Message Replied and Connection Accepted, so re-entry can fire automatically rather than from a weekly manual scan.
22. pipeline-diagnostic
High effort. The only skill that runs every single week without exception.
---
name: pipeline-diagnostic
description: Diagnose which stage is broken. Weekly.
---
Pull: requests sent, accepted, messages sent, replied, meetings
booked, deals closed.
Work the chain IN ORDER. Stop at the first failure. Do not report
five stages of numbers when the first one is broken.
1 ACCEPTANCE BELOW 15%
The connection note, or the list is off-ICP. NOT the sequence.
Do not touch the sequence.
2 ACCEPTANCE FINE, REPLIES BELOW 10%
The list is fine. The first message is the problem. Check whether
the signal in line one is specific and dated.
3 REPLIES FINE, MEETINGS LOW
The ask is mistimed, or the offer is wrong.
4 MEETINGS FINE, NOTHING CLOSING
Not an outbound problem. Price or offer fit.
5 ALL FINE, VOLUME LOW
Not quality. Check the daily cap split across campaigns.
OUTPUT the failing stage, the evidence, and ONE change.
ALSO report monthly: which signal_type produced the closed deals.
That single line changes next month's targeting more than anything
else in the report.
Never more than one change per week. Change three and a lift tells
you nothing about which one worked.
If figures are incomplete, name which stage cannot be assessed. A
diagnosis on partial data points at the wrong stage.
Stages 1 to 3 need figures no CRM holds. Prosp supplies them: requests sent and accepted, messages sent, replies received, per campaign and per account. Native HubSpot integration with field mapping, plus a REST API at prosp.ai/api/v1/leads, so the diagnostic runs on live data rather than a weekly manual export.
Templates and checklists
Four fixed formats. Every recurring document in the system.
icp.md — the seven sections from skill 01, with the source of every attribute and an explicit UNKNOWN for anything unevidenced.
sequence-spec.md — action, delay, exact copy, exit condition, per node. Plus the daily split and the ceiling it was checked against.
weekly-report.md — the diagnostic chain result stopping at the first failure, one metric per stage with its action, exactly one recommended change. Banned: impressions as a headline, percentages without absolutes, any metric with no action attached.
pre-launch-checklist.md
[ ] ICP derived from 10+ closed-won deals, not assumed
[ ] voice.md contains 12 verbatim phrases
[ ] List graded B or above
[ ] dropped.csv retained for audit
[ ] Every row has a dated signal or NONE
[ ] Intent scored and sorted descending
[ ] Daily split stated against the account ceiling
[ ] No wait node after any connection request
[ ] Every voice note paired with a written message
[ ] Merge prompts previewed against real contacts
[ ] lead_source names the campaign, not the channel
[ ] Exit event confirmed on the follow-up sequence
The weekly loop, after the build
MONDAY 22 pipeline-diagnostic. One change, no more.
MONDAY 21 part two, the re-entry scan
TUESDAY 03 filter-pass and 04 list-grader on new rows
TUESDAY 06 signal-finder and 07 intent-scorer on survivors
WEDNESDAY Top up the campaign, within the split
DAILY 18 reply-classifier over the inbox
DAILY 15 and 17 on whatever it routes
FRIDAY 19 crm-hygiene and 20 source-tagger
MONTHLY Which signal_type produced closed deals
QUARTERLY 01 icp-derivation, re-derived against closed-won
The build is a one-off. This loop is the system, and it runs on a cheaper model because every judgement call already lives in a file.
Three things to remember
- Hand it an outcome, not a task. Twenty-two skills chained in one run is what the model was built for. Invoking them one at a time wastes the whole upgrade.
- Three gates, not six. Each sits where a wrong decision compounds rather than stays local. Everything between them is reversible by editing a file.
- Build with Fable 5 once, run on a cheaper model after. The expensive part is the figuring out, and that only happens once per ICP.
Fable 5 builds the system. Prosp runs the half that reaches people 💜