@sellable/mcp 0.1.54 → 0.1.56

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

@@ -34,8 +34,8 @@ The JSON flow is the source of truth for stage order, `requiredArtifacts`,
 replace them.
 
 Each stage writes its own artifact into the draft directory before the next
-stage starts. `brief-v1.md` is an internal first-draft snapshot; `brief.md` is
-the current customer-facing and downstream campaign thesis input.
+stage starts. `brief-v1.md` is the customer-facing brief output; `brief.md` is
+the canonical downstream campaign thesis input.
 
 After validation artifacts are complete, show the user a commit gate with 6
 choices (approve / revise-brief / revise-leads / revise-rubric /
@@ -78,25 +78,17 @@ Validated draft directory:
   Claude Code, this is `AskUserQuestion`. In Codex, this is
   `request_user_input` (enabled in Default mode by
   `[features].default_mode_request_user_input = true`, not available in
-  `codex exec`). Treat them as equivalent approval gates and persist the same
-  draft artifacts after the user answers. Use this structured gate for crisp
-  identity confirmations, compact setup intake, and approval gates. Never use it
-  to collect raw open text like LinkedIn URLs, company domains, pasted notes,
-  long campaign ideas, or detailed feedback. For buyer strategy, offer/CTA,
-  proof, and lead source, use the structured gate when it is exposed, but treat
-  the visible choices as shortcuts, not a rigid multiple-choice survey. Every
-  setup question must allow a custom typed answer. In Codex,
-  `request_user_input` adds a freeform Other path; in Claude, include an
-  `Other / custom` option. Keep setup intake to two panels because Codex
-  supports at most three questions per panel: target/offer/proof first, lead
-  source second. Do not use checkbox/radio multi-select language like "pick
-  one", "multi-select", or "choose all that apply" for these setup questions.
-  If an interactive
+  `codex exec`). Treat them as equivalent approval/intake gates and persist the
+  same draft artifacts after the user answers. Use this structured gate only for
+  multiple-choice decisions or approval gates. Never use it to collect open text
+  input like LinkedIn URLs, company domains, notes, pasted context, campaign
+  ideas, or feedback. For open text, ask in normal chat and wait for the user to
+  paste the value. If an interactive
   Codex session does not expose `request_user_input`, do not silently degrade to
   a plain chat question; stop and tell the user:
 
   ```text
-  I need Codex’s quick question panel for campaign approvals.
+  I need Codex’s quick question panel to collect campaign inputs and approvals cleanly.
 
   It isn’t enabled in this Codex session yet. I can fix that by updating your Codex settings once, then you’ll reopen Codex and run this again.
 
@@ -112,7 +104,7 @@ Validated draft directory:
   $sellable:create-campaign
 
   After that, I’ll confirm who we’re launching for, then ask the setup questions
-  in chat and start the campaign brief.
+  and start the campaign brief.
   ```
 
   If they decline, tell them to switch to Plan/collaboration mode and rerun
@@ -144,27 +136,7 @@ Validated draft directory:
 - Any time the user is reviewing a list or decision, use rendered Markdown with
   short indexed sections and bullets. Do not use label-plus-paragraph blocks
   like `Key numbers:` followed by one long paragraph. Do not use fenced code
-  blocks for review surfaces. The readable chat surface should look like:
-
-  ```text
-  ## Lead source decision
-
-  **1. Chosen source**
-  - Signals, with a strict filter
-
-  **2. Quick numbers**
-  - **Signals:** 491 posts reviewed. 9/40 sampled engagers fit. Estimate:
-    180-260 usable leads.
-  - **Sales Nav:** 2,598 active profiles. Preview was broader and noisier.
-
-  **3. Sample leads**
-  - Joyjit Ghosh — Co-Founder, Prospectee.io
-  - Ashish Rai — Founder & CEO, ReachHQ
-
-  **4. Tradeoff**
-  - More context, but the filter needs to cut consultants and creators.
-  ```
-
+  blocks for review surfaces.
 - Do not treat the active Sellable workspace as the campaign subject. The
   workspace only tells you where the campaign will be saved. Before buyer, CTA,
   proof, or source questions, identify two things:
@@ -186,9 +158,7 @@ Validated draft directory:
   or most recent company, then ask a structured confirmation question:
 
   ```text
-  Workspace: {workspace}
-
-  I found {matched sender} connected here.
+  I’m ready to build this in {workspace}. I found {matched sender} connected here.
 
   Is that you, and is this campaign for {company}?
   ```
@@ -219,11 +189,11 @@ Validated draft directory:
   company they want to send on behalf of so you can research context:
 
   ```text
-  Workspace: {workspace}
+  I’m ready to build this in {workspace}.
 
-  First, paste your LinkedIn URL or the company website. I’ll use it to confirm
-  the sender and company, then we’ll choose the target, offer, proof, and lead
-  source.
+  First, paste your LinkedIn URL or the company website you want to send on
+  behalf of. I’ll use that to understand the company before we pick the target,
+  offer, proof, and lead source.
   ```
 
   If there is no strong sender match, do not show a structured choice that says
@@ -233,7 +203,7 @@ Validated draft directory:
   customer-facing shape should be:
 
   ```text
-  Workspace: {workspace}
+  I’m ready to build this in {workspace}.
 
   First, what’s your LinkedIn URL? If you’d rather start from the company, paste
   the company website instead.
@@ -243,8 +213,6 @@ Validated draft directory:
   `fetch_linkedin_profile` and infer the user's current or most recent company
   from the profile. For a company website, call `fetch_company` when possible,
   otherwise one web lookup.
-  Before the lookup, use concise progress copy:
-  `Got it — I’ll look it up and confirm the sender + company.`
 
   If `list_senders` did not already run, call it once after the lookup to see
   whether the fetched user appears to match a connected sender. If there is a
@@ -263,29 +231,23 @@ Validated draft directory:
   Sender options should include connected sender names if available, `same as
 me`, `I’ll paste a different sender profile`, and `Other / custom`.
 
-  After the user confirms the subject and sender, run one bounded lightweight
-  company-context pass before asking the campaign setup questions. A sender
-  LinkedIn profile lookup is not enough by itself unless it clearly includes the
-  company's website, product category, customer, and offer context. If the host
-  can run tools in parallel, use one parallel batch with at most 2-3 cheap
-  lookups: `fetch_company` on a LinkedIn company URL from the profile when
-  available; `WebFetch` for the company website/domain when available; otherwise
-  one `WebSearch` for `{company} official website` or `{company} product`. If
-  parallel tool calls are unavailable, do the single highest-confidence lookup
-  first and continue. Do not run full company research, source discovery, Sales
-  Nav, Prospeo, Signals, or multi-query browsing here. The goal is a fast 15-30
-  second context read so the four setup questions feel specific. If identity is
-  still unavailable, use neutral/custom intake options instead of guessed
-  vertical-specific options.
+  After the user confirms the subject and sender, run one lightweight company
+  lookup if it has not already run, then ask the campaign setup questions. The
+  setup questions should use the confirmed company context so they do not feel
+  generic. If identity is still unavailable, use neutral/custom intake options
+  instead of guessed vertical-specific options.
 
 - Before the identity gate, use this customer-facing shape:
 
   ```text
-  Workspace: {workspace}
+  I’m ready to build the campaign in {workspace}.
 
