content-writer
Research topics and write content like blog posts, articles, and marketing copy. Use when a user asks to write a blog post, create an article, draft marketing copy, write website content, create a newsletter, produce thought leadership content, or write any long-form or short-form copy.
What this skill does
# Content Writer
## Overview
Research topics and produce polished written content across formats: blog posts, articles, marketing copy, landing page text, newsletters, and more. Adapts writing style to audience, purpose, and brand voice. Focuses on clarity, engagement, and actionable value for the reader.
## Instructions
When a user asks you to write content, follow these steps:
### Step 1: Define the content brief
Clarify these elements before writing:
| Element | Question to Answer |
|---------|-------------------|
| Format | Blog post, article, landing page, ad copy, newsletter? |
| Audience | Who is reading this? What do they already know? |
| Goal | Inform, persuade, entertain, convert? |
| Tone | Technical, conversational, authoritative, playful? |
| Length | Short (300-500), medium (800-1200), long (1500-2500)? |
| Keywords | Any SEO terms or phrases to include? |
| CTA | What should the reader do after reading? |
If the user does not specify these, infer reasonable defaults and state your assumptions.
### Step 2: Research and outline
1. **Research the topic** — gather key facts, statistics, and angles
2. **Identify the hook** — what makes this worth reading right now?
3. **Create an outline:**
```
Title: [Compelling, specific headline]
Hook: [Opening that grabs attention - question, stat, or bold claim]
Section 1: [Setup - establish the problem or context]
Section 2: [Core content - main insights, steps, or arguments]
Section 3: [Evidence - examples, data, case studies]
Section 4: [Practical takeaway - what the reader can do now]
CTA: [Clear next step for the reader]
```
### Step 3: Write the content
**Opening (first 2-3 sentences):**
- Start with a hook: surprising statistic, provocative question, or relatable scenario
- Establish why the reader should care
- Preview what they will learn or gain
**Body paragraphs:**
- One idea per paragraph, 3-5 sentences each
- Use subheadings every 2-3 paragraphs for scannability
- Include concrete examples, numbers, and specifics
- Break up text with bullet points, bold key phrases, and short sentences
**Closing:**
- Summarize the key takeaway in 1-2 sentences
- End with a clear call to action
- Leave the reader with something to think about or do
### Step 4: Edit and polish
- Cut filler words ("very", "really", "basically", "actually")
- Replace passive voice with active voice
- Ensure every paragraph earns its place — if it does not advance the point, cut it
- Verify any claims or statistics are reasonable
- Read the opening — would you keep reading?
## Examples
### Example 1: Technical blog post
**User request:** "Write a blog post about why teams should adopt TypeScript"
**Output structure:**
```markdown
# Why Your Team Should Switch to TypeScript in 2025
Your JavaScript codebase is a ticking time bomb. Every `undefined is not
a function` error in production proves it. Here's why TypeScript is worth
the migration cost.
## The Problem with JavaScript at Scale
[2 paragraphs on pain points: runtime errors, refactoring fear,
onboarding friction]
## What TypeScript Actually Gives You
### Catch Bugs Before They Ship
[Example of a type error caught at compile time vs. production]
### Refactor with Confidence
[Example of renaming a field across 200 files safely]
### Self-Documenting Code
[Example of types replacing outdated JSDoc comments]
## The Migration Path
[3-step practical approach: strict mode off, gradual conversion,
enable strict]
## The Bottom Line
TypeScript is not about types. It is about building software you can
change without breaking. Start with one module. You will not go back.
```
### Example 2: Marketing landing page copy
**User request:** "Write copy for a project management tool landing page"
**Output:**
```markdown
# Hero Section
**Headline:** Ship projects on time. Every time.
**Subhead:** The project management tool that replaces your spreadsheets,
standups, and status meetings.
**CTA:** Start free trial
# Problem Section
**Headline:** Sound familiar?
- Tasks falling through the cracks
- "What's the status?" messages all day
- Deadlines that keep moving
- Spreadsheets no one updates
# Solution Section
**Headline:** One place for everything
[3 feature blocks with headline + 1-sentence description + icon]
# Social Proof
**Headline:** Trusted by 2,000+ teams
[3 short testimonials]
# Final CTA
**Headline:** Stop managing chaos. Start shipping.
**CTA:** Get started free — no credit card required
```
### Example 3: Newsletter edition
**User request:** "Write a weekly newsletter about AI for developers"
**Output structure:**
```markdown
Subject: [Specific hook about this week's top story]
# [Newsletter Name] — Issue #42
## The Big Story
[3-4 paragraph deep dive on the week's most important AI development]
## Quick Hits
- **[Tool/Launch]:** [1-sentence summary with link]
- **[Research]:** [1-sentence summary with link]
- **[Tutorial]:** [1-sentence summary with link]
## Code Corner
[Short practical tip or code snippet developers can use today]
## One More Thing
[Interesting aside, prediction, or question for readers]
```
## Guidelines
- Write for humans, not search engines. Good content ranks because people read and share it.
- Every piece needs a clear angle or thesis. "Here's everything about X" is not an angle. "Why X is broken and how to fix it" is.
- Use specific numbers and examples over vague claims. "Reduced load time by 2.3 seconds" beats "significantly faster."
- Front-load value. The reader should get something useful within the first 3 paragraphs.
- Avoid jargon unless writing for an expert audience. If you must use technical terms, explain them.
- Vary sentence length. Short sentences create urgency. Longer sentences provide explanation and nuance. Mix them.
- Subheadings should be informative, not clever. The reader scanning headings should understand the full article.
- Always end with a clear next step. Do not let the reader finish and wonder "so what?"
- Match the brand voice if the user provides examples or guidelines. Consistency matters more than flair.
Related in Writing & Docs
jax-development
IncludedUse this skill when the user is writing, debugging, profiling, refactoring, reviewing, benchmarking, parallelising, exporting, or explaining JAX code, or when they mention JAX, jax.numpy, jit, grad, value_and_grad, vmap, scan, lax, random keys, pytrees, jax.Array, sharding, Mesh, PartitionSpec, NamedSharding, pmap, shard_map, Pallas, XLA, StableHLO, checkify, profiler, or the JAX repo. It helps turn NumPy or PyTorch-style code into pure functional JAX, fix tracer/control-flow/shape/PRNG bugs, remove recompiles and host-device syncs, choose transforms and sharding strategies, inspect jaxpr/lowering/IR, and benchmark compiled code correctly.
nature-article-writer
IncludedDrafts, rewrites, diagnostically critiques, and style-calibrates primary research manuscripts for Nature and Nature Portfolio journals. Use when the user wants a Nature-style title, summary paragraph or abstract, introduction, results, discussion, methods, figure legends, presubmission enquiry, cover letter, reviewer response, or when a scientific draft sounds generic, jargon-heavy, structurally weak, or AI-ish and needs precise, broad-reader-friendly prose without inventing data, analyses, or references. Best for primary research articles and letters rather than reviews or press releases unless explicitly adapting one.
deckrd
IncludedDocument-driven framework that derives requirements, specifications, implementation plans, and executable tasks from goals through structured AI dialogue. Use when user says "write requirements", "create spec", "plan implementation", "derive tasks", "structure this feature", "break down into tasks", or "document this module". Also use for reverse engineering existing code into docs (/deckrd rev). Do NOT use for direct code writing — use /deckrd-coder after tasks are generated. Do NOT use when the user only wants to run or fix existing code without planning.
clinical-decision-support
IncludedGenerate professional clinical decision support (CDS) documents for pharmaceutical and clinical research settings, including patient cohort analyses (biomarker-stratified with outcomes) and treatment recommendation reports (evidence-based guidelines with decision algorithms). Supports GRADE evidence grading, statistical analysis (hazard ratios, survival curves, waterfall plots), biomarker integration, and regulatory compliance. Outputs publication-ready LaTeX/PDF format optimized for drug development, clinical research, and evidence synthesis.
handling-sf-data
IncludedSalesforce data operations with 130-point scoring. Use this skill to create, update, delete, bulk import/export, generate test data, and clean up org records using sf CLI and anonymous Apex. TRIGGER when: user creates test data, performs bulk import/export, uses sf data CLI commands, needs data factory patterns for Apex tests, or needs to seed/clean records in a Salesforce org. DO NOT TRIGGER when: SOQL query writing only (use querying-soql), Apex test execution (use running-apex-tests), or metadata deployment (use deploying-metadata).
accelint-ac-to-playwright
IncludedConvert and validate acceptance criteria for Playwright test automation. Use when user asks to (1) review/evaluate/check if AC are ready for automation, (2) assess if AC can be converted as-is, (3) validate AC quality for Playwright, (4) turn AC into tests, (5) generate tests from acceptance criteria, (6) convert .md bullets or .feature Gherkin files to Playwright specs, (7) create test automation from requirements. Handles both bullet-style markdown and Gherkin syntax with JSON test plan generation and validation.