@sellable/mcp 0.1.144 → 0.1.145

package/dist/tools/registry.js

@@ -0,0 +1,59 @@
+import { authToolDefinitions } from "./auth.js";
+import { blueprintCommitToolDefinitions } from "./blueprint-commit.js";
+import { bootstrapToolDefinitions } from "./bootstrap.js";
+import { campaignToolDefinitions } from "./campaigns.js";
+import { cellToolDefinitions } from "./cells.js";
+import { startCliLoginToolDef, waitForCliLoginToolDef } from "./cli-login.js";
+import { contextToolDefinitions } from "./context.js";
+import { directCampaignToolDefinitions } from "./direct-campaigns.js";
+import { engageBootstrapToolDefinitions } from "./engage-bootstrap.js";
+import { engageDiscoveryToolDefinitions } from "./engage-discovery.js";
+import { engageMemoryToolDefinitions } from "./engage-memory.js";
+import { engageStateToolDefinitions } from "./engage-state.js";
+import { enrichmentToolDefinitions } from "./enrichment.js";
+import { frameworkToolDefinitions } from "./framework.js";
+import { leadToolDefinitions } from "./leads.js";
+import { linkedinToolDefinitions } from "./linkedin.js";
+import { navigationToolDefinitions } from "./navigation.js";
+import { onDemandToolDefinitions } from "./one-off.js";
+import { processingToolDefinitions } from "./processing.js";
+import { promptToolDefinitions } from "./prompts.js";
+import { readinessToolDefinitions } from "./readiness.js";
+import { rowToolDefinitions } from "./rows.js";
+import { rubricToolDefinitions } from "./rubrics.js";
+import { senderToolDefinitions } from "./senders.js";
+import { sequencerToolDefinitions } from "./sequencer.js";
+import { tableToolDefinitions } from "./tables.js";
+import { verifyRowToolDefinitions } from "./verify-row.js";
+import { workspaceToolDefinitions } from "./workspaces.js";
+export const allTools = [
+    ...campaignToolDefinitions,
+    ...authToolDefinitions,
+    startCliLoginToolDef,
+    waitForCliLoginToolDef,
+    ...bootstrapToolDefinitions,
+    ...engageBootstrapToolDefinitions,
+    ...engageDiscoveryToolDefinitions,
+    ...workspaceToolDefinitions,
+    ...frameworkToolDefinitions,
+    ...contextToolDefinitions,
+    ...navigationToolDefinitions,
+    ...leadToolDefinitions,
+    ...enrichmentToolDefinitions,
+    ...processingToolDefinitions,
+    ...rubricToolDefinitions,
+    ...readinessToolDefinitions,
+    ...rowToolDefinitions,
+    ...cellToolDefinitions,
+    ...promptToolDefinitions,
+    ...linkedinToolDefinitions,
+    ...onDemandToolDefinitions,
+    ...directCampaignToolDefinitions,
+    ...senderToolDefinitions,
+    ...engageStateToolDefinitions,
+    ...engageMemoryToolDefinitions,
+    ...sequencerToolDefinitions,
+    ...tableToolDefinitions,
+    ...blueprintCommitToolDefinitions,
+    ...verifyRowToolDefinitions,
+];

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/mcp",
-  "version": "0.1.144",
+  "version": "0.1.145",
   "type": "module",
   "description": "Sellable MCP server for Claude Code and Codex campaign workflows",
   "main": "dist/index.js",

package/skills/create-campaign/SKILL.md

@@ -152,13 +152,14 @@ For Signal Discovery, the customer-facing approval card must use the exact
 action shape "Approve scraping N Signal Discovery posts?" and the chat summary
 should be a compact `## Source Recommendation` block with:
 
-- goal: about 300 good-fit prospects after cleanup, enrichment, and filters
-- working assumption: about 15% of raw post engagers become good-fit prospects
-- engagers needed: about 2,000 raw engagers
+- good-fit target: about 150 prospects after cleanup, enrichment, and filters
+- source-candidate plan: about 1,000 raw engagers using a conservative 15%
+  fit-rate assumption unless sampled data supports a different number
+- review checkpoint: import the first 25 leads for fit and message review
 - a selected-post table with post author/topic, why it fits, and visible
   engagement
 - total visible pool and estimated good-fit pool
-- first pass: build the source list, then import only 15 leads into the review
+- first pass: build the source list, then import only the review
   batch
 - fallback: switch to Sales Nav recent activity if the review batch is
   vendor-heavy, agency-heavy, or off-ICP
@@ -251,7 +252,7 @@ After every `update_campaign({ campaignId, currentStep })`, use
 `get_campaign_navigation_state` when available as a compact orientation check:
 match the saved campaign state to the expected watch-link step, explain the
 current state in one sentence, and only then continue. Sender selection belongs
-at Settings after message approval and 15-row validation. After message
+at Settings after message approval and review-batch validation. After message
 validation, use Settings to help the user connect or select a LinkedIn sender.
 Explain Slack reply review before launch. After sender selection, attach the
 recommended sequence and move the watched UI to Send. Do not start the campaign
@@ -614,9 +615,9 @@ updates.
    until `hasMore=false`. The create-campaign message-review safety gate is a
    supplemental approval checklist, not a replacement for the long prompt. Use
    campaign state, campaign brief content, selected source state, and imported
-   review-batch rows as the source of truth; do not read stale local markdown,
-   inspect the database directly, or synthesize local validation artifacts from
-   general knowledge.
+   review-batch rows as the source of truth; do not read stale local markdown
+   such as `message-validation.md`, inspect the database directly, or synthesize
+   local validation artifacts from general knowledge.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Import only the first
    bounded review batch after the source is attached to the campaign; do not
@@ -640,7 +641,7 @@ updates.
    `mcp__sellable__update_campaign({ campaignId, currentStep })` before major
    visible work so the user can watch progress in the app: `create-offer` for
    the brief, `pick-provider` or the selected provider step while sourcing,
-   `filter-choice` after the 15-row review batch, `create-icp-rubric` as soon
+   `filter-choice` after the review batch, `create-icp-rubric` as soon
    as filters are approved, `apply-icp-rubric` after rubrics save and while
    waiting for message-template approval, `validate-sample` while the approved
    template unlocks bounded enrichment/filter scoring on Filter Leads,

package/skills/create-campaign-v2/SKILL.md

@@ -167,9 +167,9 @@ selected posts exist:
 
 Use Signal Discovery first.
 
-**Goal:** ~300 good-fit prospects after cleanup, enrichment, and filters<br>
-**Working assumption:** ~15% of raw post engagers become good-fit prospects<br>
-**Engagers needed:** ~2,000 raw engagers
+**Good-fit target:** ~150 prospects after cleanup, enrichment, and filters<br>
+**Source-candidate plan:** scrape ~1,000 raw engagers using a conservative 15% fit-rate assumption<br>
+**Review checkpoint:** import the first 25 leads into the campaign for fit and message review before scaling<br>
 
 ### Selected posts
 
@@ -186,12 +186,12 @@ Use Signal Discovery first.
 
 Approve scraping these 3 posts.
 
-This gives enough volume to target ~300 good-fit prospects after cleanup, while
+This gives enough volume to work toward ~150 good-fit prospects, while
 keeping the source tied to people already engaging with Claude Code outbound /
 AI-native sales workflows.
 
-**First pass:** build the source list, then import only 15 leads into the
-review batch so we can inspect quality before scaling.
+**First pass:** build the source list, then import only the 25-lead review
+batch so we can inspect fit and messages before scaling.
 
 **Fallback:** if the review batch is too vendor-heavy, agency-heavy, or
 off-ICP, switch to Sales Nav recent activity.

package/skills/create-campaign-v2/SOUL.md

@@ -238,8 +238,8 @@ for source approval before import.
 
 For Signal Discovery, the second gate is not "approve source" in the abstract.
 It is a concrete scrape approval: show a compact `## Source Recommendation`
-with the ~300 good-fit prospect goal, 15% raw-engager assumption, selected-post
-table, total visible pool, estimated good-fit pool, first-pass 15-row review
+with the ~150 good-fit prospect goal, 15% raw-engager assumption, selected-post
+table, total visible pool, estimated good-fit pool, first-pass review
 batch, and fallback. The approval question should be "Approve scraping N Signal
 Discovery posts?"
 

