@sellable/mcp 0.1.143 → 0.1.145

package/skills/create-campaign-v2/references/final-handoff-contract.md

@@ -33,8 +33,8 @@ order (all before waiting for the user):
    `get_campaign_navigation_state` when available so the watch link visibly
    lands on Settings before sender setup.
 4. Explain sender setup and Slack in normal customer language: Sellable needs a
-   connected LinkedIn sender before anything can send, and Slack reply review
-   matters because replies and approvals need a channel the team will monitor.
+   connected LinkedIn sender for launch, and Slack reply review matters because
+   replies and approvals need a channel the team will monitor.
 5. If no connected sender exists, surface the campaign Settings link
    `/campaign-builder/{campaignId}/settings?mode=claude`, tell the user to
    connect a sender there, and STOP. Do not attach sequence and do not start.
@@ -70,7 +70,7 @@ The final handoff must answer five customer questions in plain language:
 - why the selected LinkedIn sender and Slack reply review matter before launch
 - what clicking Start does (approves/starts the campaign send path)
 - how to revise (reply with what to change, or use the campaign UI)
-- whether anything has started yet (nothing sends until the user starts)
+- current launch status and what the final Start action does
 
 When `lead-source-intake.json` exists, also answer:
 
@@ -84,8 +84,8 @@ When `lead-source-intake.json` exists, also answer:
 
 Use the exact state name `awaiting-user-greenlight` so logs and UX artifacts
 can verify the state-machine stop point, but explain it in normal words: the
-campaign is built, sender/sequence setup is being completed, and nothing sends
-until the user's final start decision. The watched UI may advance through
+campaign is built, sender/sequence setup is being completed, and the final
+start decision is still ahead. The watched UI may advance through
 Settings, Sequence, and Send while this state-machine step remains the final
 handoff.
 

package/skills/create-campaign-v2/references/message-review-safety-gate.md

@@ -91,19 +91,94 @@ but the [topic] thread felt close enough to send`. Otherwise omit the
 
 ## Customer-Facing Message Review
 
-Render this in chat before asking:
-
-- `Status: message-review`
-- `Subject:`
-- `Message:` with the tokenized template or approved AI-native message
-- `Rendered examples:`
-- `Good token fill:`
-- `Good omit:`
-- `Token notes:`
-- `My take:`
-- `Suggested adjustment:`
-- `Question: approve-message or revise-messaging?`
-- `Recommendation: approve-message` or `Recommendation: revise-messaging`
+Render this in chat before asking. Use Markdown structure so the approval target
+is visually scannable:
+
+````markdown
+Status: message-review
+
+## Message Template
+
+**Subject**
+
+```text
+{{tokenized_subject}}
+```
+
+**Body**
+
+```text
+{{tokenized_message_body}}
+```
+
+## Rendered Examples
+
+### Good token fill
+
+Use when the row has a clean, supported fill.
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+### Good omit / fallback
+
+Use when a row signal or company context is missing, weak, or awkward.
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+### Bad fill to avoid
+
+```text
+Subject: ...
+
+Hey First,
+
+...
+```
+
+**Why this is wrong:** one sentence naming the exact token-fill failure.
+
+## Token Notes
+
+| Token            | Use when                 | Fallback |
+| ---------------- | ------------------------ | -------- |
+| `{{first_name}}` | Clean first name exists. | `there`  |
+
+## Recommendation
+
+**My take:** ...
+
+**Suggested adjustment:** ...
+
+**Question:** approve-message or revise-messaging?
+
+**Recommendation:** approve-message
+````
+
+Formatting requirements:
+
+- Put the tokenized template and every rendered example in fenced `text` blocks
+  so chat gives them a distinct background.
+- `Good token fill` and `Good omit / fallback` must each contain a complete
+  rendered subject + body, not a bullet list of token names or a single
+  bridge-line fragment.
+- Include `Bad fill to avoid` when the row sample has a tempting but unsafe
+  source-mechanics or raw-headline fill; otherwise include `Bad fill to avoid:
+none found`.
+- Use a token notes table, not paragraph-only token notes.
+- Keep reasoning outside the code blocks so the blocks are easy to inspect and
+  approve.
 
 `My take` and `Suggested adjustment` must be specific. The adjustment can be
 "approve as-is, or revise once to X if you want Y"; it must not be empty.

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

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

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

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

package/skills/create-campaign-v2/references/step-15-re-cascade.md

@@ -2,8 +2,7 @@
 
 This reference governs Step 15 (`auto-execute-messaging`) re-cascade
 behavior when Step 14's validate-sample loop graduates additional rows
-from pending → passed after the first `generate_messages` call has
-already run.
+from pending → passed after the first Generate Message cells have already run.
 
 Load whenever Step 15 is about to transition to
 `awaiting-user-greenlight`, and on every resume into Step 15.
@@ -25,7 +24,7 @@ Re-cascade runs whenever ALL of the following are true:
 
 1. Step 15 has already observed the initial review-batch message cascade.
 2. A subsequent check of rubric state shows rows that were pending at
-   first generate_messages time are now passed.
+   first message-generation pass are now passed.
 3. Those newly-passed rows do NOT yet have generated messages
    (`messagesCount` flat relative to pre-cascade).
 4. Step 15 has NOT yet transitioned to `awaiting-user-greenlight`.

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

@@ -14,14 +14,14 @@ Building campaign with {Claude Code or Codex}               [Exit watch mode]
 {visibleState} {agentIntent}
 
 Next: {nextAction}
-{safety?}
 ```
 
 UI owns the header, driver label, button, progress bar, step count, and static
 stage labels. The driver label comes from the watch URL mode (`mode=claude` or
 `mode=codex`), so do not add separate guide args for it. You own `stage`,
 `headline`, `visibleState`, `agentIntent`, and any exceptional `nextAction`,