-  First I’ll check for a connected LinkedIn sender. If I can’t confirm one, I’ll
-  ask for your LinkedIn URL or company website before we choose the target,
-  offer, proof, and lead source.
+  First I’ll check whether you already have a connected LinkedIn account here.
+  If I can’t confirm it, I’ll ask for your LinkedIn URL or company website and
+  use that to understand the company before we choose the target, offer, proof,
+  and lead source.
+
+  Then I’ll turn that into a campaign brief for you to approve before anything is created.
   ```
 
 - Fast Intake Mode is mandatory for hosted/rehearsal net-new runs. Ask the
@@ -293,28 +255,22 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   that first packet, the first assistant turn may only call
   `bootstrap_create_campaign`, load this workflow prompt with
   `get_subskill_prompt({ subskillName: "create-campaign-v2" })`, optionally run
-  one lightweight identity lookup, then confirm launch identity. After
-  identity is confirmed, run the bounded lightweight company-context pass above
-  before generating buyer/offer/proof/source options. If the user
+  one lightweight identity lookup, then use the structured question gate. If the user
   supplied a company website/domain, call exactly one of `fetch_company`,
   `WebFetch`, or `WebSearch` to identify what the company actually does before
   generating setup options. If the user supplied a LinkedIn profile URL, call
   `fetch_linkedin_profile` before generating setup options. Do not infer the
   product category from the company name alone. If no domain, website, LinkedIn
-  profile, or sender identity is supplied, the first setup intake must ask for
-  the launch identity before buyer/offer/source. Before that first setup intake,
-  do not run source discovery, Sales Nav, Prospeo, Signals, Bash, Read, Write,
-  Edit, Glob, Grep, full company research, or
+  profile, or sender identity is supplied, the first structured question gate
+  must ask for the launch identity before buyer/offer/source. Before that first
+  structured question gate, do not run source discovery, Sales Nav, Prospeo,
+  Signals, Bash, Read, Write, Edit, Glob, Grep, full company research, or
   draft-directory inspection/creation. `list_senders` is allowed once before the
   first identity gate as a quiet token/sender inference shortcut, and once means
   once: do not call it again after a LinkedIn lookup if it already ran. Do
   draft-directory setup only after the founder answers. After launch identity is
-  confirmed, ask buyer, offer/CTA, proof, and lead source through the structured
-  question gate when available. Split the setup intake into two panels:
-  target/offer/proof first, then lead source. Do not present these as
-  checkbox/radio multi-select gates. Use 2-3 context-specific suggested answers
-  per question as fast-start shortcuts, and rely on the freeform custom path for
-  nuanced answers.
+  confirmed, the setup packet must ask buyer, offer/CTA, proof, and lead source,
+  and all four questions must include an `Other / custom` option.
 - After the founder answers the first strategy/source packet, explain the next
   stage only: campaign brief creation and brief approval. Use this shape:
 
@@ -393,33 +349,7 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   In the `Lead plan` section, do not expose internal provider shorthand as the
   explanation. Avoid bare phrases like `signal discovery`, `founder-led GTM`,
   `RevOps`, `outbound systems`, or `pipeline architecture` unless they are
-  translated into what the user can understand. For example:
-
-  ```text
-  I’ll start by looking for LinkedIn activity from founders and revenue leaders
-  who are talking about pipeline problems, CRM handoffs, outbound tooling, or
-  messy sales processes.
-  ```
-
-  Do not paste the full rich brief into chat for approval unless the user asks.
-  Do not show long filesystem paths in the normal approval view. After the slim
-  brief, include only:
-
-  ```text
-  Open artifact: [brief.md]
-  ```
-
-  If clickable links cannot be created, show one compact fallback line:
-  `Trouble opening artifacts? I can show the file paths.`
-
-  The `Offer / CTA` section must name the useful thing the buyer gets by
-  replying. Do not use vague peer-call framing like `compare notes`, `swap
-  notes`, `worth chatting`, `pick your brain`, or a bare `15 minute call` unless
-  the user explicitly asks for that. A low-friction CTA is only good when the
-  object is concrete: a checklist, workflow teardown, benchmark, sample, short
-  loom, diagnostic, bottleneck map, relevant proof asset, or a working session
-  with a clear output. If the first draft produces a vague CTA, revise it before
-  showing the brief.
+  translated into what the user can understand.
 
   After rendering that brief, ask for brief approval when there is a real
   strategic choice or the user has not already made the direction obvious. The
@@ -460,13 +390,8 @@ should test for this campaign. Those can run in parallel and usually take
   `npx`), call APIs, query databases, inspect prompt dumps, run git, or
   synthesize artifact content. Use `Read`/`Write`/`Edit` for artifact files and
   MCP tools for product actions.
-- `brief-v1.md` is only an internal first-draft snapshot. Do not show it in the
-  normal user-facing approval view. `brief.md` is the stable downstream input,
-  current user-facing brief, and thesis source.
-- On brief edits or revisions, update `brief.md` directly. Do not run another
-  long brief-generation pass just to create `brief-v2.md`. If version history is
-  ever needed, create it only as a cheap local copy after the edit; never spend
-  model/research time writing duplicate versions.
+- `brief-v1.md` is the user-facing brief. `brief.md` is the stable downstream
+  input and remains the thesis source.
 - `lead-review.md` and `lead-sample.json` are the required outputs of `find leads`.
 - `lead-filter.md` is the primary output of `filter leads`.
 - `rubric.json` is optional and secondary to `lead-filter.md`.
@@ -478,30 +403,29 @@ should test for this campaign. Those can run in parallel and usually take
   sample rows that already look like probable good fits. It can contain rough
   candidate messages and element tests, but it cannot select the final winner
   and cannot override `lead-filter.md`.
-- `message-validation.md` is the normal output of `generate message`.
+- `message-validation.md` is the internal validation artifact produced by the
+  user-facing `message generation` stage.
 - `message-review.md` and `message-review-decision.md` are the mandatory
   message quality gate outputs between `message-validation.md` and
   `approval-packet.md`.
 - Run the dependency chain as a DAG: `create-campaign-brief` -> `find leads`;
   once `lead-review.md` and `lead-sample.json` exist, run `filter leads` and
-  the explicit `generate message` validation as parallel branches from the same
-  basis (`brief.md`, `lead-review.md`, `lead-sample.json`). Approval waits for
-  both `lead-filter.md` and `message-validation.md`, then reconciles that the
+  `message generation` as parallel branches from the same basis (`brief.md`,
+  `lead-review.md`, `lead-sample.json`). Approval waits for both
+  `lead-filter.md` and `message-validation.md`, then reconciles that the
   selected message basis rows still pass the final filter.
-- Parallel means real parallel execution, not just optimistic progress copy.
-  After lead review:
-  - If the host exposes Task/subagent workers and host policy allows them for
-    this user request, launch two disjoint workers: one owns `lead-filter.md`
-    and optional `rubric.json`; the other owns `message-prep.md`,
-    `message-validation.md`, and `message-review.md`.
-  - If only parallel tool batching is available, batch only independent tool
-    reads/lookups. Do not pretend whole artifact-writing stages are running in
-    the background.
-  - If real parallel execution is not available or not allowed, run the same DAG
-    sequentially and use honest copy: `I’ll tighten the filter first, then draft
-the message from the same sample.`
-  - Never say `kicking off two workstreams`, `in parallel`, or `background`
-    unless parallel branches were actually launched.
+- Parallel means real parallel execution, not optimistic progress copy. After
+  lead review, if the host exposes Task/subagent workers and host policy allows
+  them for this user request, launch two disjoint workers: one owns
+  `lead-filter.md` and optional `rubric.json`; the other owns the user-facing
+  message generation branch and may write `message-prep.md`,
+  `message-validation.md`, and `message-review.md`. If only parallel tool
+  batching is available, batch independent tool reads/lookups only. If real
+  parallel execution is not available or not allowed, run the same DAG
+  sequentially and use honest copy: `I’ll tighten the filter first, then draft
+the message from the same sample.` Never say `kicking off two workstreams`,
+  `in parallel`, or `background` unless parallel branches were actually
+  launched.
 - Never run a downstream stage until the active `flow.v2.json` step's
   `requiredArtifacts` exist.
 - Never call a tool outside the active step's `allowedTools`, and never call a
@@ -575,37 +499,34 @@ Ask the user only when one of these is true:
   packet so the founder can approve or revise the message deliberately.
 
 When asking subjective strategy questions (buyer scope, first ask, proof
-emphasis, tone, lead-source preference), use the structured quick question panel
-when available. Do not make it feel like a rigid multiple-choice survey:
-suggested directions are shortcuts, and the user must be able to type a custom
-answer in their own words. Ask target, offer, and proof in the first panel; ask
-lead source in a second panel. Do not add custom options to the final six-choice
-commit gate.
+emphasis, tone, lead-source preference), always make it clear the user can give
+a custom answer. Add an explicit `Other / custom` option to each subjective
+question. Do not rely on prose like "you can add detail" as the only custom
+path. Do not add custom options to the final six-choice commit gate.
 Use customer-facing question wording:
 
-- target prospects: `Who should this campaign target?`
-- main CTA / offer: `What useful thing should {{sender_or_company}} offer them?`
-- proof emphasis: `What proof should we lean on?`
+- target prospects: `Who should be the target prospects for this campaign? Pick one or combine.`
+- main CTA / offer: `What should the main CTA or offer be? Pick one or combine.`
+- proof emphasis: `Which proof point would most increase this buyer's confidence in {{company}}? Multi-select fine.`
 - lead source: `How should we get the people for this campaign?`
 
