@sellable/mcp 0.1.267 → 0.1.269

package/skills/create-post/references/premise-development.md

@@ -1,42 +1,16 @@
-# Premise Development V2
+# Premise Development
 
 A strong post is not an idea with a better hook. A strong post is a valuable
 premise wrapped in a sharp opening.
 
-Use this stage after audience/hook research and before hook candidates. V2 premise
-development also consumes the source post templates from hook research:
-post positioning breakdowns, viral-post outlines, hook-to-body promise maps, and
-body expression inputs.
-
-Do not generate hook candidates until at least one `Premise Card` exists and at
-least one source template has either been selected or explicitly rejected as a
-poor fit.
+Use this stage after market/hook research and before hook candidates. Do not
+generate hook candidates until at least one `Premise Card` exists.
 
 ## Goal
 
 Turn the raw idea into a real story, observed tension, or useful argument that a
 specific reader would care about.
 
-Use this post tension framework when evaluating whether the premise can hold
-attention:
-
-```text
-Belief -> Contradiction -> Stakes -> Proof -> Mechanism -> Reframe -> Useful Move
-```
-
-- `Belief`: what the reader already thinks or wants to be true
-- `Contradiction`: what the source story reveals that does not fit the belief
-- `Stakes`: what the reader loses if they keep believing the old version
-- `Proof`: the scene, number, repeated pattern, or concrete artifact that makes
-  the contradiction credible
-- `Mechanism`: why the thing actually works or fails
-- `Reframe`: the sharper way to see the problem after the mechanism is clear
-- `Useful Move`: what the reader can do, notice, stop doing, or test next
-
-A post feels "edge of seat" when the hook creates a contradiction the target
-reader cares about, the body delays the answer only while adding proof, and each
-beat either raises tension or repays tension. If a beat does neither, cut it.
-
 The premise must answer:
 
 - who this is for
@@ -48,8 +22,6 @@ The premise must answer:
 - why now
 - why this user can credibly say it
 - what proof is available and what proof is missing
-- which source template, if any, should shape the narrative
-- which positioning sequence the user's post should follow
 
 If the premise has no real scene, no tension, and no reader value, stop before
 drafting. Ask for the missing story or save only a `needs_revision` premise
@@ -61,14 +33,10 @@ Before writing premise cards, search the available source material:
 
 - raw idea text
 - voice memo or transcript if provided
-- `Transcript Worldview Packet` from create-post capture
 - `core/story-bank.md`
 - `core/answer-bank.md`
 - `core/proof-ledger.md`
 - `core/wins-ledger.md`
-- `core/transcripts/INDEX.md`
-- `core/content-memory/INDEX.md`, relevant clusters, cards, questions, and
-  post seeds
 - approved references and gold standards
 - current-session user corrections or rejections
 
@@ -80,37 +48,11 @@ Look for:
 - a before/after: what changed in the user's belief
 - a specific object: Slack note, customer call, campaign table, reply, list,
   demo, failed draft, stale idea, messy workflow
-- repeated worldview: the user's recurring operating belief behind the idea
-- hot-take ingredient: the specific advice, default behavior, or market cliche
-  the user is pushing against
 
 If no real story is present, use an observed pattern only if it is traceable to
 the raw source or memory. Mark the gap in the premise card. Do not fabricate a
 customer, call, outcome, date, metric, or private scene.
 
-## Worldview And Hot-Take Extraction
-
-Before scoring premise cards, extract the user's source-backed worldview from
-the transcript packet:
-
-```text
-Worldview extraction:
-- worldview claim:
-- source transcript/cluster/card:
-- repeated phrase or language pattern:
-- lived proof behind it:
-- common advice it challenges:
-- hot take version:
-- public-safe version:
-- private/sensitive material to avoid:
-- confidence: strong | medium | weak
-```
-
-A good hot take is not just a contrarian sentence. It must trace to something
-the user has said, seen, shipped, sold, or learned repeatedly. If the hot take
-only exists because an outside creator framed it well, mark it as borrowed and
-do not use it as the user's premise.
-
 ## Premise Cards
 
 Generate 3-5 premise cards before hooks. Each card must use this shape:
@@ -139,7 +81,7 @@ tension:
 reader value:
 <what the reader learns, sees differently, or can do after reading>
 
-why now / audience tension:
+why now / market heat:
 <what current research says is resonating>
 
 credible why-us:
@@ -151,32 +93,14 @@ proof available:
 proof missing:
 <claims that cannot be made yet>
 
-worldview source:
-<transcript/cluster/card/source-backed belief used>
-
-hot take:
-<public-safe sharp version of the user's source-backed disagreement>
-
 best frame:
 story | contrarian take | teardown | founder confession | future thesis | lesson
 
-source template fit:
-<selected source template name or none>
-
-positioning sequence to test:
-<Category -> Category -> Category -> ...>
-
-viral outline to adapt:
-<beat names from selected source template, rewritten for this user's story>
-
 hook territories:
 - <territory 1>
 - <territory 2>
 - <territory 3>
 
-body expression inputs:
-- <line shape, proof slot, story beat, mechanism explanation, or closing move>
-
 risk:
 <why this premise might still be weak>
 
@@ -184,214 +108,6 @@ score:
 <1-100 with short reason>
 ```
 
-## Template-Aware Premise Selection
-
-Do not treat source templates as decoration. A source template is useful only
-when its narrative engine matches something the user can credibly say.
-
-For each premise card, compare it against the selected keeper templates from
-hook research:
-
-```text
-Template fit check:
-premise:
-source_template:
-template narrative engine:
-matching user story/proof:
-missing user story/proof:
-positioning sequence fit:
-hook promise fit:
-body payoff fit:
-voice fit:
-borrow:
-do not borrow:
-fit verdict: strong | partial | weak | reject
-```
-
-Reject a template when it depends on source-specific proof, celebrity reach,
-personal context the user does not have, or a body structure that would force a
-fake story. Prefer a less viral template that fits the user's real proof over a
-more viral template that requires borrowed authority.
-
-## Viral Narrative Structure
-
-Once a premise and source template are selected, create the user's viral-post
-outline before writing body prose.
-
-Use this format:
-
-```text
-User viral-post outline:
-selected_premise:
-selected_source_template:
-hook_promise:
-see_more_tension:
-body_payoff:
-positioning_sequence:
-  <Category> -> <Category> -> <Category> -> ...
-
-beats:
-1.
-  beat_name:
-  narrative_job:
-  user_story_or_proof:
-  positioning_categories:
-  reader_state_before:
-  reader_state_after:
-  line_shape_to_test:
-  proof_safety:
-```
-
-The outline should preserve the source template's useful narrative jobs while
-replacing all source-specific proof, scenes, status, jokes, and examples with
-the user's material.
-
-## Body Expression Lab
-
-After the selected hook and viral-post outline exist, generate body expression
-candidates before writing the final draft. This is where the system tests
-different ways to express the same structure.
-
-Generate 5-8 body expression candidates. Every candidate must use:
-
-- the same selected hook or hook territory
-- the same selected premise
-- the same viral-post outline
-- the same positioning sequence
-- only user-sourced story and proof
-
-Each candidate should vary the expression, not the facts:
-
-```text
-Body expression candidate:
-name:
-expression_strategy:
-opening_after_hook:
-beat_lines:
-  1. <line or paragraph>
-  2. <line or paragraph>
-positioning_sequence_coverage:
-hook_promise_repaid:
-best_lines:
-weak_lines:
-proof_risk:
-voice_risk:
-score:
-```
-
-Useful expression strategies:
-
-- plain field guide
-- founder confession
-- proof-first roadmap
-- teardown then replacement
-- scene then lesson
-- enemy naming then mechanism
-- compact build-in-public note
-
-Do not create candidates by changing the claim. Create candidates by changing
-line order, amount of scene, proof placement, rhythm, and how the mechanism is
-explained.
-
-## Combine Pass
-
-After body expression candidates are scored, combine the best parts into one
-draft outline before prose.
-
-Record:
-
-```text
-Combined body plan:
-selected_hook:
-selected_expression_parts:
-lines_kept:
-lines_rewritten:
-lines_cut:
-positioning_sequence_final:
-hook_promise_repayment:
-proof_gaps_remaining:
-why_this_combination_wins:
-```
-
-If no candidate repays the hook promise with real user proof, return to premise
-development or ask the user for the missing story. Do not save a `ready` draft.
-
-## Pre-Draft Narrative Outline
-
-Before final prose, produce a compact `Pre-Draft Narrative Outline`. This is the
-user-visible argument skeleton that lets the user confirm what the post is
-trying to say, in what order, and which proven body shapes are being adapted
-before the system writes body copy.
-
-Use this format:
-
-```text
-Pre-Draft Narrative Outline
-I. Hook and click debt
-   A. Selected hook: <selected hook>
-   B. Rendered mobile preview verdict: <pass | warn | fail + why>
-   C. What "see more" must repay: <the open loop the first body beat must answer>
-
-II. Thesis the post will defend
-   A. One-sentence thesis: <the post's operating claim>
-   B. Reader being taught: <specific audience, not a broad persona>
-   C. Why this reader cares now: <timely pain, belief, or decision>
-
-III. Operating model
-   A. Core equation or mechanism: <the model the post teaches>
-   B. Key definitions:
-      i. <term>: <plain definition + concrete examples>
-      ii. <term>: <plain definition + concrete examples>
-
-IV. Body shape borrowed from posts that worked
-   A. Selected source template or no-template rationale: <source or rationale>
-   B. Source-message outline being adapted:
-      i. <source post + P1/P2/P3 branch sequence from the original message>
-      ii. <which original paragraph/line/phrase jobs matter most>
-   C. Working body pattern(s) being adapted:
-      i. <pattern name>: <beat order and why it works>
-      ii. <pattern name>: <beat order and why it works>
-   D. What gets borrowed:
-      i. <narrative job, sequence, transition, or proof order>
-   E. What must not be copied:
-      i. <source wording, creator-specific proof, joke, or context>
-
-V. Narrative beats
-   A. Beat 1: <job, reader state before/after, example/proof>
-      i. Line shape or section label: <how it will appear>
-      ii. Concrete examples: <examples/numbers>
-   B. Beat 2: <job, reader state before/after, example/proof>
-      i. Line shape or section label: <how it will appear>
-      ii. Concrete examples: <examples/numbers>
-   C. Beat 3: <job, reader state before/after, example/proof>
-      i. Line shape or section label: <how it will appear>
-      ii. Concrete examples: <examples/numbers>
-
-VI. Scan path and proof safety
-   A. Mobile scan path: <what skimmers learn from labels/numbers/close>
-   B. Proof claims:
-      i. <claim>: <source + public-safety status>
-   C. Abstractions to remove:
-      i. <abstract phrase> -> <concrete replacement>
-   D. Draft risks: <risk and how to avoid it>
-```
-
-Quality gate:
-
-- The outline must explain the post before the draft exists.
-- The outline must be useful to a reader who only scans the finished post.
-- The outline must include proof claims and risk before prose.
-- The outline must define any operating terms that could be misunderstood.
-- The outline must use `I.`, `A.`, and `i.` hierarchy. A flat field list fails.
-- If the post is adapting bodies that worked, the outline must name the source
-  message outline being adapted and the body pattern, including which original
-  paragraph/line/phrase jobs transfer and what beat order, proof order, or
-  transition logic is being borrowed.
-- If the post is a field guide, the narrative beats must show the hierarchy
-  before prose, such as best-to-worst, highest-to-lowest intent, or
-  source-to-outcome.
-- If the outline cannot be made concrete, return to premise development.
-
 ## Premise Quality Gate
 
 A premise can move to hook generation only when it passes all of these:
@@ -402,10 +118,7 @@ A premise can move to hook generation only when it passes all of these:
 - `reader_value`: pass
 - `credible_speaker`: pass
 - `proof_safety`: pass
-- `audience_tension`: pass or explained
-- `template_fit`: pass or explicitly no-template
-- `hook_to_body_repayment`: pass
-- `pre_draft_narrative_outline`: pass
+- `market_heat`: pass or explained
 
 If any gate fails:
 
@@ -424,11 +137,8 @@ For each hook candidate, include:
 - which tension it opens
 - which reader value it implies
 - whether the real scene appears in the first screen or shortly after
-- source template or no-template rationale
-- hook promise the body must repay
 
 Reject hooks that are accurate but do not reveal the premise's tension or value.
-Reject hooks that create a promise the selected viral-post outline cannot repay.
 
 ## Body Relationship
 
@@ -445,6 +155,5 @@ body outline:
 7. close returns to the premise without summarizing
 ```
 
-Replace this generic outline with the selected viral-post outline when a source
-template is available. If the outline cannot be filled without inventing proof,
-return to premise development.
+If this outline cannot be filled without inventing proof, return to premise
+development.

package/skills/providers/prospeo.md

@@ -9,10 +9,31 @@ Prospeo supports search + import in the campaign builder flow.
 ## Provider Decision Tree
 
 - Known account list or CSV: use `load_csv_domains` or `save_domain_filters`, then `search_prospeo`.
+- Current LinkedIn job-post intent: use `search_harvest_jobs`, review the job artifact, then use `confirm_harvest_job_companies` with selected Harvest job IDs to create a `domainFilterId`; only then call `search_prospeo` for hiring stakeholders at those companies. Harvest jobs are the account source, not a people-search replacement.
 - Company/account lookalikes: use `search_prospeo_companies`, review the account sample, then use `confirm_prospeo_company_accounts` with the returned `companySearchToken` to create a `domainFilterId`; only then call `search_prospeo` for people at those accounts. Account rows are not people leads yet.
 - Person search with known filters: use `search_prospeo` directly.
 - LinkedIn activity, content-source, or post-engagement intent: stay on Signal Discovery or Sales Nav, not Prospeo.
 
+Current LinkedIn job-post account sourcing must follow:
+
+```text
+search_harvest_jobs -> confirm_harvest_job_companies -> search_prospeo
+```
+
+Use `search_harvest_jobs` when the user's account-source intent is current
+LinkedIn job posts, for example "companies hiring Power BI developers in the US
+this month." The search tool writes review artifacts and returns a token or
+`mcp-harvest-job-search-token:*` reference. After reviewing selected jobs, call
+`confirm_harvest_job_companies` with selected Harvest job IDs only. It resolves
+real company website domains from selected job details and bounded
+`/linkedin/company` fallback, then returns a `domainFilterId` for
+`search_prospeo`.
+
+Do not paste LinkedIn company URLs as domains. Do not detail-fetch every job row
+by default; fetch details only for selected batches during confirmation. Use
+Prospeo directly when the user wants broader volume, company attributes,
+lookalikes, or people search without needing current LinkedIn job evidence.
+
 Company/account lookalikes must follow:
 
 ```text

package/skills/create-post/references/linkedin-preview-rendering.md

@@ -1,221 +0,0 @@
-# LinkedIn Preview Rendering
-
-This asset defines the required rendered-preview contract for create-post hook
-research, hook candidate generation, gold-standard decomposition, and draft
-validation.
-
-Character budgets are only diagnostics. They are not the preview gate. A hook is
-not studied, selected, or ready until its visible mobile and desktop blocks come
-from `mcp__sellable__calculate_linkedin_hook_preview` or from a stricter
-authenticated LinkedIn screenshot.
-
-Do not let the LLM imagine wrapping. The normal path is a function call that
-returns rendered mobile and desktop lines. HTML and PNG outputs from
-`mcp__sellable__render_linkedin_post_preview` are optional visual QA artifacts,
-not the primary interface.
-
-## Rendering Basis
-
-LinkedIn does not publish exact feed truncation rules, and rendering can vary by
-surface, app version, device, media attachment, and account state. Use this
-deterministic function as the MCP review gate for unpublished drafts.
-
-Simple operating policy: judge the hook by the first 3 rendered lines. Use ~140
-characters on mobile and ~210 characters on desktop as guardrails only. If the
-3-line preview and the character guardrail disagree, trust the rendered lines.
-
-Call:
-
-```json
-mcp__sellable__calculate_linkedin_hook_preview({
-  "postText": "<full post text or candidate hook block>",
-  "sourceLabel": "<draft id, hook id, or source label>",
-  "measurementMode": "browser"
-})
-```
-
-When local Chrome is available, browser measurement is the preferred functional
-basis because it asks the browser layout engine to wrap the text under the
-contract. When Chrome is unavailable, the tool falls back to the deterministic
-width model and must mark that basis.
-
-Treat "see more" as a rendered-line problem first and a character-count problem
-second. Observed LinkedIn screenshots show the current desktop feed behaving
-like a first-3-rendered-lines clamp: a first line, a blank line, and a third
-line can be all that appears before `... more`.
-
-- review gate: first 3 rendered visual lines
-- mobile feed: tighter because the text column is narrower
-- desktop feed: more characters can fit per line, but still review line count
-- posts with media may show fewer text lines before truncation
-- blank lines and intentional separators consume visible preview lines
-- device width, font scaling, app version, browser, and profile/page context can
-  move the cutoff
-
-Because of that variation, never say a hook is guaranteed to render before
-"see more." Say `pass`, `warn`, or `fail` under the rendered-preview contract,
-and show the visible mobile and desktop blocks.
-
-When an authenticated LinkedIn feed/composer/browser screenshot is available,
-that screenshot is the strongest evidence. Still record the fields below so
-future agents can compare candidates without redoing the visual inspection.
-
-Observed public LinkedIn post text style for feed-style post pages:
-
-```text
-selector basis: p.attributed-text-segment-list__content
-font family: -apple-system, system-ui, "Segoe UI", Roboto, "Helvetica Neue",
-  "Fira Sans", Ubuntu, "Oxygen Sans", Cantarell, "Droid Sans",
-  "Lucida Grande", Helvetica, Arial, sans-serif
-font size: 14px
-line height: 21px
-font weight: 400
-letter spacing: normal
-white space: pre-wrap
-overflow wrap: break-word
-text color: rgba(0, 0, 0, 0.9)
-mobile text width: 308px
-desktop text width: 582px
-review clamp: first 3 rendered text lines
-```
-
-The `review clamp` is not an official LinkedIn rule. It is the conservative
-apples-to-apples region create-post must use when comparing hooks. Do not let a
-desktop pass rescue a mobile fail.
-
-## Required Rendering Record
-
-Every shortlisted source hook, adapted hook block, generated hook candidate, and
-selected hook must include a `renderedPreview` record:
-
-```text
-renderedPreview:
-  basis: linkedin_rendering_rule_function | authenticated_linkedin_screenshot | manual_user_source
-  cssContractVersion: linkedin-preview-rendering/v2
-  mobile:
-    textWidthPx: 308
-    fontSizePx: 14
-    lineHeightPx: 21
-    clampLines: 3
-    charGuardrail: 140
-    measurementBasis: local_chrome_browser_layout | estimated_width_model
-    visibleTextBlock: <literal first 3 rendered lines>
-    renderedLines:
-      - <line 1 exactly as wrapped>
-      - <line 2 exactly as wrapped>
-      - <line 3 exactly as wrapped>
-    lineCountBeforeClamp: <number>
-    blankLinesBeforeClamp: <number>
-    corePainProofOrCuriosityVisible: true | false
-    corePointVisible: true | false
-    intentionalOpenLoop: true | false
-    specificClickQuestionVisible: true | false
-    payoffPlannedImmediatelyAfterClamp: true | false
-    seeMoreClickReason: <why a reader would click see more>
-    seeMoreRisk: pass | warn | fail
-  desktop:
-    textWidthPx: 582
-    fontSizePx: 14
-    lineHeightPx: 21
-    clampLines: 3
-    charGuardrail: 210
-    measurementBasis: local_chrome_browser_layout | estimated_width_model
-    visibleTextBlock: <literal first 3 rendered lines>
-    renderedLines:
-      - <line 1 exactly as wrapped>
-      - <line 2 exactly as wrapped>
-      - <line 3 exactly as wrapped>
-    lineCountBeforeClamp: <number>
-    blankLinesBeforeClamp: <number>
-    corePainProofOrCuriosityVisible: true | false
-    corePointVisible: true | false
-    seeMoreRisk: pass | warn | fail
-  diagnostics:
-    charCount: <number>
-    charCountIncludingNewlines: <number>
-    firstLineChars: <number>
-    firstTwoPhysicalLinesChars: <number>
-    longestNonblankLineChars: <number>
-    blankLineVisualRisk: none | low | medium | high
-    pointAfterMobileClamp: true | false
-    openLoopType: none | hidden_payoff | contradiction | proof_gap | workflow_reveal | asset_reveal | story_gap
-    rewriteIfTruncated: <short fallback>
-```
-
-If a host cannot produce literal wrapped line blocks from
-`calculate_linkedin_hook_preview`, return `blocked` or `needs_revision`; do not
-claim the hook passed preview validation from character counts alone.
-
-## Study Rules
-
-For source-post research:
-
-- Render the exact visible opening from full text when full text is available.
-- If only a search preview is available, render only the preview text and set
-  `basis: manual_user_source` or record `sourceTextBasis: search_preview`.
-- Lower confidence when the search preview is cut off or the body is
-  unavailable.
-- Extract hook lessons from the rendered first-screen experience, not from the
-  full post in isolation.
-
-For generated hooks:
-
-- Generate the hook from the selected premise first.
-- Render the hook for mobile and desktop before scoring it.
-- Score the rendered first-screen click reason before scoring cleverness.
-- If the goal is see-more clicks, the hook may intentionally hide the payoff
-  after the mobile clamp, but the visible block must create a specific question
-  the target reader wants answered.
-- Rewrite any candidate whose real point appears after the mobile clamp unless
-  that point is the planned payoff for an intentional open loop.
-
-## Pass, Warn, Fail
-
-Use these rendered gates:
-
-- `pass`: the mobile rendered preview shows the pain, proof, or curiosity by the
-  end of the first 3 rendered lines, and either the core point is
-  understandable without opening "see more" or an intentional open loop creates
-  a specific click question with an immediate planned payoff.
-- `warn`: the mobile rendered preview creates useful curiosity but the core
-  point or click question is slightly softened by wrapping, blank-line rhythm,
-  or one missing context word. A compact fallback is required.
-- `fail`: the hook's real point appears after the first 3 mobile rendered lines,
-  the visible open loop is vague, the first rendered line is generic setup,
-  blank lines consume the preview before the reader sees the point, or desktop
-  fit is the only reason it looks good.
-
-A draft cannot be `ready` when the selected hook has:
-
-- no `renderedPreview`
-- `mobile.seeMoreRisk: fail`
-- `mobile.corePainProofOrCuriosityVisible: false`
-- `mobile.corePointVisible: false` unless `mobile.intentionalOpenLoop: true`,
-  `mobile.specificClickQuestionVisible: true`, and
-  `mobile.payoffPlannedImmediatelyAfterClamp: true`
-- `pointAfterMobileClamp: true` unless the point after the clamp is the
-  intentional payoff for a specific open loop
-
-## Report Format
-
-Research reports must show rendered preview blocks for the best examples and
-recommended draft directions:
-
-```text
-Rendered preview:
-mobile:
-<line 1>
-<line 2>
-<line 3>
-
-desktop:
-<line 1>
-<line 2>
-<line 3>
-
-verdict: pass | warn | fail
-why: <what is visible before the fold>
-```
-
-Do not say "it fits on mobile" without showing what the mobile reader actually
-sees.

package/skills/research/config.json

@@ -1,9 +0,0 @@
-{
-  "parallelMode": "wide",
-  "agentCount": 6,
-  "maxToolCallsPerAgent": 2,
-  "senderMaxAgents": 2,
-  "senderMaxToolCallsPerAgent": 3,
-  "progressMode": true,
-  "debugMode": true
-}