-`safety`, `workerStatuses`, or `blockedReason`.
+`workerStatuses`, `blockedReason`, or concise `safety` note for blocked/recovery
+states.
 
 ## Copy Rules
 
@@ -40,6 +40,11 @@ stage labels. The driver label comes from the watch URL mode (`mode=claude` or
   sample you are checking, and why that helps this campaign.
 - At filter choice, do not say filtering the batch before rubrics and message approval are saved.
 - Avoid internal terms: MCP, tool, currentStep, workflow table, scout, debug.
+- Treat `safety` as optional internal context, not a visible disclaimer.
+- Do not repeat long negative lists like "no leads import, no enrichment, no
+  messages, no sequence, no sending" in routine watch copy. Prefer one concise
+  gate phrase only when it matters: "Approval covers scouting/search only" or
+  "Next gate: selected-post scrape."
 - Do not invent time estimates.
 
 ## Stages
@@ -86,8 +91,7 @@ Default source funnel:
   "headline": "Choosing the lead source",
   "visibleState": "The browser is on Pick Provider while Codex explains the source path before opening a provider lane.",
   "agentIntent": "Codex will start with people engaging with relevant LinkedIn posts when that looks plausible, then switch to Sales Nav to find ICP people actively posting on LinkedIn, then search by titles, and use Prospeo for a broader account/contact path. Sales Nav with recent activity remains the first LinkedIn fallback.",
-  "nextAction": "Review source",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source"
 }
 ```
 
@@ -99,8 +103,7 @@ Signal Discovery viability handoff:
   "headline": "Checking Signal Discovery viability",
   "visibleState": "The browser is moving from Pick Provider into Signal Discovery so the exact posts and sample math are visible.",
   "agentIntent": "Codex is testing whether relevant posts have enough ICP-looking engagers before recommending this as the source.",
-  "nextAction": "Review source math",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source math"
 }
 ```
 
@@ -112,8 +115,7 @@ Source direction override:
   "headline": "Testing the requested source",
   "visibleState": "The campaign asked for hiring and account signals, so Codex is starting with Prospeo instead of the default LinkedIn engagement path.",
   "agentIntent": "It is checking whether this source has enough reachable ICP-looking people before importing a review batch.",
-  "nextAction": "Review source",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source"
 }
 ```
 
@@ -125,8 +127,7 @@ Source fallback:
   "headline": "Switching source lanes",
   "visibleState": "The Signal Discovery sample did not show enough ICP-looking engagers for a confident first batch.",
   "agentIntent": "Codex is trying Sales Nav with recent activity so the source can still preserve some buyer activity context.",
-  "nextAction": "Review source",
-  "safety": "No leads import until you approve the source."
+  "nextAction": "Review source"
 }
 ```
 
@@ -149,9 +150,8 @@ Source recommendation ready:
   "stage": "find-leads",
   "headline": "Review the source in Codex",
   "visibleState": "The browser is showing the evaluated Signal Discovery source with counts and sample quality.",
