@sellable/mcp 0.1.261 → 0.1.263

package/skills/create-post/SKILL.md

@@ -108,6 +108,7 @@ Use these MCP tools when available:
 - `mcp__sellable__get_post_idea`
 - `mcp__sellable__list_post_ideas`
 - `mcp__sellable__save_hook_research`
+- `mcp__sellable__render_linkedin_post_preview`
 - `mcp__sellable__save_post_draft`
 - `mcp__sellable__update_post_draft`
 - `mcp__sellable__list_post_draft_iterations`
@@ -342,21 +343,30 @@ Visible Flow Trace
 
 4. Hook Autopsies
 - source hook:
-- rendered/mobile preview or preview-basis:
+- rendered/mobile preview artifact from `render_linkedin_post_preview` or
+  authenticated LinkedIn screenshot:
 - see-more tension:
 - curiosity debt:
 - body promise:
 - why it works:
 - why it may not transfer:
 
-5. Post Positioning Breakdowns
+5. Source Message Outlines
+- source:
+- outline basis:
+- source paragraph order:
+- branches by paragraph/line/phrase:
+- high-level goal of each branch:
+- reusable move without copying wording:
+
+6. Post Positioning Breakdowns
 - source:
 - positioning sequence:
 - line-level narrative techniques:
 - reusable template lines:
 - adaptation guards:
 
-6. Viral-Post Outlines
+7. Viral-Post Outlines
 - source template:
 - hook job:
 - see-more trigger:
@@ -364,7 +374,7 @@ Visible Flow Trace
 - body payoff:
 - close job:
 
-7. Market Belief Map
+8. Market Belief Map
 - resonating ideas:
 - implicit beliefs:
 - wants / resentments / fears:
@@ -372,7 +382,7 @@ Visible Flow Trace
 - why this user can credibly say it:
 - what not to claim:
 
-8. Premise Cards
+9. Premise Cards
 - 3-5 cards:
 - story/scene:
 - tension:
@@ -383,7 +393,7 @@ Visible Flow Trace
 - score:
 - selected premise:
 
-9. Source Template Selection
+10. Source Template Selection
 - selected template:
 - positioning sequence to borrow:
 - hook move to borrow:
@@ -392,15 +402,15 @@ Visible Flow Trace
 - forbidden borrowing:
 - no-template rationale if rejected:
 
-10. Hook Lab
+11. Hook Lab
 - at least 12 hooks:
-- rendered preview record or explicit preview-basis:
+- rendered preview artifact from `render_linkedin_post_preview`:
 - hook-to-body promise:
 - score:
 - selected hook:
 - rejected winning-looking hooks and why:
 
-11. Pre-Draft Narrative Outline
+12. Pre-Draft Narrative Outline
 - hierarchical outline shown before draft:
 - I. hook and click debt:
 - II. thesis the post will defend:
@@ -410,7 +420,7 @@ Visible Flow Trace
 - VI. scan path and proof safety:
 - user corrections applied before prose:
 
-12. Body Expression Lab
+13. Body Expression Lab
 - 5-8 body-expression candidates:
 - best lines:
 - weak lines:
@@ -419,13 +429,13 @@ Visible Flow Trace
 - score:
 - combined body plan:
 
-13. Draft
+14. Draft
 - draft body:
 - lines intentionally copied from user source:
 - outside-source wording copied: yes/no:
 - known weak lines:
 
-14. Validation And Save
+15. Validation And Save
 - ready status:
 - proof gate:
 - voice gate:
@@ -619,6 +629,15 @@ Post positioning breakdown templates:
    - reusable template lines:
    - Sellable adaptation:
 
+Source message outlines:
+1. source + outline basis
+   - source paragraph order:
+   - paragraph/line/phrase branches:
+   - high-level goal of each branch:
+   - reader effect:
+   - reusable move:
+   - adaptation guard:
+
 Viral-post outlines:
 1. outline name
    - hook job:
@@ -812,17 +831,34 @@ Each hook must include:
 
 Do not copy source wording. Copy only the structure.
 
-Use this conservative mobile-first LinkedIn preview gate. LinkedIn does not
-publish exact "see more" cutoff rules, and rendering varies by device, app
-version, font, media, and line break. These are v1 safety budgets, not claims
-about an official LinkedIn limit:
-
-- `pass`: hook is <= 110 chars including newlines, every nonblank line is <= 45 chars, and the hook's core point lands before likely truncation.
-- `warn`: hook is 111-140 chars including newlines, any nonblank line is 46-55 chars, or blank lines create visual-line risk. Blank lines are allowed, but they count as physical lines.
-- `fail`: hook is > 140 chars including newlines, any nonblank line is > 55 chars, or the hook's point depends on text after likely truncation.
+Use the rendered-preview contract from
+`references/linkedin-preview-rendering.md`. LinkedIn does not publish exact
+"see more" cutoff rules, and rendering varies by device, app version, font,
+media, and line break. Treat character counts as diagnostics only, not as proof
+that the hook will render before "see more."
+
+The selected hook and top candidates must include literal mobile and desktop
+visible blocks. Current third-party preview tools and 2026 creator references
+generally cluster around mobile showing about 2-3 text lines and desktop showing
+about 3-4 text lines before "see more," with media attachments sometimes showing
+less. Blank lines and `--` separators consume visible preview lines.
+
+Use:
+
+- `pass`: rendered mobile preview shows the pain, proof, or curiosity by the end
+  of the first 3 rendered lines, and either the core point is visible or a
+  specific intentional open loop is visible with immediate body payoff planned
+- `warn`: rendered mobile preview creates useful curiosity but wrapping,
+  blank-line rhythm, media risk, or one missing context word weakens it; include
+  a compact fallback
+- `fail`: the hook's real point appears after the rendered mobile review clamp,
+  the visible open loop is vague, blank lines consume the preview before the
+  point, or desktop fit is the only reason it looks good
 
 Desktop preview usually has more room. Still record `desktopPreviewFit`, but
-never let desktop fit compensate for a mobile `fail`.
+never let desktop fit compensate for a mobile `fail`. Do not tell the user "we
+know" how LinkedIn will render unless there is an authenticated LinkedIn
+screenshot; say it passes the renderer and show the visible blocks.
 
 If a hook's point depends on text after the likely preview, rewrite it before
 selecting it. A selected hook may carry a `warn` only when the warning is about
@@ -839,6 +875,7 @@ Draft from:
 - approved or latest `Pre-Draft Narrative Outline`
 - hook research artifact
 - selected source template or no-template rationale
+- source-message outline for any outside post being adapted
 - viral-post outline
 - post positioning breakdown template
 - body expression candidates and combined body plan

package/skills/create-post/references/hook-research-playbook.md

@@ -7,12 +7,14 @@ readers click "see more," decompose each post into a reusable narrative and
 positioning template, and then adapt those templates to the user's real story
 without copying source wording.
 
-V2 research has four outputs:
+V2 research has five outputs:
 
 1. weighted source winners: the best recent posts to learn from
 2. hook autopsies: exact preview measurements, open loops, and tension created
-3. viral-post outlines: the narrative structure of each source post
-4. post positioning breakdown templates: line-level positioning and narrative
+3. source-message outlines: the paragraph/line/phrase structure of each source
+   post in its original order
+4. viral-post outlines: the reusable narrative structure of each source post
+5. post positioning breakdown templates: line-level positioning and narrative
    technique maps that can be adapted into the user's draft
 
 ## Search Inputs
@@ -254,19 +256,33 @@ Measure the visible opening for every shortlisted source post before extracting
 the hook pattern. This makes the study useful for LinkedIn, not just generally
 "good writing."
 
-LinkedIn does not publish exact "see more" cutoff rules. Treat these as
-conservative v1 planning budgets:
-
-- `pass`: opening hook is <= 110 chars including newlines, every nonblank line
-  is <= 45 chars, and the hook's core point lands before likely truncation.
-- `warn`: opening hook is 111-140 chars including newlines, any nonblank line is
-  46-55 chars, or blank lines create visual-line risk. Blank lines are allowed,
-  but they count as physical lines.
-- `fail`: opening hook is > 140 chars including newlines, any nonblank line is
-  > 55 chars, or the hook's core point depends on text after likely truncation.
+LinkedIn does not publish exact "see more" cutoff rules. Treat preview fit as a
+rendered-line problem first, not a fixed character-count rule. Current
+third-party preview tools and 2026 creator references generally cluster around:
+
+- mobile feed: about 2-3 visible text lines, often around 140 characters when
+  there is no media
+- desktop feed: about 3-4 visible text lines, often around 210 characters when
+  there is no media
+- media posts can show fewer text lines before truncation
+- blank lines and `--` style separators consume visible preview lines
+
+Use `references/linkedin-preview-rendering.md` as the required gate. Character
+budgets are diagnostics only:
+
+- `pass`: rendered mobile preview shows the pain, proof, or curiosity by the end
+  of the first 3 rendered lines, and the hook creates a specific click reason
+- `warn`: rendered mobile preview creates useful curiosity but loses one useful
+  context word, wraps awkwardly, or spends a visible line on blank space or a
+  separator; include a compact fallback
+- `fail`: the hook's real point appears after the rendered mobile review clamp,
+  the visible open loop is vague, blank lines consume the preview before the
+  point, or desktop fit is the only reason it looks good
 
 Desktop preview has more room, so record it separately, but never let desktop
-fit compensate for a mobile `fail`.
+fit compensate for a mobile `fail`. Never say "we know" how LinkedIn will render
+the hook unless there is an authenticated LinkedIn screenshot. Say the hook
+`passes the renderer` and show the mobile/desktop visible blocks.
 
 For each source, record:
 
@@ -280,6 +296,8 @@ For each source, record:
 - `firstTwoContentLinesChars`
 - `longestNonblankLineChars`
 - `blankLineCountBeforeFold`
+- `renderedPreview`: literal mobile and desktop visible blocks from
+  `references/linkedin-preview-rendering.md`
 - `mobilePreviewBudget`: `pass`, `warn`, or `fail`
 - `desktopPreviewBudget`: `pass`, `warn`, or `fail`
 - `blankLineVisualRisk`
@@ -434,13 +452,70 @@ line_map:
 ```
 
 Break long lines into phrase-level segments when one line contains multiple
-jobs. Preserve the original source line in the research artifact, but never
-copy it into the draft unless it is the user's own approved post.
+jobs. Use short anchors or paraphrased line labels for outside source posts; do
+not reproduce the full outside post. Never copy source wording into the draft
+unless it is the user's own approved post.
+
+## Source Message Outline
+
+Before converting a source post into a reusable template, outline the source
+message as it is. This is the branch map of the original post, not the adapted
+draft plan.
+
+The outline must preserve the source post's order and branch each paragraph,
+line, or phrase into the high-level rhetorical goal it serves. If a paragraph
+contains several jobs, split it into phrase-level branches.
+
+Use this format:
+
+```text
+Source Message Outline:
+source: <author + URL>
+outline_basis: full_text | excerpt_only | screenshot | user_supplied_text
+copyright_safety: use short anchors/paraphrases; do not reproduce the full source
+
+P1. <short paragraph anchor or paraphrase>
+  goal: <what this paragraph makes the reader think/feel/wonder>
+  why_here: <why it appears at this point in the sequence>
+  branches:
+    A. <phrase/line anchor or paraphrase>
+       job: <high-level job of this phrase/line>
+       reader_effect: <what changes in the reader>
+       reusable_move: <what can be adapted without copying wording>
+    B. <phrase/line anchor or paraphrase>
+       job:
+       reader_effect:
+       reusable_move:
+
+P2. <short paragraph anchor or paraphrase>
+  goal:
+  why_here:
+  branches:
+    A.
+       job:
+       reader_effect:
+       reusable_move:
+```
+
+Quality rules:
+
+- Do not summarize the whole post first and then invent a cleaner outline.
+- Do not skip ordinary body paragraphs; the point is to learn the source's real
+  sequence, including setup, repetition, proof, turns, and close.
+- Every branch must answer: "What is this exact line/paragraph/phrase doing?"
+- Use `P1`, `P2`, `A`, `B`, and `i` structure so the user can compare it
+  against the source post.
+- If only an excerpt is available, label `outline_basis: excerpt_only` and do
+  not infer hidden body structure.
+- After the source-message outline, then create the viral-post outline and
+  template. The adapted outline cannot replace the source-message outline.
 
 ## Viral-Post Outline
 
-After the line-level breakdown, convert each keeper into a viral-post outline.
-The outline is the narrative skeleton beneath the exact words.
+After the source-message outline and line-level breakdown, convert each keeper
+into a viral-post outline. The viral-post outline is the reusable narrative
+skeleton beneath the exact words, not a replacement for the source-message
+outline.
 
 Use this format:
 

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

@@ -5,8 +5,14 @@ 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 it has been rendered through this contract
-or through a stricter authenticated LinkedIn screenshot.
+not studied, selected, or ready until it has been rendered through
+`mcp__sellable__render_linkedin_post_preview` or through a stricter
+authenticated LinkedIn screenshot.
+
+Do not let the LLM imagine wrapping. Character counts and hand-written line
+blocks are only fallback diagnostics. The normal path is tool-rendered mobile
+and desktop artifacts: HTML always, and PNG screenshots whenever local Chrome is
+available.
 
 ## Rendering Basis
 
@@ -14,6 +20,38 @@ 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 renderer as the MCP review gate for unpublished drafts.
 
+Call:
+
+```json
+mcp__sellable__render_linkedin_post_preview({
+  "postText": "<full post text or candidate hook block>",
+  "sourceLabel": "<draft id, hook id, or source label>",
+  "renderScreenshots": true
+})
+```
+
+When screenshots are produced, the PNG files are the review artifact. When
+screenshots cannot be produced, the HTML artifact is still deterministic and
+must be opened or explicitly marked as lower confidence.
+
+Treat "see more" as a rendered-line problem first and a character-count problem
+second. Current third-party preview tools and 2026 creator references generally
+cluster around these working assumptions:
+
+- mobile feed: about 2-3 visible text lines, often around 140 characters when
+  there is no media
+- desktop feed: about 3-4 visible text lines, often around 210 characters when
+  there is no media
+- posts with media may show fewer text lines before truncation, sometimes only
+  1-2 lines
+- 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.
@@ -48,13 +86,13 @@ selected hook must include a `renderedPreview` record:
 
 ```text
 renderedPreview:
-  basis: linkedin_css_contract | authenticated_linkedin_screenshot | manual_user_source
+  basis: local_chrome_headless_screenshot | linkedin_css_contract_html | authenticated_linkedin_screenshot | manual_user_source
   cssContractVersion: linkedin-preview-rendering/v1
   mobile:
     textWidthPx: 308
     fontSizePx: 14
     lineHeightPx: 21
-    visibleTextBlock: <literal first rendered review-clamp block>
+    visibleTextBlock: <literal first rendered review-clamp block or tool estimated block when screenshot is the authority>
     renderedLines:
       - <line 1 exactly as wrapped>
       - <line 2 exactly as wrapped>
@@ -68,7 +106,8 @@ renderedPreview:
     payoffPlannedImmediatelyAfterClamp: true | false
     seeMoreClickReason: <why a reader would click see more>
     seeMoreRisk: pass | warn | fail
-    screenshotPath: <optional local path>
+    htmlPath: <local path>
+    screenshotPath: <local path when Chrome rendered PNG>
   desktop:
     textWidthPx: 582
     fontSizePx: 14
@@ -83,7 +122,8 @@ renderedPreview:
     corePainProofOrCuriosityVisible: true | false
     corePointVisible: true | false
     seeMoreRisk: pass | warn | fail
-    screenshotPath: <optional local path>
+    htmlPath: <local path>
+    screenshotPath: <local path when Chrome rendered PNG>
   diagnostics:
     charCount: <number>
     charCountIncludingNewlines: <number>
@@ -96,10 +136,11 @@ renderedPreview:
     rewriteIfTruncated: <short fallback>
 ```
 
-If a host cannot produce screenshots, it must still produce the literal wrapped
-line blocks using the CSS contract. If it cannot produce either screenshots or
-literal line wraps, return `blocked` or `needs_revision`; do not claim the hook
-passed preview validation from character counts alone.
+If a host cannot produce screenshots, it must still produce and preserve the
+HTML artifacts from `render_linkedin_post_preview`. If it cannot produce
+screenshots, HTML artifacts, or literal wrapped line blocks, return `blocked` or
+`needs_revision`; do not claim the hook passed preview validation from character
+counts alone.
 
 ## Study Rules
 

package/skills/create-post/references/post-file-contract.md

@@ -70,6 +70,10 @@ Hook research files must preserve:
 - rendered preview records for kept source hooks and adapted hook blocks,
   including literal mobile/desktop preview blocks and whether the first-screen
   promise is visible
+- source-message outlines for keeper posts, preserving source paragraph order
+  and branching each paragraph, line, or phrase into high-level goal, reader
+  effect, reusable move, and adaptation guard without reproducing the full
+  outside source post
 - extracted hook patterns
 - selected hook basis
 
@@ -88,6 +92,8 @@ Draft files must preserve:
   - score fields for hook, proof, voice, specificity, skimmability, and publish confidence
   - `verdict`: `baseline`, `keep`, `revise`, `reject`, `publish_candidate`, or a similarly explicit state
 - draft body
+- source-message outline for any outside post being adapted, when the draft's
+  body shape was learned from a specific source post
 - pre-draft narrative outline: hierarchical `I.`, `A.`, `i.` outline covering
   hook debt, thesis, reader, core mechanism, definitions, proof claims,
   working body patterns adapted, narrative beats, mobile scan path, body

package/skills/create-post/references/post-validation.md

@@ -11,6 +11,7 @@ Every saved draft needs a validation receipt. A draft without this receipt is no
 - `candidateHooksConsidered`
 - `selectedHook`
 - `selectedHookWhy`
+- `sourceMessageOutline`
 - `preDraftNarrativeOutline`
 - `preDraftStructureBrief` as a legacy compatibility alias when older drafts or
   downstream readers still expect it
@@ -170,6 +171,9 @@ Record:
 - `readerValue`: what the reader learns, sees differently, or can do
 - `proofAvailable`: source-backed proof used
 - `proofMissing`: claims intentionally avoided or requiring user input
+- `sourceMessageOutline`: source post decomposition in original order, with
+  paragraph/line/phrase branches, high-level goal of each branch, reader effect,
+  reusable move, and adaptation guard
 - `preDraftNarrativeOutline`: hierarchical `I.`, `A.`, `i.` outline showing
   hook debt, thesis, operating model, working body patterns adapted, narrative
   beats, scan path, proof claims, and abstractions to remove
@@ -316,22 +320,38 @@ proof from another creator, save as `needs_revision`.
 
 ## LinkedIn Preview Audit
 
-Audit the selected hook and top candidates against conservative LinkedIn
-preview budgets. LinkedIn does not publish exact "see more" cutoff rules, and
-rendering varies by device, app version, font, media, and line break. This audit
-is a mobile-first safety gate, not a claim about an official LinkedIn limit.
+Audit the selected hook and top candidates against the rendered-preview
+contract. LinkedIn does not publish exact "see more" cutoff rules, and rendering
+varies by device, app version, font, media, line break, and whether the post has
+media attached. This audit is a mobile-first safety gate, not a claim about an
+official LinkedIn limit.
+
+Treat character counts as diagnostics only. The gate is the literal rendered
+mobile and desktop visible block from `references/linkedin-preview-rendering.md`
+or an authenticated LinkedIn screenshot.
 
 Use:
 
-- `pass`: hook is <= 110 chars including newlines, every nonblank line is <= 45 chars, and the hook's core point lands before likely truncation.
-- `warn`: hook is 111-140 chars including newlines, any nonblank line is 46-55 chars, or blank lines create visual-line risk. Blank lines are allowed, but they count as physical lines.
-- `fail`: hook is > 140 chars including newlines, any nonblank line is > 55 chars, or the hook's point depends on text after likely truncation.
+- `pass`: the rendered mobile preview shows the pain, proof, or curiosity by the
+  end of the first 3 rendered lines, and either the core point is visible or a
+  specific intentional open loop is visible with immediate body payoff planned
+- `warn`: the rendered mobile preview creates useful curiosity but wrapping,
+  blank-line rhythm, media risk, or one missing context word weakens it; include
+  a compact fallback
+- `fail`: the hook's real point appears after the rendered mobile review clamp,
+  the visible open loop is vague, blank lines consume the preview before the
+  point, or desktop fit is the only reason it looks good
 
 Desktop preview usually has more room. Still record desktop fit, but never let
 desktop fit compensate for a mobile `fail`.
 
 Record:
 
+- `renderedPreview`
+- `renderedPreviewBasis`: `linkedin_css_contract` |
+  `authenticated_linkedin_screenshot` | `manual_user_source`
+- literal mobile visible block
+- literal desktop visible block
 - `charCount`
 - `charCountIncludingNewlines`
 - `firstLineChars`
@@ -351,9 +371,11 @@ Record:
 - `compactFallback` when `previewBudgetStatus` is `warn`
 
 If the hook only works after likely truncation, rewrite it. A draft cannot be
-`ready` with `previewBudgetStatus: fail`. A draft may be `ready` with
+`ready` with `previewBudgetStatus: fail`, with no rendered preview block, or
+with only a character-count claim. A draft may be `ready` with
 `previewBudgetStatus: warn` only when the warning is explicit, usually because
-the user prefers blank-line rhythm, and the receipt includes a compact fallback.
+the user prefers blank-line rhythm, separators, or a deliberate open loop, and
+the receipt includes a compact fallback.
 
 ## Simplifier / Concrete-Language Audit
 

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

@@ -309,12 +309,15 @@ III. Operating model
 
 IV. Body shape borrowed from posts that worked
    A. Selected source template or no-template rationale: <source or rationale>
-   B. Working body pattern(s) being adapted:
+   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>
-   C. What gets borrowed:
+   D. What gets borrowed:
       i. <narrative job, sequence, transition, or proof order>
-   D. What must not be copied:
+   E. What must not be copied:
       i. <source wording, creator-specific proof, joke, or context>
 
 V. Narrative beats
@@ -344,9 +347,10 @@ Quality gate:
 - 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 body
-  pattern and what beat order, proof order, or transition logic is being
-  borrowed.
+- 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.