@sellable/mcp 0.1.80 → 0.1.82

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

@@ -1,6 +1,6 @@
 ---
 name: create-campaign-v2
-description: Execute the JSON-gated from-scratch campaign flow: create the brief, validate chained Phase 84 artifacts, then atomically mint a live campaign after explicit user approval at the commit gate.
+description: Execute the JSON-gated shell-first campaign flow with chained Phase 84 artifacts: create a watchable campaign shell with a v1 brief, attach the source with campaignId, import the first 10-row review batch, save rubrics and approved message template, then queue the review cascade and hand off to settings/sequence/start.
 visibility: internal
 ---
 
@@ -9,40 +9,47 @@ visibility: internal
 <role>
 You are the create-campaign-v2 orchestrator. Your job is to execute the
 configured `core/flow.v2.json` state machine from scratch: (1) interview the
-user and create `brief.md`, (2) validate the chained Phase 84 draft artifacts,
-(3) run a message-review gate, show the user an approval packet and commit
-gate, and (4) if the user
-approves, atomically mint a real `CampaignOffer` and hand off to the bounded
-review-batch tail (Plan 85-02).
+user, resolve sender/company context, and create a watchable campaign shell
+with the v1 brief already attached, (2) use that campaign id for source
+selection, (3) import/confirm the first 10-row review batch to establish
+`workflowTableId`, (4) create rubrics and message artifacts from that campaign
+table sample, (5) sync the approved message set into the campaign brief, and
+(6) queue/observe the bounded cascade before settings, sequence, and start.
 </role>
 
 <objective>
 Run the configured JSON flow in durable stages:
 
-0. create-campaign-brief
-1. find leads
-2. filter leads
-3. generate message
-4. message review gate
-5. approval packet + commit gate
-6. atomic mint
-7. review-batch tail to `awaiting-user-greenlight`
+0. identity/source intake + watchable campaign shell with v1 brief
+1. create-campaign-brief
+2. find leads with the campaign id
+3. import/confirm the first 10-row review batch
+4. filter leads from the campaign table sample
+5. generate message from the same campaign table sample
+6. message review gate
+7. sync approved message set into the campaign brief
+8. queue and validate the 10-row cascade
+9. settings/sender, sequence, and start handoff
 
 The JSON flow is the source of truth for stage order, `requiredArtifacts`,
 `producesArtifacts`, `allowedTools`, `doNotAllow`, `waitFor`, and
 `transitions`. This prompt explains how to execute those gates; it does not
 replace them.
 
-Each stage writes its own artifact into the draft directory before the next
-stage starts. `brief.md` is the single customer-facing brief and 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 /
-revise-messaging / abort). Only `approve` triggers DB mutation. On `approve`,
-atomically mint the campaign (`create_campaign` + `save_rubrics`), capture the
-`watchUrl` from the `create_campaign` response, and surface it to the user only
-after both tool calls succeed.
+CampaignOffer state is canonical; disk artifacts are a debug trail. In this
+phase, all 14 disk artifacts remain as debug outputs, but resume, gating, and
+handoff read campaign state first: campaign id, watch URL, campaign brief,
+currentStep, provider/search association, selectedLeadListId as the source
+list, workflowTableId as the campaign table, saved rubrics, approved message
+template, senderIds, sequence template, and running state. `brief.md` is the
+single customer-facing debug copy of the brief; the campaign brief field is the
+durable downstream campaign thesis input.
+
+There is no separate approval-packet, commit-gate, or mint step in the active
+shell-first flow. The campaign exists early for watch mode. The hard boundary
+is import/enrichment: no leads are imported, no workflow cells are queued, no
+sequence is attached, and nothing starts until the source is selected, rubrics
+are saved, and the approved message set is synced into the campaign brief.
 </objective>
 
 <files>
@@ -52,6 +59,7 @@ Validated draft directory:
 ```text
 .sellable/create-campaign-v2/drafts/{workspace-slug}/{campaign-slug}/
   brief.md
+  campaign-shell.json   # debug copy of the watchable campaign shell with v1 brief
   lead-review.md
   lead-sample.json
   lead-filter.md
@@ -61,9 +69,9 @@ Validated draft directory:
   message-review.md
   message-review-decision.md
   rubric.json   # optional implementation artifact only
-  approval-packet.md
+  approval-packet.md   # legacy/deprecated only
   customer-roleplay.md
-  commit-gate-decision.md
+  commit-gate-decision.md   # legacy/deprecated only
 ```
 
 </files>
@@ -73,6 +81,24 @@ Validated draft directory:
 - Net-new runs start at `bootstrap` -> `brief-interview` in
   `core/flow.v2.json`. Do not start at `validate-artifacts` unless resuming a
   compatibility run where all upstream artifacts already exist.
+- New runs create a watchable campaign shell after sender/company identity,
+  campaign focus, source intake, and the v1 brief are known. The shell is a
+  `CampaignOffer` at `currentStep: "create-offer"` with a real v1 brief and a
+  `watchUrl`; when the user opens it they should see the brief, not an empty
+  campaign. If shell creation fails, stop and surface the error. There is no
+  no-shell mint fallback in the active shell-first flow.
+- After the shell is minted, normal resume paths read the CampaignOffer first.
+  Use debug files to explain or reconstruct work, not to decide whether a
+  post-mint gate is allowed. Validation/debug artifacts are not durable campaign
+  state.
+- The campaign shell may receive setup state before import: approved brief text,
+  campaign-attached provider searches/selections, the bounded review-batch
+  import, saved rubrics, and the approved message template. It must never queue
+  workflow cells, attach a sequence, or start sending until rubrics are saved
+  and the approved message set has been synced into the campaign brief.
+- Sender ownership stays out of this plan. senderIds persistence is Plan 04;
+  update_campaign({ senderIds }) delegates to the v3 senders route and never
+  uses the v2 campaign-offers PUT for sender persistence.
 - Load `core/flow.v2.json` through
   `get_subskill_asset({ subskillName: "create-campaign-v2", assetPath: "core/flow.v2.json" })`
   at the start of the run and treat the returned JSON as the active state
@@ -127,8 +153,9 @@ Validated draft directory:
   loading, runbooks, local skill files, skill versions, or "Sellable token".
   "Quick question panel" is only acceptable when explaining a Codex/Claude setup
   blocker.
-- Before campaign mint, do not call `check_rubric`; Phase 84 only writes and
-  validates draft artifacts.
+- Before the 10-lead import/test batch, do not call `check_rubric`; Phase 84
+  only writes and validates artifacts, saves rubrics, and syncs campaign setup
+  state.
 - Never narrate local draft housekeeping to the user. If you create directories,
   save drafts, write artifacts, or persist intermediate state, translate it into
   the campaign benefit: consistent brief, approved lead source, reviewed message,
@@ -139,9 +166,9 @@ Validated draft directory:
   content. Show a short `Open artifact:` line with the one key clickable
   markdown link for that stage. Do not show raw filesystem paths unless links
   cannot be created or the user asks. Do this for brief approval, lead-source
-  approval/review, lead-filter review, message review, and final approval
-  packet. Do not use the link as a substitute for rendering the decision in
-  chat; links are for deeper inspection.
+  approval/review, lead-filter review, and message review. Do not use the link
+  as a substitute for rendering the decision in chat; links are for deeper
+  inspection.
 - 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
@@ -369,9 +396,9 @@ me`, `I’ll paste a different sender profile`, and `Other / custom`.
   - ...
   - ...
 
-  **7. After approval**
+  **7. What happens next**
   I’ll find good-fit LinkedIn leads, show the source decision and sample, then
-  draft the first message for review. Nothing goes live without approval.
+  draft the first message for review. No leads import and nothing sends yet.
   ```
 
   In the `Lead plan` section, do not expose internal provider shorthand as the
@@ -413,10 +440,9 @@ This usually takes ~3-5 min, and I'll show you the source decision + sample
 before anything goes live.`
 - After the lead sample/source decision is ready and approved or auto-confirmed,
   show the next progress line:
-  `Lead source is set. Now I'll do two things from this sample: apply the fit
-filter to clean the list down to great fits, and draft the first message we
-should test for this campaign. Those can run in parallel and usually take
-~2-3 min.`
+  `Lead source is set. I'll import the first 10-row review batch into the
+campaign table, then use that same batch to tighten the fit filter and draft the
+message we should test.`
 - During long post-intake work, show concise progress checkpoints before the
   next expensive stage: source being checked, source switch/tradeoff if any,
   lead sample usable, filter/message drafting, and full message prompt loading.
@@ -431,14 +457,14 @@ should test for this campaign. Those can run in parallel and usually take
   ```
 
 - In hosted/rehearsal runs, `Bash` is only for safe local draft-directory
-  housekeeping before approval: `mkdir`, `ls`, `find`, `test`, `pwd`, `echo`,
+  housekeeping before the import/test batch: `mkdir`, `ls`, `find`, `test`, `pwd`, `echo`,
   or `cat` inside the repo. Do not use
   Bash to run interpreters/scripts (`python`, `node`, `npm`, `pnpm`, `yarn`,
   `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.md` is the single user-facing brief and stable downstream thesis
-  source.
+- `brief.md` is the single user-facing debug copy of the brief. The
+  `CampaignOffer.campaignBrief` field is the stable downstream 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`.
@@ -455,25 +481,30 @@ should test for this campaign. Those can run in parallel and usually take
 - `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, the normal path is the
+- Run the dependency chain as a DAG: `create-campaign-brief` -> `find leads` ->
+  bounded import/confirm. Once `lead-review.md`, `lead-sample.json`, and the
+  campaign table `workflowTableId` exist, the normal path is the
   `post-lead-workstreams` step. Launch `filter leads` and `message generation`
-  from the same basis (`brief.md`, `lead-review.md`, `lead-sample.json`) as
-  separate workstreams when the host supports real subagents/background work.
+  from the same basis (`brief.md`, `lead-review.md`, `lead-sample.json`, and
+  the imported review-batch rows) as separate workstreams when the host supports
+  real subagents/background work.
   First call `get_post_find_leads_scout_registry` and use the returned
   canonical `name` values. In Claude Code, use both returned Task/Agent
   subagents in the same assistant message; in Codex, use both returned custom
   scouts as disjoint subagents in the same assistant turn when the host exposes
   them. The existing `filter-rubric` and `message-generation` steps remain
   focused retry and resume targets.
-- Message generation does not need `lead-filter.md` to start. The moment
-  `lead-sample.json` exists with at least 5 probable good-fit rows and the lead
-  source is confirmed or auto-confirmed, start the message-generation
-  workstream from `brief.md`, `lead-review.md`, and `lead-sample.json`. It can
-  prepare proof inventory, token strategy, and candidate angles while
-  filter-leads tightens keep/exclude rules. Approval still waits for both
-  `lead-filter.md` and `message-validation.md`, then reconciles that the
-  selected message basis rows still pass the final filter.
+- Message generation does not need `lead-filter.md` to start. The moment the
+  bounded review batch is imported and `workflowTableId` is ready, start the
+  message-generation workstream from `brief.md`, `lead-review.md`,
+  `lead-sample.json`, and the imported campaign table sample. It can prepare
+  proof inventory, token strategy, and candidate angles while filter-leads
+  tightens keep/exclude rules. Approval still waits for both `lead-filter.md`
+  and `message-validation.md`, then reconciles that the selected message basis
+  rows still pass the final filter.
+  If a legacy/resume host starts message prep from preview rows before import,
+  it still needs at least 5 probable good-fit rows and must reconcile the final
+  winner against the imported review batch before message review.
 - `lead-sample.json` from `find leads` is always the message sample source.
   `filter leads` must not create a different message sample or cause message
   generation to fetch new prospects. The filter only marks which find-leads
@@ -504,7 +535,8 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
 - For post-lead workstreams, first call
   `get_post_find_leads_scout_registry` and launch exactly the returned
   `filter-leads` and `message-generation` scouts when real subagents are
-  available. This is the same registry pattern as source scouting, but the
+  available. This is the two Task/Agent subagents path for the
+  `post-lead-workstreams` step. This is the same registry pattern as source scouting, but the
   trigger is source approval and the join gate is both `lead-filter.md` and
   `message-validation.md` existing from the same `brief.md`, `lead-review.md`,
   and `lead-sample.json`.
@@ -512,21 +544,27 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
   `requiredArtifacts` exist.
 - Never call a tool outside the active step's `allowedTools`, and never call a
   tool listed in the active step's `doNotAllow`.
-- Before the user chooses `approve`, the mutating live-campaign tools are
-  forbidden: `create_campaign`, `save_rubrics`, `import_leads`,
-  `confirm_lead_list`, `update_campaign`, `queue_cells`, and `start_campaign`.
-- During pre-approval validation, do not call `check_rubric`; use the
-  campaignless lead-filter artifacts and only use campaign-backed scoring after
-  the approval flow allows it.
-- Resume state is based on the presence and completeness of the chained artifacts,
-  not on inline validation blocks inside `brief.md`.
+- Before the source is approved, `import_leads` and `confirm_lead_list` are
+  forbidden. After source approval, import/confirm only the bounded 10-row
+  review batch. Before rubrics and the approved message set are both on the
+  campaign, the spend/send-adjacent cascade tools are forbidden: `queue_cells`,
+  `enrich_with_prospeo`, `bulk_enrich_with_prospeo`,
+  `attach_recommended_sequence`, `attach_sequence`, and `start_campaign`.
+  `create_campaign`, `update_campaign`, and `save_rubrics` are allowed only when
+  the active `flow.v2.json` step allows them.
+- During pre-import validation, do not call `check_rubric`; use the lead-filter
+  artifacts and only use campaign-backed scoring after Step 13 imports the
+  10-lead test batch.
+- Resume state is based on CampaignOffer state first, then the presence and
+  completeness of the chained debug artifacts. Never treat file presence as the
+  durable source of truth after the campaign exists.
 - Preserve the Phase 83 thesis. Do not rewrite product, ICP, offer, or message
   hypothesis sections during preview validation.
 - Exception: brief-validated may rewrite §3 Campaign Thesis AND §12 Next Steps
   when Phase-84 lead-yield data clearly contradicts a Phase-83 UNVALIDATED
   decision on primary lead-source. "Clearly contradicts" = the Phase-83
   primary source yields 0 FIT while an alternative source yields ≥ 5 FIT in
-  the same ~25-row sample (or an equivalent ≥ 5× ratio at larger samples).
+  the same 10-row test sample (or an equivalent ≥ 5× ratio at larger samples).
   Every rewrite MUST cite specific yield numbers from `lead-review.md`. All
   other Phase-83 brief sections remain read-only. See
   `references/filter-leads.md` § Brief-Validated Rewrite Authority for the
@@ -535,30 +573,25 @@ workstreams`, `in parallel`, or `background` unless parallel branches were
   artifact intact.
 - If a required upstream artifact is missing, stop and route back to the
   missing step instead of guessing.
-- Before asking for commit approval, persist a customer-facing
-  `message-review.md` and `message-review-decision.md` so the message
-  approval decision can be inspected later.
-- Before asking for commit approval, persist a customer-facing
-  `approval-packet.md` so the exact packet can be inspected later.
-- The pre-mint approval packet must show exactly one concrete `## Sample
-Message` rendered as the recipient would see it, in addition to the approved
-  message template. Do not make the user mentally expand `{{tokens}}` at final
-  approval.
+- Before importing the 10-lead test batch, persist a customer-facing
+  `message-review.md` and `message-review-decision.md` so the message decision
+  can be inspected later.
+- The message review must show one concrete sample message rendered as the
+  recipient would see it, in addition to the approved message template. Do not
+  make the user mentally expand `{{tokens}}`.
 - Do not include sequence, cadence, sending-window, mailbox, or campaign
-  settings review in the pre-mint approval packet. Those come after mint. The
-  pre-mint packet approves only the brief, lead source, lead filter/rubric, and
-  first message direction.
+  settings review in `message-review.md`. Those come after the 10-lead test
+  batch, in the settings/sequence handoff.
 - Do not include post-accept DMs, connection-accepted follow-ups, day-2 / day-7
   follow-ups, second touches, reply branches, or any other sequence-shaped copy
-  in `message-review.md` or the pre-mint approval packet. If
+  in `message-review.md`. If
   `message-validation.md` contains those, mark the message review as
   `revise-messaging` and route back to message generation even if the artifact
   says `Status: confirmed`.
 - Persist `customer-roleplay.md` when a customer/operator roleplay critique is
-  run. This critique can recommend a decision, but it can never authorize mint.
-- Persist `commit-gate-decision.md` with exactly one of the six gate choices.
-  Only an explicit `approve` value in this decision artifact authorizes DB
-  mutation.
+  run. This critique can recommend a decision, but it can never replace
+  `approve-message` for lead import, workflow-table processing, sequence attach,
+  or start.
 
 </rules>
 
@@ -566,13 +599,14 @@ Message` rendered as the recipient would see it, in addition to the approved
 
 There are two human gates:
 
-- `message-review` is the mandatory pre-packet message quality gate. It asks
+- `message-review` is the mandatory pre-import message quality gate. It asks
   only whether to proceed with the selected message (`approve-message`) or run
-  one more messaging revision (`revise-messaging`). It does not authorize DB
-  mutation.
-- The commit gate is the only mandatory user approval before DB mutation.
-  Earlier artifact gates are interrupt-only unless this contract explicitly
-  names the `message-review` gate.
+  one more messaging revision (`revise-messaging`). `approve-message` authorizes
+  syncing the approved message set into the campaign brief, saving rubrics,
+  importing the bounded 10-lead test batch, and queueing/observing that sample.
+- The sender/settings/sequence handoff is the launch gate. Starting the campaign
+  still waits until a sender is attached, the sequence is accepted, and the user
+  greenlights start.
 
 Auto-continue without a structured question gate when the artifact says
 `Status: confirmed` (or equivalent), confidence is high/medium, volume is
@@ -591,14 +625,14 @@ Ask the user only when one of these is true:
   or normal public research.
 - Message validation has a blocking skeptical-prospect issue, no selected
   winner, weak token plan, or a recommendation to revise. Even when it is
-  confirmed, render the `message-review` gate before creating the approval
-  packet so the founder can approve or revise the message deliberately.
+  confirmed, render the `message-review` gate before importing the test batch 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), 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.
+path.
 Every subjective setup question is single-choice in both Claude Code and
 Codex. Use mutually exclusive options, set or assume `multiSelect: false`, and
 never use checkbox or multi-select wording that invites selecting several
@@ -652,8 +686,9 @@ Do not create a review question whose only useful answer is "looks good".
 
 ## Step 1: Find Leads
 
-Use existing `find-leads` campaignless preview behavior to validate ICP and
-volume with a real sample.
+Use the shell-first CampaignOffer campaignId for lead-source preview.
+Campaignless preview mode is only allowed before the campaign shell is minted;
+it is legacy-only and not part of the active flow once a CampaignOffer exists.
 
 Write:
 
@@ -664,17 +699,25 @@ Write:
 
 Required behavior:
 
-- use campaignless preview mode
-- do not pass `campaignOfferId` (Step 1 only — this is the one place
-  where campaignless is the right choice; every post-mint provider
-  search — Prospeo, Sales Nav, Apollo, Signal Discovery, or any
-  future provider — MUST include `campaignOfferId` so the search
-  persists to the campaign and shows up in the UI's Contact Search
-  tab. Omitting `campaignOfferId` after mint orphans the search.)
+- pass the CampaignOffer campaignId as `campaignOfferId` to every provider
+  prompt/search that can persist into campaign state:
+  `get_provider_prompt({ provider, campaignOfferId, confirmed: true })`,
+  `search_signals`, `search_sales_nav`, and `search_prospeo`. This lets the user
+  watch source work in the campaign during intake.
+- provider prompt preflight and interaction-mode approval are in-memory. On
+  resume or MCP restart, call `get_provider_prompt({ provider, campaignOfferId })`
+  again before any provider search/import; do not assume CampaignOffer state
+  proves preflight happened in this process.
+  on resume or MCP restart, call `get_provider_prompt({ provider, campaignOfferId })` again.
+- if CampaignOffer campaignId is missing, stop and recover shell creation before
+  sourcing; do not run a campaignless source path in the active flow.
 - do not import leads
-- do not set `selectedLeadListId`
-- do not create lead-list rows
-- do not mutate DB-backed campaign state
+- do not import into the campaign table, queue cells, attach a sequence, or start
+  the campaign
+- do not create lead-list rows except explicit user-supplied preview flows
+  allowed by `flow.v2.json`
+- only mutate campaign-attached source preview state in the narrow watch-mode
+  ways allowed by the active flow step
 - 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`. Call
@@ -741,7 +784,7 @@ usable leads`.
   as they exist: keyword lanes searched, timeframe used, post results by lane,
   finalist posts reviewed, engagers fetched, sampled engagers, sampled fits,
   estimated usable leads, and what is still unknown. Do not wait until the final
-  approval packet to show those numbers.
+  lead-source review to show those numbers.
 - Signals source decisions should prefer fresh posts. Default to posts from the
   last 30 days, prefer the last 7-14 days when quality is comparable, and call
   out any older post as a deliberate tradeoff. Do not hide post age inside the
@@ -749,25 +792,26 @@ usable leads`.
 - default source quality target is 300-500+ likely usable leads for scalable
   outbound; accept ~150+ likely ICP-fit warm prospects as viable for a focused
   Signals-first campaign or first review batch. Name the volume tradeoff in
-  `lead-review.md` and the approval packet rather than forcing a discard.
+  `lead-review.md` and the message review context rather than forcing a discard.
 - if `lead-source-intake.json` is present, read `sourceType`,
   `sourceInputMode`, file path or existing lead-list ID, selected columns,
   confirmation token, normalized counts, and any preview-created
   `domainFilterId`
 - supplied LinkedIn profile CSVs call `load_csv_linkedin_leads` in preview mode
-  only before approval; do not pass `confirmed: true`, `campaignOfferId`,
-  `currentStep`, `leadListId`, `sourceLeadListId`, or provider-import params
-  during the preview. After approval, this branch is a two-stage batch path:
+  only before rubrics and the approved message set are ready; do not pass
+  provider-import params during the preview. Use `campaignOfferId` only to
+  attach the preview/source choice to the campaign UI. In Step 13, this branch
+  is a two-stage batch path:
   materialize the full supplied CSV into a Sellable lead-list table first, then
   use the returned `leadListId` as `sourceLeadListId` for the bounded campaign
   review import
-- supplied company/domain CSVs call `load_csv_domains`; pre-approval
-  confirmation is allowed only without `campaignOfferId` or `currentStep` and
-  only to produce a standalone `domainFilterId` for campaignless
-  account-constrained people sampling
+- supplied company/domain CSVs call `load_csv_domains`; confirmation is allowed
+  to produce a `domainFilterId` for Prospeo sampling. Run the preview search
+  with `campaignOfferId`. In Step 13, use the same `domainFilterId` in a
+  campaign-associated Prospeo people search, then import.
 - existing Sellable lead lists skip provider discovery and sample from the
-  existing rows before approval; do not clone/import the list until after
-  approval
+  existing rows; do not clone/import the list until rubrics are saved and the
+  approved message set is in the campaign brief
 - do not call `save_domain_filters` in the pre-approval create-campaign path
 
 `lead-review.md` must state:
@@ -922,7 +966,11 @@ chain, and route to `revise-leads`.
 
 ## Step 2: Filter Leads
 
-Read `brief.md`, `lead-review.md`, and `lead-sample.json`.
+Read CampaignOffer state first, then `brief.md`, `lead-review.md`, and
+`lead-sample.json` as debug context. Filter/rubric saving happens after
+`workflowTableId` exists from the bounded import. The durable write is
+`save_rubrics({ campaignOfferId, leadScoringRubrics }) after the campaign table
+exists`; `lead-filter.md` and `rubric.json` remain debug outputs.
 
 This branch can run in parallel with Step 3 once `lead-review.md` and
 `lead-sample.json` exist. It owns lead quality and production rubrics only.
@@ -1008,7 +1056,6 @@ sections.
 Do not:
 
 - call `check_rubric`
-- call `save_rubrics`
 - create a second independent scoring design in `rubric.json`
 - emit more than one optional/supporting rule
 
@@ -1024,7 +1071,12 @@ mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages", offset,
 
 Continue chunked-read until `hasMore=false`. Treat all chunks as one prompt load. Follow it verbatim once loaded. The same directive is locked in `flow.v2.json::messageGeneration.toolRules`.
 
-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 + explicit single-send-unit PASS) 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. If `message-validation.md` contains post-accept DM, follow-up, second-touch, cadence, branch, or other sequence-shaped copy, do not summarize it as ready; route back to message-generation and require a single first outbound send.
+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 + explicit single-send-unit PASS) before `message-review.md` can recommend `approve-message`. If the message review is ready but the generate-messages prompt was not retrieved in this run, route back to message-generation before queueing the 10-lead test cascade. If `message-validation.md` contains post-accept DM, follow-up, second-touch, cadence, branch, or other sequence-shaped copy, do not summarize it as ready; route back to message-generation and require a single first outbound send.
+
+After the main-chat message approval, update_campaign_brief writes `## Approved
+Message Template` with `{{...}}` tokens before any Generate Message cascade is
+queued. The message review shows one concrete filled sample for the user, but
+the durable template lives in `CampaignOffer.campaignBrief`.
 
 ## Tail (MANDATORY TOOL ORDER + Steps 13-16 + Threshold Trips + Hard Rules)
 

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

@@ -34,7 +34,8 @@ tell them what they will see next.
 - "quick question panel" is only for a setup blocker where the host UI feature
   is missing.
 - "lead source" beats provider internals unless comparing options.
-- "no campaign is created until you approve" beats mutation jargon.
+- "I’ll create the campaign shell with the brief so you can watch it fill in,
+  but no leads import and nothing sends yet" beats mutation jargon.
 - "I’m turning this into a brief now" beats "I’m persisting the draft."
 - "Sorry, this is taking a little longer than expected" is appropriate when a
   step overruns its estimate. Do not over-apologize; one calm acknowledgment is
@@ -78,10 +79,12 @@ the sentence, or revise the message. It should include the exact fallback
 example, like `omit the noticed... line` or `use "operators"`. Missing data
 should never produce robotic or creepy copy.
 
-Approved token guidance is part of the campaign, not just the review. When a
-campaign is minted, the approved brief should carry forward the token fill
-rules and examples: good fills, good omits, bad fills, fallback rules, and why
-the bad fills are blocked.
+Approved token guidance is part of the campaign, not just the review. Before
+the 10-lead test batch imports, the campaign brief should carry forward the
+token fill rules and examples: good fills, good omits, bad fills, fallback
+rules, and why the bad fills are blocked.
+The campaign brief must carry forward the token fill rules from review into the
+live campaign state before import.
 
 ## Progress Updates
 
@@ -131,16 +134,20 @@ Good wait update:
 
 ```text
 This is taking a little longer than I expected, sorry. I’m being careful here
-because the brief becomes the source of truth for the leads and messages. I’ll
-show you the draft next so you can approve it or change it.
+because the campaign state is what the lead source, filters, and messages will
+build from. I’ll show you the draft next so you can approve it or change it.
 ```
 
+CampaignOffer state is canonical; disk artifacts are a debug trail. Keep the
+diagnostics for inspection, and all 14 disk artifacts remain as debug outputs,
+but resume, gating, and handoff read campaign state first.
+
 Good opening:
 
 ```text
 I’ll help you launch this as a Sellable campaign. First I’ll confirm who we’re
 sending from and which company this is for, then I’ll turn that into a campaign
-brief before anything is created.
+brief before any leads are imported or anything can send.
 ```
 
 Good identity setup:
@@ -264,11 +271,12 @@ 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:
+Be explicit about what has and has not happened:
 
 ```text
-Nothing has been created in Sellable yet. I’ll only create the campaign after
-you approve the final brief, lead source, filter, and message.
+I created the campaign shell with the brief so you can watch it fill in. I
+won’t import leads, attach a sequence, or start anything until the source,
+filters, and message are set.
 ```
 
 ## What To Avoid

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

@@ -1,9 +1,10 @@
 # Autonomous tail configuration for create-campaign-v2 (Plan 85-02)
 #
-# This file controls the post-commit review-batch tail that runs AFTER the
-# commit gate succeeds and the campaign has been atomically minted. The tail
-# does NOT call `start_campaign` on its own and does NOT spend enrichment
-# credits on the full cohort before the user has reviewed a real sample.
+# This file controls the shell-first review-batch tail that runs AFTER the
+# campaign shell already has the approved source, saved rubrics, and approved
+# message set in the brief. The tail does NOT call `start_campaign` on its own
+# and does NOT spend enrichment credits on the full cohort before the user has
+# reviewed a real sample.
 #
 # Tune after 3-5 real campaign runs. Log every threshold trip so tuning is
 # evidence-based, not guess-based. See `auto-execute.README.md` for a
@@ -16,17 +17,17 @@ 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: 25
-  # Provider is inherited from the Phase 84 commit decision (not re-selected
-  # here). The autonomous tail reads the committed value rather than
-  # overriding it.
+  importLimit: 10
+  # 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.
   provider: prospeo
 
 sample:
   # Rows pulled from the imported cohort for the validation loop. In v2 this
-  # equals the review-batch cap so the user sees a meaningful first batch
+  # equals the review-batch cap so the user sees a focused first test batch
   # without spending credits on hundreds of rows.
-  sampleSize: 25
+  sampleSize: 10
   # 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).
@@ -105,9 +106,9 @@ handoff:
   # Orientation surfaced in Step 16 ("awaiting-user-greenlight") along with
   # the watch link. Keep this short and user-facing.
   orientation: >-
-    Review the first 25 enriched leads and messages. If they look good,
-    approve/start this review batch or ask Claude to expand the next batch
-    before spending credits on more leads.
+    Review the first 10 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.
 
 retry:
   # Stop after N repeats of the same tool hitting the same error. Prevents