new-hire-detection

New-hire detection

State: to-be-approved. Deploy-verified against a live workspace: not yet. Treat Done when below as the acceptance test and review cargo-ai cdk plan before deploying. Make no outcome claim for this skill until it is approved.

The outcome

Every person who just took a role you sell to, anywhere in your market, at a company that fits your ICP, shows up in a Slack channel the team reads: who they are, where they landed, why the company fits, and the links. Not a list pulled once: a pipeline that keeps watching.

A person entering a new role is the cleanest buying signal in B2B: fresh budget, a mandate to change things, and no loyalty yet to the vendor already in place. Most of the market is not worth a rep's time, so every company is qualified against the ICP in the workspace context first, and only the ones that fit are posted. A channel that hears about everyone stops being read.

The market is the scope, not your book. The source is a Sales Navigator people search over the industry, headcount band, location and titles you choose, filtered to people who changed jobs in the last year and took this position in the last year. Watching people you already hold is track-job-changes.

The play ends at the Slack post. It writes to no CRM and sends nothing to the person. A team with a CRM can add a read-only "already in the CRM" line to the post, or make the CRM the destination with routed tasks; both are variations in references/crm-adaptation.md.

Two failure modes worth knowing before you start. A search URL encoded once instead of twice loads an empty search, and the sync reports success with nothing in it. And a missing ICP leaves the qualifier judging against nothing, so it passes everything or nothing.

Example

Every time a new VP Sales or head of RevOps starts at a US software company with 51 to 500 people, post it in #new-hires.

Illustrative output, fictional records:

Five new hires in one sync: three posted, one declined by the qualifier, one stopped at the domain guard before any qualifier call.

Put it in your project

This folder is a worked example: real CDK resources written for some other company. The job is to end up with the code your company would have written, in your project, and an agent does the adapting.

Install the required authoring skill first. If cargo-cdk is absent, run:

npx skills add getcargohq/cargo-skills --skill cargo-cdk

Then read .agents/skills/cargo-cdk/SKILL.md directly; no session reload is needed. Complete its bootstrap and use its authoring, state, plan, and deployment rules throughout. Stop before any search or template work if the skill cannot be installed or read.

1. Install it: the CLI does the copy. From inside the CDK project, cargo-ai cdk add cookbook/new-hire-detection writes this example to infra/new-hire-detection/ and this procedure to .claude/skills/new-hire-detection/. No project yet? cargo-ai cdk init --cookbook new-hire-detection && cd && npm install does both; this folder never ships a shell. If you are reading this from the project's .claude/skills/, the install already happened. Start at step 2. On a CLI too old to have add, copy this folder in as a sibling of what is there by hand; everything below is unchanged.
2. Reconcile it with what is already declared. For every resource this example carries that the project already has (a Sales Navigator, LinkedIn, LLM, or Slack connector, a new-hire folder), rewire the imports to the existing one and drop the copy. Two resources with one slug is a collision at deploy. This skill declares no defineContext: that resource is a per-workspace singleton owned by the project. Copy this skill's context/icp.md into the project's context/ only when no ICP is written there yet. This folder needs nothing in .env; append nothing and never overwrite it.
3. Pick the channel, and offer the CRM. Resolve the Slack channel id through the connector's autocomplete and set slackChannelId. Then inspect the authenticated connectors: if a CRM is connected, offer crm_lookup and crm_routing from references/crm-adaptation.md, say what each costs, and build neither without a yes.
4. Shape and count the search. Follow references/search.md: derive the titles, industries, headcount and locations from the ICP (ask only when there is none), resolve every facet id through the autocompletes, and count each URL with searchPersonMetrics. Above 2,500, split by a facet. Stop for approval of the search, the limit, the cadence and the estimated cost per sync. Nothing is extracted while it is pending.
5. Adapt and deploy for the pilot. Work the sections below in order: What should not change is what you argue back about (say what breaks, then do it if they still want it); What you can change is what you offer unprompted; What you will be asked is the floor, and you derive before you ask. Record what you changed and why under a ## Decisions section in your copy of this file. The model ships as the pilot (limit: 10, no schedule); keep it that way for the first deploy. Then run node --import tsx evals/contract.mjs from this skill's folder, followed by cargo-ai cdk types && cargo-ai cdk check && cargo-ai cdk plan from the project root. Show the diff and deploy with the play disabled. Never run cargo-ai cdk init --force in a non-empty directory.
6. Run ten, then open it up. Follow references/run.md: sync ten, enable and execute the play once, and report every run with its status and the Slack post. Only on an explicit yes after that, set the approved limit, add the cadence, and redeploy. Walk Done when line by line and report each with evidence. Deployed cleanly and produced nothing is the normal failure.

