@sellable/mcp 0.1.269 → 0.1.272

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

@@ -1,6 +1,24 @@
-# Hook Research Playbook
-
-Hook research must use current Sellable engagement data before drafting unless the user explicitly asks for `unsaved_preview`. The goal is not only to find hooks. The goal is to find what the market is currently rewarding, what the audience implicitly believes/wants/resents/fears, which controversial angle the user can credibly test, and what premise would deliver real reader value.
+# Hook Research Playbook V2
+
+Hook research must use current Sellable engagement data before drafting unless
+the user explicitly asks for `unsaved_preview`. The goal is not only to find
+hooks. The goal is to find the weighted best posts, understand why they made
+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 six outputs:
+
+1. weighted source winners: the best recent posts to learn from
+2. hook autopsies: exact preview measurements, open loops, and tension created
+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
+6. thought leader voice variants from the configured active influencer
+   list, unless the user explicitly skipped thought leaders or supplied a
+   named subset
 
 ## Search Inputs
 
@@ -29,11 +47,17 @@ Worker owns:
 - full-text matching by URL/activity ID
 - duplicate removal
 - lead-magnet, giveaway, engagement-bait, and off-voice filtering
-- market belief mapping across kept and rejected examples
+- audience tension extraction across kept and rejected examples
 - premise input extraction: real scenes, observed tensions, reader value, proof gaps
-- hook opening measurement
+- hook opening measurement and "see more" tension autopsy
 - exact phrase-pattern extraction
+- post positioning breakdown by line and phrase
+- viral-post outline extraction
+- line-to-template conversion
 - body-structure extraction
+- body-expression input extraction for the later draft lab
+- per-creator voice variant assembly when the user supplied thought
+  leaders
 - rejected-example notes
 - track-person and gold-standard recommendations
 
@@ -51,14 +75,20 @@ Worker output must be a compressed research packet, not a data dump:
 Research packet:
 - sources kept: max 8
 - sources rejected: max 8
-- market belief map: max 8 bullets
+- audience tension snapshot: max 8 bullets
 - controversy candidates: max 8
 - premise inputs: max 8
 - full adapted hook blocks: max 12
 - exact phrase patterns: max 20
+- post positioning breakdowns: max 8
+- viral-post outlines: max 8
+- reusable post templates: max 8
 - body patterns: max 8
 - source URLs and author profile URLs
 - preview measurements
+- hook-to-body promise maps
+- body expression inputs
+- thought leader voice variants
 - confidence gaps
 - save recommendations
 ```
@@ -118,23 +148,59 @@ Penalize lead-magnet and engagement-bait mechanics unless the user explicitly as
 - "like and comment"
 - broad giveaway framing that makes engagement inflate without proving the hook/body worked
 
-## Market Belief Map
+## Keeper Threshold
+
+Only promote a source post into template analysis when it clears a practical
+keeper threshold. A post does not have to be perfect, but it must be useful
+enough that copying its structure would teach the draft something.
+
+Keeper fields:
 
-Before selecting a hook or writing a draft, synthesize a market belief map from
-the kept and rejected posts. This is the step that prevents an internally
-coherent post from becoming externally boring.
+```text
+keeper_score:
+  topic_fit: 1-10
+  hook_preview_strength: 1-10
+  see_more_tension: 1-10
+  body_payoff_strength: 1-10 | full_text_unavailable
+  positioning_density: 1-10
+  creator_repeat_success: 1-10 | unknown
+  engagement_quality: 1-10
+  replicability_for_user: 1-10
+  voice_fit: 1-10
+  penalties:
+    lead_magnet:
+    engagement_bait:
+    celebrity_or_account_size_only:
+    borrowed_proof:
+    body_unavailable:
+  verdict: keeper | maybe | reject
+  why:
+```
+
+Use `keeper` only when the post has enough hook and body visibility to create a
+template. Use `maybe` when the hook is useful but the body is unavailable or the
+post depends too much on the source creator's status. Use `reject` when the post
+is mostly reach, giveaway mechanics, copied trend language, or poor fit.
+
+## Audience Tension Snapshot
+
+Before selecting a hook or writing a draft, synthesize an audience tension
+snapshot from the kept and rejected posts. This is the step that prevents an
+internally coherent post from becoming externally boring without forcing the
+workflow into a large audience model.
 
 Record:
 
 - resonating ideas: what topics or claims are repeatedly earning real
   engagement in the last 30-120 days
-- implicit beliefs: what the audience seems to already believe but may not say
-  directly
 - audience wants: what they want to feel, learn, try, buy, avoid, or be early to
-- audience resentments: what they are tired of, embarrassed by, or angry about
+- visible tension: the contradiction, tradeoff, cost, or unfinished question
+  readers are reacting to
+- audience objections: what they are tired of, skeptical about, embarrassed by,
+  or likely to argue with
 - audience fears: what risk would make them hesitate
 - argument bait: what they will plausibly disagree with in comments
-- credible controversy: what the user can argue without borrowing someone else's
+- credible angle: what the user can argue without borrowing someone else's
   proof or pretending to have data they do not have
 - avoid list: ideas that are inflated by comment bait, stale category claims,
   celebrity reach, giveaway mechanics, or poor voice fit
@@ -142,11 +208,11 @@ Record:
 The selected direction must include:
 
 ```text
