unbroker skill

unbroker

Find where a person's personal information (name, addresses, phone, email, relatives) is exposed on data brokers and people-search sites, then remove it - automatically where possible, with guided human steps only where a site demands a CAPTCHA, government ID, phone call, or fax. Manages multiple people independently. It does not defeat anti-bot systems, does not act on anyone without recorded consent, and does not remove public records (voter/property/court) or accounts the person controls.

The Python CLI (scripts/pdd.py) owns the deterministic state - config, dossiers + consent, the broker database, tier planning, the ledger, drafts, reports, email sending (SMTP), verification-link polling (IMAP), and the autonomous action queue (next). You (the agent) do the scanning and form-driving with native tools: webextract and browserexec for searching and web forms, and cronjob for recurring re-scans. Runs can be entered from a phone number alone (spam-call scrubbing), with the FTC Do Not Call registry one-shot (dnc) alongside the opt-outs.

Autonomy contract

This skill is designed to run hands-off. After intake (+ recorded consent) there are exactly TWO legitimate human touchpoints: (1) the intake conversation itself, and (2) ONE consolidated human-task digest at the end of the run ($PDD tasks). Between those:

picks the most autonomous valid config itself.

• Never ask the operator to choose configuration. $PDD setup --auto detects capabilities and

recorded at intake is standing authorization for T0-T2 opt-outs. The one exception: an action carrying confirmfirst: true (always set on dncregister, a registry signup the intake consent does not cover) waits for the operator's yes in every mode. (autonomy=assisted sets confirm_first on every submission for cautious operators.)

• Never pause before individual submissions when autonomy=full (the default): the consent

--reason "...") and keep going; it all surfaces once in the final digest.

• Never interrupt the run for human-only work. Record it (record ... humantaskqueued

to take right now (scan, poll verification, re-check, opt out parents-first, requeue blocked), plus the human digest. Execute every action, record outcomes, re-run next, repeat until donefornow. Then present the digest, report, and schedule the cron.

• Drive the whole run as a loop over $PDD next - it returns the exact ordered actions

The hard limits that autonomy never overrides: no acting without recorded consent, no disclosure beyond disclosurefields, no CAPTCHA/anti-bot bypass, and confirmedremoved only after a verifying re-scan.

When to Use

out, register it on the Do Not Call Registry, and re-check on a schedule.

• "Remove my (or my family member's) data from data brokers / people-search sites."
• "Opt me out", "delete me from Spokeo/Whitepages/etc.", "clean up after a doxxing."
• "Set up recurring privacy monitoring" (brokers re-list people).
• Checking which brokers still expose someone and why.
• "My number keeps getting spam calls" - phone-led scrub: find where the number is listed, opt

Prerequisites

one it detects, reading credentials from the shell env and from $HERMESHOME/.env** so keys Hermes already loads for its own tools are picked up without re-exporting - each one converts a class of human tasks into agent actions):

• python (stdlib only; no extra packages needed for the core engine).
• Optional upgrades (the skill works zero-config without these; setup --auto turns on every

whenever the key is present, and it is the intended baseline: a real residential-IP cloud browser clears soft/managed CAPTCHAs (Cloudflare Turnstile, hCaptcha/reCAPTCHA checkbox) as normal operation, so those brokers stay automated (T1) instead of becoming human tasks. This is not CAPTCHA "solving" - no solver service, no fingerprint spoofing; only interactive/behavioral ("hard") challenges the browser genuinely cannot pass fall back to a human task. Without the key, the plain agent browser is used and soft-CAPTCHA brokers drop to T2 (human).

• Cloud browser (recommended default): BROWSERBASEAPIKEY. setup --auto selects it

emails and opens verification links through the operator's logged-in webmail using browserexec. Nothing is stored. This requires Hermes to be pointed at the operator's own logged-in browser, NOT a cloud browser: a headless cloud browser (Browserbase) holds no webmail session and is itself Cloudflare/DataDome-gated on webmail and on session-bound broker gates (e.g. PeopleConnect guided-mode). Drive the operator's real Chrome over CDP - launch chrome --remote-debugging-port=9222 --user-data-dir="$HOME/.hermes/chrome-debug" (a dedicated debug profile signed into the webmail once, not the Default profile) and attach Hermes's browser to 127.0.0.1:9222 with /browser connect. $PDD cdp launches this for you** (finds Chrome/Chromium/Brave/Edge, starts it detached on the dedicated profile, prints the CDP endpoint; --check to test, --print for the command). See references/methods.md -> "Browser backends: scan vs execute". Falls back to drafts for an email if the inbox isn't reachable.

• Email automation, two credential-free-or-not options:
• Browser mode (no password): setup --email-mode browser. The agent sends opt-out/CCPA

EMAILIMAPHOST for non-mainstream providers; gmail/outlook/yahoo/icloud/fastmail inferred). The CLI sends via send-email and reads verify links via poll-verification. The agentmail skill (per-broker aliases) also counts.

• SMTP/IMAP (stored creds): EMAILADDRESS + EMAILPASSWORD (+ EMAILSMTPHOST /

• Google Sheets tracker: the google-workspace skill.
• The scrapling skill for stealth/Cloudflare-protected pages.

How to Run

Run everything through the terminal tool. From this skill's directory:

PDD="python scripts/pdd.py"

The engine stores data under $PDDDATADIR (default $HERMESHOME/unbroker), written 0600. Run via terminal, not executecode (that sandbox scrubs env and redacts output, which breaks reading the dossier).

Quick Reference

Batch operation (two-phase: crawl-all, then delete)

For anything past a couple of brokers, run this as map → reduce → act, not broker-by-broker:

verdict for each (found / notfound / indirectexposure / blocked). Scanning has no side effects, so it is safe to parallelize and retry. Getting the full exposure map before acting is what unlocks cluster dedup and prioritization below. Default: the parent drives webextract probes directly - most people-search sites render name/phone/address results as static HTML that webextract reads in seconds. Escalate to browserexec only for the few JS-only sites, and to delegatetask subagents only for genuinely reasoning-heavy work (large-scale namesake/relative disambiguation). Do NOT hand a browser-toolset subagent a big list of brokers to crawl - in the field this timed out repeatedly (600s, ~5-6 brokers each, no summary) because browser navigation is heavy; the ledger writes that survived came at 10x the cost of parent webextract. A blocked (DataDome/Cloudflare/antibot) site is not* a subagent job either: record blocked and requeue it for a stealth/cloud browser (Browserbase) pass. Subagent reports are self-reports - the parent re-fetches key URLs to confirm a found before trusting it (this cuts both ways: it caught a real listing the parent had wrongly assumed was a false positive).

• Phase 1 - DISCOVER (read-only, parallel, idempotent). Crawl every broker first and record a

next action, collapses ownership clusters (a parent removal that clears children is ONE action, not N - e.g. one Intelius/PeopleConnect suppression covers Truthfinder/Instant Checkmate/US Search/…), and prints next_actions. phase is discover while anything is unscanned, else delete.

• REDUCE - $PDD plan --batch. Collapses the crawl into a phase-oriented plan: groups by

plan --batch orders the found group cluster-parents-first (most children first) and emits a parentplaybook with tailored, ordered steps per parent - follow that order and those steps (full recipes in references/methods.md → "Ownership clusters - DO PARENTS FIRST"). Do the cluster parents (skipping the covered children), re-scan each parent's children after it confirms (they usually drop out), then the standalone listings; send the indirectexposure cases as CCPA/GDPR delete-my-PII emails (send-email --kind ccpaindirect), and defer blocked to the stealth-browser pass. Opt-outs hit CAPTCHAs, email-verification loops, and session binding - work them one at a time, carefully (this is the opposite of fan-out), but do NOT stop to ask permission per submission in autonomy=full; in assisted, confirm each one. Usually prefer deletion over suppression where a broker offers both (Spokeo/BeenVerified) - but follow the record's deletion.prefer: PeopleConnect is the exception** (prefer: false), where deleting your user data removes your suppressions and does not stop public-records re-listing, so you suppress-and-maintain instead.

• Phase 2 - DELETE (sequential, irreversible). Work the reduced groups parents first:

accessible removal channel, even when a listing was not first confirmed - it discloses only the subject's own identifiers to the broker's own official channel, so it does not violate least-disclosure. Two corollaries: (1) a guided flow that matches email+DOB+name and says "no results" is a stronger notfound than any scrape - the opt-out flow doubles as the search; (2) when a form is automation-hostile (hard CAPTCHA, Cloudflare/DataDome, slide-to-verify slider), default to the broker's cited rights-request email (name+state+contact-email only) rather than recording blocked. CAPTCHA policy: never defeat behavioral/token/slider challenges; OK to read a static distorted-text or plain-arithmetic CAPTCHA on the subject's own opt-out, but stop if the site rejects the whole submission after a correct answer (it is fingerprinting the automation). Third-party/indirect records are the exception - still confirm those before acting. Per-site game plans + the meta-search no-op skip-list are in references/site-playbooks.md; the full policy is in references/methods.md.

• Blind opt-out is the DEFAULT, not a fallback. Submit an opt-out/deletion on **every site with an

suppression and the subject re-lists across the whole affiliate cluster. If a "Your deletion request for PeopleConnect.us is Complete" email ever appears, the suppression is gone -> re-run suppression and re-verify the Control step reads "suppressed". Never leave this cluster on a completed deletion (see references/brokers/intelius.json).

• PeopleConnect delete-wipes-suppression (permanent rule). A PeopleConnect deletion wipes the

Subagent reports are self-reports: the parent re-verifies key claims (listing URLs, match basis) before recording found and before any deletion.

Procedure (the autonomous loop)

the most autonomous valid combination itself (programmatic email when EMAIL creds exist, Browserbase when its key exists, age encryption when the binary exists, autonomy=full). Then $PDD doctor and show the operator the readiness output for information, not as a question** - proceed immediately. Mention what would unlock more automation (e.g. email creds) but do not wait.

1. Setup (once, no questions). Run $PDD setup --auto - it detects capabilities and configures

--consent-method). Without consent the engine refuses to plan or act. Collect everything in one pass - names/aliases, current + prior cities, emails, phones - so you never have to come back with questions. For California subjects, also read references/legal/drop.md: next will surface a drop_submit one-shot that deletes from every registered broker (~545) at once, which is the single highest-leverage action. File it, then drop --filed. For non-CA subjects the registry is covered by targeted CCPA/GDPR emails (registry --search, then send-email); the people-search sites are worked directly in either case.

1. Intake + consent (the ONE human conversation). $PDD intake ... with --consent (and

1. Drain the queue. Loop:

while true:
     q = $PDD next <subject>
     if q.actions is empty: break
     execute EVERY action in order; record each outcome via $PDD record

next emits, in order: refreshbrokers (stale cache), fanoutscan/scaninline (Phase 1 crawl - see step 4), pollverification (in-flight email confirmations), verifyremoval (due re-checks), optoutwebform/optoutemailsend (Phase 2, parents-first with playbook steps), indirectemailsend, and stealthrescan. Human-only work never appears as an action - it accumulates in q.humandigest. In autonomy=full, execute actions without pausing, except any action with confirmfirst: true, which waits for the operator in every mode.

delegatetask subagent per batch, in parallel, passing that batch's ready-made brief - do not scan all brokers yourself sequentially. For scaninline: scan the few brokers yourself. Either way, each broker gets every searchvectors entry via the references/methods.md ladder (webextract → site: probe → browserexec → scrapling), a 404 is INCONCLUSIVE (not notfound), blocked is recorded when antibot is set and no stealth browser is available, and subject vs namesake/relative is confirmed before recording: $PDD record --found --evidence '{"listingurls":[...]}'. The parent re-verifies key found claims from subagents before trusting them.

1. Scanning (when next says so). For fanoutscan: run $PDD fanout and spawn one

broker record's own optout.playbook (field-verified; cluster parents like PeopleConnect, Whitepages, BeenVerified, Spokeo have exact, live-checked recipes). Deletion usually beats suppression: when an action carries preferdeletion, complete the record's DELETION lane, not just the hide-my-listing flow. When it carries prefersuppression instead (PeopleConnect - deleting removes your suppressions and does not stop re-listing), do the suppression flow and keep it maintained; use their Delete button only for a deliberate data-purge. Per method:

1. Opt-outs (when next says so). Actions come pre-ordered parents-first with steps from each

a js() click to submit), submit only disclosurefields, capturescreenshot() the confirmation, then the action's after record command. Playbooks may end with a right-to-delete send-email follow-up - do it (full erasure, not just listing suppression).

• webform → drive optouturl with browserexec (newtab + waitforload, fill_input,

--listing records + discloses in one step (recipient locked to addresses the broker record declares; next picks the kind from residency - never claim CCPA/GDPR for someone who can't). In browser mode it returns a recipient-locked compose payload: compose a new message to compose.to with compose.subject/compose.body exactly in the operator's webmail via browserexec and send (no password); in programmatic mode it SMTP-sends. next also routes human-gated forms (phone-callback/gov-ID) through a broker's deletion email when one exists - the rescue lane** (verified Whi