What you will be asked

Derive before you ask. An input with a lookup is looked up, not asked. Only the ones marked asked genuinely live in the operator's head.

Checked before moving on, not after the deploy:

• market: every facet value is an id from an autocomplete, titles are quoted, and the three job-change filters are still in every URL
• search_size: counted for the URLs actually being deployed, each under 2,500
• slack_channel: the id resolves to the channel the operator named, and the Slack connector can post to it

What you can change

The code is a worked example. These reshapes are expected, and the agent offers them rather than waiting to be asked. Every one costs something; that is what makes it a variation and not the default.

What should not change

However far you adapt, these hold. Ask for one anyway and the agent tells you what breaks, then does it if you still want it, and records why under ## Decisions in your copy of this file.

• The three job-change filters stay in every search URL. (infra/models/new-hires.ts) Recently changed jobs, under a year at the company, under a year in the position. Remove one and internal promotions at long-tenured employees flood in, read as new hires, and fill the channel with people who have been at the company for a decade.
• Enrich the company first, and stop when there is no domain. (infra/plays/route-new-hires.ts) A Sales Navigator lead has a company URL, not the firmographics the qualifier judges on. A company page with no website is rarely an operating business, and every CRM variation matches on the domain.
• The qualifier's verdict gates the post. (infra/plays/route-new-hires.ts, infra/agents/icp-qualifier.ts) Without the gate every new hire in the market is posted, and the channel stops being read within a week.
• The ICP lives in the workspace context, not in the prompt. (infra/agents/icp-qualifier.ts) In the prompt, changing who qualifies becomes a deploy, and the search and the qualifier drift apart because they no longer read the same file.
• The channel is locked in the play. (infra/plays/route-new-hires.ts) A channel computed per run, or chosen by an agent, can land a prospect's name in a customer's shared channel.
• changeKinds: ["added"] stays. (infra/plays/route-new-hires.ts) Each sync re-extracts the whole search. Without added, every sync re-posts everyone in it and re-pays for every enrichment and every qualifier call.
• The model ships with no schedule. (infra/models/new-hires.ts) The cadence is added when opening up. Deleting a live schedule later does not clear it, so the pilot never carries one.
• The play ends at the Slack post. (infra/plays/route-new-hires.ts) Sending belongs to the team's own sequencer, after a person has read the post. A play that sends on a job-change signal mails people in their first week with nobody reviewing it.

Done when

• each deployed search URL was counted with searchPersonMetrics, sits under 2,500, and keeps the three job-change filters
• the pilot synced ten rows whose columns match the workflow input
• every run in the pilot ended in a named status, and every posted run is shown with its Slack message
• a not_icp run shows the qualifier's rationale, and posted nothing
• every post landed in the channel the operator named, and nowhere else
• node --import tsx evals/contract.mjs passes against the adapted resources
• after opening up, the next sync created runs only for people new since the previous one

What it costs

Fetch live prices before every estimate: cargo-ai connection integration get salesNavigator, linkedin, and the LLM connector's model. Quote the lookup time with the estimate.

Extraction is the main spend, and it repeats. fetchLeadSearch bills per extracted lead, and it is not incremental: every sync extracts the whole search again, including the people already in the model. "Changed jobs" spans roughly the last 90 days, so a sync every two weeks re-pays for most of the previous sync to find the ones who are new. One sync costs the counted search (capped at limit per URL) times the per-lead price; a month costs that times the number of syncs.

Qualifying is per new person, and only new people. Each run pays one company enrichment, and each company with a domain adds one qualifier call. The Slack post carries no per-call price of its own. The CRM variations add their own lookups and, on crm_routing, an email lookup per person.

Counting is cheap and comes first. One searchPersonMetrics call per candidate URL tells you what a sync will extract before anything is extracted.

Composes into

find-work-email or enrich-linkedin-profile for the people the team decides to contact, account-scoring for a standing score on the companies it surfaces, and the team's own sequencer after a person reads the post. With crm_routing, crm-enrichment fills the records it creates. track-job-changes is the sibling for people already in your CRM.