tease-newsletter

name	tease-newsletter
description	Use when user wants to promote a beehiiv newsletter on social media with teaser-style hooks (rather than verbatim quotes) that summarize the article without giving away the punchline — "tease this newsletter", "write teasers for the newsletter", "summarize and promote", "hook posts for the article". Each post ends with the standard "Comment newsletter…" CTA so commenters get the article DM'd to them.
user_invocable	true

tease-newsletter

Sibling to promote-newsletter. Instead of pulling verbatim snippets from the article, this skill writes short, original teaser hooks per channel that summarize the piece in a curiosity-gap style and end with the standard CTA.

The CTA is identical to promote-newsletter so the same Manychat / DM automation works:

Comment "newsletter" to get my latest post, "<Article Title>"

When to Use

Use when:

• User says "tease this newsletter", "write teasers for...", "promote with hooks", "summarize and promote", "do tease-newsletter on..."
• The article is going to LinkedIn (any kind — page or personal). LinkedIn data 2026-04-27: top 3 posts past 7 days were 0% verbatim quotes; the LinkedIn pulse accompanying post (essentially a teaser) ranked #1 by impressions within hours. Teasers outperform verbatim quotes on LinkedIn by a wide margin. Default to /tease-newsletter for LinkedIn channels and /promote-newsletter for short-form (Threads/Bluesky/Mastodon) where verbatim quotes still work.
• The article has been promoted already with verbatim snippets and the user wants a second wave with a different angle
• The article's strongest snippets are too long, too inside-baseball, or too punchline-heavy to quote raw

Do NOT use when:

• User wants verbatim quotes for short-form Threads/Bluesky/Mastodon → use promote-newsletter
• User wants full-article syndication on LinkedIn/Substack/Medium/HN/Reddit → use crosspost-newsletter
• User wants illustrated carousels → use carousel-newsletter

🟢 Happy Path (read first; everything below is edge-case detail)

For a beehiiv newsletter teaser run when nothing goes wrong. ~10-15 min wall-clock. Linear steps from invocation to scheduled posts.

Phase 1 — Content + voice (1-2 min). If URL provided, WebFetch the beehiiv post (title, subtitle, body, image URLs). If "latest", fetch the beehiiv RSS feed from reference_beehiiv_feed.md and ask the user which article. Run _shared/voice-corpus/voice-corpus to pull the voice corpus JSON (auto-refreshes if cache > 7 days). Hold the corpus for Phase 4.

Phase 2 — Outline angles (1-2 min). Read the article. Identify the single punchline (withheld), 3-5 angles, the emotional/intellectual payoff (withheld), and concrete nouns/numbers/metaphors worth name-dropping. Check the Buffer queue for existing posts about this article and annotate each angle with ✅ new or ⚠️ overlaps. Present the outline to the user.

Phase 3 — User picks ONE angle (1 min). Single AskUserQuestion (single-select, not multi-select): pick one angle, image distribution, and tease style (curiosity-gap / provocation / personal-story). Wait for the pick. One angle for all channels — length-adapt only, never angle-vary.

Phase 4 — Compose teasers (3-5 min). Prepend the voice corpus inline in working context as the author's recent newsletters. Write the chosen angle at the longest applicable length (LinkedIn/Instagram). Derive shorter platform versions by length-trimming the same message — same hook, same setup, same withheld punchline. Per-platform budget = hard limit − CTA length − 7 margin (table in Phase 4). End every post with the exact CTA: Comment "newsletter" to get my latest post, "<Article Title>". No emoji unless requested. No contiguous 7-word run from the source article. Default hero-image priority: LinkedIn (page) → LinkedIn (personal) → Instagram → Facebook → Threads. Skip Instagram if no image; skip TikTok/YouTube.

Adversarial review (REQUIRED). Run _shared/adversarial-review/adversarial-review per Phase 4's spec (source article prepended with Publication: Enterprise Vibe Code). Must return all_pass before scheduling.

Phase 5 — Review (1-2 min). Show each drafted post per channel with char count vs budget, image attachment, and CTA. Ask: "Ready to schedule these to Buffer?"

Phase 6 — Schedule to Buffer (1-2 min). Adversarial review must have returned all_pass. mcp__buffer__get_account → org ID + timezone. mcp__buffer__list_channels → filter out isDisconnected, isLocked, service: "startPage", channels below min_followers_to_promote=50. Per approved post: mcp__buffer__create_post with mode: "addToQueue", schedulingType: "automatic", tagIds: [<format:teaser>] (via _shared/buffer-post-prep), platform-specific metadata. Report per-channel success/error.

Process

Phase 1 — Fetch Newsletter Content + Voice Corpus

Same as promote-newsletter Phase 1:

• If URL provided: WebFetch the beehiiv post, extract title, subtitle, body paragraphs, image URLs.
• If "latest" or no URL: fetch the beehiiv RSS feed (URL stored in memory reference_beehiiv_feed.md), list recent articles, ask the user which one.

Also fetch the voice corpus (recent newsletters, used as voice reference in Phase 4):

_shared/voice-corpus/voice-corpus  # auto-refreshes if cache > 7 days old

Output is JSON with posts: [{title, url, published_at, source_type, body_text}] (source_type = newsletter or youtube_live). Hold onto this output for Phase 4. See PATTERNS.md#pattern-voice-grounding-for-original-copy-generation for the rationale.

Use body_text as-is in Phase 4 prompts — do NOT add a second truncation (no body_text[:N] inline). The binary already caps each post per its config. Stacking a second truncation strips signal silently. See _shared/voice-corpus/README.md § Consumers.

Phase 2 — Identify the Hook Material (no quoting yet)

Read the whole article and identify:

• The single strongest insight or claim (the "punchline" — this gets withheld in teasers)
• 3–5 angles the article approaches the topic from (each angle becomes a candidate teaser)
• The emotional/intellectual payoff the reader gets at the end (also withheld)
• Any concrete numbers, names, or vivid metaphors worth name-dropping in the tease

Present the article's structure to the user as a brief outline:

Article: "<Title>"
Punchline withheld: <one-line summary of the takeaway>
Angles available:
  A) <angle> — could tease as "..."
  B) <angle> — could tease as "..."
  C) <angle> — could tease as "..."
  D) <angle> — could tease as "..."

Also: check the Buffer queue for existing posts from this article (same procedure as promote-newsletter Phase 2). Annotate each angle with ✅ new or ⚠️ overlaps existing queued post about <subject> so the user can avoid duplicate angles.

Phase 3 — User Picks ONE Angle (then we adapt to length)

The workflow is: present angles → user picks ONE → fit that single message to each platform's length. The user's job is to choose the angle. Your job is to length-adapt — never to angle-vary.

Concretely:

1. Present the 3–5 angles from Phase 2 to the user with a one-line preview tease for each. Use AskUserQuestion (single-select, NOT multi-select) so the UI forces a single pick.
2. Wait for the user to select exactly one angle.
3. Also ask in the same prompt:
   • Which image attaches where (default: hero image on the highest-priority channel — see priority order below)
   • Tease style preference: curiosity-gap ("Here's what I learned about X — and why it surprised me"), provocation ("Most people get X wrong. Here's why."), or personal-story ("I bought a $200 paperweight last week.")
4. In Phase 4, write that one chosen angle as the canonical message at the longest applicable length (LinkedIn/Instagram). Then for shorter platforms, derive a length-trimmed version of the SAME message — same hook, same setup, same withheld punchline — just compressed. Don't introduce new content, new angles, or new framings in the shorter versions.

Banned in this phase: asking the user "would you like different angles for different platforms?" That escape hatch is the source of the per-channel-variation antipattern. Only honor that request if the user volunteers it explicitly and unprompted.

Unattended-mode fallback: If running unattended (e.g. /loop, autonomous run, or no human reviewer): pick the strongest single angle from Phase 2 and use the curiosity-gap style as default. Apply that one message to all channels with length adaptation only — do NOT auto-vary angles per channel. Proceed without waiting.

Phase 4 — Compose Teaser Posts

VOICE GROUNDING (read this BEFORE writing any draft):

Before composing, prepend the Phase 1 voice-corpus output as inline excerpts in your working context, framed as:

The author's recent newsletters (full corpus from beehiiv RSS — all available, ~12 posts and ~24k chars):

[for each post in the corpus] (<published_at>): <body_text>

The drafts you produce MUST sound like a continuation of this voice. Match:

• Sentence rhythm — typically short-to-medium with the occasional intentional fragment
• Vocabulary preferences — specific phrases the author actually uses (avoid LinkedIn-corporate-speak unless the author uses it)
• Recurring framings — e.g. "vibe coding", "agentic", "tokens from our past", "compounding taste"
• First-person stance — "I" not "you should"
• Tone — slight irreverence + grounded practicality + first-hand observation

Mismatched voice is a fail signal — same weight as a fabrication. A draft that's factually correct but reads as generic LinkedIn copy fails this rule and must be rewritten. See PATTERNS.md#pattern-voice-grounding-for-original-copy-generation.

CRITICAL RULES:

1. No contiguous run of 7+ words may be copied directly from the article. This is the verbatim rule, applied mechanically: take any 7-word substring from your draft and grep the article for it — must return zero matches. Teasers are original copy that summarize and intrigue. (This applies to the SOURCE article, not the voice corpus — voice excerpts are reference material, not source to be repeated either.)
2. Do NOT spoil the punchline. The reader's payoff for clicking through (or commenting "newsletter") is the actual insight. If the tease gives it away, the CTA fails.
3. Stay faithful to the article. Don't invent claims the article doesn't make. Don't promise insights the article doesn't deliver. Hooks summarize, they don't fabricate. Specifically banned: unverifiable third-party claims like "every leader I respect does X", "everyone in [industry] knows Y", "successful founders all keep Z on their desk". These are appeals-to-authority that the article does not back up — they sound generic and they are factually unverifiable. Stick to first-person observations the writer can stand behind.
4. No emoji unless the user requests it. Match the sibling promote-newsletter convention.
5. End every post with the exact CTA, blank line above:

   Comment "newsletter" to get my latest post, "<Article Title>"
   

Character budgets (CTA is ~70–95 chars depending on title; calculate per article):

Definition: "Total post budget" is the whole-post character count, including the tease body, the blank line, and the CTA. The 7-char margin is safety against off-by-one issues with the platform's hard limit. Stay under the budget — not just under the hard limit.

Platform	Hard limit	Total post budget
Twitter/X	280	280 - CTA length - 7 margin
Bluesky	300	300 - CTA length - 7 margin
Pinterest	300	300 - CTA length - 7 margin
Threads	500	500 - CTA length - 7 margin
Facebook	500	500 - CTA length - 7 margin
Mastodon	500	500 - CTA length - 7 margin
Instagram	2,200	2,200 - CTA length - 7 margin
TikTok	2,200	2,200 - CTA length - 7 margin
LinkedIn	3,000	3,000 - CTA length - 7 margin

Recommended tease shapes by platform:

• Threads / Twitter / Bluesky: 1–3 short lines. Lead with the hook, don't bury it. Pattern: <curiosity statement>. <stake / why-care>. <implicit promise of payoff>.
• Facebook: 2–4 lines. Conversational. Allow a personal frame ("Spent $200 on a paperweight this week...").
• LinkedIn: 3–6 short paragraphs (each 1–3 lines). Open with a hook, set up the topic, hint at the takeaway, withhold the conclusion. End with the CTA.
• Instagram: Long-form is welcome (caption can be 3–8 short paragraphs). The hero image carries the visual; the caption tells the story up to but not past the punchline.

Media attachment: Same Buffer dedupe rules as promote-newsletter — each unique image URL can only be used on one post in the queue. Ask the user how to distribute available images across the channels.

Default hero-image priority order (when the user doesn't specify): LinkedIn (page) → LinkedIn (personal) → Instagram → Facebook → Threads. The hero is the article's strongest visual; it goes to the highest-priority channel with image capacity. Instagram is forced into the list because it requires an image — if no image is available for IG, skip the IG post entirely.

Skip Instagram if no image is available for it. Skip TikTok / YouTube channels (video required).

Adversarial review (REQUIRED before user review)

Apply the Adversarial Review pattern with these per-skill specifics:

• SOURCE_LABEL: "SOURCE ARTICLE"
• SOURCE_CONTENT: the full beehiiv article body, verbatim. Prepend a Publication: Enterprise Vibe Code line above the title so reviewers know the publication name is in scope (strict reviewers like agy treat the article body as a whitelist; without this prepend they may flag the publication name as fabrication).
• SKILL_NAME: tease-newsletter
• ARTIFACT_NAME: "teaser"
• RULES_LIST:
  • Teasers are ORIGINAL copy that summarize without spoiling the punchline.
  • BANNED: any contiguous run of 7+ words copied from the source verbatim. Run a sliding window check.
  • BANNED: unverifiable third-party claims ("every leader I respect keeps a token on their desk", "everyone in [industry] knows…", "successful founders all do X").
  • BANNED: claims the article doesn't actually make (fabrication).
  • BANNED: spoiling the punchline (the reader's payoff for clicking through).
  • BANNED: emoji unless explicitly requested.
  • REQUIRED: every post ends with the canonical CTA (use _shared/cta.sh "<Article Title>").
  • REQUIRED: same core message across all channels — only length adapted, not angle.
  • REQUIRED: total post char count within platform budget (e.g. Threads = 500 - CTA - 7 margin).
• ISSUE_GUIDANCE: "For verbatim drift, quote the 7+ word run that matches source. For fabrication, quote the claim and explain what the source actually says. For punchline spoilage, quote the line that gives away the takeaway. For unverifiable claims, quote the third-party assertion."

The first time this skill ran on "Tokens From Our Past" (2026-04-26), the user caught a fabrication ("Every leader I respect keeps a token from a past reskilling on their desk") manually. This phase prevents that next time.

Phase 5 — Review Before Publishing

Present all drafted teasers for approval:

Channel: @handle (LinkedIn page)
Post (412/3000 chars):
---
<teaser body>

Comment "newsletter" to get my latest post, "<Article Title>"
---
Image: <URL or "text-only">

Repeat per channel. Highlight any line that the user might consider "too close to a verbatim quote" or "too revealing of the punchline" — let them edit before scheduling.

Ask: "Ready to schedule these to Buffer?"

Phase 6 — Schedule to Buffer

🔒 HARD GATE — adversarial review must have returned summary == "all_pass" before this phase.

If the prior _shared/adversarial-review/adversarial-review run returned some_fail for any draft in this batch, you MUST NOT call mcp__buffer__create_post for that draft. Iterate fixes per the round cap (5 rounds max), then surface deadlocks to the user. Spot-checking claims manually does NOT substitute.

Identical to promote-newsletter Phase 6 (including the min_followers_to_promote, ask-user-up-front fan-out level (1/ch, 3/ch, or all-snippets/ch), and below-threshold/locked channel filters):

1. mcp__buffer__get_account → org ID + timezone
2. mcp__buffer__list_channels → exact channel IDs (filter out isDisconnected, isLocked, service: "startPage", channels below min_followers_to_promote=50)
3. Per approved post: mcp__buffer__create_post with mode: "addToQueue", schedulingType: "automatic", tagIds: [<format:teaser Tag ID>] (24-char hex from _shared/buffer-post-prep/tag-ids.local.json — Buffer's CreatePostInput schema requires Tag IDs, not tag-name strings; tags: [...] is silently dropped), platform-specific metadata (facebook.type: "post", instagram.type: "post" + shouldShareToFeed: true, etc.). Use _shared/buffer-post-prep to do the lookup; one-time tag setup in _shared/buffer-post-prep/README.md.
4. On HTTP 429 rate limit: stop, save remaining posts to remaining-posts.md, report.
5. Report per-channel success/error.

Tease-Writing Checklist (apply to every draft before showing the user)

• Opens with a hook. First sentence ≤ 12 words preferred. Never opens with: "In this post", "Today I want to talk about", "I've been thinking about", "Here's what I learned", "Just shipped", or any other warmup formula.
• Names a concrete object, number, or vivid noun from the article (specificity = credibility).
• Sets up a question or tension the reader wants resolved.
• Does NOT answer that question.
• No contiguous run of 7+ words is copied directly from the article. (Check by sliding a 7-word window across the draft and grepping the source.)
• No emoji (unless the user requested them).
• Ends with the exact CTA and the article title in quotes.
• Whole-post character count (tease body + blank line + CTA) is within the platform's total post budget from the table above.
• No unverifiable third-party claims ("every leader I respect…", "everyone in [industry] knows…", "successful founders all do X"). First-person only, or claims the article itself supports.
• Same core message as the other channels' posts (length-adapted, not angle-varied) — unless the user explicitly asked for per-channel variations.

Common Mistakes

• Per-channel angle variations by default. The temptation to "use the long-form room on LinkedIn for a different angle than Threads" produces a feed where each channel sounds like a different person promoting a different article. One message, length-adapted, is the right default. Only vary angles when the user explicitly asks for it.
• Unverifiable third-party claims. Lines like "every leader I respect keeps a token on their desk" sound generic and aren't backed by the article. They're appeals-to-authority that won't survive a reader thinking "no they don't." Stick to first-person observations the writer can stand behind.
• Spoiling the punchline. The reader has no reason to click/comment if the post already delivered the insight. Cut the conclusion sentence.
• Vague teases ("interesting thoughts on AI"). Specificity drives clicks. Name the object, the metaphor, the concrete event.
• Verbatim drift. Easy to slip into quoting when paraphrasing. Apply the checklist's "no contiguous run of 7+ words copied" rule mechanically — slide a 7-word window across your draft and grep the article.
• Confusing the budget with the hard limit. A 459-char Facebook post is under the 500 hard limit but over a 402-char total budget. Compute the budget; don't eyeball the hard limit.
• Forgetting the queue check. A teaser angle that overlaps a queued snippet from the same article doubles up the feed. Use the same Buffer queue check pattern as promote-newsletter.
• One-size-fits-all length. A LinkedIn-length tease pasted onto Threads reads like a wall of text; a Threads-length tease on LinkedIn reads thin. Length-match per platform — length only, not angle.
• Invented specifics the source only entails. The adversarial panel's #1 teaser FAIL mode (4-round convergence on "I turned 35… B2B SaaS", 2026-06-19): stating a numeric/duration horizon the article doesn't literally write, even one it entails. The source said "wrestling since 8th grade" + "black belt this year" (entails >a decade) and framed goals as "before 36" (~1 year) — but the drafts' "One I trained in for over a decade" and "planning the next ten years" both got FAILed by the strict reviewers (composer-2.5, grok-build) as fabricated specifics while the lenient ones passed (FAIL-OR gate → blocked). Default to qualitative framing ("a sport I've trained in for years", "got serious about recently"). A number in a teaser must be lifted faithfully from the source, never inferred.
• The shortest variant spoils the punchline most easily. Compressing to Threads length tempts you to resolve the tension to land the line — the first short draft said "…it might be the whole point", which stated the article's reframe. Hold the SAME open gap in every length: the short version must withhold exactly what the long one does (e.g. "until a reframe flipped it, and one priority rose above both" — names that a priority exists, never which).

Worked Example

Input: /tease-newsletter https://www.enterprisevibecode.com/p/tokens-from-our-past-and-the-great-re-why-ing

Phase 2 outline:

Article: "Tokens From Our Past and The Great Re-Why-ing"
Punchline withheld: Disruption-induced identity loss becomes fuel when you re-derive
  your "why" around enabling others rather than personal mastery — and that same
  re-why-ing is what AI-era developers need now.
Angles available:
  A) Career-pivot artifact (the $200 Mac Pro on the desk)
  B) Cattle-not-pets / Xserve history (last forced reskill)
  C) Jiu-jitsu retirement parallel (12 years, brown belt, 2025)
  D) "Single nine" of Claude reliability (March 2026, ~90% uptime)

Phase 4 — Threads (EVC), angle D, provocation style, 290 chars:

Claude posted a single nine of reliability in March 2026. That is roughly 90% uptime.

The wrong reaction is to retreat to the old workflow. The right reaction has a name, and it is not "wait it out."

Comment "newsletter" to get my latest post, "Tokens From Our Past and The Great Re-Why-ing"

Checklist annotation for that post:

• ✅ Hook ≤ 12 words: "Claude posted a single nine of reliability in March 2026." (10 words)
• ✅ Concrete: "single nine", "March 2026", "90%"
• ✅ Tension: what is the right reaction? Named ("has a name") but not described.
• ✅ Withholds: the actual right reaction is the article's payoff.
• ✅ No 7-word verbatim run from source.
• ✅ No emoji.
• ✅ CTA exact, with title in quotes.
• ✅ 290 / 402 budget (Threads 500 - 91 CTA - 7 margin = 402). Within budget.

References

• Sibling skill (verbatim version): /Users/mikelady/dev/claude-social-media-skills/promote-newsletter/SKILL.md
• CTA convention, Buffer dedupe rule, channel filtering: see promote-newsletter Phase 4 + Phase 6
• Memory: project_channels.md (no X), reference_beehiiv_feed.md (RSS feed URL)