@sellable/mcp 0.1.54 → 0.1.56

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

@@ -57,23 +57,20 @@ turn anchored to that:
 
 Approvals only feel safe when the user can see what they are approving. Before
 any approve/revise question, show the relevant decision in plain language. For a
-brief approval, render the slim approval brief, not just a direction summary.
-Any list the user is expected to review should be rendered Markdown with short
-indexed sections and bullets. Avoid label-plus-paragraph blocks like
-`Key numbers:` followed by a dense paragraph, and never use fenced code blocks
-for review surfaces.
+brief approval, render the brief itself, not just a direction summary.
 
 Every approval should also give the user a way to inspect the source artifact.
-After the readable inline content, include an `Open artifact:` line with the one
-key link behind the decision. Do not show long plain paths in normal chat; offer
-them only as a fallback if links cannot be created. The artifact link is a backup
-for inspection, not a replacement for showing the decision in chat.
+After the readable inline content, include an `Open artifacts:` line with links
+or plain paths to the files behind the decision. The artifact links are a backup
+for inspection, not a replacement for showing the content in chat.
 
 This applies especially to message approvals. Never ask someone to approve a
-message they cannot see. In chat, show the subject and one fully filled sample
-message with no tokens first. Keep the tokenized template, good fill example,
-good omit example, bad fill example, why the bad fill is wrong, token notes, and
-fallback rules in `message-review.md` / `message-validation.md`.
+message they cannot see. Show the subject, tokenized template, a filled sample
+prospect version, good fill example, good omit example, bad fill example, why
+the bad fill is wrong, token notes, your take, and suggested adjustment first.
+The user should be able to compare "here is the template" against "here is what
+one real prospect would receive" before approving, and understand exactly how
+the tokens should and should not be filled.
 
 Every token needs a fallback. If the row does not have clean data for a token,
 the approval view should say whether to use a safe segment-level phrase, omit
@@ -95,17 +92,7 @@ Every customer-facing update should answer one of these:
 - What will the user see next?
 - What is protected until approval?
 
-Only promise parallel work when parallel work actually started. If the host
-cannot or should not launch background branches, say the real sequence:
-`I’ll tighten the filter first, then draft the message from the same sample.`
-Do not say `kicking off two workstreams`, `in parallel`, or `background` as
-aspirational copy.
-
-Before a brief approval, the user should see a slim approval brief in chat. The
-rich current brief exists in `brief.md`; the chat view is the decision surface,
-not the full working memo. `brief-v1.md` is an internal first-draft snapshot, not
-part of the normal approval UI. It should be skimmable in under 45 seconds and
-include:
+Before a brief approval, the user should see:
 
 - who we are targeting
 - why they should care
@@ -116,11 +103,6 @@ include:
 - risks / assumptions
 - what happens after approval
 
-The offer / CTA should be useful before it is convenient. Avoid vague
-peer-call asks like "compare notes" unless the user explicitly chose that. The
-buyer should know what they get if they reply: a checklist, teardown, diagnostic,
-sample, benchmark, relevant example, or working session with a concrete output.
-
 For lead-source decisions, confidence comes from concrete counts. Do not say
 "strong sample", "73% match", or "meaningful concentration" without showing the
 sample size and what was counted. Prefer:
@@ -132,37 +114,6 @@ sampled engagers; 31 looked like real ICP fits, so I’d treat this as direction
 usable people if the remaining engagers behave similarly.
 ```
 
-Lead review chat should be short and numeric. It must use rendered Markdown,
-not a fenced code block, and include bullet-pointed provider/source-angle
-estimates, one bullet per angle, so the sourcing logic is easy to scan:
-
-```text
-**1. Quick numbers**
-- **Signals / AI outbound posts:** 249 posts found. Sampled 40 engagers; 18/40
-  looked usable. Estimate: 100-250 good warm fits.
-- **Sales Nav / active SaaS founders + GTM leaders:** 27,454 active profiles before
-  filtering. First 25 had 12 strong/probable fits. Estimate: 300-800 good fits.
-- **Sales Nav / agencies + GTM consultants:** Smaller but higher intent. Estimate:
-  150-400 good fits.
-```
-
-Then show chosen source, why it won, expected connection acceptance, expected
-reply rate, 3-5 sample leads, and one tradeoff. Full tables belong in
-`lead-review.md`.
-
-Lead filter chat should always use indexed rendered Markdown and show what
-changed: keep, exclude, why, expected impact, and
-`Open artifact: lead-filter.md`.
-
-Message review chat should use indexed rendered Markdown, show one fully filled
-sample message without tokens, and keep tokenized templates in the artifact.
-
-Final approval chat should use indexed rendered Markdown for a ready-to-create
-summary: campaign, target with concrete role/title names, lead source, filter,
-one filled sample message, what approval creates, and the safety note that
-nothing sends live until greenlight. Do not include sequence/settings in final
-approval; that belongs after campaign creation.
-
 Avoid:
 
 ```text
@@ -268,6 +219,27 @@ setting: `~/.codex/config.toml` with
 
 ## Approval Ethic
 
+## Parallelism + Naming
+
+Source-angle comparison should be real, not implied. When the source is not
+supplied and multiple source angles are viable, scout Signals, Sales Nav, and
+relevant domain/contact paths as independent branches when the host can do so.
+If the host runs them sequentially, keep the output numeric but do not claim the
+source scout was parallel.
+
+Only promise parallel post-lead work when parallel work actually started. If the
+host cannot or should not launch background branches, say the real sequence:
+
+```text
+I’ll tighten the filter first, then run message generation from the same sample.
+```
+
+Do not say `kicking off two workstreams`, `in parallel`, or `background` as
+aspirational copy.
+
+Call the post-filter message stage `message generation` in chat.
+`message-validation.md` is an internal proof artifact, not the workstream name.
+
 Be explicit about when nothing has been created yet:
 
 ```text

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

@@ -206,28 +206,27 @@
       "onEnter": [
         {
           "action": "show_brief_summary",
-          "artifact": "brief.md"
+          "artifact": "brief-v1.md"
         },
         {
           "action": "render_brief_approval_checkpoint",
           "requiredVisibleContent": [
             "Campaign brief",
-            "Target",
-            "Core pain",
+            "Who we are targeting",
+            "Why they should care",
             "Offer / CTA",
-            "Proof",
-            "Lead plan",
+            "Proof to use",
+            "Lead source hypothesis",
             "Message angle",
-            "Risks",
-            "After approval",
+            "Risks / assumptions",
+            "What happens after approval",
             "approve this brief",
             "revise the brief",
             "then I will find good-fit leads"
           ],
-          "minimumVisibleBriefDetail": "slim_approval_brief_before_question",
-          "requiredArtifactLinks": ["brief.md"],
+          "minimumVisibleBriefDetail": "full_readable_brief_before_question",
+          "requiredArtifactLinks": ["brief-v1.md", "brief.md"],
           "artifactLinkTiming": "before_approval_question",
-          "chatRenderRule": "Show the brief as rendered Markdown, never as a fenced code block. Use ## Campaign brief, a one-sentence bold Decision, indexed bold section labels, and short bullets. In Lead plan, translate provider shorthand into plain user-facing language about who will be searched for and why; do not rely on bare terms like signal discovery, RevOps, outbound systems, or pipeline architecture.",
           "avoidQuestionWhenOnlyUsefulAnswerIs": "looks good"
         },
         {
@@ -301,7 +300,8 @@
         {
           "action": "run_subskill",
           "target": "find-leads",
-          "mode": "campaignless-preview"
+          "mode": "campaignless-preview",
+          "sourceScoutRule": "When source is not user-supplied and at least two viable source angles exist, scout independent source angles in parallel when host/tooling permits: Signals active-post branch, Sales Nav title/company branch, and Prospeo/domain branch only when relevant. If real parallel execution is unavailable, run the same scouts sequentially and do not claim parallel execution. Compare outputs by raw volume, n/N sampled fit, estimated good-fit range, expected reply range, and tradeoff."
         },
         {
           "action": "write_artifacts",
@@ -366,10 +366,10 @@
           "action": "show_lead_review",
           "artifact": "lead-review.md",
           "renderInlineSections": [
-            "Lead source decision",
-            "Chosen source",
+            "## Lead source decision",
+            "Recommendation",
             "Why it won",
-            "Key numbers",
+            "Quick numbers",
             "Sample leads",
             "Tradeoff"
           ],
@@ -401,19 +401,21 @@
           "forbidPercentOnlyFitRates": true,
           "requiredArtifactLinks": ["lead-review.md"],
           "artifactLinkTiming": "before_next_step_or_revision_question",
-          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. Use indexed sections and short bullets: chosen source, why it won, bullet-pointed Quick numbers with one provider/source angle per bullet, raw volume, sampled fit rate as n/N, estimated good-fit range after cleanup, expected connection acceptance range, expected reply rate range, 3-5 representative sample leads, and one tradeoff. Keep evidence tables, selected posts, discarded paths, full sample rows, and lead-sample.json details in lead-review.md. Do not show plain filesystem paths unless links cannot be created."
+          "doNotCompressToSummaryOnly": false,
+          "doNotRenderArtifactLinksOnly": true,
+          "chatRenderRule": "Show a slim rendered-Markdown decision summary only, never a fenced code block. Use indexed sections and short bullets: recommendation, why it won, Quick numbers with one provider/source angle per bullet, raw volume, sampled fit rate as n/N, estimated good-fit range after cleanup, expected reply rate range, 3-5 representative sample leads, and one tradeoff. Keep evidence tables, selected posts, discarded paths, full sample rows, and lead-sample.json details in lead-review.md. Do not show plain filesystem paths unless links cannot be created."
         },
         {
           "action": "render_post_lead_parallel_progress",
           "requiredVisibleContent": [
             "Lead source is set",
             "Tighten the fit filter",
-            "Draft the first message",
+            "Message generation",
             "approved brief and real sample leads",
             "parallel only if real parallel branches were launched"
           ],
           "timeEstimate": "~2-3 min",
-          "chatRenderRule": "If real parallel workers/branches were actually launched, say: 'I’m kicking off two workstreams now' and list the two branches. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then draft the first message from the same approved brief and sample leads.' Never claim parallelism unless the host actually started parallel execution."
+          "chatRenderRule": "If real parallel workers/branches were actually launched, say: 'I’m kicking off two workstreams now' and list 'Tighten the fit filter' and 'Message generation'. If not, do not mention parallel/background work; say: 'I’ll tighten the filter first, then run message generation from the same approved brief and sample leads.' Never claim parallelism unless the host actually started parallel execution. User-facing stage name is message generation; message-validation.md is only the internal artifact."
         },
         {
           "action": "ask_continue_revise_or_confirm_only_if_needed",
@@ -476,7 +478,7 @@
           "action": "show_lead_filter_summary",
           "artifact": "lead-filter.md",
           "renderInlineSections": [
-            "Lead filter",
+            "## Lead filter",
             "Keep",
             "Exclude",
             "Why",
@@ -623,7 +625,7 @@
             "recommendation"
           ],
           "mustRenderInlineBeforeQuestion": true,
-          "minimumVisibleMessageDetail": "filled_sample_message_no_tokens",
+          "minimumVisibleMessageDetail": "filled_sample_message_only",
           "requiredArtifactLinks": ["message-review.md"],
           "artifactLinkTiming": "before_approval_question",
           "requiredFileLabels": [
@@ -685,9 +687,11 @@
           "questionPrerequisiteVisibleLabels": [
             "Status: message-review",
             "Subject:",
+            "Tokenized template:",
             "Sample prospect fill:",
+            "Token fill basis:",
             "My take:",
-            "Concern:",
+            "Suggested adjustment:",
             "Recommendation:"
           ],
           "forbiddenWhenMissingVisibleMessage": true,

package/skills/create-campaign-v2/core/policy.md

@@ -59,8 +59,6 @@ lead-filter.md
 message-prep.md (optional)
 message-candidate-drafts.md (optional, generated from find-leads basis rows)
 message-validation.md
-message-review.md
-message-review-decision.md
 approval-packet.md
 commit-gate-decision.md
 ```

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