-Selected controversy:
+Selected angle:
 <one sentence>
 
 Why this audience would engage:
-<specific belief/want/resentment/fear>
+<specific tension, want, objection, or fear>
 
 Why this user can credibly say it:
 <raw idea, memory, story, proof, or product mechanism>
@@ -155,19 +221,21 @@ What not to claim:
 <unsupported metric, borrowed proof, or hype phrase to avoid>
 ```
 
-If the raw idea is true but the market belief map does not show a live tension,
+If the raw idea is true but the audience tension snapshot does not show a live tension,
 do not draft from the raw idea as-is. Present stronger directions or reframe the
 idea around the closest supported external tension.
 
 ## Premise Inputs
 
-After the market belief map, extract the ingredients needed for premise
+After the audience tension snapshot, extract the ingredients needed for premise
 development. Do this before hook generation.
 
 Record:
 
 - real story or scene candidates from the raw idea, memory, transcript, or
   current-session context
+- transcript worldview packet matches: clusters, transcript references, cards,
+  repeated phrasing, worldview ingredients, and hot-take ingredients
 - observed pattern candidates when no first-person story is available
 - visible tension: the uncomfortable gap, cost, contradiction, or tradeoff
 - common belief: what the audience probably believes right now
@@ -175,6 +243,7 @@ Record:
 - reader value: what the reader learns, sees differently, or can do
 - proof available: what can be safely used
 - proof missing: what cannot be claimed without user confirmation
+- private/sensitive transcript material to exclude
 
 If this section is weak, say so. Do not let the hook lab proceed as if a clever
 opening can create value that the premise does not have.
@@ -198,19 +267,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:
 
@@ -224,10 +307,19 @@ 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`
 - `corePointBeforeLikelyTruncation`
+- `seeMoreTension`: what question, contradiction, missing proof, or unfinished
+  story makes the reader want the next line
+- `curiosityDebt`: what the hook promises the body must repay
+- `firstScreenPayoffRisk`: whether the hook creates curiosity without enough
+  substance to repay it
+- `readerClickReason`: the specific reason a target reader would click "see
+  more," not a generic label like "curiosity"
 
 If only a search preview is available, do not pretend the opening is complete.
 Record `sourceTextBasis: search_preview` and lower confidence when the hook
@@ -250,6 +342,9 @@ For each shortlisted source post, record:
 - visible hook text or preview
 - opening preview measurement fields from the section above
 - hook mechanism
+- hook promise: what the body is now obligated to prove, reveal, or resolve
+- see-more tension: what makes the reader want the body
+- curiosity debt: what must be repaid quickly after the fold
 - exact hook language patterns: reusable words, phrase shapes, contrast forms,
   sentence shapes, and transition moves
 - story mechanism when the post is a story
@@ -304,6 +399,218 @@ Never reduce this section to high-level labels like "contrarian" or
 "founder story." Those labels are allowed only after the exact phrase mechanics
 are captured.
 
+## Post Positioning Categories
+
+For post research, use the familiar copy-breakdown categories, but apply them to
+public narrative posts instead of landing pages or outbound emails. Assign one
+primary category to every meaningful line or phrase, and add a secondary
+category only when the same phrase clearly does two jobs.
+
+Core categories:
+
+- `Context`: setup, scene, timing, environment, or "why this is being said now"
+- `Persona`: who the post is for or who appears in the story
+- `Problem`: pain, friction, failure mode, risk, or gap
+- `Alternative`: the old behavior, competitor, default advice, or common path
+- `Belief`: the assumption, status game, worldview, or market consensus being
+  entered
+- `Tension`: contradiction, tradeoff, discomfort, open loop, or argument bait
+- `Proof`: numbers, named events, observed outcomes, screenshots, customers,
+  repeated experience, or hard-won authority
+- `Mechanism`: the causal explanation for why the thing works or fails
+- `Capability`: the new action the reader, product, or system can perform
+- `Benefit`: positive outcome, leverage, speed, money, clarity, trust, or relief
+- `Feature`: concrete product/workflow object that powers the mechanism
+- `Identity`: founder confession, status shift, taste, vulnerability, or role
+- `Offer`: CTA, invitation, ask, or proposed next step
+- `Bridge`: transition line that moves the reader from hook to proof, from
+  proof to lesson, or from lesson to product
+
+Do not hide useful detail behind a category label. The category says what the
+line does; the technique notes must explain how the exact words do it.
+
+## Post Positioning Breakdown
+
+For every keeper post with enough text, create a line-level breakdown. This is
+the post version of the admin copy-breakdown view: every line becomes a
+positioning and narrative unit that can be templated.
+
+Use this format:
+
+```text
+Post positioning breakdown:
+source: <author + URL>
+text_basis: full_text | search_preview | manual_user_source
+overall_positioning_sequence:
+  <Category> -> <Category> -> <Category> -> ...
+
+line_map:
+1.
+  source_line:
+  char_count:
+  line_role:
+  primary_category:
+  secondary_category:
+  narrative_technique:
+  tension_created:
+  reader_question_opened:
+  body_promise:
+  proof_or_story_dependency:
+  why_this_exact_wording_works:
+  reusable_template_line:
+  adaptation_guard:
+  sellable_version_candidate:
+```
+
+Break long lines into phrase-level segments when one line contains multiple
+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 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:
+
+```text
+Viral-post outline:
+source: <author + URL>
+outline_name:
+best_for:
+not_good_for:
+hook_job:
+see_more_trigger:
+body_payoff:
+close_job:
+
+beats:
+1.
+  beat_name:
+  source_lines:
+  narrative_job:
+  positioning_categories:
+  reader_state_before:
+  reader_state_after:
+  tension_or_open_loop:
+  proof_needed:
+  reusable_instruction:
+```
+
+Examples of outline names:
+
+- proof-first roadmap
+- confession to operating rule
+- enemy naming to mechanism
+- teardown to replacement behavior
+- status reversal to concrete lesson
+- personal scene to category thesis
+
+## Line-To-Template Conversion
+
+Convert the source outline into reusable templates that preserve the narrative
+job, not the source creator's language.
+
+Use this format:
+
+```text
+Post template:
+source:
+template_name:
+positioning_sequence:
+  <Category> -> <Category> -> <Category> -> ...
+required_story_inputs:
+  - <input the user must actually have>
+required_proof_inputs:
+  - <proof needed to make the template credible>
+forbidden_borrowing:
+  - <source proof, joke, phrase, or status that cannot transfer>
+
+template_lines:
+1.
+  job:
+  line_shape:
+  allowed_moves:
+  disallowed_moves:
+  example_user_adaptation:
+```
+
+The template should be specific enough that another agent can draft from it
+without re-reading the source post. If the template only says "use a contrarian
+hook" or "tell a story," it failed.
+
+## Hook-To-Body Promise Map
+
+Every keeper hook must include a map from the preview to the body. This prevents
+the later draft from using a strong opening that the body does not repay.
+
+Record:
+
+- hook promise: what the hook says or implies the reader will get
+- curiosity debt: what the reader is waiting to learn after clicking
+- first body beat: the first line or paragraph that repays the debt
+- payoff speed: immediate | delayed | too slow
+- tension carried forward: how the body keeps the hook's question alive
+- body betrayal risk: where the body changes topic, gets generic, or overclaims
+- adaptation instruction: how the user's draft must repay the same kind of debt
+
 ## Body Structure Extraction
 
 For each keeper with full text available, extract the body in this format:
@@ -315,6 +622,9 @@ Body pattern:
 Source:
 <author + URL>
 
+Positioning sequence:
+<Context -> Proof -> Problem -> Mechanism -> Benefit ...>
+
 Sequence:
 1. <paragraph/job 1>
 2. <paragraph/job 2>
@@ -328,6 +638,13 @@ Exact language moves:
 Adapted body move:
 <how this would show up in the user's post>
 
+Body expression inputs:
+- hook promise to repay:
+- narrative beats to preserve:
+- line shapes worth adapting:
+- proof/story slots required:
+- candidate Sellable body lines:
+
 Replicability:
 high | medium | low
 ```
@@ -349,6 +666,166 @@ For story posts, do not reduce the source to "strong first line" or a generic le
 
 If the source story only works because of celebrity, outrage, giveaway mechanics, or an unavailable body section, mark it as low-replicability or `full_text_unavailable`.
 
+## Template Selection For Drafting
+
+After all keeper posts are broken down, select 1-3 source templates for the
+user's idea. Selection is based on fit, not raw engagement.
+
+For each selected template, record:
+
+```text
+Selected source template:
+template_name:
+source:
+why_this_template_fits_the_user_story:
+why_it_might_fail:
+positioning_sequence_to_borrow:
+hook_move_to_borrow:
+body_outline_to_borrow:
+line_shapes_to_test:
+required_user_inputs:
+required_proof:
+do_not_copy:
+draft_lab_instruction:
+```
+
+The draft lab instruction should tell the later premise/drafting stage exactly
+how to use the template, for example:
+
+```text
+Use the source's proof-first roadmap sequence, but replace its revenue proof
+with Christian's verified campaign-source ladder. Keep the hook's "unexpected
+best source" tension. Do not borrow the source's dinner/community proof.
+```
+
+## Thought Leader Voice Variant Workers
+
+Run a separate voice-variant worker per person for the configured active
+thought-leader list by default during draft-producing create-post flows, unless
+the user explicitly says to skip thought leaders, skip external inspiration, or
+use only a named subset. Also do this when the user supplies a list of thought
+leaders, creators, profile URLs, or handles. The configured source is
+memory-backed `discovery/influencers.md`; include only rows where
+`Include in Discovery` is not `false`, and treat each row's `Reason` as that
+person's lane/adaptation brief. This is different from general search: the
+source set is the person's own recent content.
+
+This is a hard drafting dependency. General hook research, space benchmark
+research, or a single combined "influencer takeaways" paragraph does not satisfy
+the thought-leader step. The research artifact must record the active
+configured list, expected active person count, actual voice variant count,
+missing variants, weak variants, and selected synthesis ingredients. Ready
+drafts require one voice variant per active configured person unless the user
+explicitly opted out or supplied a smaller named subset.
+
+Voice variants must model writing mechanics, not just a broad creator lens.
+Each worker has to define what "in this person's voice" means for this idea:
+target word-count band, line and paragraph rhythm, hook posture, recurring
+phrase families, vocabulary level, proof pattern, formatting habits, close
+style, and normal directness or humor. If multiple creator variants all become
+the same long LinkedIn essay with different labels, mark the lab weak or failed.
+
+Use one bounded background worker per person when the host supports background
+agents. This is required for Codex/Claude hosts that expose background agents or
+Task workers. If the host does not expose a worker mechanism, process the list
+sequentially and record `workerExecutionMode: sequential_fallback` plus the
+reason. Each worker must keep its output compact and must not return a full
+corpus dump or long research report.
+
+Runtime budget:
+
+```text
+per worker target: representative-length post + compact notes
+post variant target: match the creator's normal length for this type of idea
+source samples returned: max 3 URLs
+hook options returned: max 3
+steal/drop notes: max 5 bullets each
+normal wall-clock: one background wave, 6-10 minutes total for 6-10 people
+```
+
+Worker steps:
+
+1. Resolve the person's profile URL or handle from the user input, tracked
+   people, or memory. If the user asked for the configured list, resolve from
+   `discovery/influencers.md` first. If unresolved, ask for the URL/handle.
+2. Fetch recent posts with `mcp__sellable__fetch_linkedin_posts`.
+3. Fetch profile/follower context with `mcp__sellable__fetch_linkedin_profile`
+   when available.
+4. Sample and score the person's recent posts internally by:
+   - topic fit to the user's current idea
+   - hook preview strength
+   - body payoff strength
+   - positioning density
+   - repeated success in the same lane
+   - engagement quality
+   - engagement per 1k followers when follower count is available
+   - adaptation fit for Christian/Sellable voice
+   - lead-magnet, giveaway, and status-only penalties
+5. Build a `voice_model` before drafting. It must infer:
+   - target word-count band and normal variance for similar ideas
+   - paragraph and line rhythm
+   - hook posture and opening moves
+   - vocabulary and recurring phrase families
+   - formatting habits: bullets, numbering, equations, parentheticals, spacing
+   - proof style: story, metric, teardown, confession, field guide, challenge
+   - close style: command, reflection, CTA, punchline, or open loop
+   - factual boundaries that must come from Christian/Sellable
+6. Assume and role-play the person's public LinkedIn voice for a private
+   synthesis variant. This means adopting their likely length, vocabulary,
+   hook tension, pacing, section shape, directness, humor level, proof style,
+   formatting, and editorial instincts.
+7. Write the complete post that this creator would likely write from the user's
+   selected premise and context. Do not compress it into a short generic draft
+   or stretch a short-style creator into a generic long post.
+8. Identify what the final synthesis should steal and what it must drop.
+9. Keep factual claims grounded in the user's context. Do not invent user proof.
+
+Each configured person must receive a full person-specific variant. Do not
+summarize the group as a single "GTM influencers" research pass. The later
+drafting stage should be able to compare how Alex, Zayd, Tas, Anthony, or any
+other configured person would actually write the same Christian idea, then
+combine the strongest pieces.
+
+If a person's recent posts are weak or off-topic, still return a packet with
+`worker_status: weak`, the reviewed post count, a weaker voice variant if
+possible, confidence gaps, and a clear reason the person should not strongly
+influence the final synthesis. If the profile or posts cannot be fetched because
+of a tool failure, record `worker_status: retry_needed` and do not allow a
+`ready` draft.
+
+Worker output:
+
+```text
+Thought leader voice variant:
+person:
+profile_url:
+worker_id_or_label:
+worker_status: pass | weak | retry_needed | blocked
+recent_posts_sampled:
+follower_count: <number | unavailable>
+normalization_confidence: high | medium | low
+voice_model: [max 8 bullets covering target length, rhythm, vocabulary, formatting, proof style, close]
+mechanics_receipt:
+- target_word_count_band:
+- actual_word_count:
+- paragraph_line_rhythm:
+- vocabulary_markers:
+- formatting_markers:
+- close_style:
+- mechanics_match: pass | weak | fail
+hook_options: [max 3]
+post_variant: <complete post in the creator's inferred voice and representative length>
+steal_for_final: [max 5 bullets]
+drop_for_final: [max 5 bullets]
+source_urls_sampled: [max 3]
+confidence_gaps:
+```
+
+The worker may call the private draft "in <person>'s voice" because that is the
+role-play job. The orchestrator must not claim the creator authored it, must not
+copy exact outside wording into the final, and must ground final claims in
+Christian/Sellable context.
+
 ## Blocked States
 
 Local idea capture can still succeed when research fails.
@@ -367,8 +844,9 @@ Save the research with `mcp__sellable__save_hook_research` before drafting.
 
 The saved research must contain enough detail to support a user-visible
 `Research Learning Report`: source examples, full adapted hook blocks, exact
-phrase patterns, body structures, rejected examples, tracked-person
-recommendations, and gold-standard recommendations.
+phrase patterns, post positioning breakdowns, viral-post outlines, reusable
+post templates, hook-to-body promise maps, body structures, rejected examples,
+tracked-person recommendations, and gold-standard recommendations.
 
 If the user approves a creator/person as a recurring inspiration source, also
 call `mcp__sellable__upsert_engage_tracked_person` with: