Departments / marketing / content-writer

content-writer

Use when a marketer gives you a content brief (topic, audience, goal, length) and needs a publish-ready blog post, case study, or whitepaper. Produces a structured draft with hook, thesis, scannable body, CTA, and meta description in the brand voice defined in references/brand-voice-guide.md.

Department

Marketing

Safety

writes-local
Writes locally

Supported stacks

Stack-agnostic — no detection required.

When to use

Trigger this skill when the request includes any of:

Do not use for short social copy (use social-media), email sequences (use email-campaign), or landing pages without a narrative structure.

Inputs

Required:

Optional:

Outputs

A single Markdown document containing:

  1. Title — sentence case, ≤60 characters where possible.
  2. Meta description — 140-155 characters, includes the primary keyword and a clear value statement.
  3. Hook — first 2-3 sentences that set tension and earn the scroll.
  4. Thesis — one line stating the argument or takeaway.
  5. Body — H2/H3 hierarchy, paragraphs ≤3 lines, at least one concrete example, one data point or source, and one visual suggestion (diagram/screenshot/pull-quote).
  6. CTA — one sentence + link. Never more than one primary CTA.
  7. Author note — 2-3 bullet points on what was cut, what assumptions were made, and which claims need a source check.

Tool dependencies

Procedure

  1. Parse the brief. Extract topic, audience, goal, length. If any of the four are missing, ask once before drafting. Do not guess the audience.
  2. Load the brand voice guide. Read references/brand-voice-guide.md in full. Note the do/don’t vocabulary list and the style rules.
  3. Pick the structure by format:
    • Blog post: hook → thesis → 3-5 body sections → CTA.
    • Case study: situation → problem → approach → result (with ≥1 number) → quote → CTA.
    • Whitepaper section: executive summary → claim → evidence → counter-argument → implication.
  4. Draft the hook. Lead with a specific tension, number, or observation — never with “In today’s fast-paced world” or similar. Hook must make the thesis feel necessary.
  5. Write the body. Use H2 for major sections, H3 for sub-points. Keep paragraphs to 3 lines max on desktop. Every section needs an example, a data point, or both.
  6. Write the CTA. One action, written as the reader’s next logical step, not as a sales line. “Read the docs for the v2 migration” beats “Learn more today!”
  7. Write the meta description last. 140-155 chars, primary keyword near the front, includes the payoff.
  8. Run the quality checks below. Fix before returning.

Examples

Example 1: Blog post brief

Input:

Topic: Why platform teams are replacing internal developer portals with paved roads
Audience: Platform engineering leads at 200-1000 person SaaS companies
Goal: Educate + rank for "internal developer portal alternatives"
Length: 1,400 words
Primary keyword: internal developer portal alternatives

Output (abridged):

# The paved road is beating the portal. Here is why.

**Meta description:** Internal developer portals promise self-service. Paved roads deliver it.
Here is what platform teams learned after two years of running both.

Every platform team we talk to installed a developer portal in 2023. A year later, most
of them are quietly deprecating it. The portal was never the product — the paved road was.

## The portal promised self-service. Paved roads delivered it.

[H3: What a paved road actually is]
[H3: Where the portal model broke]

## Three signs your portal is becoming a museum
...

**Next step:** Read our paved-road reference architecture in the docs.

Author note:

Example 2: Case study brief

Input:

Topic: Ramp cut CI time 62% after moving from Jenkins to Northstack runners
Audience: Heads of DevEx at fintech and SaaS
Goal: Support sales conversation for Series C-D accounts
Length: 900 words

Output (abridged):

# Ramp cut CI time by 62% without rewriting a single pipeline

**Meta description:** Ramp's developer experience team replaced Jenkins with Northstack
runners in eight weeks. The result: 62% faster CI and zero pipeline rewrites.

When Ramp's platform team sat down in January, the CI queue was 14 minutes deep at peak...

## Situation
## The problem: queue depth, not compute
## The approach: swap the runner, keep the pipelines
## The result: 62% faster, 40% cheaper
> "We expected to rewrite. We rewrote nothing." — Priya Shah, Staff Platform Engineer

**Next step:** See the migration playbook.

Author note:

Constraints

Quality checks

Before returning the draft, confirm:

Customise for your organisation

content-writer

The LLM will rewrite this skill for your environment. Your API key and form inputs stay in your browser — only the skill and your environment go to OpenRouter.

One line. Be specific — cloud, language, framework, orchestrator.

Free text that steers the rewrite. Leave blank if nothing specific.

cost estimate: