Silent Prospect

A folder-based AI diagnostician that tells you why a local trades owner ignored the free website you built them.

Not how to fix it. Why it failed.

---

The failure it diagnoses

You run build-first outreach: you find a local service business, build them a complete spec website from their real data, and text them a link. The site is the pitch. The text just has to earn a tap.

Most of them never answer. Silence is uninformative — a plumber who never got the message and a plumber who tapped the link, read the whole site, and decided against it look identical in your CRM. They have nothing in common and require opposite responses.

Silent Prospect works backward from that silence to the mechanism that produced it.

What makes this domain hard

Build-first outreach fails differently from cold email, and generic outreach advice actively misleads here:

• The dominant failure is disbelief, not disinterest. "I built you a website" is an unverifiable claim from an unknown number. Whether the link preview card rendered often matters more than every word in the message.
• Unrequested work triggers suspicion as readily as reciprocity. That is a structural property of the model, not a copy defect, and no rewrite addresses it.
• The prospect's progress is partially observable — delivery, read receipt, tap, time on site. That turns diagnosis into elimination rather than opinion, which is what makes a real diagnosis possible here at all.

How to use it

1. Create a Claude Project.
2. Upload the whole folder as project knowledge.
3. Set the project's custom instructions to: Read CLAUDE.md first. Load only what its routing table calls for. Diagnose, then stop.
4. Paste your case (below) and ask: "Why did this prospect go silent?"

Works the same way if you drop the folder into a Claude Code session, where CLAUDE.md is picked up automatically.

What to feed it

Required:

• The message you sent, verbatim, including follow-ups
• The prospect dossier — business name, vertical, review count and rating, years in business, service area, whether they already had a website, anything else your research produced

Strongly recommended — this is what separates a real diagnosis from a guess:

• Delivery status and bubble color (blue/green)
• Whether the link preview card rendered in the thread. Most operators don't record this. It is frequently the deciding evidence.
• Read receipt timestamp
• Tap timestamp and time on site
• The staging URL, or a description of what the site actually contained

For a campaign-level diagnosis: the same fields across 20+ prospects. See reference/benchmarks.md for the log schema.

If you have nothing but the message, it will tell you so and name the one observation that would unblock it. That is a correct answer, not a failure.

What you get back

1. One primary cause, stated as a mechanism
2. The evidence — specific things in your artifacts that point there
3. The differential — what it ruled out, and why
4. A confidence rating — high, moderate, or insufficient

Then it stops. No rewrite. No fix list. No "consider testing." If you want a new message, that is a different tool.

What's in the folder

CLAUDE.md                              the map — routing table, naming conventions, tool wiring
identity.md                            who the diagnostician is, and what it refuses to be
rules.md                               the method: signal ladder, premise check, evidence gate, stop rule
examples.md                            three worked diagnoses, including one that declines to diagnose
reference/failure-modes.md             causes catalogued by where they become visible
reference/diagnostic-frameworks.md     the reasoning tools and their limits
reference/benchmarks.md                the log schema — deliberately ships with no invented numbers
cases/                                 your completed diagnoses (created on first run)
receipts/                              unedited transcripts of three blind live-fire runs — provenance inside

CLAUDE.md is read on every task and routes to the rest. A rung-0 channel failure loads two files; a campaign diagnosis loads four different ones. Nothing loads all of them, because a diagnosis of a message that was never delivered has no use for a catalogue of artifact-layer failure modes.

Case filenames carry the rung — 2026-08-08_dave-plumbing_rung2.md. That is deliberate: clustering is the campaign diagnosis, so ls cases/ answers "where does this campaign break" before you open anything.

Design notes

The signal ladder does the heavy lifting. Delivery → read → tap → reply. A cause above the observed stopping point cannot be the primary cause. If they tapped, the hook worked, however weak it looks. This is the guardrail against the failure mode this tool is most prone to: critiquing the message because the message is short and easy to have opinions about, when the message is the one thing already proven to have worked.

It is allowed to refuse. Naming a cause requires an observation that discriminates it from the runner-up. Absent that, the output is "insufficient evidence" plus the single test that would settle it. Guessing between four incompatible explanations to seem decisive sends the operator to fix something that was never broken.

benchmarks.md contains no benchmarks. There is no credible public baseline for this motion. Borrowing cold-email numbers would produce confident, wrong comparisons, so the file ships as a log schema instead.

Provenance

Extracted from a production build-first outreach pipeline (forge-pipeline — Temporal + LLM agents, discovers local-business prospects, builds each a spec site, runs outreach). The failure modes here are ones that pipeline produced.

The first-person customer-simulation pass and the anti-fabrication evidence gate are adapted from founders-circle.

Built by Sage Dutra. MIT.