@anysiteio/agent-skills 1.4.0 → 2.0.1

package/skills/anysite-crm-enrich/SKILL.md

@@ -0,0 +1,84 @@
+---
+name: anysite-crm-enrich
+description: Enrich existing CRM records (HubSpot contacts and companies) with fresh data from anysite - job titles, LinkedIn profiles, firmographics, emails. Reads records from the connected CRM, finds gaps in mapped fields, fills them from LinkedIn/Crunchbase/web sources, and writes back safely (fill-blank, dry-run, undo). Use when the user asks to enrich CRM records, fill missing fields, update contact or company data, or refresh a CRM list. Requires an active CRM connection and the anysite-crm-profile mapping.
+---
+
+# CRM Enrich
+
+Fill gaps in existing CRM records with anysite data. The most common flow: pull a list from
+the CRM, enrich only what is missing, write back only to mapped fields.
+
+## Prerequisites
+
+1. `crm_list_connections` → an `active` connection. Missing → send the user to
+   `/anysite-crm-setup` (or Profile → CRM Integration in the dashboard).
+2. The `anysite-crm-profile` skill exists → its mapping is law. Missing → minimal safe mode:
+   standard properties only, recommend running setup.
+3. Read the Writing rules in `anysite-crm-setup` — they apply to every write below.
+
+## Flow
+
+### 1. Scope — what to enrich
+
+Ask (or infer from the request): which records and which fields. Pull them:
+
+```
+crm_query_records(object_type="contacts", list_id=<working list> | search=... | emails=[...],
+                  properties=[record_id + match keys + mapped target fields])
+```
+
+Page through everything in scope. Locally split records into:
+- **complete** — all mapped target fields filled → skip (report count),
+- **enrichable** — has a match key (email / linkedin_url / domain) and gaps,
+- **unmatchable** — no key at all → report, do not guess identities.
+
+### 2. Resolve identities (contacts)
+
+- Has `linkedin_url` → `execute linkedin/user/user` (full profile: title, company, location).
+- Only email → reverse lookup: `execute linkedin/email/email_sql_user` (cached, cheap) →
+  remainder via `email_user` (live). Both take ONE email per call — loop, don't batch.
+  No profile found → leave record, report.
+- Needs email → `user_email` (batch ≤10 profiles, low yield — set expectations honestly).
+  A higher-yield `find_email_by_url` exists in the API but may be disabled in MCP — trust
+  `discover("linkedin", "user")`; if absent, stop at `user_email` and report coverage as-is.
+
+Re-use cache (`query_cache`) instead of re-fetching anything twice.
+
+### 3. Resolve companies
+
+- By domain: `execute linkedin/search/search_sql_companies {website: "<domain>", count: 1}` —
+  batch by looping domains; gives industry, employee_count, description, locations.
+- Deeper firmographics (funding, size range): `crunchbase/search` by name → alias →
+  `crunchbase/company` — only when profile maps such fields (cost-aware: 20cr each).
+
+### 4. Write back
+
+Build upsert records keyed by the CRM `record_id` you pulled in step 1 — never re-search
+the CRM for a record you already hold, and never create from an enrich flow:
+
+```
+crm_upsert_contacts(records=[{record_id, properties:{<mapped fields only>}}],
+                    allow_create=false,
+                    overwrite_properties=[<only fields marked overwrite in profile>],
+                    dry_run=true)
+```
+
+Show the diff (old → new, counts of fill/skip), get confirmation, re-run with
+`dry_run=false`. Companies go through `crm_upsert_companies`, which matches ONLY by
+`domain` — always include `domain` in the properties you pull in step 1; a company record
+without a domain is unwritable (report it, don't improvise a match). Keep request batches
+reasonable (≤100 records per call). Save the returned `run_id`.
+
+### 5. Report
+
+Written / filled-blank-skipped (`fill_blank_skip` = policy working, not an error) /
+enum warnings / unmatchable. Mention `crm_undo(run_id)` availability. If the profile maps
+`anysite_last_enriched_at`, it was stamped by the mapping — say so.
+
+## Rules specific to enrichment
+
+- Never write a value you did not get from a source this session. No invented data.
+- A profile field with no fresh source value → leave it out of `properties` entirely.
+- Enum targets (e.g. industry): pick from the CRM schema `options` list, translating the
+  source value; no match → skip with a note, don't force.
+- >10 records or any overwrite → dry-run first, always.

package/skills/anysite-crm-lookalikes/SKILL.md

@@ -0,0 +1,64 @@
+---
+name: anysite-crm-lookalikes
+description: Derive the actual ICP from the CRM's closed-won/best customers and find lookalike companies with anysite bulk search (LinkedIn company DB, Crunchbase filters), scored and deduplicated against the CRM. Use when the user asks to find companies like their best customers, expand the target list, derive their real ICP from data, or seed a prospecting campaign. Requires an active CRM connection with some won/customer records.
+---
+
+# CRM Lookalikes
+
+Your real ICP is written in your closed-won list, not in your pitch deck. Extract the
+pattern, then search 70M+ companies for more of it.
+
+## Flow
+
+### 1. Collect the seed set
+
+```
+crm_query_records(object_type="companies", list_id=<customers list> | search=...,
+                  properties=[record_id, name, domain, industry, <size/stage if mapped>])
+```
+Need the user's help to identify "best": a customers list, a lifecycle/status field, or an
+explicit pick of 10–30 names. Fewer than ~8 seeds → warn that the pattern will be weak.
+
+### 2. Profile the seeds
+
+Resolve each seed to structured firmographics:
+```
+execute linkedin/search/search_sql_companies {website: "<domain>", count: 1}   # per seed
+```
+Plus `crunchbase/company` for stage/funding on a subset (venture-relevant seeds only).
+Derive the pattern in-session and SHOW it:
+
+```
+Industries: X (60%), Y (25%) · Size: 11-200 dominant · Geo: US+UK 80%
+Stage: seed-B · Common traits: has API docs page, hiring in data roles, ...
+```
+
+The user confirms/edits the pattern — it's their ICP, the data only proposes it.
+
+### 3. Search for lookalikes
+
+- `execute linkedin/search/search_sql_companies` — industry_name/keywords DSL from the
+  pattern, employee_count band, country filter, count up to 1000.
+- `execute crunchbase/db/db_search` — when stage matters (`last_funding_type`,
+  `last_funding_date_after`); `crunchbase/search` live for `hiring: true` or
+  `shares_investors_with: [<seed investors>]` (a strong hidden-similarity filter).
+- Niche supplements per pattern: `yc/search/search_companies` (early-stage), `builtin`
+  (US tech hubs), `producthunt` (product-led).
+
+Search wide, profile narrow: the searches themselves are cheap even at count 1000, but do
+NOT enrich every candidate — score on the fields the search already returned, and fetch
+extra evidence (crunchbase lookups etc.) only for the top ~50. State the credit estimate
+before any per-candidate enrichment.
+
+### 4. Score and dedup
+
+Score candidates against the confirmed pattern (same rubric discipline as
+`anysite-crm-score` — weighted criteria, evidence per company, no guessed values).
+Dedup against the CRM by domain (`crm_query_records`) — existing accounts drop out or get
+flagged "already in CRM, unworked".
+
+### 5. Hand off
+
+Output: top-N table (name, domain, why-it-matches, score) + the confirmed ICP pattern for
+reuse. Pushing to CRM → `anysite-crm-prospect` (its dedup/create/working-list rules apply);
+finding people at these companies → same skill. This skill itself writes nothing.

package/skills/anysite-crm-prospect/SKILL.md

@@ -0,0 +1,90 @@
+---
+name: anysite-crm-prospect
+description: Find net-new leads with anysite (LinkedIn and Crunchbase search, email finding) and push them into the CRM deduplicated - companies first, then contacts with associations. Creating records is gated by the profile's allow_create. Use when the user asks to find new leads/prospects/accounts AND add them to the CRM, build a list in HubSpot, or import prospects. For research without CRM push, prefer anysite-lead-generation. Requires an active CRM connection and profile.
+---
+
+# CRM Prospect
+
+Search → resolve → dedup → create. Order matters: companies before contacts, dedup before
+create, dry-run before both.
+
+## Prerequisites
+
+Active CRM connection + profile (`allow_create: true` agreed in profile — if not, stop and
+ask). Read Writing rules in `anysite-crm-setup`.
+
+## Flow
+
+### 1. Define the search
+
+Get concrete criteria from the user (persona titles, industry, geography, size, stage).
+Estimate volume and confirm before running anything large.
+
+**Companies:**
+- `execute linkedin/search/search_sql_companies` — main path: `keywords`/`industry_name`
+  DSL, `employee_count_min/max`, `country_hq`, up to 1000/call, 1cr-class.
+- `execute crunchbase/db/db_search` — when stage/funding filters matter
+  (`last_funding_type`, `last_funding_date_after`, `investors`).
+- `execute crunchbase/search` — live, adds `hiring: true`, `it_spend_*`, `valuation_*`
+  filters (20cr/50 — use for precision, not volume).
+
+**People at those companies:**
+- `execute linkedin/search/search_users {job_title, current_company: [urn] |
+  company_keywords, location, count}` — never bare `keywords` alone (empty results).
+  Company URNs come from the company search results.
+
+### 2. Emails (cheap-first cascade)
+
+1. `execute linkedin/user/user_email` — batches of ≤10 profiles. Warn the user upfront:
+   yield is low, a large share of leads will come back email-less.
+2. A higher-yield `find_email_by_url` exists in the API but may be disabled in MCP — check
+   `discover("linkedin", "user")`; if absent, don't promise it. If present, estimate cost
+   (50cr × remainder) before running.
+3. Still nothing → **keep the lead in the report**, but know the server requires an email
+   to CREATE a contact — email-less leads can only update existing records (matched by
+   `linkedin_url`). Report them as "found, pending email"; never silently drop them.
+
+### 3. Dedup against the CRM (before any create)
+
+```
+crm_query_records(object_type="companies", search=<domain>)     # or batch by domains
+crm_query_records(object_type="contacts", emails=[...])
+```
+Dedup is reliable by email and domain. By `linkedin_url` it is best-effort only (free-text
+`search`) — for a lead with no email whose search comes up empty, do NOT create; put it in
+a manual-review bucket and say why. Existing company → reuse its record; existing contact →
+update, not create. Report how many were already known — it calibrates the user's trust.
+
+### 4. Push — companies first, then contacts
+
+```
+crm_upsert_companies(records=[{domain, properties per profile}],
+                     allow_create=true, dry_run=true)            → confirm → write
+crm_upsert_contacts(records=[{email | linkedin_url,
+                              properties per profile,
+                              associate_company_domain: <domain>}],
+                    allow_create=true, dry_run=true)             → confirm → write
+```
+Server requires email to create a contact; contacts without email that don't match an
+existing record will be skipped with a warning — report them as "found, pending email",
+don't retry blindly. When associating to companies created in the same run, prefer
+`associate_company_id` from the company upsert result. Save `run_id`s.
+
+Note: crm_* tools cannot add records to CRM lists (list_id is read-only in queries). If
+the user wants the new leads in a HubSpot list, suggest an active-list filter on a mapped
+property (e.g. `lead_source = "anysite"`) — set that property during the upsert instead.
+
+### 5. Report
+
+Created / updated / already-known / pending-email / manual-review. Never call data
+"verified" unless a verification step actually ran.
+
+## Boundaries
+
+- Creating records (`allow_create=true`) is permitted here and in `anysite-crm-champions`,
+  in both cases only when the profile's `allow_create` agrees. If the user wants research
+  without CRM push, hand off to `anysite-lead-generation`.
+- Don't set owner, lifecycle stage, or any protected field — routing belongs to the CRM's
+  own automation.
+- ICP scoring of the found leads → `anysite-crm-score`; lookalike seeding → 
+  `anysite-crm-lookalikes`.

package/skills/anysite-crm-score/SKILL.md

@@ -0,0 +1,72 @@
+---
+name: anysite-crm-score
+description: Score CRM companies or contacts against the user's ICP using anysite data (firmographics, funding stage, hiring, tech signals) and write the score into the single mapped score field. Use when the user asks to score leads, rank accounts, prioritize the pipeline, or apply ICP criteria to CRM records. Requires an active CRM connection and a profile with a score field marked overwrite.
+---
+
+# CRM Score
+
+Deterministic-ish prioritization: explicit rubric, evidence per company, score written to
+exactly one mapped field.
+
+## Prerequisites
+
+Active CRM connection. Profile must map a score target field with `mode: overwrite`
+(scores are re-computed by design). Not mapped → offer to store nothing and just report,
+or send the user to re-run `/anysite-crm-setup`. The Writing rules in `anysite-crm-setup`
+apply to every write. Cap a scoring run at ~50 companies and state the credit estimate
+(evidence calls × price) before fetching; more → propose tiers or a narrower list.
+
+## Flow
+
+### 1. Fix the rubric BEFORE fetching data
+
+Get ICP criteria from the user, or derive them with `anysite-crm-lookalikes` logic from
+closed-won records. Turn them into a written rubric with weights, e.g.:
+
+```
+industry match (0-3), size band (0-2), geo (0-1), funding stage (0-2),
+hiring in buyer function (0-1), tech/context signal (0-1)  → 0-10
+```
+
+Show the rubric, get a nod. The rubric goes into the report verbatim — scores must be
+explainable and reproducible.
+
+### 2. Fetch evidence (cheap-first)
+
+```
+crm_query_records(object_type="companies", ...) → record_id, name, domain, existing fields
+```
+- Base firmographics: `execute linkedin/search/search_sql_companies {website: <domain>}` —
+  batch resolve; industry, employee_count, locations, description.
+- Stage/funding (only if the rubric needs it): `crunchbase/search` → alias →
+  `crunchbase/company` (cache aliases; skip for obviously non-venture companies).
+- Hiring probe (only if in rubric): `linkedin/search/search_jobs` with
+  `company: [{"type": "company", "value": "<numeric id from fsd_company urn>"}]`.
+
+Skip any evidence source whose rubric weight is zero. State per-company data gaps —
+a company with missing data gets a confidence note, not a silently low score.
+
+### 3. Score
+
+Apply the rubric in-session. For every company keep one line of evidence per criterion.
+No evidence → that criterion scores 0 with an "unknown" marker, never a guessed value.
+
+### 4. Write and report
+
+```
+crm_upsert_companies(records=[{domain: "<domain>", properties:{<score field>: <value>}}],
+                     allow_create=false, overwrite_properties=[<score field>],
+                     dry_run=true)  → confirm → write → run_id
+```
+Company upserts match ONLY by domain — pull `domain` when querying records; companies
+without one get a score in the report but no write. Write ONLY the score field (plus
+`scored_at` if mapped). Report: top-N with evidence lines,
+distribution summary, gaps. Contacts scoring (persona fit) works the same way against
+contact records with `linkedin/user` evidence — same rubric-first discipline.
+
+## Boundaries
+
+- Score ≠ routing: never touch owner/stage/status based on a score.
+- Re-scoring overwrites by design — that's why the profile must explicitly mark the field.
+- Intent-level signals (fresh funding, exec hires) belong to `anysite-crm-signals`; this
+  skill measures fit. The two compose: fit × recency of signals = priority.

package/skills/anysite-crm-setup/SKILL.md

@@ -0,0 +1,147 @@
+---
+name: anysite-crm-setup
+description: Connect and configure the user's CRM (HubSpot) for safe AI-driven enrichment through anysite MCP crm_* tools. Runs a short discovery - reads the CRM schema including custom properties, agrees a deterministic field mapping with the user in 3-5 questions, and saves a local CRM profile that all future enrichment sessions follow. Use when the user wants to connect their CRM, set up CRM enrichment, configure field mapping, re-run CRM discovery after schema changes, or asks why CRM writes are skipped. Also defines the mandatory rules every agent must follow when writing to CRM with crm_upsert_contacts / crm_upsert_companies.
+---
+
+# Anysite CRM Setup
+
+Connect the user's CRM and produce a **local CRM profile** — a saved field mapping that makes every
+future enrichment write deterministic: the same data always lands in the same CRM properties.
+
+## When to use
+
+- First-time setup: "connect my HubSpot", "set up CRM enrichment"
+- Re-discovery: CRM schema changed, mapping feels stale, or writes are being skipped unexpectedly
+- Reference: the **Writing rules** section below applies to EVERY session that calls
+  `crm_upsert_contacts` / `crm_upsert_companies`, even outside setup
+
+## Prerequisites
+
+The `crm_*` tools are visible only when the user has enabled CRM integration in their Anysite
+dashboard (Profile → CRM Integration). If the tools are missing, ask the user to enable it there.
+After they enable it, the tools do NOT appear instantly: the server flag takes up to a minute to
+propagate, and the agent's tool list is cached per session — ask the user to reconnect the MCP
+server (or start a new session), then retry. This is expected behavior, not an error.
+
+## Setup flow
+
+### 1. Ensure a connection
+
+Call `crm_list_connections`.
+
+- If there is an active connection — proceed to step 2.
+- If not, call `crm_connect(provider="hubspot")`, give the user the `connect_url` to open in a
+  browser, then poll `crm_connect_status(pending_id)` every few seconds until `active`.
+
+### 2. Read the schema
+
+Call `crm_get_schema()`. You get:
+
+- `properties.contacts` / `properties.companies` — every property with `label`, `type`,
+  `options` (valid enum values), `read_only`, `custom`
+- `lists` — the user's CRM lists (id, name, processing type)
+- `protected_properties` — fields the server will never let you write
+
+### 3. Classify and auto-map
+
+Silently classify properties:
+
+- **Standard equivalents** — map automatically, do not ask: `email→email`, `jobtitle`,
+  `firstname`/`lastname`, `phone`, `city`, `country`, `company`, `website`, `domain`, `industry`,
+  `numberofemployees`, `linkedin_url→hs_linkedin_url`.
+- **Custom enrichment targets** — custom properties whose name/label suggests enrichment
+  (score, tier, segment, tech stack, intent, source): candidates for user questions.
+- **Ignore** — `read_only: true`, calculated, `hs_*` system internals, protected fields.
+
+### 4. Ask 3-5 questions maximum
+
+Ask ONLY about ambiguous or high-stakes decisions, one compact block, not an interview:
+
+- Ambiguous targets: "Intent score → `Lead Score` or `ICP Fit Score`?"
+- Overwrite policy for volatile fields: "Job titles: overwrite on change or fill blanks only?"
+- Working list: "Which list do you enrich most — 'Inbound' or 'Outbound Q3'?" (only if lists exist)
+- Creation policy: "May agents create new contacts, or update existing only?"
+
+Confirm the full mapping as ONE list for approval, then save.
+
+### 5. Save the local profile
+
+Write the agreed profile to `~/.claude/skills/anysite-crm-profile/SKILL.md` (create the directory).
+Use exactly this structure:
+
+```markdown
+---
+name: anysite-crm-profile
+description: The user's saved CRM field mapping and write rules for HubSpot enrichment via anysite MCP. ALWAYS consult this before calling crm_upsert_contacts or crm_upsert_companies - it defines which CRM properties to write, which may be overwritten, and which list is the working list. Generated by /anysite-crm-setup - do not edit manually, re-run setup to change.
+---
+
+# CRM Profile (HubSpot portal <portal_id>, connection <connection_id>)
+
+Generated <date> by anysite-crm-setup from live schema. Do not edit manually.
+
+## Field mapping — contacts
+| Anysite data | CRM property | mode |
+|---|---|---|
+| job title | jobtitle | fill_blank |
+| linkedin url | hs_linkedin_url | fill_blank |
+| intent score | icp_fit_score | overwrite |
+
+## Field mapping — companies
+| Anysite data | CRM property | mode |
+|---|---|---|
+| industry | industry | fill_blank |
+| employee count | numberofemployees | overwrite |
+
+## Rules
+- Working list: "<name>" (id <id>)
+- allow_create: <true/false, as agreed>
+- Never write (user protected, on top of server-enforced): <list or "-">
+- Enum properties and their valid values: <property>: <values>
+```
+
+Only include rows that were actually agreed or auto-mapped. Never invent mappings for data types
+that were not discussed.
+
+## Writing rules (every session, not only setup)
+
+1. **Consult the profile first.** If `~/.claude/skills/anysite-crm-profile/SKILL.md` exists, its
+   mapping is law: write ONLY to properties listed there, in the listed mode. If a new data type
+   has no mapping, ask the user once and suggest re-running setup — do not guess.
+2. **Creating a new contact requires email.** record_id and linkedin_url only MATCH existing
+   contacts; a record without email is skipped with `create_requires_email` when no match exists.
+   Never invent or guess emails — if no verified work email is available, report the person as
+   not imported and say why.
+3. **No profile? Minimal safety.** Map only obvious standard properties; ask before writing
+   anything to a custom property; recommend running `/anysite-crm-setup`.
+4. **Dry-run before bulk.** For more than ~10 records, or any `overwrite_properties`, first call
+   the upsert with `dry_run=true`, show the user the old → new diff, and write only after
+   confirmation.
+5. **Overwrite only per profile.** Pass a property in `overwrite_properties` only if the profile
+   marks it `overwrite` (or the user explicitly asked in this session).
+6. **Enum values must come from the schema.** Check `options` before writing enum properties;
+   the server skips invalid values with an `enum_option_missing` warning — do not retry blindly.
+   When sources disagree on an enum like industry (e.g. YC vertical vs LinkedIn category), pick the
+   schema option closest to how the company describes itself and mention the choice to the user.
+   Use `crm_get_schema(object_type=..., properties=[...])` to fetch just the enum you need — the
+   unfiltered schema is very large.
+7. **Report warnings honestly.** `fill_blank_skip` means the field already had a value — that is
+   the policy working, not an error. Summarize results/skipped/warnings for the user after writes.
+8. **Undo exists.** Every real write returns `run_id`. If the user is unhappy with a write,
+   `crm_undo(run_id)` restores previous values (fields changed since are reported as conflicts).
+
+## Tools reference
+
+| Tool | Purpose |
+|---|---|
+| `crm_list_connections` | Connections and their status |
+| `crm_connect` / `crm_connect_status` | OAuth connect flow |
+| `crm_get_schema` | Properties (with enum options), lists, protected fields |
+| `crm_query_records` | Read CRM: list members, by ids/emails, free-text search, paging |
+| `crm_upsert_contacts` | Write contacts (match by email / record_id / linkedin_url) |
+| `crm_upsert_companies` | Write companies (match by domain) |
+| `crm_undo` | Revert a write run by run_id |
+
+Property values are strings; numbers and booleans are accepted and coerced server-side.
+
+Server-enforced regardless of anything in this skill: fill-blank by default, protected fields,
+no empty writes, create only with `allow_create`, full write log.

package/skills/anysite-crm-signals/SKILL.md

@@ -0,0 +1,96 @@
+---
+name: anysite-crm-signals
+description: Sweep CRM target accounts for buying signals - funding rounds, executive hires, hiring surges, layoffs, news, brand mentions - using Crunchbase, LinkedIn jobs/posts and news sources, then prioritize accounts and optionally stamp signal fields back into the CRM. Use when the user asks "what's new with my accounts", wants signal-based prioritization, account monitoring, or a "who should I reach out to today" answer. Pairs with a cron/loop for always-on monitoring. Requires an active CRM connection.
+---
+
+# CRM Signals
+
+Turn a static account list into a prioritized "act now" list. One signal is a guess; 2+
+signals within ~30 days is a pattern. Signal-triggered outreach converts several times
+better than cold cadence (vendor-reported benchmarks: exec hires and job changes lead,
+then funding) — treat the ordering as solid, the exact percentages as marketing.
+
+## Prerequisites
+
+Active CRM connection (`crm_list_connections`). Profile optional for read-only sweeps;
+required if the user wants signal fields written back — and then the Writing rules in
+`anysite-crm-setup` apply.
+
+## Flow
+
+### 1. Pick the account set
+
+```
+crm_query_records(object_type="companies", list_id=<target list> | search=...,
+                  properties=[record_id, name, domain, <mapped signal fields if any>])
+```
+
+Cap a single sweep at ~50 accounts (each account costs several source calls). More →
+propose splitting or narrowing.
+
+### 2. Per-account signal collection
+
+Run the cheap universal chain for every account; add optional probes when relevant.
+
+**Funding / exec hires / news / layoffs (one lookup covers four signals):**
+```
+execute crunchbase/search {keywords: "<company name>", count: 3}   # resolve alias, once
+execute crunchbase/company {company: "<alias>"}
+  → funding_rounds[] (date, type, amount, lead investors)
+  → leadership_hires[] (date, role, description)
+  → news[] (title, date, publisher)
+  → layoffs[]
+```
+Alias resolution is case-sensitive and costs credits — if the profile maps a
+`crunchbase_alias` field, read/write it so each account is resolved once, ever.
+
+**Hiring (what they're building):**
+```
+execute linkedin/search/search_companies {keywords: "<name>", count: 1}
+  → urn like "fsd_company:1441" → numeric id "1441"
+execute linkedin/search/search_jobs {company: [{"type": "company", "value": "1441"}],
+                                     count: 20, sort: "recent"}
+```
+The `company` filter takes typed objects with the numeric id, not raw URN strings.
+Look for roles in the buyer function (e.g. RevOps/Growth/Data roles for a data product).
+
+**Mentions / social activity (optional):**
+```
+execute linkedin/search/search_posts {keywords: "\"<company name>\"",
+                                      date_posted: "past-month", count: 20}
+execute techmeme/stories/stories_search {keyword: "<company name>", count: 5}
+```
+Do NOT use gdelt (times out). Filter false positives for generic company names by checking
+the author/context before counting a mention as a signal.
+
+### 3. Score and stack
+
+Per account, count signals in the last 30/90 days, weighted by conversion value:
+exec hire in buyer function > funding round > hiring surge in relevant roles > news >
+mentions. Layoffs = negative budget signal for expansion, positive for cost-saving pitches —
+interpret against the user's product.
+
+Output tiers: **Act now** (2+ fresh signals), **Watch** (1 signal), **Quiet**.
+
+### 4. Report (and optionally write back)
+
+Always produce the human report first: account → signals → suggested angle ("congratulate
+on Series B, reference the new VP Sales hire").
+
+If the profile maps signal fields (e.g. `last_signal_type`, `last_signal_date`,
+`signal_summary`) and the user wants them stored:
+```
+crm_upsert_companies(records=[{domain: "<domain>", properties:{...}}], allow_create=false,
+                     overwrite_properties=[<signal fields — they are volatile by nature,
+                     profile must mark them overwrite>], dry_run=true)
+```
+Company upserts match ONLY by domain — pull `domain` in step 1; accounts without one are
+report-only. → confirm → write → report `run_id`.
+
+## Recurrence
+
+This skill is a one-shot sweep. For always-on monitoring suggest scheduling: a Claude Code
+cron / `/loop`, or an operator habit ("run signals every Monday"). Note what was swept and
+when in your report so the next run compares against it. Post search granularity is coarse
+(`date_posted`: past-24h / past-week / past-month only) — a weekly cadence fits it best;
+funding/news items carry their own dates, filter those by date in-session.