Article

---
argument-hint: [topic, thesis, or source URLs]
description: Write a long-form article for the website, with image prompts
allowed-tools: AskUserQuestion, WebFetch, WebSearch, Write, Read, Glob, Edit, Bash
---

Write a long-form article based on the user's input, following the established article style.

## Arguments

`$ARGUMENTS` contains free text: URLs, notes, topics, theses, or any combination. Parse it to separate:
- **URLs**: anything starting with `http://` or `https://`
- **Text notes**: everything else (topic, thesis, angle, raw material)

If `$ARGUMENTS` is empty, use AskUserQuestion to ask what the article is about.

## Step 1: Gather source material

1. Read `style/article_style.md` from `style/`. This is the long-form style supplement.
2. Read `style/writing_style.md` from `style/`. This is the primary style authority for voice, tone, and language rules.
3. Read `style/profile.md` from `style/`. This provides vocabulary, topic expertise, and voice patterns.
4. Read `style/taste.md` from `style/`. This is the visual taste profile for image prompts.
5. If URLs were found in the arguments:
   - Fetch each URL using WebFetch
   - Extract: headline, author, main argument, notable quotes, data points
6. Summarize all source material in a brief internal note (do not show to user yet).

## Step 2: Research

If the topic would benefit from supporting data or citations:
1. Use WebSearch to find 3-5 relevant sources: industry reports, academic studies, data points, expert opinions
2. Fetch the most promising results with WebFetch
3. Extract key findings, statistics, and quotable insights
4. Note the sources for inline citation in the article

Articles should be grounded in evidence where possible. The voice is practitioner-first, but data strengthens the argument.

## Step 2.5: Identify the target audience

The audience shapes angle, depth, vocabulary, and visual choices. If the user's notes already specify an audience (e.g., "for engineering leaders", "for PMs"), use it and skip the question.

Otherwise, use AskUserQuestion with these options:
- **Engineering leaders / technical decision-makers** — CTOs, VPs Eng, staff+ engineers. Assume technical depth, skip the 101, lead with architectural tradeoffs and failure modes.
- **Product & business leaders** — PMs, founders, execs. Frame in outcomes, use metaphors over jargon, fewer code details.
- **Generalists / curious professionals** — mixed backgrounds. Explain more, use analogies, avoid unexplained acronyms.
- **Mixed / broad audience** — default LinkedIn reach. Write for the smart non-specialist; technical asides in context, never as the centerpiece.

Remember this choice — it informs angles (Step 3), depth (Step 4), and visuals (Step 5).

## Step 2.6: SERP reality check

Before proposing angles, do a quick SERP read for the topic. The goal is **not** to pick the angle by what ranks — it's to make sure the angle isn't accidentally indistinguishable from what's already on page 1.

1. Pick 1–3 likely search queries a reader interested in this topic might type. Frame them as the reader would, not as the author. Calibrate vocabulary to the audience from Step 2.5.
2. Use WebSearch on each query. Skim the top ~10 results.
3. Capture, in an internal note (not shown to the user yet):
   - **Dominant format**: listicle, how-to, explainer, comparison, opinion essay, case study, news. Which formats own the SERP?
   - **Recurring framings**: what angle does almost every result take? Where do they all agree?
   - **Format gap**: what shape of piece is *missing*? (e.g. all listicles, no opinion piece; all how-tos, no skeptical take.)
   - **Proof gap**: what concrete evidence, examples, or numbers do top results lack?
   - **People Also Ask / related questions** if visible — surface them as candidate FAQ entries later (Step 6 will emit FAQPage JSON-LD if you include a `## FAQ` section).

Carry this into Step 3. The angle should either fill a real gap (format or proof) or earn its place by being a sharper, more specific take than the SERP consensus. If every top result already says what you were going to say, the angle is wrong — pick a different one.

This is a sanity check, not an SEO playbook. Don't warp the voice to match SERP norms; warp the *positioning* so the piece is genuinely additive.

## Step 3: Propose angles and structure

Based on the source material, text notes, research, and the target audience from Step 2.5, propose **2-3 angles** for the article. Each angle should:
- Be 2-3 sentences describing the thesis and approach
- Map to recurring topics from profile.md
- Represent genuinely different perspectives
- Land with the chosen audience — pick a thesis they'll care about, framed in their vocabulary

Use AskUserQuestion to present the angles.

After the user picks an angle, propose a **section-by-section outline**:
- Title + subtitle
- 4-7 section headers with 1-sentence description each
- Expected length range (e.g., "~2,000 words, 8 min read")

Present the outline with AskUserQuestion. Options:
- "Looks good" — proceed to draft
- "Needs changes" — user provides feedback on structure
- "Try different angles" — go back to angle selection

Iterate until the outline is approved.

## Step 3.5: Plan internal links

After the outline is approved and **before drafting**, identify 2–4 candidate internal links the article should weave in naturally. Internal linking is one of the cheapest discoverability levers and is much harder to retrofit cleanly.

1. **Scan existing articles**: list all non-draft article slugs and titles from `content/articles/YYYY/MM/*/article.md`. Glob is fine. For each, read the title and subtitle from frontmatter — that's enough to judge thematic fit.
2. **Scan recent posts**: glob `content/posts/YYYY/MM/*/post.md` from the last ~12 months. Many short-form posts contain the seed of an idea this article expands on; linking back gives them a second life.
3. **Check for matching topic pages**: read `config/site.yaml`