-  "agentIntent": "Approve LinkedIn Engagement or ask for a source change in chat before any leads import.",
-  "nextAction": "Approve in Codex",
-  "safety": "No leads import until you approve the source."
+  "agentIntent": "Approve LinkedIn Engagement or ask for a source change in chat.",
+  "nextAction": "Approve in Codex"
 }
 ```
 
@@ -178,10 +178,9 @@ Source approved and import starting:
 {
   "stage": "review-batch",
   "headline": "Importing the review batch",
-  "visibleState": "The browser is still showing the approved LinkedIn Engagement source leads.",
-  "agentIntent": "Codex is importing only the bounded 15-row review batch into the campaign now.",
-  "nextAction": "Review batch ready",
-  "safety": "This is still a review step; nothing launches or sends."
+  "visibleState": "The browser is still showing the approved LinkedIn Engagement source candidates.",
+  "agentIntent": "Codex is importing only the bounded review batch into the campaign now.",
+  "nextAction": "Review batch ready"
 }
 ```
 
@@ -199,10 +198,9 @@ After review batch import:
   "visibleState": "The first review batch is in the campaign. The visible sample looks mixed enough that filters should be added before message review.",
   "agentIntent": "Codex is asking whether you want to further filter these leads before message review. Skip filters only if the visible rows already look clean.",
   "nextAction": "Choose filters or skip",
-  "safety": "Nothing enriches, validates, or sends until the message is ready and approved.",
   "workerStatuses": {
     "leadFitBuilder": "idle",
-    "messageDraftBuilder": "idle"
+    "messageDraftBuilder": "running"
   }
 }
 ```
@@ -211,7 +209,8 @@ Use this after the selected review rows are present and before filters are
 saved. This is add-filters intent, not active filtering. Recommend adding
 filters when the sample is mixed/noisy, tell the user to Choose filters or skip,
 and do not say filtering the batch before rubrics and message approval are
-saved. Only show worker statuses as running if those branches actually started.
+saved. The Message Draft Builder should start immediately after the bounded
+review batch exists; mark it running only when that branch actually started.
 When the user chooses filters, immediately persist `enableICPFilters: true` and
 move to `create-icp-rubric` so the watched app shows Filter Rules while Codex
 defines the rules in chat. After `save_rubrics`, move to `apply-icp-rubric`
@@ -242,11 +241,28 @@ Review ready:
   "headline": "Review the message template",
   "visibleState": "The browser remains on Filter Leads while the message template is reviewed in chat.",
   "agentIntent": "Codex is waiting for approval before saving the template to the campaign brief and queueing enrichment/filtering.",
-  "nextAction": "Approve or revise the template",
-  "safety": "Codex will only continue after you approve."
+  "nextAction": "Approve or revise the template"
 }
 ```
 
+Template approved, bounded filter test running:
+
+```json
+{
+  "stage": "fit-message",
+  "headline": "Template saved",
+  "visibleState": "The browser stays on Filter Leads while the bounded enrichment and filter test runs.",
+  "agentIntent": "Codex saved the approved message template, queued the review-batch Enrich Prospect cells, and is waiting for at least one row to pass before moving to Messages.",
+  "nextAction": "Move to Messages after a passing row"
+}
+```
+
+Do not move to Messages immediately after `approve-message`. The visible route
+is already Filter Leads after `save_rubrics`; approving the message only unlocks
+the bounded cascade from that screen. Move to Messages only once at least one
+review-batch row passes and Generate Message cells are ready/running for the
+passing rows.
+
 Messages waiting for template:
 
 ```json
@@ -255,8 +271,7 @@ Messages waiting for template:
   "headline": "Waiting for the template",
   "visibleState": "The fit rules are saved and the message template is still being prepared.",
   "agentIntent": "Codex is waiting until the template can be reviewed.",
-  "nextAction": "Review template",
-  "safety": "No enrichment, filtering, or Generate Message cells run until the template is approved."
+  "nextAction": "Review template"
 }
 ```
 

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

@@ -36,7 +36,7 @@ Example skeleton:
 I created the campaign shell with the brief already in it.
 You can watch the lead source, filters, and messages fill in from here.
 
-No leads import and nothing sends yet.
+I’ll pause at the next approval gate before sourcing.
 
 Watch link: [Open campaign]({watchUrl})
 

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

@@ -36,10 +36,13 @@ Step 13 — import/confirm review batch only
   update_campaign(currentStep=filter-choice)
 
 Post-import main thread
-  launch Lead Fit Builder + Message Draft Builder after workflowTableId exists
+  launch Message Draft Builder immediately after workflowTableId + review rows exist
+  launch Lead Fit Builder only after user chooses filters
   save_rubrics({ campaignOfferId, leadScoringRubrics }) after the campaign table exists
-  show readable filters + one concrete sample message
-  after approval, update_campaign_brief writes `## Approved Message Template` with `{{...}}` tokens
+  keep the watched app on Filter Leads after rubrics are saved
+  while on Filter Leads, show the message template recommendation from the background Message Draft Builder
+  after approve-message, update_campaign_brief writes `## Approved Message Template` with `{{...}}` tokens
+  only then start the bounded review-batch cascade
 
 Step 14 — kick bounded cascade + observe sample
   queue_cells(cellIds=<review-batch Enrich Prospect cells only>)  <-- starts bounded chain
@@ -58,7 +61,9 @@ Step 15 — observe messaging
   get_rows_minimal                 # confirm passing rows have completed Generate Message cells
   (rare) queue_cells on any pending Generate Message cells
   token-contract spot check via get_rows
-  update_campaign(currentStep=awaiting-user-greenlight)
+  update_campaign(currentStep=auto-execute-messaging) with review-ready narration
+  ask the user to approve generated review-batch messages before Settings
+  only after approval: update_campaign(currentStep=awaiting-user-greenlight)
   (generate_messages is NOT an MCP tool; messages come from the cascade)
 
 Step 16 — awaiting-user-greenlight
@@ -144,7 +149,9 @@ what changed and orient the user to what the watch link will show next —
 reuse the v1 `create-campaign` watch-mode pattern verbatim.
 
 Resume currentStep names covered by this tail: `"auto-execute-leads"`,
-`"validate-sample"`, `"auto-execute-messaging"`,
+`"apply-icp-rubric"` (the visible Filter Leads home for the logical
+`validate-sample` loop), `"validate-sample"` (legacy resumes only),
+`"auto-execute-messaging"`,
 `"awaiting-user-greenlight"`, `"settings"`, `"sequence"`, `"send"`, and
 `"running"`. New mint-early runs normally
 enter Step 13 from `"confirm-lead-list"`; the `"auto-execute-leads"` string is
@@ -273,10 +280,12 @@ caller or start the workflow-table cascade too early. The cascade starts in
 Step 14 only after `save_rubrics` and `update_campaign_brief` have both
 succeeded.
 
-## Step 14: validate-sample (loop)
+## Step 14: validate-sample (logical loop on Filter Leads)
 
-Entered on `CampaignOffer.currentStep === "validate-sample"`. Full
-decision tree lives in `references/sample-validation-loop.md`.
+Entered after the message template is approved while the watched campaign is
+already on `CampaignOffer.currentStep === "apply-icp-rubric"` / Filter Leads.
+Do not route to a visible `validate-sample` step. Full decision tree lives in
+`references/sample-validation-loop.md`.
 
 **Step 14 starts the bounded cascade, then observes it.** Step 13 imported the
 review batch only. After `save_rubrics` and the approved message template are
@@ -381,8 +390,9 @@ Template`. If it does not, fail before the cascade runs. Do not repair
 5. If the sample fails the token contract, diagnose brief-vs-list
    (same revision loop as Step 14) and escalate if over
    `maxRevisionRounds`.
-6. On success, `update_campaign({ campaignId, currentStep:
-"awaiting-user-greenlight" })`.
+6. On success, keep `currentStep: "auto-execute-messaging"` and ask the user
+   to approve the generated review-batch messages. Only that approval may move
+   the campaign to Settings / `awaiting-user-greenlight`.
 
 **Do NOT hand-write message bodies via `update_cell`.** `update_cell`
 is reachable for legitimate operator overrides AFTER the tail hands
@@ -428,8 +438,11 @@ strings, which is why Step 16 requires Step 15 to be complete.
 6. If the sample fails the token contract or critique, diagnose +
    loop the same way Step 14 does (brief-vs-list), subject to the same
    `maxRevisionRounds` cap.
-7. On success, `update_campaign({ campaignId, currentStep:
-"awaiting-user-greenlight" })` and orient the user.
+7. On success, keep `currentStep: "auto-execute-messaging"`, show that the
+   review-batch messages are ready in Messages, and ask for approval before
+   Settings. Only after the user approves those generated messages should
+   `update_campaign({ campaignId, currentStep: "awaiting-user-greenlight" })`
+   run.
 
 Critique failure modes NEVER escalate. A critic timeout, a total
 timeout, a budget trip, a fake-proof rejection, or an unsupported-
@@ -451,7 +464,7 @@ Shape:
    `get_campaign_navigation_state` when available to confirm the watch link is
    visibly on Settings.
 4. Explain why the sender matters: Sellable needs a connected LinkedIn sender
-   before anything can send. Explain Slack reply review before launch: replies
+   for launch. Explain Slack reply review before launch: replies
    and approvals need a place the team will actually monitor, so Slack should be
    connected or intentionally skipped before launch.
 5. If no connected sender exists, surface a direct Settings link:

package/skills/load-voice/SKILL.md

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