-Offer shortcuts must be concrete deliverables or outcomes, not meeting wrappers.
-Good examples: `send a short checklist`, `map 2-3 workflow bottlenecks`, `show a
-relevant customer example`, `teardown their public workflow`, `walk through a
-sample output`, or `diagnose where the current process slows down`. Bad
-examples: `compare notes`, `quick intro call`, `worth chatting`, `pick your
-brain`, `learn more`, or `see if it makes sense`.
-
-Ask the lead-source question as the last question in the first strategy batch,
-after buyer, offer/ask, and proof/safety are understood. Frame supplied lists as
-optional, not required. Suggested lead-source shortcuts should include:
-`I can find people for you, use a CSV of LinkedIn profiles, use a CSV of company
-domains, use an existing Sellable lead list, or follow another source idea.`
-If the user pastes up to 100 LinkedIn profile URLs or company domains, normalize
-the paste into a temporary local CSV and continue through the matching CSV
-preview path. Mixed, ambiguous, malformed, or oversized pastes should ask for a
-real CSV file instead of guessing. Uploaded CSV support is larger than paste
-support: LinkedIn profile CSVs can contain up to 7,500 rows; domain CSVs can
-contain up to 7,500 rows but only 1,000 unique domains.
+Ask the lead-source question as the last question in the first strategy
+batch, after buyer, offer/ask, and proof/safety are understood. Frame supplied
+lists as optional, not required. The three visible options are exactly:
+
+1. `Find people for me (recommended if you don't already have your own list)`
+2. `I have a CSV of LinkedIn profiles`
+3. `I have a CSV of company domains`
+
+Keep `Other / custom` available for freeform answers such as a pasted list,
+an existing Sellable lead list, or another source idea. Do not put existing
+Sellable lead lists in the main three-option first batch; support them through
+custom/freeform input. If the user pastes up to 100 LinkedIn profile URLs or
+company domains, normalize the paste into a temporary local CSV and continue
+through the matching CSV preview path. Mixed, ambiguous, malformed, or oversized
+pastes should ask for a real CSV file instead of guessing. Uploaded CSV support
+is larger than paste support: LinkedIn profile CSVs can contain up to 7,500
+rows; domain CSVs can contain up to 7,500 rows but only 1,000 unique domains.
 
 Avoid internal wording like `Which proof points should the message be allowed
 to lean on?` because it describes the artifact, not the founder decision.
