@anysiteio/agent-skills 2.0.0 → 2.1.0

package/README.md

@@ -41,6 +41,7 @@ Get unlimited requests through Remote MCP Server with no request limits. Ideal f
 | `anysite-crm-score` | Score CRM companies against your ICP with an explicit rubric and write the score into the mapped field. | [SKILL.md](skills/anysite-crm-score/SKILL.md) |
 | `anysite-crm-competitor-intel` | Displacement hunting: who uses a competitor (technographics), what their users complain about (review mining), tagged into the CRM. | [SKILL.md](skills/anysite-crm-competitor-intel/SKILL.md) |
 | `anysite-crm-account-brief` | Pre-meeting one-pager for a CRM account: CRM context + funding, exec changes, news, key people's recent activity. | [SKILL.md](skills/anysite-crm-account-brief/SKILL.md) |
+| `anysite-crm-inbound` | Instant read-only verdict on one inbound lead - identity, company reality check, ICP fit, route and talking points in 2-5 calls. | [SKILL.md](skills/anysite-crm-inbound/SKILL.md) |
 | `anysite-crm-lookalikes` | Derive your real ICP from closed-won customers and find lookalike companies across 70M+ company records. | [SKILL.md](skills/anysite-crm-lookalikes/SKILL.md) |
 <!-- END_SKILLS_TABLE -->
 

package/bin/install.js

@@ -30,10 +30,11 @@ const PKG_VERSION = JSON.parse(readFileSync(join(PKG_ROOT, "package.json"), "utf
 
 const HOME = process.env.HOME || homedir();
 const CLAUDE_DIR = join(HOME, ".claude");
-const CLAUDE_SKILLS_DIR = join(CLAUDE_DIR, "skills");
 const CODEX_DIR = join(HOME, ".codex");
 const CODEX_CONFIG = join(CODEX_DIR, "config.toml");
-const MANIFEST_PATH = join(CLAUDE_SKILLS_DIR, ".anysite-skills.json");
+// Both agents use the same skills convention: <dir>/skills/<name>/SKILL.md
+const SKILLS_DST = { claude: join(CLAUDE_DIR, "skills"), codex: join(CODEX_DIR, "skills") };
+const manifestPath = (dstRoot) => join(dstRoot, ".anysite-skills.json");
 
 const MCP_NAME = "anysite";
 const MCP_URL = "https://mcp.anysite.io/mcp";
@@ -73,8 +74,8 @@ function skillDescription(name) {
   } catch { return ""; }
 }
 
-function readManifest() {
-  try { return JSON.parse(readFileSync(MANIFEST_PATH, "utf8")); } catch { return null; }
+function readManifest(dstRoot) {
+  try { return JSON.parse(readFileSync(manifestPath(dstRoot), "utf8")); } catch { return null; }
 }
 
 function detectTargets() {
@@ -91,21 +92,21 @@ function hasClaudeCli() {
 
 // ── skills install / uninstall ──────────────────────────────────────────────
 
-function installSkills(names) {
-  mkdirSync(CLAUDE_SKILLS_DIR, { recursive: true });
+function installSkills(names, dstRoot) {
+  mkdirSync(dstRoot, { recursive: true });
   const installed = [];
   const missing = [];
   for (const name of names) {
     const src = join(SKILLS_SRC, name);
     if (!existsSync(join(src, "SKILL.md"))) { missing.push(name); continue; }
-    const dst = join(CLAUDE_SKILLS_DIR, name);
+    const dst = join(dstRoot, name);
     rmSync(dst, { recursive: true, force: true });
     cpSync(src, dst, { recursive: true });
     installed.push(name);
   }
-  const prev = readManifest();
+  const prev = readManifest(dstRoot);
   const all = [...new Set([...(prev?.skills ?? []), ...installed])].sort();
-  writeFileSync(MANIFEST_PATH, JSON.stringify({
+  writeFileSync(manifestPath(dstRoot), JSON.stringify({
     version: PKG_VERSION,
     bundle: flags.bundle ?? prev?.bundle ?? null,
     installedAt: new Date().toISOString(),
@@ -114,21 +115,21 @@ function installSkills(names) {
   return { installed, missing };
 }
 
-function uninstallSkills() {
-  const manifest = readManifest();
+function uninstallSkills(dstRoot) {
+  const manifest = readManifest(dstRoot);
   const tracked = new Set(manifest?.skills ?? []);
   const removed = [];
-  if (existsSync(CLAUDE_SKILLS_DIR)) {
-    for (const d of readdirSync(CLAUDE_SKILLS_DIR, { withFileTypes: true })) {
+  if (existsSync(dstRoot)) {
+    for (const d of readdirSync(dstRoot, { withFileTypes: true })) {
       if (!d.isDirectory()) continue;
       // remove tracked skills plus legacy anysite-* installs; never touch anything else
       if (tracked.has(d.name) || d.name.startsWith("anysite-")) {
-        rmSync(join(CLAUDE_SKILLS_DIR, d.name), { recursive: true, force: true });
+        rmSync(join(dstRoot, d.name), { recursive: true, force: true });
         removed.push(d.name);
       }
     }
   }
-  rmSync(MANIFEST_PATH, { force: true });
+  rmSync(manifestPath(dstRoot), { force: true });
   return removed;
 }
 
@@ -170,8 +171,7 @@ if (flags.help) {
 }
 
 if (flags.list) {
-  const manifest = readManifest();
-  const installed = new Set(manifest?.skills ?? []);
+  const installed = new Set(detectTargets().flatMap((t) => readManifest(SKILLS_DST[t])?.skills ?? []));
   console.log("\nBundles:");
   for (const [name, b] of Object.entries(BUNDLES)) {
     console.log(`  ${name} (${b.skills.length} skills) — ${b.description}`);
@@ -186,21 +186,27 @@ if (flags.list) {
 }
 
 if (flags.status) {
-  const manifest = readManifest();
-  if (!manifest) { console.log("\nNo anysite skills installed (no manifest found).\n"); process.exit(0); }
-  console.log(`\nInstalled: ${manifest.skills.length} skills (package v${manifest.version}, ${manifest.installedAt})`);
-  if (manifest.bundle) console.log(`Bundle: ${manifest.bundle}`);
-  for (const s of manifest.skills) console.log(`  ✓ ${s}`);
-  console.log(`\nUpdate: npx @anysiteio/agent-skills@latest ${manifest.bundle ?? ""}\n`);
+  let any = false;
+  for (const t of detectTargets()) {
+    const manifest = readManifest(SKILLS_DST[t]);
+    if (!manifest) { console.log(`\n[${t}] no anysite skills installed.`); continue; }
+    any = true;
+    console.log(`\n[${t}] ${manifest.skills.length} skills (package v${manifest.version}, ${manifest.installedAt})${manifest.bundle ? `, bundle: ${manifest.bundle}` : ""}`);
+    for (const s of manifest.skills) console.log(`  ✓ ${s}`);
+    if (any) console.log(`\nUpdate: npx @anysiteio/agent-skills@latest ${manifest.bundle ?? ""}`);
+  }
+  console.log("");
   process.exit(0);
 }
 
 if (flags.uninstall) {
-  const removed = uninstallSkills();
-  console.log(removed.length
-    ? `\nRemoved ${removed.length} skills from ${CLAUDE_SKILLS_DIR}:\n  ${removed.join("\n  ")}\n`
-    : "\nNothing to remove.\n");
-  console.log(`The MCP entry is kept. To remove it: claude mcp remove ${MCP_NAME}\n`);
+  for (const t of detectTargets()) {
+    const removed = uninstallSkills(SKILLS_DST[t]);
+    console.log(removed.length
+      ? `\n[${t}] removed ${removed.length} skills from ${SKILLS_DST[t]}`
+      : `\n[${t}] nothing to remove.`);
+  }
+  console.log(`\nThe MCP entries are kept. To remove: claude mcp remove ${MCP_NAME} / edit ~/.codex/config.toml\n`);
   process.exit(0);
 }
 
@@ -218,9 +224,13 @@ if (!targets.length) {
   process.exit(1);
 }
 
-const { installed, missing } = installSkills(names);
-console.log(`\nSkills → ${CLAUDE_SKILLS_DIR}: ${installed.length} installed${missing.length ? `, unknown: ${missing.join(", ")}` : ""}`);
-if (!installed.length) {
+let installedTotal = 0;
+for (const t of targets) {
+  const { installed, missing } = installSkills(names, SKILLS_DST[t]);
+  installedTotal += installed.length;
+  console.log(`\nSkills [${t}] → ${SKILLS_DST[t]}: ${installed.length} installed${missing.length ? `, unknown: ${missing.join(", ")}` : ""}`);
+}
+if (!installedTotal) {
   console.error("Nothing was installed — check skill names with --list.");
   process.exit(1);
 }

package/bundles.json

@@ -5,6 +5,7 @@
     "skills": [
       "anysite-mcp",
       "anysite-crm-setup",
+      "anysite-crm-inbound",
       "anysite-crm-enrich",
       "anysite-crm-signals",
       "anysite-crm-champions",

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@anysiteio/agent-skills",
-  "version": "2.0.0",
+  "version": "2.1.0",
   "description": "Official anysite agent skills + one-line setup: installs skills into Claude Code / Codex and registers the anysite remote MCP server. Includes the GTM bundle (CRM enrichment, signals, prospecting).",
   "keywords": [
     "mcp",

package/skills/anysite-competitor-analyzer/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: anysite-competitor-analyzer
-description: Deep competitive intelligence combining web scraping, LinkedIn data, social media monitoring, leadership analysis, GitHub activity, Glassdoor sentiment, and community insights. Analyzes founders/C-level profiles, tracks real-time signals vs quarterly reports, and creates comprehensive competitor profiles. Use when asked to analyze competitors, research leadership teams, investigate market positioning, compare products/pricing, assess strategic threats, or gather intelligence on founders and key executives.
+description: Deep competitive intelligence combining web scraping, LinkedIn data, social media monitoring, leadership analysis, GitHub activity, Glassdoor sentiment, and community insights. Analyzes founders/C-level profiles, tracks real-time signals vs quarterly reports, and creates comprehensive competitor profiles. Use for a DEEP DOSSIER ON ONE named competitor - leadership/founder profiling, product/pricing teardown, strategic threat assessment of a single company. For tracking a landscape of several competitors over time use anysite-competitor-intelligence; for CRM-tied displacement lists use anysite-crm-competitor-intel.
 ---
 
 # Competitor Analyzer

package/skills/anysite-competitor-intelligence/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: anysite-competitor-intelligence
-description: Competitive intelligence gathering using anysite MCP server across LinkedIn, social media, Y Combinator, and the web. Track competitor activities, analyze hiring patterns, monitor content strategies, benchmark market positioning, research startup competitors, and gather strategic intelligence. Supports LinkedIn (companies, employees, posts), Instagram, Twitter/X, Reddit, YouTube, Y Combinator, and web scraping. Use when users need to analyze competitors, track competitive movements, research market positioning, monitor hiring velocity, or gather strategic market intelligence.
+description: Competitive intelligence gathering using anysite MCP server across LinkedIn, social media, Y Combinator, and the web. Track competitor activities, analyze hiring patterns, monitor content strategies, benchmark market positioning, research startup competitors, and gather strategic intelligence. Supports LinkedIn (companies, employees, posts), Instagram, Twitter/X, Reddit, YouTube, Y Combinator, and web scraping. Use for tracking a LANDSCAPE of several competitors over time - competitive movements, hiring velocity, content strategies, market positioning across a set of companies. For a deep dossier on one named competitor use anysite-competitor-analyzer; for CRM-tied displacement lists use anysite-crm-competitor-intel.
 ---
 
 # anysite Competitor Intelligence

package/skills/anysite-crm-account-brief/SKILL.md

@@ -21,16 +21,22 @@ an update candidate for `anysite-crm-enrich`/`anysite-crm-champions`.
 
 ### 2. Company snapshot
 
-- `execute crunchbase/search {keywords: name}` → alias → `crunchbase/company` →
-  funding history, `leadership_hires[]`, `news[]`, `layoffs[]`, employee range, investors.
-- `execute linkedin/search/search_sql_companies {website: domain}` → description,
+- `execute crunchbase/search {keywords: name}` → alias (verify name+domain, first hit may
+  be a namesake) → `crunchbase/company` → funding history, `leadership_hires[]` (often empty
+  for smaller companies — not a negative), `news[]`, `layoffs[]`, employee range, investors.
+  Same response, free extras for the brief: `related.competitors[]` (their competitive set),
+  `bombora_surges[]` (what their team is researching — mention only if relevant to the
+  meeting), `predictions.funding_score` (likelihood of a next round).
+- `search_sql_companies {website: "<domain>", count: 10}` + exact `website` match check
+  (substring search returns look-alike domains — verify before trusting) → description,
   specialities, locations, employee_count.
 
 ### 3. What's happening now
 
-- Hiring: `linkedin/search/search_jobs {company: [{"type": "company", "value": "<id>"}],
-  sort: "recent", count: 20}` (numeric id from the `fsd_company:<id>` URN) — what functions
-  they're growing (that's their current priorities, use in talking points).
+- Hiring: `search_companies {keywords: "<name>", count: 5}` → pick the right company by
+  name/industry/alias (first hit is often a namesake), its `urn` comes back already as the
+  `{type, value}` object → `search_jobs {company: [<urn object>], sort: "recent", count: 20}`
+  — what functions they're growing (that's their current priorities, use in talking points).
 - News: crunchbase `news[]` first (already fetched); add
   `techmeme/stories/stories_search {keyword: "<name>", count: 5}` for tech companies.
 - Employer sentiment (optional, for bigger companies): resolve the employer id first via
@@ -48,9 +54,12 @@ execute linkedin/user/user_posts {urn, count: 10,
 ```
 Caveat: `user` called with a URL may omit the `urn` in its response, and `user_posts`
 accepts ONLY a URN. If the urn is missing, recover it via
-`search_users {first_name, last_name, company_keywords, count: 3}` → pick the match →
-use its urn. Posts are personalization gold: real interests, stated problems, conference
-activity.
+`search_users {first_name, last_name, current_company: [<company urn object>], count: 3}`
+— the company-filtered search returns the URN directly (same cascade crm-enrich uses for
+email-only contacts). Posts are personalization gold: real interests, stated problems,
+conference activity. Quiet posters: `user_comments` and `user_reactions` (posts they
+engaged with) reveal what a lurker actually reads — often better meeting fuel than their
+own posts.
 No posts ≠ no signal — check `user_comments` for lurker activity if it matters.
 
 ### 5. The brief

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

@@ -35,6 +35,15 @@ Audit scope: whole portal if small; else the working list + a stated sample. Say
   "neither" group is unenrichable and un-dedupable — flag it).
 - **Duplicate candidates:** same normalized email; same domain with several company records;
   same person name + company. Candidates only — never auto-merge.
+- **Email ↔ employer mismatch:** contact's email domain vs their linked company's domain.
+  A mismatch has THREE causes needing different handling (all seen live): the person changed
+  jobs; the COMPANY rebranded/changed domain (old domain usually still receives mail — the
+  contact is fine); or the email is genuinely stale. Free discriminator already in the data:
+  if crunchbase under the domain-derived alias returns a different company NAME than the
+  LinkedIn page of that same domain — that's a rebrand, not a departure. FLAG ONLY, never
+  auto-fix in either direction — in two causes out of three there is nothing to "fix", and
+  "correcting" the company from the email domain overwrites good data with stale. Job-change
+  suspects go to anysite-crm-champions.
 - **Staleness:** if `anysite_last_enriched_at` (or similar) is mapped — age distribution;
   contacts with no activity fields; companies with dead domains (spot-check a few via
   `webparser/parse` only if the user asks).

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

@@ -35,8 +35,13 @@ Cap a run at ~100 contacts (one profile call each); more → propose batching by
 
 Per contact:
 - `linkedin_url` → `execute linkedin/user/user {user: <url>}` → current experience.
-- email only → `execute linkedin/email/email_sql_user {email}` → profile (live `email_user`
-  for the remainder).
+- email only → try `execute linkedin/email/email_sql_user {email}` (→ live `email_user`),
+  but expect misses; the reliable path uses what the CRM already knows: email domain →
+  resolve company → `organizational_urn` → `search_users {first_name, last_name,
+  current_company: [{"type": "company", "value": "<id>"}]}`. NOTE: for champion tracking
+  search by the CRM company tells you where they WERE — a zero-result search there is
+  itself a move signal; re-search without the company filter and disambiguate by
+  headline/history before concluding.
 
 Compare the profile's **current company** against the CRM company. Normalize before
 comparing (legal suffixes, casing, known rebrands); when unsure, treat as "same" — false

package/skills/anysite-crm-competitor-intel/SKILL.md

@@ -47,6 +47,14 @@ only). Filter low-rating reviews with `query_cache` (free), then extract with th
 recurring pains, switching triggers, praised alternatives, verbatim quotes worth reusing.
 Keep 3–7 pains with quote + source URL each — this is the personalization ammunition.
 
+Second ammunition source — the competitor's own ads (`ad-transparency` sources, incl.
+LinkedIn Ad Library): their current claims and positioning in their own words. Scope it to
+the 1–3 competitors under analysis (NOT per-account sweeps — per-ad detail is a separate
+call each); use server filters (`impressions_min`, `countries`, `date_option`) and open
+only the cards that matter. ~10–15cr for a whole competitor analysis. Their engagement
+graph (`post_comments`/`post_reactions` on the competitor's page — a seed with a real
+audience) adds who's actively following them.
+
 ### 3. Cross-reference with the CRM
 
 ```

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

@@ -35,9 +35,15 @@ Page through everything in scope. Locally split records into:
 ### 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.
+- Only email → try reverse lookup first: `execute linkedin/email/email_sql_user` (cached,
+  cheap) → remainder via `email_user` (live). Both take ONE email per call — loop, don't
+  batch, and expect misses (verified to return empty even for people who are on LinkedIn).
+  Then the cascade that actually works, because the CRM knows the name: email domain →
+  resolve company (verified, per anysite-mcp recipe) → `organizational_urn` →
+  `search_users {first_name, last_name, current_company: [{"type": "company",
+  "value": "<id>"}]}` → usually exactly one match, WITH the profile URN as a bonus.
+  Company filter mandatory — bare names return namesakes. Still nothing → 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.
@@ -46,10 +52,42 @@ 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).
+- By domain — with MANDATORY exact verification on every resolve (the `website` search is
+  substring match: stripe.com → Soundstripe; stlabs.com → five other *labs.com companies).
+  Default one domain per call; OR-DSL batching is an optimization with a tax — any domain
+  that didn't come back exact-matched gets re-queried individually:
+  ```
+  execute linkedin/search/search_sql_companies {website: "acme.com", count: 5}
+  # batched variant: {website: "acme.com|globex.io", count: 10× domains}, then per domain:
+  query_cache {conditions: [{"field": "website", "op": "=", "value": "acme.com"}],
+               limit: <fetched count>}
+  # query_cache filters over the WHOLE cached set; `limit` (default 10) caps only how many
+  # rows come BACK. One domain → the default is fine; a multi-domain batch → pass a limit.
+  ```
+  Only an exact-website match (normalized: lowercase, no protocol/www/path) counts as
+  resolved. Gives industry, employee_count, description, locations.
+
+  **No exact match? Do NOT stop there** — a whole class of domains never appears in its own
+  substring results (verified: `{website: "stlabs.com", count: 5}` returns five other
+  *labs.com companies and never STLabs, a live company with a LinkedIn page). Standard second
+  step, ~1cr:
+  ```
+  execute webparser/parse {url: "https://acme.com", extract_minimal: true}
+    → top-level `title` = who they say they are
+    → links[] usually carries their own linkedin.com/company/... URL
+  execute linkedin/company {company: "<that URL>"}      # exact, no fuzzy matching
+  ```
+  Only after that fails is the domain genuinely unresolved — report it, never write.
+- Deeper firmographics (funding, size range): take the alias from `crunchbase_link`, which
+  the domain-resolve above ALREADY returned — free. Only when that field is empty and the
+  company is plausibly venture-backed, fall back to the live `crunchbase/search` by name
+  (20cr, fuzzy — verify name+domain before trusting it):
+  ```
+  # crunchbase_link: "https://www.crunchbase.com/organization/acme" → alias "acme"
+  execute crunchbase/company {company: "acme"}
+  ```
+  Only when the profile maps such fields. Normalize `contacts.email` before use — trailing
+  dots observed ("founders@reducto.ai."), and a match key with a trailing dot matches nothing.
 
 ### 4. Write back
 

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

@@ -0,0 +1,68 @@
+---
+name: anysite-crm-inbound
+description: Instant read-only verdict on ONE inbound lead - who they really are, whether the company is real and ICP-fit, route suggestion and talking points - in 2-5 anysite calls. Takes an email, a name+company, or a linkedin_url; checks the CRM for prior history but writes nothing. Use when a single new lead just arrived (demo request, reply, form fill, DM) and the user wants a fast qualify/route decision. For batch prospecting use anysite-crm-prospect; for accounts already worked in the CRM use anysite-crm-account-brief.
+---
+
+# CRM Inbound — one lead, one minute
+
+Every skill in this pack is batch-shaped except the most frequent moment in GTM life:
+a single lead just landed and someone asks "is this real / are they our ICP / who takes
+the call?". This skill answers that in 2 calls (verdict) to 4–5 calls (full mini-brief).
+Strictly read-only.
+
+## Input
+
+Whatever the user has: an email, a name + company, a linkedin_url, or a forwarded
+demo-request text. Extract identifiers yourself; don't interrogate the user.
+
+## Flow (cheap-first, stop as soon as the verdict is clear)
+
+### 1. Identify the person and company
+
+- **linkedin_url** → `execute linkedin/user/user {user: <url>}` → done.
+- **email with a work domain** → resolve the company by domain (anysite-mcp recipe: exact
+  verify; `webparser/parse` fallback for common-token domains) → `organizational_urn` →
+  `search_users {first_name, last_name, current_company: [{"type": "company",
+  "value": "<id>"}]}`. Note: `email_sql_user` reverse lookup is a cheap first try but
+  verified to miss often — don't stop on its empty result.
+- **email with a personal domain** (gmail etc.) → reverse lookup try, else name+company if
+  the form/message carries them. A lead reachable ONLY via personal email = flag it.
+- **name + company** → resolve company → `search_users` with the company filter (bare
+  names return namesakes).
+
+### 2. Company reality check (1 call, often already done in step 1)
+
+The verified `search_sql_companies` row gives industry, employee_count, locations,
+description, `crunchbase_link`, `organizational_urn`. Funding stage matters → 
+`crunchbase/company` via the free alias from `crunchbase_link` (skip for obviously
+non-venture companies).
+
+### 3. CRM history (free, crm_* reads)
+
+```
+crm_query_records(object_type="contacts", emails=[...])       # known already?
+crm_query_records(object_type="companies", search="<domain>")  # account history?
+```
+Existing record with an owner → this is a routing question, not a research question; say
+who owns it. Closed-lost history → the verdict must mention it.
+
+### 4. Verdict
+
+One compact block, in this order:
+1. **Real?** — person verified (profile ↔ claimed company match), company verified.
+2. **ICP fit** — against the profile's known criteria (or the user's stated ICP); one line
+   of evidence per criterion, "unknown" where no data.
+3. **Route** — new/known, suggested owner if CRM history names one, urgency (fresh funding
+   or hiring in the buyer function raises it).
+4. **3 talking points** with dates and links (recent posts, funding, launches, hiring).
+5. **Red flags** — personal-email-only, unresolvable company, competitor employee,
+   student/job-seeker pattern.
+
+## Rules
+
+- **Read-only.** No upserts, no dry-runs. If the user wants the lead in the CRM afterwards,
+  hand off to `anysite-crm-prospect` (its dedup and create rules apply).
+- Never claim "verified" on an unverified identity — the namesake trap applies to inbound
+  more than anywhere (people misspell their own company in forms).
+- Cost: ~2 credits for a verdict, 4–5 calls for the full brief. Cheap enough to run on
+  every inbound; say so if the user hesitates.

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

@@ -21,10 +21,20 @@ explicit pick of 10–30 names. Fewer than ~8 seeds → warn that the pattern wi
 
 ### 2. Profile the seeds
 
-Resolve each seed to structured firmographics:
+Resolve each seed to structured firmographics — exact verification is mandatory on every
+resolve (the `website` search is substring match and can return only look-alike domains;
+a wrong seed poisons the whole ICP pattern downstream):
 ```
-execute linkedin/search/search_sql_companies {website: "<domain>", count: 1}   # per seed
+execute linkedin/search/search_sql_companies {website: "seed1.com", count: 5}   # per seed
+# batched variant allowed, but: any seed without an exact match must be re-queried
+# individually. query_cache filters the WHOLE cached set; `limit` (default 10) caps only
+# how many rows come back — pass one when a batch should return more than 10 matches.
+query_cache {conditions: [{"field": "website", "op": "=", "value": "seed1.com"}], limit: 50}
 ```
+A seed with no exact website match is NOT dropped yet — resolve it via the site itself
+(`webparser/parse {url, extract_minimal: true}` → top-level `title` + own linkedin.com/company
+URL in `links[]` → `linkedin/company`), or via crunchbase → `contacts.linkedin_url`. Only a
+seed that survives neither is excluded from profiling, and say which ones.
 Plus `crunchbase/company` for stage/funding on a subset (venture-relevant seeds only).
 Derive the pattern in-session and SHOW it:
 
@@ -33,6 +43,11 @@ 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, ...
 ```
 
+Build the size band from `employee_count`, never from `employee_count_range` — the two can
+contradict each other in one record (verified: `employee_count: 1465` with
+`employee_count_range: "201-500"`), and a wrong band here propagates into every search
+below. Bucket the exact counts yourself.
+
 The user confirms/edits the pattern — it's their ICP, the data only proposes it.
 
 ### 3. Search for lookalikes

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

@@ -65,9 +65,12 @@ crm_upsert_contacts(records=[{email | linkedin_url,
                               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
+Before pushing, split found emails by domain: personal addresses (gmail/yahoo/outlook and
+similar — `user_email` returns mostly these) are NOT work emails — never feed them into a
+work-email sequence; keep those leads in a "personal email only" bucket alongside
+"pending email", and say so in the report. 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

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

@@ -36,12 +36,33 @@ explainable and reproducible.
 ```
 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>"}]`.
+- Base firmographics: `search_sql_companies` by `website` — default one domain per call;
+  OR-DSL batching (`{website: "a.com|b.com|...", count: 10× domains}`) is an optimization
+  with a verification tax (see the anysite-mcp resolve recipe). Never `count: 1` — the search
+  is substring match, and a common-token domain comes back with only look-alikes even in a
+  single-domain call. Verify the exact `website` match per domain via `query_cache` with an
+  explicit `limit` (default is 10 — a 20-domain batch needs more). Unverified match = no
+  evidence, score that criterion "unknown"; a domain that never comes back exact-matched is
+  resolved via `webparser/parse` on the site itself, per the same recipe.
+- Stage/funding (only if the rubric needs it): take the alias from `crunchbase_link`, which
+  the domain-resolve above ALREADY returned — free, no lookup. Only when it is empty and the
+  company is plausibly venture-backed, fall back to the live `crunchbase/search` (20cr, fuzzy
+  — verify name+domain) → `crunchbase/company`. Skip entirely for obviously non-venture
+  companies. Note `leadership_hires[]` is unusable as an ICP criterion for SMB/startup targets
+  — measured empty on 6 of 6 live accounts, including a 281-person one.
+- Hiring probe (only if in rubric): prefer the numeric id from `organizational_urn` of the
+  domain-resolve you already did → `search_jobs {company: [{"type": "company", "value":
+  "<id>"}], count: 20}`. No resolve → `search_companies {keywords: name, count: 5}` +
+  verify by name/industry (its `urn` is already the `{type, value}` object).
+- Team-shape evidence (great for "engineering-led vs sales-led" criteria):
+  `linkedin/company/company_employee_stats` (1cr, needs company URN) — absolute headcounts
+  by function (verified: Engineering 26 / Sales 14 on a 79-person company). Don't sum its
+  `locations` array (nested buckets: US ⊃ state ⊃ metro); cross-check totals against
+  `employee_count`.
+
+Company size in the rubric: use `employee_count`, never `employee_count_range` — the two
+can contradict each other in one record (verified: 1465 vs "201-500"), and the range would
+misfile the size band silently. Range only as fallback when the count is empty, noted.
 
 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.

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

@@ -61,6 +61,8 @@ Ask ONLY about ambiguous or high-stakes decisions, one compact block, not an int
 - 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?"
+- Plan: "Are you on MCP Unlimited or a credit-based plan?" — future sessions use this to
+  decide between credit estimates (credit plans) and time estimates (Unlimited) before bulk runs
 
 Confirm the full mapping as ONE list for approval, then save.
 
@@ -97,6 +99,8 @@ Generated <date> by anysite-crm-setup from live schema. Do not edit manually.
 - 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>
+- MCP plan: <unlimited | credits>; bulk-run policy: <credit estimates | time estimates>
+- crunchbase aliases cache: <name → alias, append as resolved — saves ~20cr/account/sweep>
 ```
 
 Only include rows that were actually agreed or auto-mapped. Never invent mappings for data types

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

@@ -32,26 +32,44 @@ propose splitting or narrowing.
 
 Run the cheap universal chain for every account; add optional probes when relevant.
 
-**Funding / exec hires / news / layoffs (one lookup covers four signals):**
+**Funding / exec hires / news / layoffs / intent (one lookup covers five signals):**
 ```
-execute crunchbase/search {keywords: "<company name>", count: 3}   # resolve alias, once
+# The domain-resolve you already did (search_sql_companies) returns `crunchbase_link` —
+# extract the alias from it for FREE. Only when crunchbase_link is empty AND the company
+# is plausibly venture-backed, fall back to the expensive live search:
+execute crunchbase/search {keywords: "<company name>", count: 3}   # 20cr/50 — last resort
 execute crunchbase/company {company: "<alias>"}
   → funding_rounds[] (date, type, amount, lead investors)
-  → leadership_hires[] (date, role, description)
+  → leadership_hires[] (date, role, description) — measured live: EMPTY on 6 of 6
+    SMB/startup accounts (incl. a 281-person, 10-year-old company; sample: US tech/AI).
+    Never build the Act-now tier on its presence for that ICP; empty ≠ "no hires"
   → news[] (title, date, publisher)
   → layoffs[]
+  → bombora_surges[] (free intent bonus: topics the account's staff is researching.
+    Count it ONLY if a topic matches the user's product category — it reflects what
+    they buy, not that they need you; weak-moderate on its own, good as a stack booster)
 ```
-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.
+Alias hygiene: aliases are case-sensitive (412 on miss → re-resolve once, likely rebrand).
+Keep a name → alias table in the local profile file so future sweeps skip resolution
+entirely — the profile is a local file, it works even when CRM custom fields can't be
+created. Coverage honesty: `crunchbase_link` is filled mostly for venture-backed companies
+(≈3/10 in a live batch); bootstrapped/service companies often have NO Crunchbase record —
+for them skip the crunchbase probe entirely instead of fuzzy-searching a wrong match.
 
 **Hiring (what they're building):**
 ```
-execute linkedin/search/search_companies {keywords: "<name>", count: 1}
-  → urn like "fsd_company:1441" → numeric id "1441"
+# Preferred: the domain-resolve response already carries `organizational_urn`
+# ("company:1441") — take the numeric id from it, no extra search needed:
 execute linkedin/search/search_jobs {company: [{"type": "company", "value": "1441"}],
                                      count: 20, sort: "recent"}
+# Only for accounts that were never domain-resolved:
+execute linkedin/search/search_companies {keywords: "<name>", count: 5}
+  → pick the RIGHT company by name + industry + alias (first hit is often a namesake:
+    "Notion" returns a Media Production company first, notionhq second)
+  → its urn is already {"type": "company", "value": "<id>"} — pass through as-is
 ```
-The `company` filter takes typed objects with the numeric id, not raw URN strings.
+A wrong-company URN turns someone else's vacancies into a fake hiring signal — worse than
+no signal. Unsure which company is right → skip the hiring probe for that account, say so.
 Look for roles in the buyer function (e.g. RevOps/Growth/Data roles for a data product).
 
 **Mentions / social activity (optional):**
@@ -61,13 +79,28 @@ execute linkedin/search/search_posts {keywords: "\"<company name>\"",
 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 —
+the author/context before counting a mention as a signal. For SMALL accounts, where keyword
+search finds nothing, the better probe is the company's own feed:
+`linkedin/company/company_posts` (~1cr/10) — hiring announcements there name new people in
+`mentioned[]` with vanity aliases (new-hire signal + a warm contact in one call).
+
+### 3. Score and stack — and filter out what was already reported
+
+**Novelty check first:** if the profile maps signal fields, you pulled `last_signal_date` /
+`last_signal_type` in step 1 — a "signal" older than or equal to what the CRM already
+records is NOT news. Without it, a funding round from three months ago gets re-announced as
+fresh on every sweep and the user stops trusting the report. Previously-known signals go
+into a collapsed "already reported" section, never into Act now.
+
+Then, per account, count NEW signals in the last 30/90 days, weighted by conversion value —
+and the weights are ICP-dependent, because signal AVAILABILITY is:
+- **SMB/startup ICP:** lead with funding rounds and job postings in the buyer function —
+  both filled on every account measured; treat `leadership_hires[]` as a bonus when present
+  (it was empty on the whole live sample), catching exec changes via job postings and
+  company_posts instead.
+- **Enterprise/press-covered ICP:** exec hire in buyer function > funding round > hiring
+  surge in relevant roles > news > mentions (appointments there do reach the press feeds
+  that fill leadership_hires). 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**.

package/skills/anysite-mcp/SKILL.md

@@ -30,8 +30,13 @@ is the map: how to call them, which sources cover which GTM need, and how to not
    and paging of that result is free. Never re-run `execute` to look at the same data twice.
 4. **Cheap-first cascade.** When several endpoints can answer, call the cached/DB one first
    (`*/db/*`, `*sql*` endpoints, ~1 credit) and the live one only for the remainder.
-5. **Estimate volume before bulk runs.** `N targets × credits-per-call`. Say the number to the
-   user before launching anything above ~100 calls.
+5. **Estimate volume before bulk runs — plan-aware.** First know the user's plan (the CRM
+   profile stores it after setup; if unknown, ask once: MCP Unlimited or credit-based?).
+   - **Credit-based plan:** before anything above ~100 calls, state the estimate
+     (`N targets × credits-per-call`) and get a nod. Prefer cheap DB endpoints, batch hard.
+   - **MCP Unlimited:** credit warnings off, but keep batch sizes sane anyway — the real
+     limits are latency and upstream rate limits, so cap sweeps the same way and say
+     "this will take ~N minutes" instead of a price.
 6. **Avoid `gdelt`** — it has repeatedly timed out in practice. Use techmeme or google news
    instead.
 
@@ -40,8 +45,42 @@ is the map: how to call them, which sources cover which GTM need, and how to not
 **Company discovery (bulk):**
 - `linkedin/search/search_sql_companies` — the workhorse. Up to 1000 companies per call with
   DSL filters (keywords, industry_name, employee_count_min/max, country_hq, founded_on_min/max,
-  has_website). Also does batch lookup by `urn` list and search by `website` — use it to
-  resolve domains from a CRM into LinkedIn company records.
+  has_website). Also does batch lookup by `urn` list and search by `website`.
+  ⚠️ **`website` search is SUBSTRING match, ordered by last_modified. Verification is
+  MANDATORY on every resolve — position in the results means nothing.** Verified live:
+  `{website: "stripe.com", count: 1}` → Soundstripe; `{website: "stlabs.com", count: 5}` →
+  five *labs.com companies, none of them stlabs.com (common tokens flood the result even in
+  a single-domain call). The domain-resolve rules:
+  1) **Verify exact `website` match** (normalize both sides: lowercase, strip
+     protocol/`www.`/path) on EVERY resolve, single or batched. No exact match =
+     **unresolved** — never write anything to the CRM for it; wrong-company data lands in
+     blank fields where nobody will catch it.
+  2) Default: one domain per call, small count. OR-DSL batching
+     (`{website: "a.com|b.io", count: 10× domains}`) is an optimization with a verification
+     tax: a domain with a common token can be flooded out of the batch entirely — every
+     domain that didn't come back exact-matched must be re-queried individually.
+  3) `query_cache` filters over the WHOLE cached set (verified) but returns at most `limit`
+     rows (default 10) — pass an explicit `limit` when you expect more matches back. Sanity
+     rule: `aggregate {op: "count"}` should equal the `total` from execute; if not, page
+     with `get_page` before concluding anything.
+  4) A whole class of domains never appears in its own substring results (common-token
+     domains like stlabs.com) — so the website's own page is the STANDARD second step, not
+     an emergency: `webparser/parse {url: "https://<domain>", extract_minimal: true}` →
+     top-level `title` says who they are, `links[]` usually carries their own
+     linkedin.com/company/... URL → `linkedin/company` for the exact URN (verified, ~1cr).
+     Live shape on stlabs.com: `title: "STLabs — Intelligent Service Management"` at the TOP
+     level, while `metadata` came back `{}` and `cleaned_html` empty — read `title`, and treat
+     `metadata` as a fallback only, not the primary location.
+     Secondary fallback: `crunchbase/search` by name → `contacts.linkedin_url`. Name search
+     alone is never a source of truth.
+  Bonus from a successful resolve: the `search_sql_companies` row already carries
+  `crunchbase_link` (free crunchbase alias — skip the live 20cr search) and
+  `organizational_urn` (`company:<id>` — the numeric id goes straight into `search_jobs`).
+  ⚠️ For company SIZE use `employee_count`, never `employee_count_range` — the two fields
+  can contradict each other in the same record (verified: Clay returns `employee_count:
+  1465` alongside `employee_count_range: "201-500"`). The range field looks like the natural
+  key for size segmentation and would misfile that company by ~3x, silently. Fall back to
+  the range only when the exact count is empty, and say that you did.
 - `crunchbase/db/db_search` — filters by funding stage, last funding date, investors,
   employee range; count ≤100, dates as Unix timestamps. 1 credit/result. Response includes
   `funding_rounds[]`, `leadership_hires[]`, `layoffs[]`, `news[]`, `technologies[]`,
@@ -53,8 +92,37 @@ is the map: how to call them, which sources cover which GTM need, and how to not
   early-stage supplements (check discover for exact endpoint names before calling).
 
 **Company detail:** `crunchbase/company` (by alias — resolve via `crunchbase/search` first),
-`linkedin/company`. Note: `owler` endpoints need an owler alias and its search has no
-name/keyword parameter — not usable for looking up a named account.
+`linkedin/company`. One `crunchbase/company` call also carries free extras worth reading:
+`bombora_surges[]` (B2B intent topics — but they show what THAT company's staff researches,
+i.e. what they BUY; treat as a signal only when a topic matches what the user sells),
+`related.competitors[]`, `predictions.funding_score`, `awards[]`. Coverage caveat:
+`leadership_hires[]` is often EMPTY for smaller companies — absence of the field is not
+absence of hires. Normalize `contacts.email` (trailing dots observed: "x@y.ai.").
+A third resolve path when crunchbase is already fetched: `contacts.linkedin_url` →
+`linkedin/company` → exact URN (verified; bypasses both fuzzy searches).
+Note: `owler` endpoints need an owler alias and its search has no name/keyword parameter —
+not usable for looking up a named account.
+
+**Engagement graph (who interacted with content):** `linkedin/post/post_comments`,
+`post_reactions`, `post_reposts` and `linkedin/company/company_posts` (~1cr/10) — answers
+"who paid attention to this content", incl. people outside your title filters. Identifiers:
+comments/reposts carry a vanity alias; reactions give only an obfuscated `/in/ACoAA...` URL
+plus `internal_id` — `user_email` accepts the `internal_id`, never the obfuscated URL.
+Honest scaling: volume follows the SEED's audience, not the target's importance (large brand
+post → dozens of engagers; 80-person company → 0–2 per post), and on a small account those
+few are mostly the company's OWN staff plus engagement farmers (verified: 3 of 4 commenters
+were employees) — filter by the author's company first and expect nothing left. Use this on
+seeds with a real audience (a competitor's page), not on SMB target lists. For small accounts
+the reliable nugget is `company_posts` → `mentioned[]`: hiring announcements name new people
+with their vanity aliases. `linkedin/company/company_employee_stats` (1cr) gives
+function/skill/location breakdown — cross-check totals against `employee_count` from
+`linkedin/company` before trusting absolutes, and never sum the `locations` array: its
+buckets are nested (US ⊃ California ⊃ SF Bay Area), so summing double-counts badly. Its
+`llm_hint` promises seniority and growth trends that the response does not contain.
+
+**Ads as a budget signal:** the `ad-transparency` sources (incl. LinkedIn Ad Library) are
+untapped — a company running B2B ads is telling you it has budget and who its ICP is.
+Listing is cheap; per-ad detail is a separate call each (N+1) — budget accordingly.
 
 **People:** `linkedin/search/search_users` (use `job_title` + `current_company` or
 `company_keywords`; never bare `keywords` alone — returns empty), `linkedin/user` (full
@@ -62,20 +130,34 @@ profile, needs alias/URL/URN — never guess the alias), `linkedin/user/user_pos
 `user_experience`, `user_comments`.
 
 **Email finding (cascade, cheap → expensive):**
-1. `linkedin/user/user_email` — batch up to 10 profiles, cheap, low yield.
+1. `linkedin/user/user_email` — batch up to 10 profiles, cheap, low yield. Truths from live
+   testing: it returns mostly PERSONAL addresses (gmail/yahoo), one row per EMAIL — not per
+   profile (group by `alias`/`internal_id` or you duplicate contacts), and its `found` field
+   is always true (useless as a check). Personal addresses are not work emails — never
+   present them as outreach-ready.
 2. `linkedin/user/find_email_by_url` — by vanity URL, high yield but expensive (50cr).
    **May be disabled on the server** — trust `discover("linkedin", "user")`: if it is not
    listed there, it does not exist; stop at step 1 and say so honestly.
-3. No email found → keep the lead anyway; CRM contact upserts match by `linkedin_url` too
-   (but note: creating a NEW contact requires an email — no email means update-only).
-
-**Reverse lookup (email → person):** `linkedin/email/email_sql_user` (cached DB) →
-`linkedin/email/email_user` (live) for the remainder.
+3. No work email found → keep the lead anyway; CRM contact upserts match by `linkedin_url`
+   too (but note: creating a NEW contact requires an email — no email means update-only).
+
+**Reverse lookup (email → person), reliability order:**
+1. `linkedin/email/email_sql_user` (cached DB) → `email_user` (live) — cheap, but verified
+   to return empty even for people who are definitely on LinkedIn. Try, don't rely.
+2. The cascade that works when you know the name (a CRM does): email domain → resolve the
+   company (verified, see above) → `organizational_urn` → `search_users {first_name,
+   last_name, current_company: [{"type": "company", "value": "<id>"}]}` → usually exactly
+   one match, delivered WITH the `fsd_profile` URN needed for `user_posts`. The company
+   filter is mandatory — a bare name returns namesakes.
 
 **Hiring signals:**
 - `linkedin/search/search_jobs` — by company; works for any company. The `company` param
-  takes `[{"type": "company", "value": "<numeric id>"}]` — extract the id from the
-  `fsd_company:<id>` URN returned by `search_companies` (raw URN strings are not accepted).
+  takes `[{"type": "company", "value": "<numeric id>"}]`. `linkedin/search/search_companies`
+  returns `urn` ALREADY in that object form — pass it through as-is. Only `search_sql_companies`
+  returns string URNs (`fsd_company:<id>`) — there, extract the numeric id yourself. And
+  verify the company before using its URN: the first search hit is often a namesake
+  (verified: "Notion" → NOTION Media Production first, the real notionhq second) — check
+  name + industry + alias.
 - `greenhouse/jobs/jobs_search {board_token, count}` — full descriptions via `content=true`;
   `ashby/jobs/jobs_search {board_name, count}` — descriptions always included. Both need the
   company slug; 412 = wrong token, fall back to linkedin jobs.
@@ -111,12 +193,14 @@ Covers any URL when no named source fits. Web search: `duckduckgo/search`, `brav
 The standard pattern for account signals (used by the crm-signals skill):
 
 ```
-company name/domain
-  → crunchbase/search (resolve alias, once; cache it)
-  → crunchbase/company → funding_rounds, leadership_hires, news, layoffs
-  → linkedin search_jobs(company urn) → what they hire for
-  → linkedin search_posts(company name, past-month) → mentions
+company domain
+  → search_sql_companies {website} + exact verify        (firmographics
+     ↳ crunchbase_link → alias FREE   ↳ organizational_urn)
+  → crunchbase/company {alias} → funding_rounds, leadership_hires, news, layoffs, bombora
+  → search_jobs {company: [{type, value from organizational_urn}]} → what they hire for
+  → search_posts (company name, past-month) → mentions
 ```
+Three paid calls per account instead of four — the live crunchbase/search drops out.
 
 Stack signals: one signal is a guess, 2–3 signals within ~30 days is a pattern worth acting on.