Lead Plan

---
# GENERATED from SKILL.md.tmpl — edit the .tmpl, then run scripts/build.sh.
name: lead-plan
version: 0.5.11
publisher: localoy
capabilities: [files, web]
# No localoy stages: this is one structured conversation plus one document.
# A small model finishes it in a single turn; splitting it buys nothing.
# The plan's headings are checked on disk at the end of the turn: a model
# that skipped the outreach questions is sent back to settle them.
produces: PLAN-{slug}.md
# The user decides these themselves; the app sends a plan back until each
# was asked (a list-only job asks them too: they decide who is on the list).
asks:
  - topic: company size (a range, in the unit that fits)
    words: [size, how big, how large, employees, people, staff, headcount, outlets, branches, locations, sites, trucks, beds, rooms, seats, revenue]
  - topic: the person who would reply (role at that size)
    words: [who should, who would, who replies, who answers, who decides, decision maker, role, title, owner, founder, manager, person]
sections: [What we sell, Who buys, Territory, List size target, Disqualifiers, Trigger, Angle and ask, Proof we can offer, Channel and sender, Outreach rules, Cadence, Success, Can it be done]
description: Plan a whole outreach campaign — who to reach and why now, what we say and offer, the channel, cadence and follow-ups, and what counts as success — as PLAN-<topic>.md, the plan every later sales step reads and ticks off. (localstack)
author: localoy
license: MIT
platforms: [linux, macos, windows]
metadata:
  hermes:
    tags: [sales, planning, icp, localstack]
    related_skills: [lead-search, lead-retro]
allowed-tools:
  - Bash
  - Read
  - Write
  - WebSearch
  - WebFetch
  - AskUserQuestion
triggers:
  - define our icp
  - prospecting brief
  - plan our prospecting
  - who should we target
  - write a brief
tags: [sales, plan, icp, brief]
---

## When to invoke this skill

Turns "find me people to sell to" into a plan for the whole outreach the user
is about to run — not just a search. Who we reach and why now, what we say
and what we ask for, through which channel, how often and how many times,
and how we will know it worked. The list exists to serve the message: a lead
nobody can reach, or nobody would reply to, is not a lead. It is `PLAN-<topic>.md` in the working folder — a
standard file any agent can open and pick up from. Use when asked to "define
our ICP", "plan prospecting", or before a lead run.

A **topic** is one piece of sales work, named as a short lowercase slug from
the niche and territory: `austin-dentists`, `berlin-saas-cfos`. Everything for
it shares the name: `PLAN-<topic>.md`, `leads-<topic>.csv`.

## What you read first (optional seeds — never required)

1. **A document the user points at** — a positioning doc, a pitch, a plan.
   If they name one, read it and offer to seed the plan from it. Its
   contents are the user's own context, not observed web fact.
2. **An existing plan:** `ls PLAN-*.md 2>/dev/null`. If one matches this
   topic, offer "revise this plan" vs "start a new topic". Its newest
   `## Retro` section may carry a "Change next time" list; if it does, put
   those items on the table explicitly.
3. **DESIGN.md**, if present — positioning, tone and channel decisions
   already made. Do not re-ask what it settles.

None found → interview the user directly, then wait.

## Outreach or list only?

"to sell to", "we sell X", "for our product", "customers for", a named
product — the user is going to reach these people: plan the outreach. List
only when they say so ("just the list", "for research", "to hand to my
team"). When it is truly unclear, ask once; never decide list-only yourself.

## Think before you ask — the user will not spell everything out

Users describe the trigger ("whose competitor just raised") and forget the
shape of a buyer. Do not expect a better prompt; your job is to notice the
gap. Before asking anything, picture the list a plain search would return
for their words — the first five names that come to mind. Then ask yourself:

- **Could they actually sell to these?** If the obvious names are giants,
  household brands, or companies already served by big vendors, company size
  is the first question.
- **Would this person answer?** A CEO of a 5,000-person company never reads a
  cold note. Ask which role really owns the problem at the size they pick.
- **Is the trigger testable?** Name what counts as proof ("a comparison page
  either side publishes", "a dated announcement"), and what does not ("both
  named in one market report").
- **Is anything doubled?** Many targets resting on one event (one round, one
  news story) make a thin list — ask whether that is fine.
- **Where are they, really?** The region decides the channel people answer
  (WhatsApp in Brazil, India, the Gulf and much of Africa; Facebook pages
  for small shops in Bangladesh or the UK; contact forms in Japan; LINE,
  KakaoTalk, phone), the language the messages are written in, and the
  cold-outreach law (GDPR and UWG in Germany, PECR in the UK, CASL in
  Canada). Recommend the local channel and ask about the language; name the
  law in the plan when it limits who can be written to. Germany, one rule:
  cold email to a business needs prior consent (UWG §7(2) Nr. 3, no
  "presumed consent" for email); a B2B phone call may rest on presumed
  consent (§7(2) Nr. 2); a contact form counts as email.
- **What happens after we find them?** Walk the outreach to the end: what
  the first message says, what it asks for, where it is sent, who sends it,
  how many follow-ups. Every step the user hasn't decided is a question —
  a list built for a channel the user won't use is wasted work.

Two questions are always asked, even when you could decide them, because
they change every row: **company size** (a range in the unit that fits —
people, outlets, trucks, beds) and **the person who would reply** at that
size. Ask each with your recommendation first. Every other gap that would
change who is on the list becomes a question too — asked in **two rounds
at most**, never one by one. Round one, in a single ask call: the questions
that change the list (size, the person who replies, territory, channel — up
to four). Round two, only if needed: what is still open (proof, sender,
cadence). Each question has 2–4 concrete options, your recommended one
first and marked "(recommended)", and a few words on why it matters. Never
ask what the user already said; anything left after round two, decide
yourself and mark as your pick. A plan written before these are settled records them as
`UNKNOWN — ask before the run`, and the run does not start.

## What the plan must pin down — the whole outreach

Who
- **What we sell** — in the buyer's words, not the website's copy.
- **Who buys (ICP)** — company size (a range in people, always — asked if
  not given), the situation that makes them buy, and the person who would
  actually reply at that size (not the most senior title).
- **Territory** — "anywhere" is a choice the user makes, not a default.
- **List size target** — decides the fetch budget downstream; 500 at most per round.
- **Disqualifiers** — the cheapest quality lever in the pipeline:
  `/lead-qualify` cuts with exactly these.

Why now and what we say
- **The trigger** — the event that makes this the moment (a rival raised, a
  new hire, a launch), and what counts as proof of it on a page.
- **The angle** — one sentence connecting their trigger to our product, in
  their words. If the trigger doesn't lead to a sentence they'd care about,
  the list is wrong, not the copy.
- **The ask** — what a yes looks like: a reply, a 15-minute call, a trial, a
  free audit. One ask per message.
- **Proof we can offer** — a customer, a number, a demo link the user
  really has. UNKNOWN if none; never invented.

How
- **Channel** — email, LinkedIn, contact form, phone; what the user can and
  will actually send from, and what they never do.
- **Sender** — whose name the messages go out under, and the tone.
- **Cadence** — first touch plus how many follow-ups, how many days apart,
  and how many sends a day (deliverability and the user's own time).
- **Outreach rules** — the cold-outreach law for the territory and channel,
  named (CAN-SPAM in the US, PECR in the UK, GDPR and UWG §7 in Germany, CASL
  in Canada, the Spam Act in Australia, LGPD in Brazil, PDPL in Saudi
  Arabia, Japan's 特定電子メール法…), and what it means for this list in one
  line: who may be written to cold, what every message must carry (sender
  identity, an opt-out), what is off limits (personal emails, private
  individuals). Every outreach plan has it; not knowing the law is a reason
  to look it up, not to skip it.
- **Success** — what counts as working (replies, calls booked) and when the
  retro looks at it.

## Ground rules (non-negotiable)

1. **The brief records what the user said**, plus anything observed on the
   web with its URL. No invented market facts, no imagined competitor lists,
   no "typically these buyers..." filler.
2. **A fact the user did not supply is written as
   `UNKNOWN — ask before the run`** — never guessed. A brief with honest
   holes beats a confident wrong one.
3. **Light web checks are allowed, cited — never the search itself.** No
   harvesting candidates, no lists of companies, no lead rows while planning;
   the search starts after the user's yes. Confirming a niche's vocabulary or
   a territory's shape is one or two searches, each cited inline; this is a
   planning skill, not a research run.
4. **What we sell is the user's words.** A bare brief with no product gets
   one question about it; if they still don't say, write "not given — drafts
   stay generic", never a product, offer, price or sender you made up.

## Can it be done — find out before the run

Before the plan is final, size it with two or three searches (snippets only,
no page reads): how many companies like this exist where the user sells, and
how many are likely to pass the disqualifiers. Write one line under
`## Can it be done`: "Expect about 8–12 of the 20 wanted" and why.

When the plan cannot be met as asked, say so plainly in the plan and in one
question with the closest workable versions as options, recommended first —
never start a run that will end in a padded or empty list:

- **Too few exist** ("expect about 3"): widen the one rule that limits most
  (size, region, trigger window), or accept fewer.
- **Too many** — a plan's list is **500 at most** (owner, 2026-10-03). Asked
  for more, offer 500 (recommended: the best-fitting segment first) or a
  smaller sample to prove the fit; later rounds add the next 500, skipping
  what was found.
- **Private people are never the list.** Homeowners, patients, parents,
  job seekers, any person as a consumer — even from public records (tax rolls,
  court filings, licence lists of individuals). Localoy finds businesses and
  the people who run them in their work role, nothing else (owner, 2026-10-03).
  Say so in one line and offer the business version as the recommended
  option: for "homeowners who need solar", the installers, roofers and
  builders who serve them, or the businesses with roofs. Never offer the
  private-person list as an option. Outreach the territory's law forbids is
  out the same way.
- **Too vague to search** ("100 companies"): the decisions in round one fix
  that; if they don't, ask once more instead of guessing.

## A new round starts from the last

When `leads-<topic>.csv` already exists, the plan opens from it, before any
question:

- **Already found** — counts by verdict (keep / close / cut), the close rows
  still waiting on the user's call, and one line: every company in the list
  is skipped by the next search (matched by its website's domain).
- **Search angles** — which angles produced keeps, which ran dry (DROPPED,
  with why); the next round starts with the working ones and new ones, never
  a dropped one.
- **What to change** — if most close rows miss the same rule ("over 200
  people" eight times), ask once whether to loosen it; that question replaces
  a round of new searching.

Never start a topic's second round from nothing: the list and the angles are
what the first one paid for.

## Procedure

**1. Seed or interview** per the discovery order above, with the questions
from "Think before you ask". Company size and the reachable person are
always settled before the plan is final.

**2. Write the plan.** `PLAN-<topic>.md`. Revising an existing plan edits
it in place: keep its `## Steps`, `## Drafts`, `## Retro` and other sections
the later steps wrote; change only the brief sections. Template for a new one:

```
# Plan: <topic>

## What we sell
## Who buys (ICP)
## Territory
## List size target
## Disqualifiers
## Trigger              (the event, and what proves it on a page)
## Angle and ask        (one sentence why now; what a yes looks like)
## Proof we can offer
## Channel and sender
## Outreach rules       (the law that applies and what it means here)
## Cadence              (first touch + follow-ups, days apart, sends a day)
## Success              (what counts, when we look)
## Search angles        (a table lead-search keeps: angle | checked | kept | close | status — open, working, DROPPED: why)
## Can it be done       (the sizing check: expected count, or why not, and the closest workable version)
## Already found        (on a new round: what the list holds — see "A new round starts from the last")

## Steps
- [ ] search    — /lead-search finds leads into leads-<topic>.csv (or bring your file to /lead-qualify)
- [ ] qualify   — /lead-qualify checks each row, fills the gaps, keeps or cuts
- [ ] draft     — /lead-draft writes ## Drafts below
- [ ] reach     — /lead-reach sends each draft after your yes
- [ ] retro     — /lead-retro writes ## Retro below

(Handing the list to someone else? /lead-export, any time — not a step.)

## Open questions
(each UNKNOWN still to settle, or "none")
```

**Standard files.** This folder is kept in files any agent already reads. Update them in place; never scatter output into new folders.
- **AGENTS.md** — create it if missing. localstack owns only the block between `<!-- localstack:start -->` and `<!-- localstack:end -->`; rewrite that block, never anything outside it. The block says what this folder is for, the rules (drafts only; nothing is sent without the user's explicit yes, one message at a time; no invented facts), a map of the files below, and one line per topic (its PLAN, its lead count, the next unticked step) and per report (its file and date).
- **CHANGELOG.md** — create it if missing (`# Changelog`). Add one bullet for this run under today's `## YYYY-MM-DD` heading, newest date first: the skill, the topic, and the counts or outcome (e.g. `- lead-search austin-dentists: 18 found, 3 skipped as already contacted`).
- **TODOS.md** — create it if missing (`# TODOs`). Add each open next action as `- [ ] <action> (<topic>)`; tick items this run finished; never delete lines.
- **DESIGN.md** — decisions meant to last (positioning, tone, channels to use or avoid). Read it before writing anything a person will see; add to it only when the user states or approves a decision.

When the user states a lasting decision while you interview — "we never cold
call", "keep it casual", "LinkedIn only" — offer to record it in DESIGN.md
under a dated line, and record it only on their yes.

**3. Read it back.** Show the user the plan's key lines in chat — who, why
now, the angle and the ask, channel and cadence, success — so a wrong premise
dies here, where it is cheap.

**4. Hand off** — only when `## Open questions` says none. Never offer the
search while a decision is still open, and never ask a question after the
hand-off. In Plan mode the hand-off IS the mode switch: one switch_mode offer
to Auto, not a separate "run it?" question first. Offer the next stage — "Run `/lead-search` against this
plan now?" — as a structured question where the runtime supports one, plain
text otherwise. On yes, invoke `/lead-search` if this runtime can invoke
skills directly (Claude Code: the Skill tool); otherwise tell the user to
type `/lead-search` (Codex: `$lead-search`).

## Quality bar

- The plan holds decisions, never work: no found companies, search results or
  progress logs in it — those go to the lead list and the changelog.
- One current section under each heading — revise in place, never append a
  second "Where we are" or leave answered items under Open questions.
- A list-only job (no outreach) says so once, and the outreach sections say
  "not part of this job" instead of asking about them.

- Every brief section present; unsupplied facts say `UNKNOWN — ask before the run`.
- `## Steps` present with all five steps unticked (or kept as they were, on a revision).
- AGENTS.md lists this topic; CHANGELOG.md has today's line.
- Disqualifiers are concrete enough to test against an observation ("no
  physical location listed", "aggregator-only web presence"), not vibes.
- The plan sections fit on one page. A brief nobody rereads mid-run is decoration.