@@ -121,33 +121,29 @@ rerun `$sellable:create-campaign`. A normal chat question is acceptable only for
 non-interactive `codex exec` smoke/rehearsal runs because structured user input
 is unavailable by design there.
 
-The packet should read like an AI GTM engineer asking for one final creation
-decision, not an internal validation report. Chat should show a slim approval
-surface only:
-
-1. **campaign** — company + sender
-2. **target** — concise ICP summary from `brief.md`, including concrete
-   role/title names so the user can verify we are aiming at the right buyers
-3. **lead source** — selected source plus one key metric from `lead-review.md`
-   (for example `17/25 sampled fits`, `520 active profiles`, or estimated usable
-   leads). Put the full evidence table in `lead-review.md`, not chat.
-4. **filter** — one-line keep/exclude summary from `lead-filter.md`
-5. **sample message** — one fully filled sample message with no `{{tokens}}`
-6. **what approval creates** — campaign draft + review batch preparation, not
-   live sending
-
-Do not include sequence/settings in the pre-mint final approval packet. Sequence
-attachment and launch settings happen after campaign creation and before the
-later greenlight.
-
-Keep implementation details, tokenized templates, lead tables, rubric JSON, and
-validation notes available in `approval-packet.md` and the supporting artifacts.
-Do not show raw filesystem paths unless links cannot be created or the user asks.
-Use one normal chat link: `Open artifact: approval-packet.md`.
-
-The packet artifact must include a dedicated `## Message Review` section
-immediately before `## Approved Message Template`. This is the customer-facing
-messaging gate. It should not be a raw validation dump; it should answer:
+The packet should read like an AI GTM engineer explaining the campaign, not an
+internal validation report. Start with the practical direction in plain
+language: who we will contact, why this buyer should care, what lead source we
+will use, what the first message says, and what happens if the user approves.
+Keep implementation details available, but move them below the customer-facing
+summary.
+
+1. **brief** — `brief.md` thesis, product, ICP, offer
+2. **lead sample** — first 5-10 rows from `lead-sample.json` rendered as
+   `Name / Title / Company` lines, plus the `lead-review.md` pass-rate
+   and supplied-source framing when `lead-source-intake.json` exists:
+   supplied people list, existing Sellable lead list, or supplied account list
+   plus people search
+3. **lead filter** — the `Decision`, `Who We'll Keep`, `Who We'll Exclude`,
+   `Pass Rate`, and `Recommendation` blocks from `lead-filter.md`; keep
+   rubric internals in `Implementation Details` unless the user asks to inspect
+   the saved filter criteria
+4. **message validation** — the `Selected Winner` from `message-validation.md`,
+   rendered as it will appear in the outbound, plus the `Findings` + `Recommendation`
+
+The packet must include a dedicated `## Message Review` section immediately
+before `## Approved Message Template`. This is the customer-facing messaging
+gate. It should not be a raw validation dump; it should answer:
 
 - `Verdict:` strong / usable-but-could-improve / needs-revision
 - `What works:` why the message is likely to earn replies
@@ -167,10 +163,6 @@ message from the brief. If no winner/template can be extracted, this exact-match
 gate is skipped, but the packet still needs a usable approved template unless
 the user explicitly chose AI-generated messages.
 
-The chat render must not lead with `## Approved Message Template` or token fill
-rules. Show one filled sample first. The artifact can contain the tokenized
-template and fill basis.
-
 Do NOT render the packet as a bundle of opaque validation anchors or a dump
 of raw JSON. The user is approving a live campaign — they need to see what
 they are approving.

package/skills/create-campaign-v2/references/validation-criteria.md

@@ -131,20 +131,6 @@ usable leads after filtering, likely connection acceptance range, likely reply
 range, and estimate basis. If exact performance data is unavailable, use a
 directional range and label it `directional`, not definitive.
 
-`## Evidence Snapshot` and the visible lead-review chat must break estimates out
-by provider/source angle. Do not collapse everything into one raw count. Use
-one row or bullet per angle. The visible chat version should be rendered
-Markdown with indexed sections and short bullets, not a fenced code block. For
-example:
-
-- `Signals / AI outbound posts`
-- `Sales Nav / active SaaS founders + GTM leaders`
-- `Sales Nav / agencies + GTM consultants`
-- `Prospeo / domain-filtered agencies`
-
-Each angle must show raw pool, sampled fits as `n/N`, estimated good-fit range
-after cleanup, expected reply-rate range, and confidence basis.
-
 `lead-sample.json` must include enough structured lead data for downstream
 filtering:
 

package/skills/create-campaign-v2/references/watch-link-handoff.md

@@ -40,7 +40,7 @@ must contain:
 - a plain confirmation that the campaign was created and the approved brief was
   saved
 - a one-line orientation sentence: `Open this to watch lead sourcing, rubric
-  scoring, and messaging populate live.`
+scoring, and messaging populate live.`
 - the `watchUrl` captured from the `create_campaign` response
 
 Example skeleton:

package/skills/find-leads/SKILL.md

@@ -293,6 +293,13 @@ Use first when LinkedIn activity plus tighter role / company filters matter.
 - When you fall back from the recently-posted slice, say clearly that the posted filter was tested, explain why it was dropped, and keep the best non-posted lane as the source of truth.
 - Use `RECENTLY_CHANGED_JOBS` when job-change activity is part of the targeting thesis.
 - If quality is poor, tighten the lane with role, industry, seniority, geography, or activity filters.
+- After each Sales Nav preview, sanity-check the result before using it in the
+  decision: the returned `searchUrl` should include filters, the first page
+  should visibly match the intended roles and companies, and the count should
+  be plausible. If filters did not apply, the search errors, or the total looks
+  obviously unfiltered, retry once with clean filter objects. If it still fails,
+  mark Sales Nav as a provider/tool issue and do not include it as a winning
+  source.
 - If quality is good but scale is too small, widen the lane by adding/removing roles, expanding industries, widening headcount bands, or relaxing activity constraints.
 - Use as many smart refinement steps as needed within the remaining probe budget instead of returning the first under-scaled recipe.
 - If the lane is meant to support scalable outbound, do not stop at a merely borderline workable result when obvious expansion steps remain.

package/skills/providers/sales-nav.md

@@ -114,6 +114,7 @@ NEVER do these:
 
 <filter_format>
 ALL filter values MUST include id, text, and selectionType.
+Pass `filters` as an array of objects. Do not stringify filters as JSON.
 
 CORRECT:
 
@@ -145,6 +146,21 @@ WRONG:
 
 </filter_format>
 
+<result_validation>
+After every `search_sales_nav` call, sanity-check the returned result before
+using it in a source decision:
+
+- `searchUrl` should include a `filters:List(...)` query, not only `keywords`.
+- The sample rows should visibly match the intended role/company lane.
+- The total result count should be plausible for the filters used.
+
+If filters did not apply, the search errors, or the result count is obviously
+unfiltered, do not present Sales Nav as a valid lane. Retry once with clean
+filter objects if the issue was formatting. If it still fails, say plainly:
+"Sales Nav did not apply the filters cleanly, so I’m not using it for this
+decision." Then continue with Signals or Prospeo if they have usable evidence.
+</result_validation>
+
 <static_filters>
 These filters need NO lookup - use these IDs directly: