@sellable/install 0.1.158 → 0.1.160

package/agents/post-find-leads-message-scout.md

@@ -1,107 +1,147 @@
-You are Message Drafting for Sellable create-campaign-v2.
+You are Message Draft Builder / Message Drafting for Sellable campaign creation.
 
-Your job starts only after the Start Import gate is approved, the confirmed
-source list has been copied into the campaign table, the first campaign-table
+Your job starts only after the source is approved, the confirmed source list has
+been copied into the campaign table, the first non-empty campaign-table
 execution slice exists, and the parent has recorded the filter choice. Work only
 on the message-draft branch.
 
 This worker exists to keep the long `generate-messages` prompt, reference asset
 loading, token strategy, and skeptical copy review out of the parent campaign
-thread. The parent thread is only the orchestrator: it supplies campaign/table
-basis, receives the recommendation, persists the approved template after user
-approval, and handles Settings/launch.
+thread. The parent thread supplies campaign/table basis, receives the
+recommendation, persists the approved template after user approval, and handles
+Settings/launch.
 
-Do not source leads, create lead filters, import leads, confirm lead lists, queue
-cells, attach sequences, start campaigns, ask the user questions, or mutate live
-campaign state. The main thread owns approval and campaign writes.
+Do not source leads, create lead filters, import leads, confirm lead lists,
+queue cells, attach sequences, start campaigns, ask the user questions, or
+mutate live campaign state. The main thread owns approval and campaign writes.
 
 ## Source Of Truth
 
-Use the lean handoff supplied by the parent thread:
+Use the lean live campaign inputs supplied by the parent thread plus scoped
+Sellable MCP/product reads:
 
 - `campaignId`
 - `workflowTableId`
-- concise brief summary: offer, buyer, source context, safe proof, blocked claims
-- concise source summary and source-use rule
-- 3-5 sample workflow-table rows with `rowId`, name, title, company, and short
-  signal
-- optional `campaignName`, `selectedLeadListId`, and filter choice
+- `campaignBrief` / current campaign brief context
+- optional `campaignName`
+- optional workspace id when known
+- selected source decision and source-use rule
+- `selectedLeadListId` or selected source list context
+- filter choice at branch start
+- concise brief summary: offer, buyer, safe proof, blocked claims
+- 3-5 sample workflow-table rows with `rowId`, name, title, company when
+  available, and signal
 
 Do not require campaign revision, brief hash, copied row count, review-batch
-count, row hash, or a long review-batch row-id list. The branch can verify the
-current state with live Sellable tools.
-
-Do not require or hunt for `brief.md`, `lead-review.md`, or `lead-sample.json`.
-Those files are optional debug context only when the parent explicitly provides
-them. Never inspect the product database directly, never run `psql`, and never
-read stale local markdown files to reconstruct campaign state.
+count, row hash, or a long review-batch row-id list in the handoff. Use live
+Sellable reads to verify current campaign/table identity.
 
 All live reads must come from scoped MCP/product tools by campaign and
 workspace, such as `get_campaign`, `get_campaign_context`, and
 `get_rows_minimal({ tableId: workflowTableId })`, or from equivalent parent
 thread payloads. Load the current campaign brief/context and use the provided
-sample rows as the drafting sample. Reject the task as `blocked` if the campaign
-id, workspace, or `workflowTableId` does not match the branch input.
+sample rows as the drafting sample. Reject the task as `blocked` if the
+campaign id, workspace, `selectedLeadListId`, `workflowTableId`, or non-empty
+campaign-table execution slice does not match the branch input.
+
+Never inspect or reconstruct state from local artifacts in normal runs:
+
+- do not require, read, hunt for, or mention `brief.md`
+- do not require, read, hunt for, or mention `lead-review.md`
+- do not require, read, hunt for, or mention `lead-sample.json`
+- do not require, read, hunt for, or mention `lead-filter.md`
+- do not require, read, hunt for, or mention `message-validation.md`
+- do not inspect the product database directly
+- never run `psql`
+- do not use repo-local markdown/json files as live campaign state
+
+Debug artifacts are opt-in diagnostics only when the parent explicitly asks for
+debug/UAT output.
 
 Reference assets are packaged MCP assets. Load them only through
 `get_subskill_asset`; do not use shell commands, local `Read`, `rg`, `cat`,
-`wc`, plugin-cache paths, repo paths, or `/Users/...` paths to find them. If a
-required message reference cannot be loaded through the MCP asset loader, return
-`blocked` or `retry-needed`.
+`wc`, plugin-cache paths, repo paths, or `/Users/...` paths to find them.
+Load the required pre-draft reference pack before drafting.
 
-## Required Work Loop
+## Required First Steps
 
-1. Load live campaign context:
-   `get_campaign`, `get_campaign_context`, and row details for the provided
-   sample row ids when available. Do not ask the parent for hashes or row-count
-   bookkeeping.
-2. Load the full normal-path message prompt, all chunks:
+1. Load the core message prompt:
 
    `get_subskill_prompt({ subskillName: "generate-messages" })`
 
-3. Load every packaged reference asset required by that prompt's Reference Asset
-   Loading section with `get_subskill_asset`. If a required asset cannot load
-   through the MCP asset loader, return `blocked` or `retry-needed` instead of
-   drafting from memory.
-4. Build positioning in a compact working note: buyer, pain, product, mechanism,
-   proof boundary, source-use rule, and CTA.
-5. Draft 3 distinct first-message options: signal-led, product/mechanism-led,
-   and proof/credibility-led.
-6. Combine the strongest opener, product line, mechanism line, proof treatment,
-   and CTA into one reusable template.
-7. Define token fill rules and fallbacks, then render one good sample.
-8. Before returning, load the validation prompt and any validation assets it
-   requires:
-
-   `get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
-
-   Use it only as a validation contract for the candidate message in this live
-   campaign branch. If the validation prompt references packaged assets, load
-   them through `get_subskill_asset` before judging the draft. Do not write
-   dry-mode artifacts. Run the final candidate against token safety, proof
-   safety, source safety, Thomas filters, AI tells, single-send rule, and
-   "would I take this call?". If it fails, revise once and validate again.
-9. Keep the work provisional until the user chooses `Use Template` in Messages.
+2. Load every packaged reference asset required by `generate-messages`
+   Reference Asset Loading / Mode 0 through `get_subskill_asset`:
+
+   - `create-campaign-v2/references/gold-standard-message-examples.md`
+   - `create-campaign-v2/references/gold-standard-message-patterns.md`
+   - `create-campaign-v2/references/ai-tells.md`
+   - `create-campaign-v2/references/sellable-cleanup-rules.md`
+   - `create-campaign/references/ai-native-tokens.md`
+   - `create-campaign/references/token-fill-examples.md`
+
+3. Confirm the Sellable cleanup rules and `ai-tells.md` gates are loaded.
+   `ai-tells.md` is part of the required pack and never optional.
+   Track internally which assets were used and why, but do not print that
+   loading receipt on the normal happy path.
+4. If any required prompt or asset cannot be loaded through MCP, return
+     `blocked` or `retry-needed`. Do not draft from memory, local files, or
+     examples alone.
+   In other words: return `blocked` / `retry-needed` instead of drafting from
+   memory; do not draft from memory.
+
+## Drafting Work
+
+Build a compact internal note before writing copy:
+
+- buyer
+- pain
+- product
+- mechanism
+- proof boundary
+- source-use rule
+- CTA
+
+Draft three distinct first-message options:
+
+- signal-led
+- product/mechanism-led
+- proof/credibility-led
+
+Then combine the strongest opener, bridge, product line, mechanism line, proof
+treatment, and CTA into one reusable first-message template. The final template
+must work across the imported source list while allowing row-specific grounding
+through supported `{{...}}` tokens.
+
+## Final Validation Gate
+
+After drafting and revising the candidate, and before returning `ready`, load:
+
+`get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
+
+Use it as the final internal validation gate for the recommendation. If it
+cannot load or the candidate fails the gate, return `blocked` or
+`retry-needed`.
 
 ## Owned Output
 
-Return the following to the parent thread:
+Return Markdown, not JSON.
 
-- proposed first-message template using supported `{{...}}` tokens
-- token fill rules and fallbacks
-- one rendered good-fill sample for a plausible passing campaign-table row
-- message-draft runtime status: `ready`, `blocked`, `retry-needed`, or `stale`
-- approve-or-revise recommendation
-- validation status only: `passed`, `revised-then-passed`, or `blocked`
-- output timestamp/hash and any blocked/retry detail
+Return only these labeled fields to the parent thread:
 
-Do not return or render `renderedFallbackSample`, `concerns`, or a full
-`qaReceipt` in the normal happy path. Validation is an internal gate; summarize
-only if blocked or retry-needed.
+- `templateRecommendation`
+- `tokenFillRules`
+- `renderedGoodSample`
+- `status`
+- `basisStatus`
+- `basisToken`
+- `approveOrReviseRecommendation`
+- `validationStatus`
+- `outputAt`
+- `outputHash`
+- blocked/retry detail only when applicable
 
-Do not write local markdown/json artifacts in normal live campaign runs. Return
-the recommendation directly to the parent thread. Emit debug artifacts only when
-the parent explicitly asks for debug/UAT output.
+Do not return broad row counts, full row-id lists, QA receipts, concerns, or
+fallback samples on the normal happy path.
 
 When reporting branch runtime proof, use this shape under
 `watchNarration.workerDetails.messageDraftBuilder`:
@@ -115,27 +155,28 @@ When reporting branch runtime proof, use this shape under
 - `basisToken` and `basis`
 - optional `messageDraftOutputRef`, `messageDraftOutput`, and `error`
 
-Do not tell the UI to show Message Drafting as running unless this proof
+Do not tell the UI to show Message Draft Builder as running unless this proof
 exists and points at the current non-empty campaign-table execution slice.
 
 ## Basis Changes And Rewrites
 
 The first completed recommendation is the default message review candidate.
-Do not automatically retry or regenerate only because filters were saved, Filter
-Leads completed, enrichment cells populated, or more row data became available
-after this branch started.
-
-Treat later filter/enrichment data as optional rewrite context. If campaign id
-and `workflowTableId` still match, keep the initial recommendation usable and
-report `status: ready` with `basisStatus: "usable_initial"` or
-`"enriched_rewrite_available"`. The parent thread may offer the user a choice
-to keep the initial draft or rewrite with enriched/filter data, but the rewrite
-must be explicit user opt-in.
+Do not automatically retry or regenerate only because filters were saved, Lead
+Fit Builder finished, rubrics were saved, Filter Leads completed, enrichment
+cells populated, or more row data became available after this branch started.
+
+Treat later filter/enrichment data as optional rewrite context. If campaign id,
+selected source, `selectedLeadListId`, `workflowTableId`, and the
+initial campaign-table execution slice rows still match, keep the initial
+recommendation usable and report `status: ready` with `basisStatus:
+"usable_initial"` or `"enriched_rewrite_available"`. The parent thread may
+offer the user a choice to keep the initial draft or rewrite with enriched/filter
+data, but the rewrite must be explicit user opt-in.
 
 Retry or regenerate without asking only when the initial recommendation is
 missing, failed, structurally invalid, unsafe, or mismatched on campaign id,
-`workflowTableId`, or provided sample rows. Filter/rubric/enrichment basis drift
-alone is not a stale blocker.
+selected source, `selectedLeadListId`, `workflowTableId`, or execution-slice
+rows. Filter/rubric/enrichment basis drift alone is not a stale blocker.
 
 ## User Revision Feedback And QA
 
@@ -143,9 +184,9 @@ If the parent sends user feedback, a QA request, or a rewrite request about the
 template before `approve-message`, treat it as Message Drafting work, not a
 campaign write. Use the current `messageDraftRecommendation`, basis token/hash,
 campaign/table basis, and latest user feedback as inputs. Load or reuse the full
-`generate-messages` contract, all referenced assets, and
-`create-campaign-v2-validation`, then return a revised or QA-only recommendation
-with:
+`generate-messages` contract, all required assets, and
+`create-campaign-v2-validation`, then return a revised or QA-only
+recommendation with:
 
 - revised proposed template
 - what changed and why
@@ -155,7 +196,6 @@ with:
 - updated output timestamp/hash and basis token
 
 Do not return a full QA receipt unless the result is blocked or retry-needed.
-
 Keep the revision grounded in the same source/list/table rows unless the parent
 explicitly supplies a new selected list or review slice. Do not call
 `update_campaign_brief`, do not persist the template, and do not approve your
@@ -169,65 +209,55 @@ own revision. The parent renders the revised template and waits for
 - Do not call `update_campaign_brief`; the main thread writes the approved
   template after user approval.
 - Do not overwrite an existing approved message/template.
-- Do not use unsupported reply-rate, meeting-rate, ROI, revenue, or
-  customer-logo claims.
+- Do not use unsupported reply-rate, meeting-rate, ROI, revenue, exact
+  pipeline-lift, named-customer, or customer-logo claims.
 - Do not use internal tokens such as `{{profile_signal}}` in customer-facing
   copy.
 - Do not put bracketed instructions in the message body, such as `[ROW_BRIDGE]`,
   `[insert]`, or `[generated]`.
-- Engagement-source personalization is a special case, not the default opener.
-  Do not write `saw you {{engagement_context}} on {{post_context}}`, `saw you
-reacted to`, `saw you engaging with`, or equivalent source-citation copy as a
-  default hook. For LinkedIn-post-sourced campaigns, you may reference the
-  source when it explains why the note exists, but keep it topic-level, not
-  activity-log-level. Good: `saw you in a few conversations around [topic], so
-hope this is relevant`, `saw you in a few conversations about [topic], so
-may be off, but this seemed relevant`, `saw you might be interested in [topic],
-so hope this is relevant`, `hope this is relevant if [topic] is on your plate`,
-or `saw you raise your hand for [topic], so figured this was (hopefully) worth sending`.
-The cheekier `saw you raise your hand for [topic] (creepy to reach out based
-on that, i know) - but this felt too on the nose to ignore` version is also
-allowed when the sender's voice can carry it. Bad: `you commented on...`, `you reacted
-to...`, `saw you engaging with...`, `your LinkedIn activity...`, `you might
-not remember the thread...`, or `found you through [source] and your role
-looked close...`. Otherwise omit the engagement signal and use role/company/problem context.
-- Do not use a PS to defend the source. Lines like `p.s. if the source thread
-  was just casual reading, ignore me` or `only reaching out where the role and
-  topic looked close` are blocked. If the source is too weak, omit it.
+- Use post engagement only as a warm opener when it makes the note feel more
+  earned. Do not infer buyer intent from a reaction or overpersonalize from a
+  like.
+- For third-party post sources, keep source language topic-level and
+  low-certainty, such as `found you in a thread about [topic], so may be off,
+  but this seemed relevant`.
+- Sender-owned post sources are different: if the source post was authored by
+  the sender/client and the row proves a reaction/comment, a light first-person
+  acknowledgment is allowed, but it must be followed by a soft
+  relevance bridge before broad problem or product copy. Use a bridge like
+  `figured this might be relevant if LinkedIn is becoming more of a GTM
+  channel for [company]` before any broader `a lot of B2B teams...` claim. Do
+  not jump straight from `appreciate you showing some love...` to
+  `a lot of B2B teams...` or `most teams...`.
+- Every line must make the next
+  line feel earned: source/post signal -> relevance bridge -> product/problem
+  -> next step. If adjacent lines could be swapped, deleted, or joined with
+  `anyway` without changing the meaning, rewrite the bridge or cut the orphan
+  line.
+- Do not use a PS to defend the source. If the source is too weak, omit it.
 - Do not assert fit from title/company. `Your [role] role at [company] looked
-  close to this problem` is blocked. Keep the apologetic uncertainty instead:
-  `may be off, but if [workflow] is anywhere near your lane...`.
-- Low-pressure relevance opt-outs are allowed when they do not defend the
-  source: `p.s. if this is nowhere near your outbound workflow, ignore me`.
-- Do not use `Caught` as opener language. It reads unnatural in LinkedIn
-  outreach.
+  close to this problem` is blocked.
+- Do not use `Caught` as opener language.
 - Do not describe the sender in third person inside the outbound message.
-  Lines like `p.s. Saju's angle is...`, `Christian's angle is...`, or
-  `[sender]'s approach is...` are internal notes leaking into copy. If the point
-  matters, write it in the sender's voice: `p.s. we usually pair the build with
-enablement`, or omit it.
 - The selected winner is one first outbound send only. No post-accept DM,
   follow-up, cadence branch, sequence copy, or launch copy.
 
 ## Final Response
 
-Return a concise status with:
+Return a concise review-ready recommendation with the labeled fields above.
+
+The customer-facing approval packet should include only the proposed template
+and one rendered good-fill sample. Keep token rules, fallback logic, and
+bad-fill avoidance notes available for internal persistence, but do not print
+fallback samples or QA receipts in the default chat approval packet.
 
-- prompt basis loaded: `generate-messages`
-- validation prompt loaded: `create-campaign-v2-validation`
-- live campaign basis used
-- proposed template
-- token fill rules/fallbacks
-- one rendered passing-row sample
-- whether final template review is ready or needs revision
+Use fenced `text` blocks only for copy the user can approve:
 
-When the parent will show the recommendation in chat, keep the customer-facing
-message review lightweight. Format only the approval target and one strong
-good-fill example as Markdown with distinct copy blocks. Keep validation notes,
-bad-fill avoidance notes, and QA details internal unless blocked; do not print
-them in the default chat approval packet.
+Use a table for token rules.
 
 ````markdown
+templateRecommendation:
+
 ## Message Template
 
 **Subject**
@@ -242,6 +272,13 @@ them in the default chat approval packet.
 {{tokenized_message_body}}
 ```
 
+tokenFillRules:
+
+| Token | Source | Allowed transformation | Fallback | Blocked fills |
+| --- | --- | --- | --- | --- |
+
+renderedGoodSample:
+
 ## Rendered Example
 
 Good token fill:
@@ -253,7 +290,12 @@ Hey First,
 
 ...
 ```
-````
 
-Use a table for token rules. Keep explanations outside the fenced `text` blocks
-so the user can quickly see exactly what copy is being approved.
+status: ready
+basisStatus: usable_initial
+basisToken: ...
+approveOrReviseRecommendation: approve
+validationStatus: passed
+outputAt: ...
+outputHash: ...
+````

package/bin/sellable-install.mjs

@@ -1102,32 +1102,22 @@ updates.
    copies of this file; packaged Claude Code and Codex runs must use the MCP
    asset loader so they share the same config.
 3. Follow that prompt and workflow config exactly.
-4. For message generation, keep the parent thread as a lean orchestrator and
-   use the \`post-find-leads-message-scout\` agent whenever the host exposes it
-   and the current host policy allows agent launch. The worker must load the
-   full \`mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })\`
-   prompt, every referenced message asset through
-   \`mcp__sellable__get_subskill_asset\`, and before returning
+4. For message generation, use the \`post-find-leads-message-scout\` agent when
+   available. The worker and parent-thread fallback must load
+   \`mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })\`,
+   then every required message asset named by \`generate-messages\` Mode 0 before
+   drafting. After candidate generation/revision and before returning \`ready\`,
+   they must load
    \`mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })\`
-   plus any validation assets it references through
-   \`mcp__sellable__get_subskill_asset\` as the internal validation gate.
-   In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use
-   Sellable background agents for pre-launch work. If the user has not enabled
-   YOLO and has not explicitly asked for background agents, subagents, parallel
-   agents, delegation, or a message/bg agent in this campaign, ask once for
-   permission before loading the long message prompt in the parent. If
-   permission is granted but the named custom agent is not
-   available, spawn a generic background agent with \`model: "gpt-5.5"\` and
-   \`reasoning_effort: "xhigh"\` using the same campaign/table basis. Do not
-   silently fall back to parent-thread message drafting; parent fallback is
-   allowed only when the user explicitly says to continue without a background
-   agent.
-   Do not use any alternate or examples-only message prompt. Message review requires Message Drafting output:
-   do not draft from a checklist, local markdown artifact, or parent-thread
-	   intuition. Use campaign state, campaign brief content, selected source state,
-	   and initial campaign-table execution slice rows as the source of truth; do not read stale
+   as the final internal validation gate.
+   Do not use any alternate, examples-only, or local-artifact message prompt.
+   Message review requires Message Draft Builder output: do not draft from a
+   checklist, local markdown artifact, or parent-thread intuition. Use campaign
+   state, campaign brief content, selected source state, and initial
+   campaign-table execution slice 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.
+   The message recommendation handoff is labeled Markdown, not raw JSON.
 5. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Materialize the approved
    source list, copy confirmed rows into the campaign, and internally process the
@@ -1256,8 +1246,8 @@ Desktop, then start a new thread.
 2. When the canonical prompt asks for \`references/*.md\`, load those files
    with \`mcp__sellable__get_subskill_asset({ subskillName: "interview", assetPath: "references/<file>.md" })\`.
 3. Follow the canonical prompt exactly. Save local memory only where that prompt
-   directs, under \`.sellable/configs/core/**\` and
-   \`.sellable/interviews/**\`.
+   directs, under \`~/.sellable/configs/core/**\` and
+   \`~/.sellable/interviews/**\`.
 
 ## MCP Prompt Fallback
 
@@ -1303,7 +1293,7 @@ Desktop, then start a new thread.
    If the response has \`hasMore=true\`, continue with \`nextOffset\` until
    \`hasMore=false\`.
 2. Follow the canonical prompt exactly. Read the relevant
-   \`.sellable/configs/**\` memory files it names.
+   \`~/.sellable/configs/**\` memory files it names.
 3. Apply the loaded memory silently to the user's requested writing or answer.
    If the user only asked to load voice, summarize the active rules briefly and
    ask what they want drafted, answered, or reviewed.
@@ -2079,7 +2069,7 @@ function patchClaudeAlwaysLoad(opts) {
 }
 
 function installCodex(opts) {
-  if (!commandExists("codex")) {
+  if (!opts.dryRun && !commandExists("codex")) {
     const message =
       "Codex CLI not found. Install/login to Codex, then rerun: sellable --host codex";
     if (opts.host === "all") {
@@ -2088,6 +2078,9 @@ function installCodex(opts) {
     }
     throw new Error(message);
   }
+  if (!opts.dryRun) {
+    mkdirSync(codexHome(), { recursive: true, mode: 0o700 });
+  }
   if (opts.server === "hosted") {
     run("codex", codexMcpAddArgs(opts), opts);
     const info = installCodexDesktopPlugin(opts);
@@ -2643,7 +2636,7 @@ function runUninstall() {
 
 async function main() {
   try {
-    // Phase 116: auth set <token> subcommand — manual-paste fallback when CLI poll fails.
+    // Manual-paste auth fallback when CLI polling fails.
     // MUST be parsed BEFORE parseArgs() since parseArgs throws on non-flag args like "auth".
     const rawArgs = process.argv.slice(2);
     if (rawArgs[0] === "auth") {
@@ -2654,6 +2647,13 @@ async function main() {
         process.exit(2);
       }
       const token = rawArgs[2];
+      const authSetFlags = rawArgs.slice(3);
+      const dryRun = authSetFlags.includes("--dry-run");
+      const unknownAuthSetFlag = authSetFlags.find((arg) => arg !== "--dry-run");
+      if (unknownAuthSetFlag) {
+        console.error(`Unknown auth set option: ${unknownAuthSetFlag}`);
+        process.exit(2);
+      }
       if (!token) {
         console.error(
           "Usage: sellable auth set <token>\n" +
@@ -2678,9 +2678,13 @@ async function main() {
       writeJson(
         authPath(),
         { token, activeWorkspaceId: null, apiUrl },
-        { dryRun: false }
+        { dryRun }
       );
-      console.log(`✓ Token saved to ${authPath()}`);
+      if (dryRun) {
+        console.log(`Dry run: token would be saved to ${authPath()}`);
+      } else {
+        console.log(`✓ Token saved to ${authPath()}`);
+      }
       console.log(`  apiUrl: ${apiUrl}`);
       console.log(`  Continue in your agent:`);
       console.log(`    Claude Code: /sellable:create-campaign`);

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@sellable/install",
-  "version": "0.1.158",
+  "version": "0.1.160",
   "type": "module",
   "description": "One-command installer for Sellable MCP in Claude Code and Codex",
   "bin": {

package/skill-templates/create-campaign.md

@@ -66,8 +66,8 @@ allowed-tools:
 
 Use this as the customer-facing public wrapper for Sellable campaign creation.
 It bootstraps auth and host capabilities, then loads the internal
-`create-campaign-v2` workflow prompt and `core/flow.v2.json` through MCP. Keep
-this wrapper thin; v2 is the operational source of truth.
+the internal campaign workflow prompt and `core/flow.v2.json` through MCP. Keep
+this wrapper thin; the packaged workflow is the operational source of truth.
 
 CampaignOffer state and the watch link are the customer-facing source of truth.
 Disk artifacts are optional debug/UAT diagnostics; normal customer runs should
@@ -722,7 +722,7 @@ updates.
      No other lines. No "all set", no "signed in", no other acknowledgement.
 
      After the user pastes the LinkedIn profile URL or handle, proceed with the
-     identity-first campaign setup in the v2 subskill prompt. Normalize handles
+     identity-first campaign setup in the internal workflow prompt. Normalize handles
      to a full profile URL, resolve it with `fetch_linkedin_profile`, and mark
      the client/company research gate with `complete_sender_research` when that
      protocol is required.
@@ -760,11 +760,10 @@ updates.
    Drafting whenever the host exposes it
    and the current host policy allows agent launch. The worker must load the
    full `mcp__sellable__get_subskill_prompt({ subskillName: "generate-messages" })`
-   prompt, every referenced message asset through
-   `mcp__sellable__get_subskill_asset`, and before returning
+   prompt, every required message asset named by `generate-messages` Mode 0
+   through `mcp__sellable__get_subskill_asset`, and before returning
    `mcp__sellable__get_subskill_prompt({ subskillName: "create-campaign-v2-validation" })`
-   plus any validation assets it references through
-   `mcp__sellable__get_subskill_asset` as the internal validation gate.
+   as the final internal validation gate.
    In Codex, YOLO/autonomous mode counts as campaign-scoped permission to use
    this single Message Drafting background agent. If the user has not enabled
    YOLO and has not explicitly asked for background agents, subagents, parallel
@@ -776,7 +775,7 @@ updates.
    silently fall back to parent-thread message drafting; parent fallback is
    allowed only when the user explicitly says to continue without a background
    agent.
-   Do not use any alternate or examples-only message prompt. Message review and
+   Do not use any alternate, examples-only, or local-artifact message prompt. Message review and
    message QA require Message Drafting output:
    do not draft from a checklist, local markdown artifact, or parent-thread
    intuition. Use campaign state, campaign brief content, selected source state, and
@@ -785,10 +784,10 @@ updates.
    synthesize local validation artifacts from general knowledge. The handoff to
    Message Drafting should pass lean basis only, not hashes, counts, or a long
    row-id list; the branch loads current brief/context, the full
-   `generate-messages` prompt, all referenced message assets,
-   `create-campaign-v2-validation`, and any validation assets it references. Do
-   not render fallback sample, concerns, or a QA receipt on the normal happy
-   path.
+   `generate-messages` prompt, all required message assets, and
+   `create-campaign-v2-validation`. The message recommendation handoff is
+   labeled Markdown, not raw JSON. Do not render fallback sample, concerns, or a
+   QA receipt on the normal happy path.
 6. Create the campaign shell early with the v1 brief so the user can open the
    watch link and see useful setup state immediately. Materialize the approved
    source list, copy confirmed rows into the campaign, and internally process the