New to Claude Skills? Learn how to install them →

gooseworks-ai on GitHub

Signal Scanner

Free

Detect buying signals for targeted outreach.

Get this skill

Free · Opens the source repo

What Signal Scanner does

Signal Scanner is a scheduled scanning tool designed to identify buying signals across Total Addressable Market (TAM) companies and watchlist personas. It operates on a three-phase architecture that leverages both free and paid sources to extract valuable insights. The first phase utilizes existing data to detect signals such as headcount growth, tech stack changes, and funding rounds. The second phase employs Apify to gather signals from job postings, LinkedIn content, and profile updates. Finally, the third phase involves post-processing to deduplicate results, score signals, and update lead statuses. This structured approach ensures that users can activate signals effectively for their outreach efforts.

The skill is particularly useful for sales and marketing teams looking to transition from static lists of leads to a more dynamic, intent-driven outreach strategy. By running scheduled scans, users can stay informed about key changes within their target accounts, allowing them to time their outreach more effectively. The integration with Supabase for storing signals means that users can easily access and utilize the data for downstream activation, enhancing their overall lead generation process.

To ensure accuracy and prevent premature outreach, Signal Scanner emphasizes a careful approach to database writes. Users are required to run a dry-run of the scan before any data is written, allowing them to review potential signals and make informed decisions. This safety measure is critical, as incorrect signals can lead to misguided outreach efforts and negatively impact lead statuses across multiple records. By following this protocol, users can maintain the integrity of their outreach strategy while leveraging the insights provided by the scanner.

When to use it

Use Signal Scanner after populating your TAM with companies and personas, and for regular scans to identify outreach opportunities.

When not to use it

Avoid using this tool if you do not have a structured TAM or if you require immediate one-off insights without the need for ongoing monitoring.

What you can build with it

Regular Outreach Scans

Set up daily or weekly scans to continuously identify buying signals and optimize your outreach timing.

Transitioning to Intent-Driven Outreach

Use Signal Scanner to move from static lead lists to a more dynamic approach based on real-time buying signals.

Monitoring Key Accounts

Employ the scanner to keep track of significant changes in your target accounts, such as leadership shifts or funding events.

How to install Signal Scanner

View source

1. Install with the skills CLI

npx skills add gooseworks-ai/goose-skills/signal-scanner --agent claude-code

2. Or install it manually

Download the skill folder and drop it into ~/.claude/skills/ for all projects, or .claude/skills/ to scope it to one repo. Restart Claude Code so it picks up the new skill.

Anthropic's agentic coding CLI, and the reference implementation of Agent Skills. Drop a skill folder into ~/.claude/skills and Claude Code loads it automatically whenever a task matches the skill's description. Claude Code docs

Inside SKILL.md

Written by gooseworks-ai

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

PrioritySignalLevelSourceCost
P0Headcount growth (>10% in 90d)CompanyData diffsFree
P0Tech stack changesCompanyData diffsFree
P0Funding roundCompanyData diffsFree
P0Job posting for relevant rolesCompanyApify linkedin-job-search~$0.001/job
P1Leadership job changePersonApify linkedin-profile-scraper~$3/1k
P1LinkedIn content analysisPersonApify linkedin-profile-posts + LLM~$2/1k + LLM
P1LinkedIn profile updatesPersonApify linkedin-profile-scraper~$3/1k
P2New C-suite hireCompanyDerived from person scansFree

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

FlagEffect
--config PATHPath to config JSON (required)
--testLimit to 5 companies, 3 people
--yesAuto-confirm Apify cost prompts. Only use for pre-approved scheduled scans.
--dry-runDetect signals but don't write to DB. Always run this first.
--max-runs NOverride 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

Frequently asked questions about Signal Scanner

Similar skills