@@ -642,12 +563,31 @@ Required behavior:
 - do not set `selectedLeadListId`
 - do not create lead-list rows
 - do not mutate DB-backed campaign state
-- run a parallel source scout when the source is not supplied, but choose the
-  lanes from the sourcing approach rather than running every provider by
-  default. For Signals-first campaigns, search multiple Signals keyword lanes
-  and fetch top-post engagers in parallel. For Sales Nav-first or
-  Prospeo/account-first campaigns, run multiple preview lanes for that provider
-  in parallel and use Signals only as a warmth/quality check when relevant
+- run a real parallel source-angle scout when the source is not supplied and at
+  least two viable source angles exist. Treat source scouting as independent
+  branches, then compare the outputs in `lead-review.md`.
+  - Branch A: Signals / active LinkedIn posts. Search relevant keyword lanes,
+    review finalist posts, fetch top-post engagers, and estimate warm-fit
+    volume.
+  - Branch B: Sales Nav / title + company filters. Run preview filters, inspect
+    preview rows, and estimate scalable-fit volume.
+  - Branch C: Prospeo / domains only when the campaign has a domain/account
+    path or the user supplied domains. Estimate email/contact scale and call out
+    weaker LinkedIn activity.
+    If the host cannot run these branches in parallel, run them sequentially and
+    do not claim they ran in parallel. If only one source angle is credible, say
+    that and run the best primary source plus one cheap fallback/quality check
+    when available. For Signals-first campaigns, search multiple Signals keyword
+    lanes and fetch top-post engagers in parallel when tool batching allows it.
+    For Sales Nav-first or Prospeo/account-first campaigns, run multiple preview
+    lanes for that provider in parallel and use Signals only as a warmth/quality
+    check when relevant
+- after every Sales Nav preview, validate that filters actually applied before
+  using the lane in `lead-review.md`: `searchUrl` should include filters, the
+  first page should match the intended roles/companies, and the result count
+  should be plausible. If Sales Nav returns a giant unfiltered pool, drops the
+  filters, or errors after one clean retry, call it out as a provider/tool
+  issue and do not recommend Sales Nav.
 - for Signals-first campaigns, raw post search volume is only inventory, not
   lead volume. `492 post results` means matching LinkedIn posts found across
   keyword lanes; it does not mean 492 prospects. The source decision must name
