/signal-scanner

name: signal-scanner
description: >
  Detect buying signals across TAM companies and watchlist personas.
  Three-phase architecture: (1) free diff-based signals from existing data
  (headcount growth, tech stack changes, funding rounds), (2) Apify-powered
  signals (job postings, LinkedIn content analysis, profile changes), and
  (3) post-processing with dedup, scoring, and lead status updates.
  Writes signals to Supabase signals table for downstream activation.
tags: [lead-generation]

Signal Scanner

Scheduled scanner that detects buying signals on TAM companies and watchlist personas, writes them to the `signals` table, and sets up downstream activation.

When to Use

• After TAM Builder has populated companies and personas
• As a recurring scan (daily/weekly) to detect timing-based outreach triggers
• When you need to move from static lists to intent-driven outreach

Prerequisites

• `SUPABASE_URL` + `SUPABASE_SERVICE_ROLE_KEY` in `.env`
• `APIFY_TOKEN` in `.env` (for Phase 2 signals)
• `ANTHROPIC_API_KEY` in `.env` (optional, for LLM content analysis)
• TAM companies populated via `tam-builder`
• Watchlist personas created for Tier 1-2 companies

Signal Types

| Priority | Signal | Level | Source | Cost | |----------|--------|-------|--------|------| | P0 | Headcount growth (>10% in 90d) | Company | Data diffs | Free | | P0 | Tech stack changes | Company | Data diffs | Free | | P0 | Funding round | Company | Data diffs | Free | | P0 | Job posting for relevant roles | Company | Apify linkedin-job-search | ~$0.001/job | | P1 | Leadership job change | Person | Apify linkedin-profile-scraper | ~$3/1k | | P1 | LinkedIn content analysis | Person | Apify linkedin-profile-posts + LLM | ~$2/1k + LLM | | P1 | LinkedIn profile updates | Person | Apify linkedin-profile-scraper | ~$3/1k | | P2 | New C-suite hire | Company | Derived from person scans | Free |

Config Format

See `configs/example.json` for full schema. Key sections:

• `client_name` — which client's TAM to scan
• `signals.*` — enable/disable each signal type with thresholds
• `scan_scope` — filter by tier, status, lead_status

Database Write Policy

**CRITICAL: Never write signals or update lead statuses without explicit user approval.**

The signal scanner writes to multiple tables: `signals` (insert), `enrichment_log` (insert), `companies` (patch snapshots), and `people` (patch lead_status). These writes affect downstream outreach decisions — bad signals lead to bad outreach timing.

**Required flow:** 1. **Always run `--dry-run` first** to detect signals without writing to the database 2. Present the dry-run results to the user: signal count, types, top signals, affected companies/people 3. **Get explicit user approval** before running without `--dry-run` 4. Only then run the actual scan that writes to the database

**Why this matters:**

• Signals drive outreach timing — incorrect signals trigger premature outreach
• `lead_status` changes from `monitoring` to `signal_detected` are hard to undo across many records
• Snapshot updates affect future signal diffs — bad snapshots cascade into future scans
• Enrichment log entries track Apify credit spend

**The agent must NEVER pass `--yes` on a first run.** The `--yes` flag is only for pre-approved scheduled scans where the user has already validated the signal detection logic.

Usage

# Dry run first (ALWAYS DO THIS) — detect signals without writing to DB
python skills/capabilities/signal-scanner/scripts/signal_scanner.py \
  --config skills/capabilities/signal-scanner/configs/my-client.json --dry-run

# Full scan (only after user reviews dry-run results and approves)
python skills/capabilities/signal-scanner/scripts/signal_scanner.py \
  --config skills/capabilities/signal-scanner/configs/my-client.json

# Test mode (5 companies max)
python skills/capabilities/signal-scanner/scripts/signal_scanner.py \
  --config configs/example.json --test --dry-run

# Free signals only (skip Apify)
# Set all Apify signals to enabled: false in config

Flags

| Flag | Effect | |------|--------| | `--config PATH` | Path to config JSON (required) | | `--test` | Limit to 5 companies, 3 people | | `--yes` | Auto-confirm Apify cost prompts. **Only use for pre-approved scheduled scans.** | | `--dry-run` | Detect signals but don't write to DB. **Always run this first.** | | `--max-runs N` | Override Apify run limit (default 50) |

Output

Signals table writes

Each signal includes: `client_name`, `company_id`, `person_id`, `signal_level` (company or person), `signal_type`, `signal_source`, `strength`, `signal_data` (JSON), `activation_score`, `detected_at`, `acted_on`, `run_id`.

Other database writes

• Person `lead_status` updated to `signal_detected` when activation_score >= threshold
• Company `metadata._signal_snapshot` updated for next diff cycle
• Person `raw_data._signal_snapshot` updated for next diff cycle
• `enrichment_log` entries with `tool='apify'`, `action='search'` or `'enrich'`, plus `credits_used`

Console output

• Summary stats printed to stdout

Activation Score

activation_score = strength * recency_multiplier * account_fit

Recency:   <24h = 1.5, 1-3d = 1.2, 3-7d = 1.0, 1-2w = 0.8, 2-4w = 0.5
Account:   Tier 1 = 1.3, Tier 2 = 1.0, Tier 3 = 0.7

Connects To

• **Upstream:** `tam-builder` (provides companies + people)
• **Downstream:** `cold-email-outreach` (acts on signals)

File Structure

signal-scanner/
├── SKILL.md
├── configs/
│   └── example.json
└── scripts/
    └── signal_scanner.py