newsletter-ad-writer

name	newsletter-ad-writer
platforms	["cowork","claude-code"]
description	Write ad copy for developer-focused newsletter placements (sponsored links, primary ads, exclusive ads). Use this skill when the user asks to write newsletter ads, create newsletter placements, draft sponsored content for newsletters, write ad copy for developer newsletters, or says 'time for newsletter ads' or 'let's do this week's ads.' Also trigger when the user mentions newsletter ad copy, sponsored link copy, newsletter placement, developer newsletter ads, Cooperpress newsletters, or asks for ads for specific newsletters like Frontend Focus, Node Weekly, JavaScript Weekly, Go Newsletter, Ruby Weekly, Postgres Weekly, or React Status. Handles character-counted copy in developer voice with audience-specific hooks.
references	["product-marketing-context","brand-voice-guide","newsletter-ad-reference"]

Newsletter Ad Writer

Write ad copy for developer-focused newsletter placements. Produces character-counted, developer-voice copy for sponsored links, primary ads, and exclusive ads across Cooperpress and similar technical newsletters. Each ad is tailored to the newsletter's specific developer audience.

When to use this skill

• Writing weekly newsletter ad placements (sponsored links, primary, exclusive)
• Creating ad copy for developer newsletters (Frontend Focus, Node Weekly, JavaScript Weekly, Go Newsletter, Ruby Weekly, Postgres Weekly, React Status, etc.)
• Drafting multiple newsletter ads for the same week
• Refreshing or iterating on existing ad copy

When NOT to use this skill

• Writing the Tiger Data owned newsletter (use newsletter-writer)
• Writing social media posts (use social-post-writer)
• Writing email sequences or drip campaigns (use email-nurture-planner)
• Writing blog posts or long-form content (use brand-voice-writer)

Instructions

Step 0: Pre-flight check

Invoke the marketing-preflight skill via the Skill tool, passing this skill's name: field value (newsletter-ad-writer) as the args. Do not proceed until it completes successfully. If it stops with an error, follow its instructions and stop.

If marketing-preflight returned a stale-connector footer note, append it verbatim at the end of your final response to the user.

Also fetch the No Fly List before doing any work:

get_marketing_reference(slug: "no-fly-list")

This is a list of customers who cannot be publicly referenced. Load these names as a hard constraint: never include any No Fly List customer in any output — not as named examples, proof points, customer quotes, case study references, or any other mention. If the user requests content featuring or referencing a No Fly List customer, stop and inform them that this customer cannot be publicly referenced. If a No Fly List name appears in source material you are working from, omit it from all outputs.

1. Load brand, voice, product, and performance context

Fetch Tiger Den references:

• Always fetch: product-marketing-context, brand-voice-guide, and newsletter-ad-reference using get_marketing_context(slugs: ["product-marketing-context", "brand-voice-guide", "newsletter-ad-reference"]).
• product-marketing-context loads audience personas, positioning, terminology, and proof points.
• brand-voice-guide loads the writing foundation. This skill defers to brand-voice-writer for all voice, tone, and writing quality guidance. Read the "Trade Show Assets / Ads / Social Copy" section for ad-specific guidance: (1) Inspire, grab attention instantly, (2) Drive action, tell them exactly what to do next. One main message, one clear action, graspable in under five seconds.
• newsletter-ad-reference loads newsletter profiles (audience, character limits, recommended angles per newsletter) and historical performance data: newsletter rankings, top-performing ad examples, content theme benchmarks, fatigue signals, and strategic recommendations. Use profiles to tailor ads in Step 4 and performance data to optimize recommendations in Step 5b. If this doc is not available, proceed without it. The skill still writes good ads from brand voice; this doc adds audience targeting and performance optimization.
• Scan proof points in product-marketing-context. Note customer metrics, compression ratios, migration stories, and pull quotes. Specific numbers outperform generic claims.

Freshness checks:

• If product-marketing-context is more than 6 months old, flag it.
• If newsletter-ad-reference is more than 4 months old, flag it: "The performance data was last updated [date]. Consider running /newsletter-ad-review with fresh data to keep recommendations current."

2. Gather the brief

Collect these inputs from the user. Ask for anything not provided:

• Newsletters: Which newsletters are we placing in this week? (e.g., Frontend Focus, Node Weekly, JavaScript Weekly, Go Newsletter, Ruby Weekly, Postgres Weekly, React Status)
• Ad types per newsletter: Sponsored link, primary, or exclusive? (Determines character limits and fields)
• Product focus: Which product or angle? (Default: TimescaleDB time-series unless specified)
• Any specific angle or theme? (e.g., "let's try a real-time dashboard angle for Frontend Focus this week")
• Anything to avoid? (e.g., "we ran the 'slow query' angle last week on JS Weekly, try something different")

If the user provides all of this upfront, skip the questions and proceed to Step 3.

3. Internalize the rules

These rules are non-negotiable. Apply them to every ad:

Character limits (hard caps, no exceptions):

Character limits vary by publisher and ad type. Refer to the newsletter profiles in the newsletter-ad-reference doc for the exact limits per publisher. For quick reference, here are the Cooperpress defaults:

Ad Type	Title	Supporting Text
Sponsored Link	70 characters	120 characters
Primary	60 characters	250 characters
Exclusive	60 characters	250 characters

Always count characters, not words. After drafting every title and supporting text, count the characters and display the count. If over the limit, rewrite before presenting. If the user names a newsletter or publisher not in the profiles file, ask for character limits before drafting.

Developer voice principles:

• Problem-first, not product-first. Lead with recognition ("that's me") or curiosity ("wait, what?"), not features.
• Written like a dev would talk, not a marketer. Stop the scroll with a real problem.
• Audience-specific hooks. Tailor the angle to each newsletter's audience (see Step 4).
• Core narrative: Stay on Postgres. No second database. Pipelines, sync lag, and drift are the real cost.

Terminology and formatting:

• Use "Postgres" not "PostgreSQL"
• Company name: Tiger Data (creators of TimescaleDB)
• URL: https://www.tigerdata.com/timescaledb
• CTA: "Try free" for sponsored links, "Start building for free" for primary/exclusive
• Features land in supporting text, not titles: hypertables, 95% compression, continuous aggregates
• Title and supporting text complement each other (never repeat the same words)
• No em dashes. Use commas, periods, or colons instead.

4. Write audience-specific ads

Each newsletter has a distinct developer audience. Tailor the hook and angle accordingly.

Use the newsletter profiles. Refer to the newsletter profiles in the newsletter-ad-reference doc (loaded in Step 1) for detailed audience descriptions, recommended angles, and hook patterns per newsletter, organized by publisher. Match the user's requested newsletter to the right profile and use its angles and hook patterns as your starting point.

New newsletter or publisher? If the user names a newsletter not in the profiles doc, ask them: (1) Who publishes it? (2) Who reads it? (3) What ad types and character limits does it support? Use their answers to build an audience profile on the fly and write ads using the same developer voice principles. Suggest they add it to the newsletter-ad-reference doc in Tiger Den for future use.

5. Draft the ads

For each newsletter placement, produce:

1. Title with character count
2. Supporting text with character count
3. Company/Service Name: Tiger Data (creators of TimescaleDB)
4. URL: https://www.tigerdata.com/timescaledb

Process per ad:

1. Generate 3-5 title options using different angles from Step 4.
2. For each title, draft supporting text that complements (not repeats) the title.
3. Count characters for every option. Display as: Title (XX chars):
4. Verify all are under the character limit. Rewrite any that exceed it.
5. Select the strongest option as the recommended pick. Present all options so the user can choose.

Title formulas to draw from:

• Developer pain: "Your [thing] Was Fast at Launch. What Happened?"
• Architecture insight: "Adding a Database Is Easier Than Removing One"
• Postgres loyalty: "You Picked Postgres for a Reason. Don't Leave It for Analytics."
• Stack identity: "Go + Postgres. That's the Whole Analytics Stack."
• Specific technical pain: "SELECT COUNT(*) Shouldn't Take 8 Seconds"
• Speed contrast: "Fast APIs Deserve Fast Analytics"
• Challenge the assumption: "That Slow Dashboard? It's Not a Frontend Problem."

Supporting text patterns:

• Problem then solution: State the pain, then how TimescaleDB solves it. End with CTA.
• Extend the narrative: Continue the story the title started. Don't restart with a product pitch.
• Feature proof: After establishing the problem, land 2-3 specific features (hypertables, 95% compression, continuous aggregates) as the solution. End with CTA.

5b. Apply performance insights (if available)

If the newsletter-ad-reference reference was loaded from Tiger Den, use it to inform your recommendation pick:

• Prefer high-performing placement types. If the data shows one ad type significantly outperforms another for this publisher, note it when the user has a choice.
• Favor proven themes and angles. For the recommended pick, lean toward title formulas and content themes that have historically driven strong engagement for that specific newsletter.
• Reference the swipe file. Use the top-performing ad examples as inspiration (not templates). Note what made them work and apply those principles to fresh copy.
• Flag fatigue signals. If the performance data flags a newsletter for fatigue or declining performance, tell the user and suggest varying the angle more aggressively or adjusting cadence.
• Note destination URL patterns. If certain link destinations (product page vs blog) historically perform better, recommend accordingly.

If the performance reference was not available (Tiger Den not connected or doc doesn't exist yet), skip this step. The ads will still be well-written from profiles and brand voice; they just won't be performance-optimized.

6. Present the output

Format each ad as a complete placement block:

## [Newsletter Name] ([Ad Type])

**Recommended:**

- **Title (XX chars):** [Title text]
- **Supporting Text (XXX chars):** [Supporting text]
- **Company/Service Name:** Tiger Data (creators of TimescaleDB)
- **URL:** https://www.tigerdata.com/timescaledb
- [For Primary/Exclusive only] **Image URL:** [TBD]
- [For Primary/Exclusive only] **Masthead Image:** [TBD]

**Alternates:**

1. **Title (XX chars):** [Alternate title 1]
   **Supporting Text (XXX chars):** [Alternate supporting text 1]

2. **Title (XX chars):** [Alternate title 2]
   **Supporting Text (XXX chars):** [Alternate supporting text 2]

Separate each newsletter with a horizontal rule.

7. Brand voice cross-check

After drafting all ads, review against the brand voice guide (loaded in Step 1 via brand-voice-writer's foundation). Apply the full voice and terminology checks from that guide, plus these ad-specific checks:

1. Character limits. Re-verify every title and supporting text is under the limit. This should have been enforced during drafting. If any are over, rewrite now.
2. Problem-first. Every title should lead with a developer pain or insight, not a product name or feature.
3. No repetition between title and supporting text. Flag and fix any ads where the title and supporting text use the same key phrase.
4. No marketing fluff. Remove "revolutionary," "game-changing," "cutting-edge," or vague superlatives. Replace with specific claims.

Fix issues inline. If no issues are found, state "No voice issues found."

8. Log the placements

After the user confirms the final ads, offer to append them to the newsletter ads log. If the user has a log file, format the entries following the existing log structure (week header, newsletter sections with all fields).

Quarterly maintenance

The performance data, swipe file, and newsletter profiles should be refreshed quarterly when new publisher reports are available. Use /newsletter-ad-review to process new data and update the Tiger Den newsletter-ad-reference doc (which contains both profiles and performance data).

Tiger Den tools used

• get_marketing_context -- fetch product-marketing-context, brand-voice-guide, and newsletter-ad-reference (Step 1)
• search_content -- find recent blog posts, case studies, or benchmarks to reference in ad copy if a proof-point angle is needed

Output format

Present everything directly in chat as structured Markdown. Do not create files unless the user requests it.

Include this note at the end: "To adjust any ad, tell me what to change. I can try different angles, swap titles between alternates, or rewrite for a different audience."

Hand-off

After the ads are confirmed, offer to:

• Run de-slop if any ads feel AI-generated
• Log the placements to the team's newsletter ads log
• Create social posts to complement the newsletter campaign (using social-post-writer)

Do not auto-trigger other skills. Wait for the user to confirm the output looks good first.