inbox-miner

Run the extraction stage, which reads bodies only from allowlisted senders and uses a distill subagent to emit schema-validated signals with company name, kind, canonical URL, and provenance. Each signal is deduplicated by resolved canonical URL and presented at a write gate before anything is stored.

Stage A discovery uses metadata only — sender, subject, labels — and never calls get_thread. Stage B reads bodies exclusively from an approved allowlist, scoped to Gmail's promotions, updates, and forums categories so Primary personal mail is excluded by design.

Signals are deduplicated by the redirect-resolved canonical URL rather than by company, kind, and date. Within a run, all signals citing the same URL are merged into one event carrying all citing newsletters in metadata.sources, then checked against prior events in Supabase.

No. Every write to Supabase or Notion requires explicit approval at a resolved-target write gate showing exactly which company rows will be matched or created. The gate is permanent, and a missing SUPABASE_API_KEY causes a hard fail with nothing written or labeled.

If the plaintext body is under roughly 800 characters or matches stub patterns, the skill falls back to parsing the subject line, then resolving the primary link including base64-encoded click paths, and finally fetching the view-online archive URL. Stub-sourced signals are flagged with lowered confidence.

Email lacks strong natural keys, so deduplication is weaker than ATS or calendar-keyed sources and relies on the canonical-URL gate plus human review. The skill also cannot route event, job, or offer classes in v1 — those are only labeled for later phases.