@@ -753,17 +693,12 @@ table with one row per selected or finalist post:
 `## Evidence Snapshot` must include a compact numbers-first table:
 
 - source lane / keyword or filter
-- provider/source angle label, e.g. `Signals / AI outbound posts`,
-  `Sales Nav / active SaaS founders + GTM leaders`, or
-  `Prospeo / domain-filtered agencies`
 - timeframe searched
 - raw results found
 - finalist posts or preview rows reviewed
 - sampled people
 - sampled fits, shown as `n/N (%)`
 - estimated usable people
-- estimated good-fit range after cleanup
-- expected reply-rate range
 - confidence note (`sample-backed`, `directional`, or `needs more sample`)
 
 For Signals-first campaigns, `## Sample Leads` must group representative sample
@@ -777,11 +712,11 @@ directional range and label it `directional`, not definitive.
 
 When showing `lead-review.md` to the user, render a slim decision summary in
 chat, not the full evidence table. Use rendered Markdown directly with short
-bullet lines; do not use fenced code blocks for the user-facing lead review.
-The visible response must include:
+indexed sections and bullet lines; do not use fenced code blocks for the
+user-facing lead review. The visible response must include:
 
 - `Lead source decision`
-- `Chosen source`
+- `Recommendation`
 - `Why it won`
 - `Quick numbers` as bullet points, with one provider/source angle per bullet.
   Each bullet must include raw volume, sampled fit rate as `n/N`, estimated
@@ -794,33 +729,6 @@ Keep `## Evidence Snapshot`, selected posts, discarded paths, full sample rows,
 and `lead-sample.json` details in artifacts. Do not show raw filesystem paths
 unless links cannot be created or the user asks.
 