package/skills/create-campaign-v2/core/auto-execute.README.md

@@ -33,16 +33,16 @@ the imported review batch for validation).
 
 - **`sampleSize`** — How many rows the validation loop pulls from the
   imported review batch. In v2 this matches the review-batch cap
-  (default 15), so the user sees enough real rows to judge the campaign
+  (default 25), so the user sees enough real rows to judge the campaign
   without spending credits on hundreds more.
 - **`minProjectedPass`** — Passing-message floor required before handoff.
-  The default requires 3 passing examples from the 15-row review batch.
+  The default requires 5 passing examples from the 25-row review batch.
   Math:
   ```text
   projectedPass = round(passInSample / sampleSize * importLimit)
   ```
-  With defaults (sampleSize=15, importLimit=15), `projectedPass` equals
-  the actual review-batch pass count. 3 passing rows is exactly at the
+  With defaults (sampleSize=25, importLimit=25), `projectedPass` equals
+  the actual review-batch pass count. 5 passing rows is exactly at the
   floor.
 - **`maxRevisionRounds`** — Hard cap before escalating to the user. A
   revision round is one full sample pass that triggered brief revision

package/skills/create-campaign-v2/core/auto-execute.yaml

@@ -17,7 +17,7 @@ import:
   # Initial review batch imported in Step 13 before the sample validation
   # loop. Import + enrichment must never exceed this cap before the user
   # reviews the sample and explicitly asks to expand.
-  importLimit: 15
+  importLimit: 25
   # Provider is inherited from the campaign-attached source association created
   # during find-leads. Step 13 may re-run provider preflight in memory, but it
   # does not choose a new source.
@@ -27,11 +27,11 @@ sample:
   # Rows pulled from the imported cohort for the validation loop. In v2 this
   # equals the review-batch cap so the user sees a focused first test batch
   # without spending credits on hundreds of rows.
-  sampleSize: 15
+  sampleSize: 25
   # Projected first-batch passing count required to proceed to sample
   # messaging. This is not approval to scale the full source list.
   # projectedPass = round(passInSample / sampleSize * importLimit).
-  minProjectedPass: 3
+  minProjectedPass: 5
   # Hard cap on revision loops before escalating to the user. On a stale
   # resume the counter does NOT reset — the 3-round cap holds across
   # sessions.
@@ -106,7 +106,7 @@ handoff:
   # Orientation surfaced in Step 16 ("awaiting-user-greenlight") along with
   # the watch link. Keep this short and user-facing.
   orientation: >-
-    Review the first 15 enriched leads and messages. If they look good,
+    Review the first 25 enriched leads and messages. If they look good,
     attach a sender in Settings, accept the recommended sequence, and start
     the campaign without spending credits on more leads first.
 

package/skills/create-campaign-v2/core/flow.v2.json

