series-planner

# 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**

```markdown
## 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**

```markdown
## 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-linking is complete (prev/next navigation for all parts)
- [ ] No cliff-hangers that frustrate readers (each part delivers closure, even if it references others)
- [ ] No filler parts (each part has substantial, non-redundant content)
- [ ] Part count within 3-7 bounds (enforced strictly)

**Step 3: Output plan**

Use the series plan format from `references/output-format.md`.

**Gate**: All validation checks pass. Plan is complete and ready for delivery.

---

## Series Types (Summary)

Three pri