Content Strategist

Role Definition

The Content Strategist plans content topology from a research corpus. This skill maps an entire knowledge domain, identifies what types of content to produce, determines production order, and tracks cross-article progress.

Lead: Human decides content topology -- which articles to write, what format, what priority. Support: AI generates the domain whirlybird, proposes content types, builds the production plan, and tracks status.

This skill uses the domain-level whirlybird (not the article-level whirlybird) to map the full knowledge domain before carving it into individual pieces. The domain whirlybird shows everything you could write about. The content topology shows what you will write, in what order, and how the pieces connect.

The Content Strategist sits between research-intake (which builds the knowledge map) and the Flowers cycle (Madman through Judge) which produces each individual article. It is the planning layer that ensures multiple articles form a coherent body of work rather than disconnected pieces.

When to Use This Skill

• After research-intake has delivered a knowledge map and the goal is multiple articles
• When planning a content series, pillar-and-cluster strategy, or topic hub
• When deciding which article to write first from a large research corpus
• When mapping a knowledge domain to identify all potential content pieces
• When building an editorial calendar or production plan for a content initiative
• When tracking progress across multiple articles in various stages of the Flowers cycle
• When evaluating whether a new article idea fits the existing content topology
• When a completed article reveals that a branch needs its own cluster piece or targeted piece
• When cross-linking opportunities emerge between articles in production
• When the production order needs revision based on new priorities or discovered dependencies
• When scoping article-level whirlybirds for individual pieces entering the Flowers cycle
• When determining whether a feather warrants its own targeted piece or belongs as a section in its parent cluster

Core Workflow

1. Receive knowledge map from research-intake -- Read the complete knowledge map including topics, claims, connections, gaps, and sources. Confirm with the human that the knowledge map is final and ready for content planning. If no knowledge map exists, route back to research-intake first.

2. Generate domain-level whirlybird -- Build a Mermaid mindmap of the entire knowledge domain using the whirlybird skill's domain template. The center is the knowledge domain itself. Branches are major theme areas. Feathers are potential article topics or specific angles. Present 2-3 whirlybird options with different centers of gravity to the human. See references/content-topology.md for how the whirlybird maps to content types.

3. Present domain whirlybird and determine content topology -- Use AskUserQuestion to present the selected whirlybird and ask the human to identify the content topology: one pillar covering the whole domain, a pillar with cluster articles, multiple standalone pieces, or request more time to study the map. The human's choice determines the content plan structure. See references/content-topology.md for topology options and derivation rules.

4. Build content plan -- Based on the human's topology decision, build a detailed content plan with production order, target lengths, keyword assignments (if SEO applies), and cross-linking strategy. Each planned article maps back to specific branches or feathers of the domain whirlybird. See references/content-plan-template.md for the full plan format.

5. Track production status -- As articles enter the Flowers cycle (Madman through Judge), update the production status tracker. Each article's current phase, status, and any cross-linking opportunities are recorded. See references/production-tracking.md for the tracking format and efficiency patterns.

Reference Guide

Constraints

MUST DO:

• Generate a domain-level whirlybird before proposing any content plan
• Present multiple whirlybird options for human selection (minimum 2)
• Let the human choose the content topology -- do not decide pillar vs. cluster vs. standalone
• Map every planned article back to specific whirlybird branches or feathers
• Include production order rationale in the content plan
• Track cross-linking opportunities between planned articles
• Update the production status tracker at every phase transition for every article
• Accept hybrid topologies the human proposes -- the standard options are starting points, not constraints
• Include target lengths for each planned article based on content type (pillar: 2,500-5,000, cluster: 1,500-3,000, targeted: 800-1,500)
• Scope article-level whirlybirds to the branch they cover, preventing sprawl into adjacent branches

MUST NOT DO:

• Skip the domain whirlybird and jump straight to a content plan
• Decide the content topology without human input
• Plan articles that do not map to the knowledge map or domain whirlybird
• Begin article production (Madman phase) from within this skill -- hand off to the appropriate skill
• Ignore SEO considerations when the human has indicated SEO is a goal
• Create article-level whirlybirds here -- those belong to the whirlybird skill during each article's Flowers cycle
• Start a cluster article before its parent pillar is complete -- the pillar establishes the framework, terminology, and linking structure
• Allow an article into the plan that does not trace back to a specific element of the domain whirlybird
• Insert cross-links as footer lists -- links must be contextual, embedded in relevant text
• Duplicate research across articles -- all articles draw from the shared research corpus established during research-intake

Output Templates

The primary output is the Content Plan. See references/content-plan-template.md for the full template.

A minimal content plan contains:

• Domain whirlybird (selected by human)
• Content topology decision (pillar, cluster, standalone, or hybrid)
• Article list with titles, types, target lengths, and whirlybird source
• Production order with rationale
• Cross-linking strategy
• Shared research corpus reference

Production Status Tracker Format

Track each article's lifecycle through the Flowers cycle:

Update the tracker at every phase transition, when a quality-rubric evaluation sends an article back for rework, and when cross-links become insertable because both linked articles are complete.

Topology Decision Prompt Format

Present topology options using a structured prompt that covers: a single pillar article, a pillar with cluster articles (one per branch), multiple standalone articles, or a request for more study time. Include estimated word counts for each option. Do not proceed until the human selects.

Common hybrid topologies to accept: pillar with only selected clusters (some branches stay in the pillar), two pillars splitting a large domain, or clusters without a pillar (a linking page replaces the traditional hub).

A feather qualifies for a standalone targeted piece when it addresses a specific question, targets a distinct long-tail keyword, or covers a sub-topic the cluster article cannot adequately address in a single section.

Knowledge Reference

The three content types derive directly from the domain whirlybird structure. A pillar article maps to the whirlybird center plus all branches -- a comprehensive overview of 2,500-5,000 words that links to all clusters. Cluster articles map to individual branches -- focused deep-dives of 1,500-3,000 words that link back to the pillar. Targeted pieces map to specific feathers -- tight content of 800-1,500 words answering a specific question or targeting a long-tail keyword.

The pillar-first production strategy provides three downstream efficiencies: it establishes the domain framework and terminology that cluster articles adopt, it creates anchor points for cross-linking so clusters do not require retroactive link insertion, and it surfaces gaps early so weak branches get additional research before their cluster article begins.

Cross-article efficiency comes from the shared research corpus. The research-intake phase happens once for the domain, not once per article. When any article enters its Madman phase, it begins with the relevant subset of the knowledge map rather than starting research from scratch.

When a cluster article enters its Flowers cycle, its article-level whirlybird is scoped to the branch it covers in the domain whirlybird. The branch label becomes the article whirlybird center. The feathers from that branch become the article whirlybird branches. Additional feathers may emerge from the article's Madman phase. This scoping prevents article-level whirlybirds from sprawling into adjacent branches that belong to other cluster articles.

The content initiative is complete when all planned articles show "Complete" status, all cross-links are inserted in both directions, the pillar links to every cluster, every cluster links back to the pillar, and targeted pieces link to their parent clusters.

Content Plan Template

This reference provides the full content plan format used by the content-strategist skill.

---

Full Content Plan Format

# Content Plan: [Domain]

## Domain Summary
[2-3 sentences describing the knowledge domain and the strategic intent behind this content initiative]

## Domain Whirlybird (Selected)

\```mermaid
mindmap
  root((Domain Center))
    Branch One
      Feather 1a
      Feather 1b
    Branch Two
      Feather 2a
      Feather 2b
      Feather 2c
    Branch Three
      Feather 3a
      Feather 3b
\```

## Content Topology: [Pillar + Clusters / Standalone / Hybrid]

**Rationale:** [Why this topology fits the domain and the human's goals]

---

## Pillar Article

**Working title:** [title]
**Center of gravity:** [from whirlybird center]
**Branches covered:** [all / selected -- list which]
**Target length:** [word count]
**Primary keyword:** [if SEO applies, otherwise omit]
**Secondary keywords:** [if SEO applies]
**Purpose:** [what this article accomplishes for the reader]
**Cross-links to:** [list of cluster articles it will link to]

---

## Cluster Articles

### Cluster 1: [Working Title]

**Source:** Branch [N] -- [branch label]
**Focus:** [specific angle this article takes on the branch]
**Target length:** [word count]
**Primary keyword:** [if SEO]
**Links to pillar:** [how it connects -- specific section or concept]
**Links to other clusters:** [cross-linking opportunities]
**Key feathers to cover:**
- [Feather N.1]: [what this feather becomes in the article]
- [Feather N.2]: [what this feather becomes in the article]

### Cluster 2: [Working Title]

**Source:** Branch [N] -- [branch label]
**Focus:** [specific angle]
**Target length:** [word count]
**Primary keyword:** [if SEO]
**Links to pillar:** [connection point]
**Links to other clusters:** [cross-linking opportunities]
**Key feathers to cover:**
- [Feather N.1]: [mapping]
- [Feather N.2]: [mapping]

[Repeat for each cluster article]

---

## Targeted Pieces

### Targeted 1: [Working Title]

**Source:** Feather [N.N] -- [feather label]
**Focus:** [specific question this piece answers]
**Target length:** [word count]
**Primary keyword:** [if SEO, likely a long-tail keyword]
**Links to:** [which cluster or pillar this connects to]
**Justification:** [why this feather warrants its own piece rather than a section in the cluster]

[Repeat for each targeted piece]

---

## Production Order

The production order determines which articles are written first. The order is strategic, not arbitrary.

1. **Pillar article** -- Write first. The pillar establishes the domain framework that all other pieces reference. Writing the pillar first forces clarity on the overall argument and creates the linking structure for clusters.

2. **[Cluster title]** -- Highest-value cluster. [Why this cluster comes second -- highest search volume, strongest material, most urgent topic, or dependency for other clusters.]

3. **[Cluster title]** -- [Rationale for this position in the order.]

4. **[Cluster title]** -- [Rationale.]

5. **Targeted pieces as needed** -- Targeted pieces can be written in any order after their parent cluster is complete. They fill gaps, target long-tail keywords, or address specific reader questions.

### Production Order Rationale

| Position | Article | Reason |
|----------|---------|--------|
| 1 | Pillar | Establishes framework and linking structure |
| 2 | [Cluster] | [Specific reason] |
| 3 | [Cluster] | [Specific reason] |
| N | Targeted pieces | Fill gaps after parent cluster exists |

---

## Cross-Linking Strategy

### Internal Links

| From | To | Link Context |
|------|----|-------------|
| Pillar, Section [N] | Cluster [A] | "For a deeper dive into [topic], see [link]" |
| Cluster [A], Section [N] | Pillar | "This is part of our [domain] series. See the overview: [link]" |
| Cluster [A], Section [N] | Cluster [B] | "[Topic from B] directly affects [topic from A]. See [link]" |
| Targeted [1] | Cluster [A] | "For broader context on [branch topic], see [link]" |

### Linking Principles

- Every cluster links back to the pillar at least once
- The pillar links forward to every cluster
- Clusters cross-link when they share concepts or dependencies
- Targeted pieces link to their parent cluster
- Links are contextual (embedded in relevant text), not footer lists

---

## Shared Research Corpus

All articles draw from the same research corpus established during research-intake.

**Corpus location:** [path to research materials]
**Knowledge map:** [path or reference to the knowledge map]
**Gap-fill notes:** [paths to any notes created during gap analysis]

When entering the Madman phase for any article in this plan, begin with the relevant subset of the shared corpus rather than starting research from scratch.

---

## Notes and Constraints

[Any additional context: publication timelines, SEO targets, audience considerations, format requirements, or constraints the human has specified]

---

Adapting the Template

No SEO

When the content strategy is not SEO-driven, omit all keyword fields. Replace them with audience-centric fields:

• Reader question addressed: [what question this piece answers]
• Reader transformation: [what changes for the reader after reading]

Single Pillar (No Clusters)

When the topology is a single pillar article, the content plan simplifies to just the Pillar Article section plus Production Order. Omit Cluster Articles and Targeted Pieces sections.

Standalone Articles (No Pillar)

When the topology is multiple standalone articles, replace the Pillar Article section with a Series Overview section that describes how the articles relate without a hub page. Each article gets its own entry similar to the Cluster format.

Content Topology

This reference describes how to derive content types from the domain whirlybird, present topology options to the human, and map whirlybird elements to planned articles.

---

Content Types from Domain Whirlybird

The domain whirlybird maps the full knowledge domain. Each structural element of the whirlybird corresponds to a potential content type:

Derivation Rules

Pillar from center: The domain whirlybird center defines the pillar article's scope. Every branch the pillar touches becomes a section in the pillar article. The pillar does not go deep on any single branch -- it covers all of them at a moderate level and links out to clusters for depth.

Clusters from branches: Each primary branch of the domain whirlybird is a natural cluster article. The branch label becomes the cluster's focus. The feathers under that branch become the cluster article's sections or key arguments.

Targeted pieces from feathers: Individual feathers that have enough substance for standalone content become targeted pieces. Not every feather warrants its own article. A feather qualifies for a targeted piece when it addresses a specific question, targets a distinct keyword, or covers a sub-topic the cluster article cannot adequately address in a section.

Example Derivation

Given this domain whirlybird:

mindmap
  root((API Security))
    Authentication Methods
      OAuth 2.0 flows
      API key management
      JWT best practices
    Rate Limiting
      Throttling strategies
      Quota management
      Abuse detection
    Data Protection
      Encryption at rest
      TLS configuration
      PII handling

The derivation produces:

• Pillar: "The Complete Guide to API Security" -- covers all three branches at moderate depth
• Cluster 1: "API Authentication Methods Explained" -- from the Authentication branch
• Cluster 2: "Rate Limiting Strategies for APIs" -- from the Rate Limiting branch
• Cluster 3: "Protecting Data in API Architectures" -- from the Data Protection branch
• Targeted piece: "OAuth 2.0 Authorization Code Flow with PKCE" -- from the OAuth 2.0 feather, if it has enough substance
• Targeted piece: "How to Handle PII in REST APIs" -- from the PII handling feather

---

Content Topology Decision

After the human selects a domain whirlybird, present the topology options using AskUserQuestion.

Topology Options

Based on the domain whirlybird, here are your content topology options:

A) **One pillar article** -- A single comprehensive piece covering the entire domain.
   Best for: Establishing authority on a topic, creating a definitive reference.
   Estimated length: [2,500-5,000 words]

B) **Pillar + clusters** -- One pillar article linking to [N] cluster articles, one per branch.
   Best for: SEO topic hubs, building a content library, thorough domain coverage.
   Estimated total output: [word count estimate across all pieces]

C) **Multiple standalone articles** -- [N] independent articles, each covering one branch.
   Best for: When branches are distinct topics that do not need a hub, or when publishing across different outlets.
   No pillar needed.

D) **Let me study the map** -- Take more time to evaluate the domain whirlybird before deciding.

Which topology fits your goals?

Do not proceed to the content plan until the human has made a topology decision.

Hybrid Topologies

The human may propose a hybrid that does not match the standard options. Common hybrids:

• Pillar + selected clusters -- Only some branches get cluster articles. Others are covered adequately in the pillar.
• Two pillars -- The domain is large enough to split into two pillar articles, each with its own clusters.
• Clusters without a pillar -- The branches are strong enough as standalone pieces. A linking page may replace the traditional pillar.

Accept and plan for any topology the human proposes. The standard options are starting points, not constraints.

---

Mapping Whirlybird to Content Plan

Once the topology is decided, map each planned article to its whirlybird source:

Mapping Table Format

| Planned Article | Type | Whirlybird Source | Branch/Feather |
|----------------|------|-------------------|----------------|
| [Pillar title] | Pillar | Center + all branches | Entire domain |
| [Cluster A title] | Cluster | Branch 1 | [branch label] |
| [Cluster B title] | Cluster | Branch 2 | [branch label] |
| [Targeted piece title] | Targeted | Feather 2.3 | [feather label] |

Every planned article must trace back to a specific element of the domain whirlybird. If an article does not map to the whirlybird, either the whirlybird is incomplete or the article does not belong in this content plan.

---

Scoping Article-Level Whirlybirds

When an individual article enters the Flowers cycle, it gets its own article-level whirlybird. This whirlybird is scoped to the branch (or branches) the article covers, not the full domain.

For a cluster article covering Branch 2 of the domain whirlybird:

• The article whirlybird center is the branch label
• The article whirlybird branches are the feathers from the domain whirlybird
• Additional feathers may be added from the Madman output for that article

The domain whirlybird stays at the strategy level. Article whirlybirds are created during each article's individual Flowers cycle by the whirlybird skill.

Production Tracking

This reference describes how to track production status across multiple articles in a content plan, identify cross-article efficiencies, and manage the lifecycle of a multi-article content initiative.

---

Production Status Format

Track every article in the content plan using the following table:

## Production Status

| # | Article | Type | Phase | Status | Last Updated | Link |
|---|---------|------|-------|--------|-------------|------|
| 1 | [Pillar title] | Pillar | Judge | Complete | [date] | [link to draft] |
| 2 | [Cluster A title] | Cluster | Carpenter | In progress | [date] | -- |
| 3 | [Cluster B title] | Cluster | Madman | In progress | [date] | -- |
| 4 | [Cluster C title] | Cluster | Not started | Queued | -- | -- |
| 5 | [Targeted piece title] | Targeted | Not started | Blocked (waiting on Cluster A) | -- | -- |

Phase Values

Status Values

---

Cross-Article Efficiencies

When producing multiple articles from the same research corpus, several efficiencies apply:

Shared Research Corpus

All articles draw from the same knowledge map and gap-fill research. When entering the Madman phase for any article:

1. Start with the subset of the knowledge map relevant to that article's branch 2. Include any gap-fill notes that address topics in the article's scope 3. The Madman still generates 3-5x raw material, but the seed is richer because the research corpus already exists

This eliminates redundant research across articles. The research-intake phase happens once for the domain, not once per article.

Pillar-First Strategy

Writing the pillar article first provides three efficiencies for downstream cluster articles:

1. Framework established. The pillar defines the domain framework, terminology, and argument structure. Cluster articles adopt this framework rather than inventing their own.

2. Linking structure ready. The pillar creates anchor points that cluster articles link back to. Without the pillar, cross-linking requires retroactive insertion.

3. Gaps surfaced early. The pillar writing process reveals which branches have strong material and which need additional research before their cluster article is started.

Cross-Linking During Production

As each article is completed, update the cross-linking strategy:

## Cross-Link Status

| Link | From Article | To Article | Status |
|------|-------------|------------|--------|
| Section 2 deep dive | Pillar | Cluster A | Inserted (Cluster A complete) |
| Context reference | Cluster A | Pillar | Inserted |
| Dependency link | Cluster B | Cluster A | Pending (Cluster B in Carpenter) |
| Sub-topic link | Cluster A | Targeted 1 | Pending (Targeted 1 not started) |

Links are inserted in both directions when both articles exist. When only one article is complete, note the pending link for insertion when the other article is finished.

Article-Level Whirlybird Scoping

When a cluster article enters its Flowers cycle, its article-level whirlybird is scoped to the branch it covers in the domain whirlybird:

• Center: The branch label from the domain whirlybird
• Branches: The feathers from that domain whirlybird branch
• Additional feathers: New material generated during the article's Madman phase

This scoping prevents the article-level whirlybird from sprawling into adjacent branches that belong to other cluster articles.

---

Production Update Protocol

Update the production status tracker at each phase transition:

1. Phase start: Update the Phase column when an article enters a new phase 2. Phase complete: Update Status to "In review" when awaiting human approval 3. Human decision: Update Status to "In progress" (next phase) or "Rework" (return to prior phase) 4. Completion: Update Status to "Complete" and add the link to the finished draft 5. Cross-links: Update the cross-link status table when links are inserted or become possible

Update Trigger Points

The tracker should be updated when:

• An article moves from one Flowers phase to the next
• A quality-rubric evaluation sends an article back for rework
• A cross-link becomes insertable because both articles are now complete
• The human requests a status overview
• Production order changes based on new information or priorities

---

Completion Criteria

The content initiative is complete when:

• [ ] All planned articles show "Complete" status
• [ ] All cross-links are inserted in both directions
• [ ] The pillar article links to every cluster article
• [ ] Every cluster article links back to the pillar
• [ ] Targeted pieces link to their parent clusters
• [ ] The knowledge-harvester has captured artifacts back to the vault (if applicable)
• [ ] The human has approved the final state of all articles