Cluster Planner

---
name: cluster-planner
description: Turn one published pillar into a publishing roadmap — 8 to 15 supporting cluster posts with validated volume, exact titles, angles, and the internal-link map. Use when asked to plan a content cluster, build supporting posts around a pillar, turn one post into a roadmap, decide what to write next after a pillar, map internal links for a topic, or someone says 'the pillar is live, now what'. For whole-site pillar strategy, see site-architecture. For each post's go/no-go, see topical-authority-check.
metadata:
  version: 1.0.0
---

# Cluster planner

Runs **right after a new pillar goes live.** One pillar standing alone is a
good post; a pillar with its cluster is topical authority. This skill turns the
pillar into the roadmap: **8–15 supporting posts with validated volume and
difficulty, exact titles, angles, and an internal-link map.**

The difference from site-architecture: that skill plans the *site's* pillars;
this one operationalises *one* pillar into its publishable cluster.

## Before you start

| Input | Why |
| --- | --- |
| The live pillar URL and its keyword | The hub everything links up to |
| Keyword data access (Semrush or free stack) | Every proposed post ships with validated numbers, honestly shaped |
| The registry of published posts | Proposals must not duplicate or cannibalise what exists |
| The site's publishing cadence | A 15-post roadmap means nothing without a rate |

## Step 1 — Mine the pillar for cluster seams

Each of the pillar's H2 sections is a candidate subtopic: the section answers
the question at hub depth; the cluster post takes it deep. Add the question
research the pillar *didn't* absorb — the PAA/AlsoAsked questions too big for
an FAQ entry are cluster posts waiting.

## Step 2 — Validate each candidate

Per candidate, before it enters the roadmap:

1. **Volume and difficulty** — from the data source, shape preserved (ranges
   stay ranges).
2. **Registry check** — nothing already published targets this intent.
3. **Winnability** — the top-5 test from the topical check applies to every
   cluster post, not just pillars.

Candidates that fail stay listed as rejected-with-reason — a silently dropped
candidate gets re-proposed next quarter.

## Step 3 — Specify each post exactly

For every surviving candidate:

- **Exact title** — not a topic area; the title the writer will use.
- **The angle** — what this post argues that the pillar section could not.
- **Cluster spec**: 1,500–2,200 words, links **up to the pillar twice**,
  **across to two siblings**.
- Its target keyword and the questions it owns.

## Step 4 — Draw the link map

The map, not prose: every cluster post → pillar (twice), → two named siblings.
Sibling pairs are chosen by adjacency of intent, so the across-links read as
natural next-reads, not obligations. The pillar links **down to every cluster
post** — the pattern humans always miss in reverse.

## Step 5 — Sequence by the cadence

Order the roadmap: dependencies first (a comparison post before the posts it
compares), then by validated volume. Attach dates from the real cadence and the
1:2 refresh rule — new cluster posts share the calendar with refreshes.

## Output

```
# Cluster roadmap: <pillar title> (<url>)

| # | Exact title | Angle | Keyword | Vol (shape) | Diff | Links up | Siblings | Date |
[8-15 rows]

Rejected candidates: <title — reason> (kept for the record)
Link map: pillar ↓ all <n> · every post ↑ pillar ×2 · sibling pairs listed
Cadence: <n>/month alongside <2n> refreshes (1:2 rule)
Data: <source + shape caveats>
→ each post enters the pipeline via topical-authority-check on its date
```

## When it breaks

| What you see | What it means | The fix |
| --- | --- | --- |
| Roadmap of topic areas, not titles | Planning stopped one step early | Exact titles — the writer should never have to invent one |
| Cluster posts read like the pillar sections | No distinct angle per post | The angle states what the post argues beyond the hub |
| Two cluster posts fighting for one term | Registry/cannibalisation check skipped | Every candidate checks the registry before entering |
| 15 posts planned, 2 published, roadmap dead | Sequenced without the real cadence | Dates from actual capacity, shared with the refresh calendar |
| Sibling links feel forced | Pairs chosen by list order, not intent adjacency | Re-pair by what a reader would genuinely read next |
| The pillar never links down | The classic missing pattern | The map includes pillar ↓ every post, added at each publish |
| Roadmap built on exact volumes from ranges | False precision entering the plan | Shapes preserved; decisions noted as range-based |

Never pad to 15 posts because the range says 8–15. A cluster of 9 strong posts
beats 15 where six are filler — the range is a capacity, not a quota.

## Rules

- **Exact titles, validated numbers, or it isn't a roadmap**, because "we
  should cover pricing" is a wish and a titled, dated, volumed post is a plan.
- **Every post links up twice and across twice**, because the cluster's
  authority is the graph, not the word count.
- **The registry is checked before every proposal**, because the planner
  proposing a published post embarrasses the whole system.
- **Rejections are recorded with reasons**, because silent drops return as
  next quarter's bad ideas.
- **The range is a capacity, not a quota**, because filler posts dilute the
  authority the cluster exists to build.

## Related skills

- **site-architecture** — the site-level plan this operationalises per pillar.
- **topical-authority-check** — each roadmap post still passes the gate on its
  publish date.
- **link-orchestrator** — patches the map into the live graph as posts ship.
- **keyword-research** — the validation data layer.