-Use this chat shape for the quick-number bullets:
-
-```text
-**1. Quick numbers**
-- **Signals / AI outbound posts:** 249 posts found. Sampled 40 engagers; 18/40
-  looked usable. Estimate: 100-250 good warm fits. Expected reply: 6-12%.
-- **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
-  after title/company cleanup. Expected reply: 4-9%.
-- **Prospeo / domain-filtered agencies:** 1,000+ likely contacts if we need scale,
-  but weaker LinkedIn activity. Estimate: 500-1,000 contacts. Expected reply:
-  2-5%.
-```
-
-After the lead source is set, use this progress copy before the parallel
-filter/message work:
-
-```text
-Lead source is set.
-
-I’m kicking off two workstreams now:
-1. Tighten the fit filter so we only reach out to the right people.
-2. Draft the first message from the approved brief and real sample leads.
-
-These can run in parallel and usually take ~2-3 min.
-```
-
 For supplied profile CSVs and existing lead lists, `lead-review.md` must not
 describe a generic TAM estimate or pretend the rows came from Sales Nav/Prospeo
 discovery. For supplied domain/account lists, explain that domains are account
@@ -891,31 +799,6 @@ Required behavior:
 - `Recommendation`
 - `Implementation Details`
 
-When showing the filter result in chat, render a slim summary before moving to
-message review. Use rendered Markdown, indexed sections, and short bullets:
-
-```text
-## Lead filter
-
-**1. Keep**
-- {role/title family}
-- {company/context family}
-
-**2. Exclude**
-- {false-positive family}
-- {false-positive family}
-
-**3. Why**
-- {sample-backed reason}
-
-**4. Expected impact**
-- {1 line}
-
-Open artifact: lead-filter.md
-```
-
-Keep production rubric details and `rubric.json` internals in the artifact.
-
 When `rubric.json` is emitted, it must use the production rubric shape, not a
 custom sidecar schema:
 
@@ -956,43 +839,6 @@ Continue chunked-read until `hasMore=false`. Treat all chunks as one prompt load
 
 Do NOT proceed to Step 4 (message review gate) without loading and following the full generate-messages workflow. `message-validation.md` must prove the full workflow ran (all required sections present + raw sendable Selected Winner) before `message-review.md` can recommend `approve-message`. If the message review or approval packet is ready but the generate-messages prompt was not retrieved in this run, route back to message-generation instead of asking the commit gate.
 
-When showing message review in chat, lead with one fully filled sample message,
-not the tokenized template. Use rendered Markdown, indexed sections, and short
-bullets around the sample. The visible response must include:
-
-- `Message review`
-- `Subject`
-- `Sample message` with no `{{tokens}}`
-- `Why it should work`
-- `Concern`
-- `Recommendation`
-- `Open artifact: message-review.md`
-
-Keep tokenized templates, token fill basis, rendered examples, good/bad token
-fill examples, validation notes, and `message-validation.md` details in
-artifacts.
-
-## Step 4: Final Approval Packet
-
-When showing the final approval packet, render a slim "ready to create" summary
-in chat. Use rendered Markdown, indexed sections, and short bullets. The visible
-response must include:
-
-- `Ready to create campaign`
-- `Campaign`
-- `Target` with concrete role/title names
-- `Lead source` with one key metric
-- `Filter`
-- `Sample message` with one fully filled sample and no `{{tokens}}`
-- `What approval creates`
-- `Safety`
-- `Open artifact: approval-packet.md`
-
-Keep tokenized templates, evidence tables, rubrics, validation notes, and long
-implementation details in `approval-packet.md`. Do not include
-sequence/settings in the final approval packet; sequence attachment and launch
-settings happen after campaign creation and before the later greenlight.
-
 ## Tail (MANDATORY TOOL ORDER + Steps 13-16 + Threshold Trips + Hard Rules)
 
 The full tail detail (~17k chars: MANDATORY TOOL ORDER, auto-execute-leads, validate-sample loop, auto-execute-messaging, awaiting-user-greenlight, threshold-trip logging, tail hard rules) lives in a dedicated on-demand subskill to keep this entry prompt fast to load.