Fable 5 for Agency Owners: One Brief, Every Client's LinkedIn, Run End to End

Fable 5 is built for long-running tasks. In goal mode it keeps working until the goal is met rather than stopping at the end of a turn.

A client LinkedIn engagement is exactly that shape: ICP, list, content, sequence, launch, report. Six stages that normally take six separate briefs.

One brief per client. Fable 5 runs the chain.

Why goal mode changes the job

The usual agency pattern is a person sitting between every stage. You brief the ICP work, review it, brief the list build, review it, brief the content, review it. Six briefs and six waits per client.

Goal mode collapses that. You write one brief, set the goal, and it works through the chain until the deliverable exists. Your review moves to the end, or to the two gates you set deliberately.

At one client that saves an afternoon. At eight clients it is the difference between onboarding taking a week and taking a day.

The cost point nobody mentions

Fable 5 is expensive. Use it for the part that is expensive to figure out, not the part that runs every week.

Build the client's system once with Fable 5: the ICP, the pillars, the sequence architecture, the skill files. That is the hard reasoning and it happens once per client.

Then run the weekly operation on Opus, or test whether Sonnet holds. The figuring out has already happened and lives in files.

Practically: Fable 5 for onboarding week, cheaper models for weeks two onward. Budget it per client, not per month.

Per-client folder structure

The folder is the coordination layer. Each stage reads what the previous one wrote, which is why one brief can carry a six-stage chain with no orchestration code.

clients/[CLIENT]/
├── brief.md              <- you write this, once
├── icp.md                <- stage 1
├── filtered-leads.csv    <- stage 2
├── pillars.md            <- stage 3
├── sequence-spec.md      <- stage 4
├── prosp-prompts.md      <- stage 4
└── report/               <- stage 6, weekly

mkdir -p clients/[CLIENT]/report

Never share a file between clients. Voice, ICP and proof are all client-specific, and a shared file produces two accounts that sound like the same person.

The six stages

#	Stage	Writes	Gate
1	ICP from their customers	icp.md	Client confirms
2	List build, filter, grade	filtered-leads.csv	Grade B or above
3	Content pillars and warmup	pillars.md	None
4	Sequence and copy	sequence-spec.md, prosp-prompts.md	Client signs off copy
5	Launch	Live campaign	You launch, not the model
6	Weekly diagnostic	report/	One change per week

Two gates, both at the points where something goes out under the client's name. Everything else runs unattended.

The goal to run

Read clients/[CLIENT]/brief.md.

Goal: produce a launch-ready LinkedIn outbound system for this client.

Run stages 1 to 4 in order. Each stage reads what the previous one
wrote into clients/[CLIENT]/.

Stop and wait for my approval at two points only:
- After stage 1, before list building
- After stage 4, before anything is built in the sender

Between those, keep working. Do not check in for confirmation on
intermediate decisions, make them and note them.

Hard rules for the whole run:
- Never invent a number, a client name or a 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.

End with: the two things I need to review, and every assumption you
made.

The brief

The only thing you write per client. More detail in means less correction later.

# Client Brief: [CLIENT]

## What they sell
One line, in the words a customer would use:
What a meeting with them is actually for:

## Who they sell to
Exact job title:
Company type and size:
What that person is trying to do:
What they have already tried that failed:
Who this is NOT for:

## Proof, with permission
Numbers they can stand behind publicly:
Named customers they can reference:
Anything legal needs to review before publishing:

## Voice
Three adjectives:
Two phrases they would never say:
Copy of theirs that already worked (paste it):

## Account state
Roughly what share of the ICP is already 1st degree:
Sales Navigator, yes or no:
Other campaigns already running on this account:

## CRM
Closed-won deals from the last 12 months (export or access):

The last line is the one that changes the output most. An ICP derived from who actually bought beats an ICP someone described in a kickoff call.

The "other campaigns already running" line matters because send limits are account-wide, and stage 4 needs to know what budget is left.

Stages 1 and 2. Fable 5 runs both, stopping between them for your approval on the ICP.

The filter runs before any enrichment. That order is the cost control, and at agency volume across eight clients it is the difference between viable and not.

Stage 1: icp-from-customers

mkdir -p .claude/skills/icp-from-customers

---
name: icp-from-customers
description: Derive a client ICP from their closed-won deals rather
  than from what they said in the kickoff call.
---

Read clients/[CLIENT]/brief.md. Pull closed-won deals, last 12 months.

For each: company size, industry, tech stack if visible, buyer job
title, deal size, days to close, and the trigger that started it.

Output to clients/[CLIENT]/icp.md:

1. The three attributes correlating with fast closes
2. The three correlating with long or lost deals
3. Exact job titles that actually signed, not the ones they target
4. Company size band with the highest win rate
5. The searchable version: a LinkedIn or Sales Navigator filter string

If there are fewer than 10 closed-won deals, say so plainly. Do not
derive a pattern from three customers and present it as one.

Flag any gap between who they said they sell to and who actually
bought. That gap is usually the most valuable thing in the document.

The last instruction is what makes this worth showing a client. Telling them their real buyer is a different title from the one on their website is a strong first deliverable.

Stage 2a: linkedin-list-builder

mkdir -p .claude/skills/linkedin-list-builder

---
name: linkedin-list-builder
description: Build a raw prospect list for a client. Use after their
  ICP is approved.
---

Read clients/[CLIENT]/icp.md.

Source in priority order, highest intent first:
1. Commenters and likers on a relevant post, theirs or a competitor's
2. Attendees of a relevant LinkedIn event
3. Members of a relevant LinkedIn group
4. Search matching the ICP filter string

Capture per lead: full name, headline, company, company size, location,
LinkedIn URL, and the source.

Write to clients/[CLIENT]/prospects.csv with a linkedin_url column.
That header name is required by the import, do not rename it.

Enrich nothing yet. Look up no emails. Most of this list will be
discarded in the next step.

Source 1 first, always. Prosp imports commenters, likers, or both directly from a post URL, and can keep pulling future reactions as they arrive, so a client post that keeps performing keeps feeding the list without anyone touching it.

Stage 2b: icp-filter-pass

Run on Haiku. Classification across a whole list, not reasoning.

mkdir -p .claude/skills/icp-filter-pass

---
name: icp-filter-pass
description: Filter a raw list against the client ICP before any
  enrichment. Run on Haiku.
---

Read clients/[CLIENT]/icp.md and prospects.csv.

Per row return exactly one of: KEEP, DROP, UNSURE.

KEEP    Matches both the job title band and the company size band
DROP    Fails either, or is a competitor, or a student, or an agency
        when the client sells to in-house teams
UNSURE  Headline is ambiguous. Do not guess.

One line of reasoning per row, 12 words maximum.

KEEP and UNSURE to filtered-leads.csv. DROP to dropped.csv so the
filter can be audited when the client asks why someone was excluded.

Report the drop rate. Below 40% usually means the search was too
narrow, not that the list is unusually good.

Keeping dropped.csv matters for client work specifically. "Why isn't [big logo] on the list" is a question that comes up, and having the reason logged is a better answer than rebuilding.

Stage 2c: list-quality-scorecard

The gate. Nothing enters a client campaign below B.

mkdir -p .claude/skills/list-quality-scorecard

---
name: list-quality-scorecard
description: Grade a client list A to F before it enters a campaign.
---

Grade filtered-leads.csv across eight dimensions, 1 to 10:

1. ICP fit: share matching both bands
2. Title accuracy: decision makers or influencers
3. Company fit: size, sector, geography
4. Data completeness: rows missing fields
5. Deduplication: within the list, and against this client's past
   campaigns, and against every OTHER client's active campaigns
6. Recency: how recently each profile was active
7. Reachability: how many are already 1st degree
8. Signal strength: how many have a trigger event attached

Average into a letter grade.
A 9.0+ send today   B 7.5+ send   C 6.0+ fix two lowest first
D 4.5+ rebuild list   F below rebuild the ICP

Below B, stop. Name the two lowest dimensions and the fix for each.

Dimension 5 has an agency-specific clause. Two clients with overlapping ICPs will otherwise message the same person in the same week from two accounts, which looks exactly like what it is.

Stage 2d: post-engager-scorer

When the list came from post engagement, order it before you work it.

mkdir -p .claude/skills/post-engager-scorer

---
name: post-engager-scorer
description: Score post engagers by depth and fit so the send budget
  goes to the right people first.
---

Score each engager on two axes, 1 to 3, multiply. Maximum 9.

DEPTH
1  Reaction only
2  Short comment
3  Substantive comment, or engaged more than once

FIT, against clients/[CLIENT]/icp.md
1  Adjacent to the ICP
2  Right role wrong company type, or the reverse
3  Exact match

6 to 9   Contact this week
3 to 5   Hold, watch for a second signal
1 to 2   No outreach. Keep in the list, spend no send on it.

Add a score column, sort descending.

The reason to score rather than blanket-send: 20 connection requests a day is the recommended ceiling and it is account-wide. A client list of 400 is five weeks of their entire budget, so the order you work it in decides the whole quarter.

You do not have to choose between a big list and a tight one. Import everyone into Prosp, since importing costs nothing, then use add tag nodes and a check data in column condition to route only the high scorers into the sending branch. The rest stay in the workspace for when the client has an offer that fits them.

Stages 3 and 4. Content warmup runs alongside the sequence build because warm outreach converts several times better than cold, and content is what creates the warmth.

Stage 4 ends at the second gate. The client signs off copy before anything is built in the sender.

Stage 3: content-pillars

mkdir -p .claude/skills/content-pillars

---
name: content-pillars
description: Build a client's content pillars and weekly calendar from
  their brief and ICP.
---

Read clients/[CLIENT]/brief.md and icp.md.

Produce three pillars. Each must be a repeatable topic, not a theme.
"Cold email" is a topic. "Growth" is a theme and produces nothing.

Per pillar:
- The topic, in one line
- Why this ICP cares, tied to what they have already tried and failed
- Five post angles inside it
- Which of the client's real proof points support it

Then a weekly calendar: three posts, one per pillar, with the angle
named for the first four weeks.

RULES
- No em dashes. No hashtags in the body.
- Hook is lines 1 to 2 and must earn the See More click alone.
- One idea per line, three lines maximum per paragraph.
- Only proof from brief.md. Never invent a figure.
- Match the voice: three adjectives in, two banned phrases out.

Write to clients/[CLIENT]/pillars.md.

These posts are the top of the funnel and the lead source at the same time. Every one that lands produces commenters and likers, and Prosp imports both straight from the post URL. So stage 3 is not separate from stage 5, it feeds it.

Stage 4a: signal-finder

No signal, no message. This is the skill that stops a client's outreach reading like everyone else's.

mkdir -p .claude/skills/signal-finder

---
name: signal-finder
description: Find a verifiable, dated reason to contact each lead.
---

For each lead in filtered-leads.csv, find ONE signal.

TIER 1, act this week
- Posted about the exact problem the client solves, within 30 days
- Hiring for a role that implies the problem
- Funding round in the last 90 days
- Changed job in the last 60 days

TIER 2, act this month
- Commented on a competitor's post
- Company shipped something relevant
- Attended a relevant event

TIER 3, no signal
- ICP fit only

Every signal verifiable and dated. Record the date and the URL, because
the client will ask where it came from.

No signal means NONE. Do not stretch "works at a SaaS company" into a
trigger.

Add signal, tier, date and source columns.

Stage 4b: sequence-builder

mkdir -p .claude/skills/sequence-builder

---
name: sequence-builder
description: Turn signals and openers into a node-by-node sequence spec
  ready to build in the sender.
---

Output a node list, not prose. Per node: the action, the delay before
it, the exact copy, the exit condition.

RULES
- Every touch a different angle. Never "just following up".
- Message 2 references something message 1 did not.
- Four touches maximum. After that the answer is no.
- Reply stops the sequence for that lead, always.
- Connection requests auto-detect acceptance, so no wait node after one.
- Any voice note pairs with a written message, before or after.
- First touch under 300 characters. Long reads as template.
- One ask, answerable in ten words.
- Never mention the product in message one.

Branch on connection state:
1st degree      message straight away
Not connected   connection request, then message on acceptance

Banned openers, these are burnt:
"I came across your profile"
"I hope this message finds you well"
"Quick question for you"

Check the send budget in brief.md. If other campaigns are already
running on this account, state the split rather than assuming the full
allocation is available.

Write to clients/[CLIENT]/sequence-spec.md.

The spec maps one to one onto the Prosp builder. Available 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.

Connection request notes need Sales Navigator. Without it, leave the note blank rather than writing one that will not send.

Stage 4c: prosp-prompt-writer

The handoff. Fable 5 writes the instruction that personalises each message at send time against live profile data, so one sequence covers a whole list without one template going to everyone.

mkdir -p .claude/skills/prosp-prompt-writer

---
name: prosp-prompt-writer
description: Convert sequence copy into Prosp AI prompts that
  personalise per lead at send time.
---

Syntax, keep the two distinct:
  {{double curly}}   Prosp's own 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,
which means the signal column from stage 4a is usable here.

RULES
- Only the opening line varies. Keep the ask identical so results are
  comparable across the list.
- 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 {{last post}}. Be specific about what they
  actually said. Under 90 characters. If {{last post}} is empty, use
  {{headline}}. Never open with "I came across".]
  [Then this line unchanged:] Worth a look at how [X] handle this?

Write to clients/[CLIENT]/prosp-prompts.md.

Preview before anything sends. Prosp runs sample outputs against real contacts in the campaign, which catches the prompt that reads fine on lead one and produces something odd on lead five.

Stage 4d: voice-note-scripter

mkdir -p .claude/skills/voice-note-scripter

---
name: voice-note-scripter
description: Script a LinkedIn voice note for a client sequence.
---

Under 20 seconds. Roughly 50 words. Count them.

STRUCTURE
- Their name
- The one thing everyone on this list shares, because one recording
  goes to the whole segment
- The reason for reaching out, one sentence
- The ask, phrased so yes is easy

WRITE FOR SPEECH
- Contractions throughout
- Sentences that run out of breath naturally
- One filler word. 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, the estimated seconds.

Worth the client conversation it takes to set up: 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 from the client, ideally reading the actual script that will be sent so the clone knows how they sound in context. Get the permission in writing. It is their voice.

Stages 5 and 6. Fable 5 stops at the second gate. You launch.

This is the only stage that touches LinkedIn, and the only one where a mistake costs a client their account rather than an afternoon.

Account architecture across clients

One Prosp account maps to one LinkedIn profile. Multi-client runs through workspace team members: a separate account per client profile, each created in its own browser session because cookies conflict, all invited into one workspace you administer.

White-label with your own domain and branding, plus a sub-workspace per client, keeps the client-facing surface yours. Check you have unused slots before creating one, and set TTL under 60 for faster domain verification.

Three connection routes: credentials with the free residential proxy, Chrome extension session transfer, or a manual session cookie. Then it runs on Prosp's servers, so nothing depends on a machine in your office staying awake.

Turn 2FA on before connecting a client account. If you connect via the extension, stop using that profile manually in the same browser.

Accounts idle 7 or more days get parked automatically and send nothing until reactivated in Settings, Accounts. Check that before blaming a campaign.

Build the five nodes

sequence-spec.md maps straight onto this.

1  Import
   Post URL, CSV, event, group, search or Lead Finder

2  Condition: lead is 1st level

3  YES branch
   Message, using the prompt from prosp-prompts.md
   Wait 3 days
   Voice note, paired with a short written message

4  NO branch
   Connection request
   (no wait node, acceptance is auto-detected)
   Message on acceptance
   Wait 3 days
   Follow-up, different angle, no link

5  Add tag
   Tag by source and signal tier so attribution survives to reporting

Connection requests check for acceptance every 24 hours for two weeks, then move the lead on after a random 1 to 24 hour delay. So the wait card people add after step 4 does nothing except slow the sequence.

The cap split, per account

Action	Free	Premium / Sales Nav
Connection requests	20/day, 100/week	30 to 50/day
Direct messages	~100/week	~150/week
Profile views	80/day	150/day
Comments	60/day	60/day
InMail	n/a	50/month

Account-wide, not per campaign. This is the single most common way a client account gets restricted. Three campaigns set to 20 each means that account attempts 60 a day. Split it, 10 + 5 + 5, set per campaign.

Builder defaults are higher than recommended: 30 messages, 30 invites, 5 InMails, 80 comments, 80 likes, 80 profile visits per day. Lower them on every client account rather than leaving them.

Connection request limits and message limits are separate buckets, so both run at full allocation at once. When LinkedIn caps an account, only connection requests pause and it resets in 2 to 3 days. Do not pause everything.

Lead states and cross-client dedupe

Not Contacted, In Campaign, Contacted, Not Accepted (unaccepted after 14 days, auto-withdrawn), Replied (stops the campaign for that lead), Duplicate, Blacklist, Failed.

Turn on "skip leads contacted by another campaign". At agency scale this is not optional, because two clients with adjacent ICPs will otherwise both message the same person in the same week.

Sender assignment is random from the accounts under their cap, then fixed for that lead, so one person never gets messages from two of your accounts in the same campaign.

Stage 6: campaign-diagnostic

Run weekly per client. Diagnoses causally rather than listing numbers.

mkdir -p .claude/skills/campaign-diagnostic

---
name: campaign-diagnostic
description: Diagnose why a client campaign is underperforming. Weekly.
---

Pull per client: requests sent, accepted, messages sent, replied,
meetings booked.

Work the chain in order. Stop at the first failure.

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: is the signal specific, one ask, under 300 characters.

3  REPLIES FINE, MEETINGS LOW
   The outreach works. The ask or the offer is the problem.
   Check: is the meeting asked for at the right moment, is the agenda
   named.

4  ALL FINE, VOLUME LOW
   Not quality. Check the cap split across this account's campaigns.

Output the failing stage, the evidence, and ONE change. Never more than
one per week or you will not know which one worked.

Write to clients/[CLIENT]/report/week-[DATE].md.

The numbers come out of Prosp directly, or into the client's CRM: native HubSpot integration with OAuth and field mapping, 12 webhook events including Message Replied and Connection Accepted, and a REST API at prosp.ai/api/v1/leads. So the weekly report builds from campaign data rather than screenshots.

Set the lead source to name the campaign, not the channel. "LinkedIn" tells the client nothing three months later.

The weekly loop across a portfolio

Monday     campaign-diagnostic per client. One change each, no more.
Monday     Check parked accounts and cap usage against allocation.
Tuesday    Top up lists. Grade before import. Below B, rebuild.
Daily      Work the unified inbox. Filter by replied and unread.
Friday     Client reports out of report/.

The unified inbox spans every connected account with tags and filters by campaign, replied and unread, which is what makes a daily pass across eight clients a single task rather than eight logins.

Pricing at agency volume

Worth knowing before you quote a retainer, since the cost per client falls as you add them.

$79.99 per account per month at 1 to 5 accounts. $59.99 at 6 to 30. $39.99 at 31 plus. Annual saves around 23%, quarterly around 12%.

The 6 to 30 tier adds a dedicated Slack channel and a 1:1 outbound specialist session every four weeks.

There is also a 30% uncapped affiliate programme, which is relevant if you are recommending it to clients who will run their own accounts rather than buying seats through you.

Fable 5 builds the system. Prosp runs it, across every client account 💜

↳ Start a 14 Day Free Trial 💜 ↳ Watch Full Tutorial ▶️