@@ -460,7 +460,7 @@
           "requiredInlineFields": [
             "primary source and exact filters/recipe",
             "specific source action awaiting approval",
-            "for Signal Discovery: Source Recommendation markdown with goal ~300 good-fit prospects, ~15% raw-engager fit assumption, ~2,000 raw engagers needed, selected-post table, total visible pool, estimated good-fit pool, first pass, and fallback",
+            "for Signal Discovery: Source Recommendation markdown with ~150 good-fit prospects as the target, source-candidate plan ~1,000 raw engagers at a conservative ~15% fit assumption, review checkpoint size, selected-post table, total visible pool, estimated good-fit pool, first pass, and fallback",
             "for Signal Discovery: selected post count and target engager/source-candidate volume",
             "bounded review batch size",
             "runner-up and why it lost",
@@ -541,7 +541,7 @@
             "importLimit"
           ],
           "requiredValues": {
-            "importLimit": 15
+            "importLimit": 25
           },
           "modeAddHandshake": {
             "firstCallReturns": "needsModeSelection when adding to an existing campaign-attached list",

package/skills/create-campaign-v2/references/approval-gate-framing.md

@@ -15,7 +15,7 @@ packet.
 
 The approval gate used to be the place where the user authorized
 spend/send-adjacent mutation. It is now compatibility-only. New runs import the
-bounded 15-row review batch after source approval, save rubrics and the approved
+bounded review batch after source approval, save rubrics and the approved
 message template after post-import review, and only then queue the cascade.
 
 If `campaign-shell.json` exists, a draft `CampaignOffer` row already exists but

package/skills/create-campaign-v2/references/filter-leads.md

@@ -174,6 +174,14 @@ If more than roughly 20% of the review batch appears to be the forbidden side,
 classify it as a list/source problem and return `revise-find-leads`; do not
 hide that problem behind narrow rubrics.
 
+## Suppression And Relationship Safety
+
+Do not put DNC or one-off relationship-safety notes into production rubrics
+unless the review batch shows that the pattern will leak at meaningful volume
+and normal DNC/domain suppression will not catch it. Former employers, existing
+customers, investors, partner lists, and one-off do-not-contact domains usually
+belong in the recommendation as DNC/suppression instructions outside the rubric JSON.
+
 ## Production Rubric Shape
 
 Confirmed rubrics must use the production `LeadScoringRubric` fields exactly:
@@ -265,6 +273,40 @@ Interpretation:
 - Density dramatically below the band: likely source contamination, ICP drift,
   or provider-side weakness; investigate before launch.
 
+## Post-Filter Signal Enrichment Pass (Sales Nav lane)
+
+Run this only for Sales Nav FIT rows when the downstream message step does not
+already have row-level post evidence. In normal campaign-backed runs, use live
+campaign-table row state as the source of truth. In explicit debug/UAT artifact
+flows, append the diagnostic copy back to `lead-sample.json`.
+
+This pass exists to protect the Earned-right and Read-as-1:1 substance filters.
+Without row-level posts, message generation is likely to fall back to generic
+category openers or presumed intent instead of evidence the recipient can
+recognize.
+
+Contract:
+
+- scope: Sales Nav FIT rows only; do not enrich MAYBE or REJECT rows for this
+  pass
+- budget cap: top 10 FIT rows by filter score
+- tool: `mcp__sellable__fetch_linkedin_posts`, called per row
+- fetch: most recent 3-5 public posts when available
+- target surface: store each result as `recent_posts[]` entries with
+  `{ url, posted_at, excerpt }`; keep `recent_posts: []` for quiet profiles
+- order of operations: run AFTER `lead-filter.md` is written, BEFORE
+  `message-validation.md` starts drafting
+
+Record enrichment outcome in the filter summary: rows attempted, rows with
+posts, rows with zero public posts, and tool failures. If more than half of the
+attempted rows have zero posts, flag low signal density and tell message
+generation to prefer trigger, peer-observation, or non-post proof instead of a
+post-quote opener.
+
+Do not convert "recently posted" or post availability into an ICP fit rubric.
+The posts are message evidence only; buyer qualification still comes from role,
+authority, account fit, capacity, geography, and exclusions.
+
 ## Decision Rules
 
 - Use `confirmed` when the source lane is viable and the rubrics are enough to

package/skills/create-campaign-v2/references/sample-validation-loop.md

@@ -6,7 +6,7 @@ on every revision round.
 
 ## Principle
 
-We spend a bounded review batch (default 15 rows) to prove fit before the
+We spend a bounded review batch (default 25 rows) to prove fit before the
 user spends credits on hundreds more leads. The sample loop has one job:
 answer the question "do we have enough real passing examples for the user to
 judge this campaign?" Message generation starts earlier: the first row that
@@ -23,7 +23,7 @@ auto-revise leads.
 - `CampaignOffer.currentStep === "apply-icp-rubric"` (the watched app is
   already on Filter Leads after `save_rubrics`; `validate-sample` is the
   logical loop name, not a visible route)
-- Imported review batch from Step 13 (size: `importLimit`, default 15)
+- Imported review batch from Step 13 (size: `importLimit`, default 25)
 - Config from `auto-execute.yaml`: `sample.sampleSize`,
   `sample.minProjectedPass`, `sample.maxRevisionRounds`
 - Persisted counter `revisionRound` (starts at 0 on first entry; persists
@@ -56,7 +56,7 @@ auto-revise leads.
 6. wait_for_rubric_results(sample, targetCount = <cohortSize>, minPassedCount = 1)
    - cohortSize = stats.totalRows of the enrichment batch, or the
      imported batch count
-   - default targetCount=15 matches the default review batch, but pass the
+   - default targetCount=25 matches the default review batch, but pass the
      explicit batch count anyway so future larger expansion batches do not
      accidentally stop early
      (see §Known Tool Behaviors #3)
@@ -172,8 +172,8 @@ company, enrichCellId, enrichStatus) over the default shape.
 
 ### 5. `wait_for_rubric_results` can timeout with enough signal to decide
 
-Observed: a 15-row review batch may return `ready=false`, `reason="timeout"`,
-and partial stats such as 13/15 scored, 2 passing, 2 messages generated. That is
+Observed: a 25-row review batch may return `ready=false`, `reason="timeout"`,
+and partial stats such as 20/25 scored, 4 passing, 4 messages generated. That is
 enough to diagnose an underperforming sample. Waiting again without active
 processing makes the experience feel frozen.
 
@@ -190,16 +190,16 @@ once only if active processing is still visible.
 projectedPass = round(passInSample / sampleSize * importLimit)
 ```
 
-Worked examples with defaults (sampleSize=15, importLimit=15):
+Worked examples with defaults (sampleSize=25, importLimit=25):
 
-| passInSample | projectedPass | Handoff? (minProjectedPass=3) |
+| passInSample | projectedPass | Handoff? (minProjectedPass=5) |
 | ------------ | ------------- | ----------------------------- |
 | 0            | 0             | No — escalate or revise       |
-| 2            | 2             | No — escalate or revise       |
-| 3            | 3             | Yes — exactly at floor        |
-| 4            | 4             | Yes                           |
+| 3            | 3             | No — escalate or revise       |
+| 5            | 5             | Yes — exactly at floor        |
+| 8            | 8             | Yes                           |
 | 10           | 10            | Yes                           |
-| 15           | 15            | Yes                           |
+| 25           | 25            | Yes                           |
 
 When non-default importLimit/sampleSize are configured, the math scales
 the same way. In the default review-batch mode, the sample size equals the
@@ -263,8 +263,8 @@ rate is zero with no pattern that brief editing could fix.
 
 Signal examples:
 
-- 15/15 rows are wrong function / wrong seniority / wrong geo.
-- 12/15 rows enrich to empty strings for the tokens the brief needs.
+- 25/25 rows are wrong function / wrong seniority / wrong geo.
+- 20/25 rows enrich to empty strings for the tokens the brief needs.
 - Rubric passes 0 rows and the failure reasons are all "not ICP."
 - **Marketplace supply-side contamination:** >20% of sample rows match
   the brief §14 forbidden side (e.g. Skillsync sample contains

package/skills/create-campaign-v2/references/step-13-import-leads.md

@@ -55,7 +55,7 @@ Supported branches:
   `import_leads({ campaignOfferId })` for Signal Discovery unless selected posts
   already exist on the campaign. Provider import materializes the source lead
   list from the approved source-capacity plan; it is not the same target as the
-  15-row campaign review batch.
+  default 25-row campaign review batch.
 - **Supplied LinkedIn profile CSV** — confirm `load_csv_linkedin_leads` only
   after rubrics and the approved message set are ready. Batch/materialize the
   uploaded CSV into a Sellable lead-list table. Persist the returned
@@ -106,9 +106,9 @@ fills the source lead list; it does **not** clone rows into the campaign table:
 ```text
 import_leads({
   campaignOfferId,
-  targetLeadCount: <sourceTargetGoodFitLeads; default 300>,
+  targetLeadCount: <sourceCandidateTarget; provider default>,
   // Signal Discovery only:
-  targetEngagerCount: <ceil(sourceTargetGoodFitLeads / sampledFitRateAfterCleanup)>,
+  targetEngagerCount: <ceil(targetGoodFitLeads / sampledFitRateAfterCleanup)>,
   maxPostsToScrape: <postsNeeded from approved math>
 })
 ```
@@ -120,9 +120,12 @@ so dedup ratios are visible.
 
 For Signal Discovery, do not scrape every currently selected/promoted sample
 post by default. Before `import_leads`, reconcile selected posts with the
-approved source math. If the math says 20 good fits per 100 engagers and the
-source target is 300 good-fit leads, pass `targetEngagerCount` around 1,500 and
-only enough posts to reach that engager count. The subsequent
+approved source math. The default good-fit target is 150 and the conservative
+fallback fit rate is 15%, so the default source-candidate plan is about 1,000
+raw engagers. If the sampled fit rate is stronger or weaker, use the sampled
+rate with a conservative cleanup factor, cap the source candidates at the
+approved provider limit, and select only enough posts to reach that engager
+count. The subsequent
 `confirm_lead_list` call still uses `targetLeadCount: <importLimit>` so only the
 bounded review batch enters the campaign table.
 

package/skills/create-campaign-v2/references/watch-guide-narration.md

@@ -178,8 +178,8 @@ Source approved and import starting:
 {
   "stage": "review-batch",
   "headline": "Importing the review batch",
-  "visibleState": "The browser is still showing the approved LinkedIn Engagement source leads.",
-  "agentIntent": "Codex is importing only the bounded 15-row review batch into the campaign now.",
+  "visibleState": "The browser is still showing the approved LinkedIn Engagement source candidates.",
+  "agentIntent": "Codex is importing only the bounded review batch into the campaign now.",
   "nextAction": "Review batch ready"
 }
 ```

package/skills/load-voice/SKILL.md

@@ -0,0 +1,129 @@
+---
+name: load-voice
+description: Load Sellable voice/company memory before answering questions, writing posts, applications, replies, or other copy in the user's voice.
+visibility: public
+allowed-tools:
+  - Read
+  - Glob
+  - Grep
+---
+
+# Load Sellable Voice
+
+<role>
+You are the Sellable voice loader. Your job is to read the user's durable
+Sellable voice/company memory into the current thread before drafting,
+answering, rewriting, reviewing, or calibrating copy in the user's voice.
+
+This is a read-only usage workflow. Do not interview by default, do not write
+memory files, and do not update `.sellable/**` unless the user explicitly asks
+to switch into `$sellable:interview`.
+</role>
+
+<default_use_cases>
+Use this workflow when the user asks to:
+
+- answer questions on behalf of them
+- write or rewrite a LinkedIn post
+- answer an application, investor, customer, or sales question
+- draft a sales reply, objection response, cold note, or website line
+- review whether copy sounds like them
+- "use my voice", "load my voice", "answer like me", or "write this as me"
+  </default_use_cases>
+
+<load_order>
+Read only relevant files. Start with the active `.sellable/configs` memory
+layer, not random repo docs.
+
+If `.sellable/configs` is not visible from the current working directory, use
+`Glob` to find `**/.sellable/configs/core/my-company.md`, excluding
+`node_modules`, `.next`, `dist`, and `.git`, then use the nearest parent as the
+Sellable memory root.
+
+## Core Voice And Judgment
+
+Read these when present:
+
+- `.sellable/configs/core/about-me.md`
+- `.sellable/configs/core/anti-ai-writing-style.md`
+- `.sellable/configs/core/decision-rules.md`
+- `.sellable/configs/core/context-modes.md`
+
+## Company Truth And Proof
+
+Read these when present:
+
+- `.sellable/configs/core/my-company.md`
+- `.sellable/configs/core/answer-bank.md`
+- `.sellable/configs/core/proof-ledger.md`
+- `.sellable/configs/core/story-bank.md`
+- `.sellable/configs/core/wins-ledger.md`
+
+## Writing-Specific Guidance
+
+Read these when present and relevant to the task:
+
+- `.sellable/configs/writing/styleguide-core.md`
+- `.sellable/configs/writing/comments.md`
+
+## Transcript Or Topic Context
+
+Do not bulk-read raw transcripts. If the user asks about a specific topic,
+story, sales call, customer, market view, or correction, first read:
+
+- `.sellable/configs/core/transcripts/INDEX.md`
+- the most relevant file under `.sellable/configs/core/transcripts/topics/`
+
+Only read raw archives under `.sellable/interviews/**` when the index/topic file
+points to one and the current task needs that source detail.
+</load_order>
+
+<operating_rules>
+
+- Keep the loader lightweight. The first pass should usually be 6-10 files, not
+  every file under `.sellable`.
+- Apply the loaded profile silently after a short confirmation. Do not paste a
+  long summary of the memory unless the user asks for one.
+- If the user already gave a concrete writing task, load the memory and then do
+  the task. Do not stop at "I loaded the files."
+- If the user only asked to load voice, say what you loaded, name the strongest
+  active rules in 3-6 bullets, then ask what they want drafted, answered, or
+  reviewed.
+- If exact proof, numbers, customer names, or timelines are not confirmed in
+  the loaded memory, preserve that uncertainty. Do not launder uncertain proof
+  into clean claims.
+- Use the current `context-modes.md` behavior for the requested surface:
+  LinkedIn post, sales reply, website, investor/application answer, outbound, or
+  internal strategy.
+- When answering on behalf of the user, write in first person unless the user
+  asks otherwise.
+- If a question cannot be answered from memory, make the smallest honest
+  assumption or ask one specific follow-up. Do not invent private history,
+  metrics, customer facts, or beliefs.
+- If the user says the output is wrong, ask what feels off and accept messy
+  dictated notes. Use that correction in the current thread. If they want the
+  correction saved durably, route them to `$sellable:interview`.
+  </operating_rules>
+
+<response_shape>
+After loading memory, use this shape when there is no concrete draft task yet:
+
+```text
+I loaded your Sellable voice/company memory from {n} files. I’ll apply it
+silently unless you override it.
+
+The active rules I’m carrying forward:
+- ...
+
+What should I answer, write, or review?
+```
+
+When there is already a concrete task, keep the confirmation to one sentence,
+then produce the answer or draft.
+</response_shape>
+
+<quality_bar>
+The result should feel like the user has a standing voice file in the thread:
+specific, current, proof-safe, and ready to answer on their behalf without
+forcing them to re-explain the same voice/company context every time.
+</quality_bar>

package/skills/providers/prospeo.md

@@ -62,7 +62,8 @@ search_prospeo({
 - Pass `searchId` on subsequent pages to paginate.
 - Use `import_leads` with `provider: \"prospeo\"` and the `searchId` to create a lead list and start import.
 - **IMPORTANT:** If `import_leads` returns `needsModeSelection: true`, use `AskUserQuestion` to ask "add to existing leads or replace?" Do NOT assume.
-- After the list finishes and the user confirms it looks good, call `confirm_lead_list` with the `jobId` and `targetLeadCount` from `import_leads` to import into the campaign table.
+- Default source target is 300+ good-fit leads, capped at 2,500 source candidates for now.
+- After the list finishes and the user confirms it looks good, call `confirm_lead_list` with the `jobId` and the review-batch `targetLeadCount` from the active campaign defaults to import only the review batch into the campaign table.
 - `import_leads` owns the watched move to `confirm-lead-list` after a lead list/job exists.
 - `confirm_lead_list` owns the watched move to `filter-choice` after the bounded review batch exists.
 - Post-confirm readback order is required:

package/skills/providers/sales-nav.md

@@ -349,9 +349,9 @@ Step 4 - Final Search + Confirm:
 What would you like?"
 
 User: "Save it"
-→ import_leads({campaignOfferId: "cmp_xxx", searchId: "search_xxx", targetLeadCount: 100})
+→ import_leads({campaignOfferId: "cmp_xxx", searchId: "search_xxx", targetLeadCount: 300})
 → (wait for lead list to finish, ask user to confirm)
-→ confirm_lead_list({campaignOfferId: "cmp_xxx", jobId: "<jobId from import_leads>", targetLeadCount: 100})
+→ confirm_lead_list({campaignOfferId: "cmp_xxx", jobId: "<jobId from import_leads>", targetLeadCount: 25})
 → wait_for_campaign_table_ready({campaignId: "cmp_xxx"})
 → get_campaign_context({campaignId: "cmp_xxx", refresh: true}) + get_rows_minimal(...)
 </iteration_example>
@@ -382,6 +382,8 @@ User: "Save it"
 <limits>
 - 25 results per page
 - Maximum 100 pages (2,500 leads)
+- Default source target: 300+ good-fit leads, capped at 2,500 source
+  candidates for now
 - Maximum 5 search calls per session
 - If user needs more than 2,500: explain limit, suggest splitting by region
 </limits>