# Hiring Radar > Use this skill when job postings should be watched as buying signals — continuously, with no outreach. Runs daily over watched accounts plus job descriptions matching tracked queries, keeps only the hiring patterns that matter to your GTM (hiring spree, buyer-persona hire, build-vs-buy, competitor tool in JD), and lands each signal on the account record with a per-signal alert and a reconciled digest. Built for inbound, PLG, and relationship-led motions. Detection and classification only — it never drafts or sends outreach. - Skill: `swan-gtm/hiring-radar` (Agent Skill, multi-file: 2 files) - Install (CLI): `npx skillmds@latest add swan-gtm/hiring-radar` - Raw SKILL.md: https://api.skillmd.com/api/skills/swan-gtm/hiring-radar/raw - Safety review: pending - Works with: Claude Code, Claude.ai, OpenAI Codex - Category: Marketing & Growth - Author: swan-gtm (https://skillmd.com/u/swan-gtm) - Updated: 2026-09-17 - Page: https://skillmd.com/skills/swan-gtm/hiring-radar --- Run when target accounts' job postings should work as buying signals. Produces classified signals with dated evidence, a per-signal alert, and a reconciled digest — detection only, never outreach. Run this daily to keep a live picture of who is building what across your target accounts. Hiring is budget made visible: a team being built today is a tooling decision being made this quarter. **Setup state.** Not yet configured for this org. Before scheduling, configure: the account watchlist (tier-A daily, rest weekly), the mention-scan queries (competitor and own products, watched role titles), the signals channel, and your own-domain exclusions. Maintain the configuration of connectors from job-board-sourcing-and-actor-schemas.md here. After setup, rewrite this paragraph to describe the current configuration. ## Step 1 — Pull fresh postings (two scans, never conflated) **Watchlist scan**: jobs posted BY watched accounts — company-filtered. **Mention scan**: jobs at ANY company matching a tracked query — a role title ("data engineer"), a technology in the JD ("SharePoint"), or both ("administrator" + your platform). A JD that mentions a watched company is NOT that company's hiring signal. Pull everything since the last run, paginated to the end. Drop your own postings — a query on your own product returns your own ads. LinkedIn only through native integration, never a third-party scraper; other boards one vetted, test-run scraper each — schemas and the vetting protocol are in [references/job-board-sourcing-and-actor-schemas.md](references/job-board-sourcing-and-actor-schemas.md). ## Step 2 — Keep only GTM-relevant patterns (the threshold) Tune to your GTM; everything else is log-only: - **Hiring spree** — 3+ fresh roles, same team → tooling decisions being made now - **Buyer-persona hire** — "first" / "Head of" the persona you sell to → a new owner with a 90-day agenda - **Build-vs-buy tell** — JD describes building what you sell → funded, unstaffed, still open - **Executive hire** in your buying committee → their first quarter decides what stays - **Competitor tool required in a JD** → displacement intel - **Your product required in a JD** → a customer signal for the CS owner Single postings, category-term-only mentions, evergreen and reposted listings drop — a pattern is only real if the posted dates are. ## Step 3 — Resolve and gate Resolve the true employer behind agency-posted listings, or drop them. Then gate mention-scan finds to ICP: non-ICP dies here as a log entry, never an alert. ## Step 4 — Dedup and suppression ledger Check account memory for `Last hiring signal: YYYY-MM-DD (pattern)`. The same pattern within 30 days doesn't re-alert — new postings attach as evidence. An active deal never re-alerts as new: flag as "warm signal on active deal" for the deal owner. **Write the ledger note for every account processed or skipped, with the reason.** ## Step 5 — Read, log, alert Read the surviving JDs — named tools, team-size hints, reporting line, pain language — and log those words to the account record with scan of origin, class, roles, posted dates, and links. Then one per-signal message to the signals channel: the account, the pattern with dated links, who likely owns the consequence, and one line on what it means. **One pattern = one alert**, however many postings feed it, and only within 14 days of the posted dates — older hiring is context, not news. ## Step 6 — Digest Close each run with a single summary: X postings pulled → Y patterns classified → Z alerts → skipped with reasons. Zero postings across ALL watched accounts on three consecutive runs is a sourcing failure until verified — never report it as market silence. ## What good looks like A great run reads like a radar sweep: dead postings die at the threshold, agency listings are resolved or dropped, and each real pattern lands once, with dated links and a one-liner on why it matters. The digest reconciles, and a quiet run says "quiet, verified" rather than nothing. Mediocre looks like: five alerts for one spree, congratulating a staffing agency, evergreen reposts counted as ramps, a mention hit alerted as a watched account's own hiring, or — worst — a silent zero nobody checked. ## Tighten over time After 3–6 weeks, read the ledger and digests: signals per week, share acted on within the 14-day window, share on unowned net-new accounts. Prune pattern classes and queries nobody acts on, suggest widening the setup phrases/sources. If alerts outrun rep capacity and net-new share is high, extend step 5 with a draft-for-review branch — the radar still never sends. ## Rules - MUST pull LinkedIn postings only through native integration; every other board through one vetted, test-run apify scraper. - NEVER draft, queue, or send outreach — this play detects, classifies, and alerts, and stops there.