Stalled-deal nudge

State: to-be-approved. Deploy-verified against a live workspace: yes, on 2026-10-04, on native models seeded with five deals (four open, one closed) and four activities: the selection returned the two deals quiet 24 and 33 days plus the one never touched, and excluded the deal touched the day before and the closed one; one digest per owner landed in Slack with one deal_nudges row per deal carrying its ts; a re-run once the ledger was readable posted nothing and wrote nothing. 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

An open deal stops dying in silence. Every Monday morning one agent finds the open deals with no logged activity in the last fourteen days and posts one digest per owner to a locked Slack channel. For each deal:

• How quiet: days since the last logged activity, and how many Mondays running it has been flagged.
• Last: the line the last note, meeting or call left off on, quoted with its date.
• Why now: one sentence grounded in that deal, such as a close date about to slip, a next step nobody took, or an objection left unanswered.
• Draft: a follow-up of at most four sentences that picks up from the quoted line, for the owner to send. The agent never sends it.

The worked example runs on Cargo native models, with no CRM connector: gtm_opportunities (the standard deal schema), gtm_accounts, and gtm_activities, one row per logged email, meeting, call or note. Last activity is computed in SQL as the latest occurred_at per deal, not read off a roll-up property, so "quiet for N days" is a query anyone can read. With deals in HubSpot, Salesforce or Attio, the models are swapped for connector-backed ones and the agent does not change (crm-backed below). A ledger records each deal nudged per ISO week: a re-run the same Monday posts nothing, and a failed post is retried the next run. A native write takes a few minutes to become readable, through SQL and search_records alike, so a re-run within those minutes does not see the ledger yet and posts again; the Monday cadence never comes close. The agent reads the deal models and never writes them.

Example

Every Monday, tell each rep which of their open deals went quiet and draft the follow-up.

Illustrative output, fictional records:

:hourglass: *Stalled deals · Dana Ruiz · 2026-W41*
_2 open deals with no logged activity in 14+ days._

*Fabrikam — Platform* — Proposal, $64,000, closes Oct 31 · quiet 19 days, flagged 1 Monday running
Last: Sep 17 "Send the security questionnaire and we'll take it to procurement."
Why now: The close date is three weeks out and the questionnaire that unblocks procurement never went.
Draft: > Hi Lee, attaching the completed security questionnaire you asked for on the 17th.
       > If procurement needs anything else to keep the Oct 31 date, send it my way today.

*Northwind — Expansion* — Discovery, $22,000, closes Nov 20 · quiet 16 days
Last: Sep 20 "Let's regroup once the Q4 budget is set."
Why now: Q4 budgets were due Oct 1, so the regroup they asked for is now.
Draft: > Hi Priya, you mentioned regrouping once Q4 budget was set. Is this week good?

Five owners had stalled deals, so five digests landed and eleven rows were added to deal_nudges; a second run that Monday posted nothing.

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. If the cargo-cdk skill is in your session it carries the long form of this; if not, this is enough.

1. Install it — the CLI does the copy. From inside the CDK project, cargo-ai cdk add cookbook/stalled-deal-nudge writes this example to infra/stalled-deal-nudge/ and this procedure to .claude/skills/stalled-deal-nudge/. No project yet? cargo-ai cdk init <dir> --cookbook stalled-deal-nudge && cd <dir> && npm install does both. 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. If the project already has a Slack or Anthropic connector, or gtm_opportunities, gtm_accounts or gtm_activities models, rewire the imports to the existing one and drop the copy; two resources with one slug is a collision at deploy. If the deals live in a CRM, apply crm-backed now, before the first deploy.
3. Point Slack at your channel and name the owners. Authorize the Slack connector if the workspace does not have one (cargo-ai cdk add connector/slack). Set channelId in infra/agents/nudger.ts to a channel id (C…) from that connector's channel autocomplete, and invite the bot. Fill OWNERS in infra/agents/nudger.prompt.ts from the distinct owner_id values on open deals. references/digest.md (installed beside this file) is the digest shape.
4. Adapt. 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. If you are asking more than about four questions you have skipped lookups. Record what you changed and why under a ## Decisions section in your copy of this file.
5. Check, then plan. node --import tsx evals/contract.mjs from this skill's folder, then npm run check && cargo-ai cdk plan from the project root. Show the diff, and deploy only on an explicit yes: cargo-ai cdk deploy. Never cdk init --force into a non-empty directory.
6. Verify. With the models filled (or seeded with test rows, cargo-ai storage record create-bulk), run the prompt's selection by hand (cargo-ai storage SQL over the models) and compare it with what a rep would call stalled. Then send the agent its trigger text once (cargo-ai ai message create), walk Done when line by line with evidence, and send it again: the second run must post nothing.

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:

• gtm_opportunities and gtm_activities hold rows, and every open deal's activities carry its opportunity_id
• the selection SQL run by hand returned deals a rep agrees are stalled, and none that are closed
• channelId is a C… id the Slack connector can see, and the bot is in that channel
• node --import tsx evals/contract.mjs passes

What you can change

What should not change

• "Stalled" is asked in SQL, over every deal. (infra/agents/nudger.prompt.ts §1) Neither the models nor a CRM-backed extractor filter. Put the rule in an extractor's config and it becomes invisible to anyone reading the query, and changing N means a redeploy and a re-extraction instead of an edited line.
• Last activity is computed from activity rows. (infra/agents/nudger.prompt.ts §1) A roll-up property a sync forgets to refresh makes every deal look quiet.
• The ledger is checked before research and written after the post. (infra/agents/nudger.prompt.ts §2 and §5) Check after and every re-run pays for the research again. Write before and a failed post is recorded as sent, so the owner hears nothing and the deal is skipped all week.
• The ledger, not Slack history, is the dedupe. (infra/agents/nudger.ts) Reading the channel back treats a deleted digest or another bot's post as "already nudged". The contract fails if a Slack read sits on uses.
• channelId is locked on postMessage. (infra/agents/nudger.ts) Digests carry deal amounts and quoted prospect lines.
• The deal models are read, never written. (infra/agents/nudger.ts) A nudge that could move a stage or close a deal changes the forecast from a guess. The only writable model is the ledger.
• The draft is never sent. (infra/agents/nudger.prompt.ts) The owner knows things the CRM does not, such as a call last week nobody logged. A sent draft is how a prospect gets a "just checking in" the day after they signed.
• Weekly. (infra/agents/nudger.ts) The ledger keys on the ISO week. A daily cron would post Monday's digest and then nothing for six days, which reads as broken; to nudge daily, change the ledger key with it.

Done when

• node --import tsx evals/contract.mjs passes
• cargo-ai cdk plan reports the agent, the gtm_opportunities, gtm_accounts, gtm_activities and deal_nudges models, the two connectors and the two folders
• the hand-run selection returned only open deals whose latest activity is older than QUIET_DAYS
• the first run posted exactly one digest per owner with stalled deals, in the references/digest.md shape, and wrote one deal_nudges row per deal with the digest's Slack ts
• a second run the same Monday, once the first run's ledger rows read back through SQL, posted nothing and added no row
• every Last: quote exists in the gtm_activities row it came from, with that date
• no draft was sent and no deal, account or activity row changed

What it costs

There is no enrichment provider, no CRM connector and no per-record fan-out: the selection and the last-activity reads are SQL over the workspace's own models. The one connector action is the Slack post. Immediately before the plan, read its live price:

• cargo-ai orchestration action list postMessage --kind connector --integration-slug slack

Say the number out loud; the run posts once per owner with stalled deals. The recurring cost is the agent run, once a week, billed as LLM tokens through the Anthropic connector. It scales with the number of stalled deals that week, and maxSteps caps it per run. A crm-backed adaptation adds the CRM extract: read its price with cargo-ai connection integration get <crm>.

Composes into

call-capture (logged calls are the activity that keeps a deal off the list), meeting-prep (the meeting the nudge books gets a card), and weekly-planning (the stalled count is a line in the week's plan).