/series-planner

name: series-planner
promoted_to: content-calendar
description: "Plan multi-part content series: structure, cross-linking, cadence."
user-invocable: false
allowed-tools:
  - Read
  - Write
  - Bash
  - Grep
  - Glob
  - Edit
  - Task
command: /series
routing:
  triggers:
    - "plan series"
    - "multi-part content"
    - "content series"
    - "article series"
    - "content arc"
  category: content-creation
  pairs_with:
    - content-calendar
    - topic-brainstormer
    - publish

Series Planner Skill

Overview

This skill plans multi-part content series with proper structure, cross-linking, and publishing cadence. It implements a three-phase workflow: **ASSESS** (determine viability), **DECIDE** (select structure), and **GENERATE** (produce plan). Each phase has gates to prevent scope creep, ensure standalone value, and maintain quality constraints.

---

Reference Loading Table

| Signal | Load These Files | Why | |---|---|---| | choosing publication frequency and managing delays | `cadence-guidelines.md` | Loads detailed guidance from `cadence-guidelines.md`. | | series navigation links and Hugo implementation | `cross-linking.md` | Loads detailed guidance from `cross-linking.md`. | | writing the series plan output | `output-format.md` | Loads detailed guidance from `output-format.md`. | | selecting series type, part count, word targets | `series-types.md` | Loads detailed guidance from `series-types.md`. |

Instructions

Usage

/series [topic or idea]
/series --type=progressive [topic]      # Force series type
/series --parts=5 [topic]               # Target part count
/series --with-landing [topic]          # Include landing page plan
/series --minimal [topic]               # Titles and scope only

Phase 1: ASSESS

**Goal**: Determine whether the topic is viable as a series and identify natural divisions.

**Step 1: Analyze topic**

## Series Assessment
Topic: [user-provided topic]
Scope: [narrow / medium / broad]
Natural divisions: [how this topic breaks apart]
Audience progression: [beginner to expert? single level?]

**Step 2: Check viability**

Verify these constraints before proceeding:

• Topic has natural divisions (minimum 3 distinct subtopics required — this is non-negotiable)
• Each division can stand alone as complete content (not dependent on reading other parts)
• Logical progression exists between parts (reader can follow from one to the next)
• Not artificially padded (each part must earn its place with substantial unique content, no filler)

**Step 3: Detect series type**

Match topic signals to type. See `references/series-types.md` for full templates.

| Signal | Type | |--------|------| | "learn", "master", "deep dive" | Progressive Depth | | "build", "create", "project" | Chronological Build | | "why we chose", "migration", "debugging" | Problem Exploration |

**Gate**: Topic passes viability check with 3+ natural divisions identified. If topic fails viability, recommend single post or scope adjustment. Proceed only when gate passes.

Phase 2: DECIDE

**Goal**: Select series type, part count, and structure.

**Step 1: Select type and justify**

## Series Decision
Type: [Progressive Depth / Chronological Build / Problem Exploration]
Justification: [why this type fits]
Part Count: [3-7, enforced strictly]
Total Estimated Words: [X,XXX - X,XXX]

Enforce part count bounds strictly: minimum 3 parts, maximum 7 parts. No exceptions. The 3-7 constraint prevents both over-engineering (splitting one idea across 8+ parts) and under-engineering (calling 2 loosely related posts a "series").

**Step 2: Draft part breakdown**

For each part, define:

• Title and scope (1 sentence describing what this part covers)
• Standalone value (what reader learns from this part alone, without reading others)
• Forward/backward links (references to adjacent parts, for context only)

**Step 3: Validate standalone value**

For EVERY part, verify it passes the standalone test:

• Reader learns something complete and actionable (not a half-concept requiring other parts)
• Working code/config/output is possible from this part alone (readers aren't blocked waiting for next part)
• No critical information deferred to other parts (concepts explained fully in their own context)
• Someone landing on just this part via search gets something useful (SEO and UX principle)

Red flags that fail standalone test — reject any part showing these:

• "To understand this, read Part 1 first" as mandatory dependency
• Part ends mid-implementation with "Part 2 will continue"
• Core concepts explained only in earlier parts
• "Part 2 will explain why this works" — Part 1 reader is stranded

This is the failure mode prevention layer. Standalone value is non-negotiable because: 1. Search traffic lands on any part randomly, not always on Part 1 2. Readers expect complete value from the part they're reading 3. Multi-part cliff-hangers frustrate readers and hurt SEO

**Step 4: Select publishing cadence**

See `references/cadence-guidelines.md` for detailed criteria. Default to weekly unless topic complexity or content depth suggests otherwise.

**Gate**: All parts pass standalone value check. Part count is strictly 3-7. Type selection justified. Proceed only when gate passes.

Phase 3: GENERATE

**Goal**: Produce the complete series plan with all metadata.

**Step 1: Build series plan**

Output the complete plan including: 1. Series header with type and metadata 2. Detailed breakdown per part (scope, standalone value, links) 3. Cross-linking structure (see `references/cross-linking.md`) 4. Publication schedule with dates 5. Hugo frontmatter template per part

**Step 2: Final validation**

Before outputting, verify all constraints one final time:

• [ ] Every part has standalone value described (not deferred to other parts)
• [ ] Word counts are realistic (800-1500 per part, within 20% variance across parts to avoid reader whiplash)
• [ ] Cross-lin