Site prospector

Site Prospector

<objective> The front of the local-website business: find businesses that would benefit from a free demo site, surface them with honest reasoning, and — for the ones the user picks — verify the facts, build and deploy a site, and produce ready-to-send outreach. It **orchestrates `site-forge`** for the build (Claude invokes it; they hand off via a shared brief file) and keeps a **bounded ledger** so the pipeline never loses state and never grows forever. Truth discipline is core: claims get verified or labeled, and demo sites carry a not-affiliated disclaimer. </objective> <context> @ledger/index.md </context>

<execution_context> Autonomous by default — a hands-off finder→builder. Required stops: (1) the user picks which candidates to pursue (Phase 2), and (2) anything that sends or publishes externally.

• 🟢 Auto: search, evaluate, fact-verify, write the brief, invoke site-forge (in auto), deploy the demo, draft outreach, update the ledger.
• 🟡 Ask: which candidates to build (always); repointing form leads; custom domains.
• 🔴 Never: send/publish outreach without explicit go (drafts only); publish a flagged-unverified claim without the demo disclaimer; pay for anything. Quality note: each demo is built as well as is autonomously reachable, then a per-site "upgrade to full" flag is surfaced so a winner can be re-run with site-forge full for Gemini/Veo media. </execution_context>

<process> <phase name="1_scout"> ## Phase 1 — Scout candidates Find businesses matching the brief (trade + area) via jina/web/maps — see `references/candidate-search.md`. Strongest signal: a real, reputable business with **no working website or a parked/for-sale domain**. Gather per candidate: name, owner, contact channels, current web presence (or lack), and one specific honest hook. </phase> <phase name="2_present_and_pick"> ## Phase 2 — Present + pick Present candidates with **honest reasoning** (hook, reputation reality, fit, ease) using the rubric in `references/candidate-search.md`. Let the user pick one or more (AskUserQuestion). No cheerleading — surface the weak ones as weak. </phase> <phase name="3_verify"> ## Phase 3 — Verify facts (truth discipline) Before building, verify each pick — license, ratings, affiliations, years, entity identity — per `references/fact-verification.md` (Sunbiz, DBPR, BBB, manufacturer locators, Yelp/BuildZoom; watch the same-name entity trap). Mark each claim **verified** or **aspirational**; aspirational claims may go on a *demo* with the disclaimer, never presented as fact. </phase> <phase name="4_build"> ## Phase 4 — Build (orchestrate site-forge) Per picked business, write/update its ledger entry `ledger/active/<slug>.md` (details, verified facts, hook, voice, assets — the entry doubles as the build brief, so there's one file, not two). Then **invoke the `site-forge` skill in `auto` mode**, pointing it at that file. site-forge owns the build — do not duplicate its recipes here. If `site-forge` isn't installed, say so and offer to install/locate it. </phase> <phase name="5_deploy"> ## Phase 5 — Deploy + disclaimer site-forge deploys; confirm the live URL and that the demo carries the not-affiliated disclaimer. Record the URL. </phase> <phase name="6_outreach"> ## Phase 6 — Tailored outreach (drafts only) Generate a copy-pastable outreach page with `scripts/outreach-page.sh` — sequenced FB DM → email → text, cross-referenced, with timing + one follow-up — per `references/outreach.md`. **Draft only; never send.** Pricing/positioning in `references/monetization.md`. </phase> <phase name="7_ledger"> ## Phase 7 — Ledger update Append/update the entry per `references/docs-ledger.md`: status, URL, verified facts, outreach drafted, decisions, $. Apply the rolling-window bound (recent entries full; older compacted to one-liners in `ledger/archive.md`). </phase> </process>

<saved_rules_format> Accumulate learnings in ledger/lessons.md (durable). Format: - {topic}: {rule} — set {YYYY-MM-DD ET} e.g. "channel: FB DM first for solo trades", "verify: same-name LLC trap is common", "skip: businesses with a current modern site". Surface relevant rules at the start of a run. </saved_rules_format>

Bounded ledger (never grows forever)

• ledger/index.md (@-loaded): one line per business — slug · status · URL · last-touched. Pruned to the most recent ~30; older roll to archive.md.
• ledger/active/<slug>.md — full entry while in-flight.
• ledger/archive.md — one-liners for closed/cold businesses.
• ledger/lessons.md — saved rules. Format + rollover rule: references/docs-ledger.md.

<recovery_protocol> Interrupted mid-scout → resume from candidates in ledger/active/. Mid-build → check whether the site-forge run produced a deploy; resume from Phase 5. Mid-outreach → the drafts page is idempotent; regenerate. Never re-send (drafts only, nothing to double-send). </recovery_protocol>

<error_handling>

• site-forge not installed → surface; offer to install/locate. Never inline its build logic.
• Fact sources blocked/empty → fall back to a researcher agent; an unverifiable claim stays aspirational, never asserted.
• Same-name entity ambiguity → stop and confirm identity before building.
• Ledger index > ~30 entries → roll oldest to archive.md (one-liners). </error_handling>

<success_criteria>

• Candidates presented with honest, evidence-based reasoning.
• User explicitly picked which to pursue.
• Facts verified or labeled aspirational; demo carries the disclaimer.
• Site built via site-forge (not re-implemented here) and deployed.
• Outreach drafted (never sent), sequenced + cross-referenced.
• Ledger updated; index bounded; lessons captured. </success_criteria>