# Publishing Cadence Guidelines

Recommendations for series publication frequency based on content type and goals.

---

## Cadence Options

### Weekly (Recommended Default)

**Schedule:** Same day each week (e.g., every Tuesday)

**Best for:**
- Standard series (3-5 parts)
- Evergreen technical content
- Building sustained audience interest
- Content that benefits from reader feedback between parts

**Advantages:**
- Maintains momentum without overwhelming
- Time to incorporate feedback
- Sustainable writing pace
- Allows promotion between posts

**Example schedule:**
```
Week 1 (Dec 3):  Part 1 - Foundation
Week 2 (Dec 10): Part 2 - Core Implementation
Week 3 (Dec 17): Part 3 - Advanced Topics
Week 4 (Dec 24): Part 4 - Production
```

---

### Bi-Weekly

**Schedule:** Every other week

**Best for:**
- Deep technical content (1500+ words per part)
- Complex topics requiring research
- Part-time content creation
- Audiences that need digestion time

**Advantages:**
- More time for thorough writing
- Complex topics get proper treatment
- Sustainable for side projects
- Reader has time to implement/experiment

**Example schedule:**
```
Dec 3:   Part 1 - Problem Space
Dec 17:  Part 2 - First Approach
Dec 31:  Part 3 - What Went Wrong
Jan 14:  Part 4 - Final Solution
```

---

### Daily (Launch/Event Mode)

**Schedule:** Consecutive days (typically Mon-Fri)

**Best for:**
- Time-sensitive content
- Product/feature launches
- Conference tie-ins
- Short series (3-4 parts max)

**Advantages:**
- Maximum momentum
- Captures full attention
- Good for event-driven content
- Creates urgency

**Disadvantages:**
- No time for feedback incorporation
- Demanding production schedule
- Reader may fall behind

**Example schedule:**
```
Monday:    Part 1 - Announcement
Tuesday:   Part 2 - Getting Started
Wednesday: Part 3 - Deep Dive
Thursday:  Part 4 - Advanced Usage
Friday:    Part 5 - What's Next
```

---

### Staggered

**Schedule:** Part 1, gap, then remaining parts weekly

**Best for:**
- SEO optimization (Part 1 establishes search presence)
- Content calendar balancing
- Testing audience interest before committing

**Pattern:**
```
Week 1:  Part 1
Week 2:  [gap - promote Part 1, gather feedback]
Week 3:  Part 2
Week 4:  Part 3
Week 5:  Part 4
```

**Advantages:**
- Part 1 builds search ranking before series continues
- Gap builds anticipation
- Time to adjust based on Part 1 reception
- Remaining parts maintain momentum

---

## Cadence Selection Criteria

### Choose Weekly When:

- [x] Content is evergreen
- [x] Parts are 800-1200 words each
- [x] You have buffer of completed parts
- [x] Audience expects regular content
- [x] No urgent time constraints

### Choose Bi-Weekly When:

- [x] Parts are 1500+ words each
- [x] Content requires significant research
- [x] Writing is not your primary job
- [x] Topics are complex and dense
- [x] Reader needs implementation time

### Choose Daily When:

- [x] Content is time-sensitive
- [x] Series is short (3-4 parts max)
- [x] All parts are complete before publishing
- [x] You can dedicate full attention to promotion
- [x] Audience will engage daily

### Choose Staggered When:

- [x] SEO is a primary goal
- [x] Testing topic interest
- [x] Balancing with other content
- [x] Part 1 is particularly strong/shareable

---

## Day and Time Considerations

### Best Days for Technical Content

| Day | Effectiveness | Notes |
|-----|---------------|-------|
| Tuesday | Excellent | Early week, past Monday chaos |
| Wednesday | Excellent | Mid-week, high engagement |
| Thursday | Good | Before weekend reading time |
| Monday | Fair | Competing with work catch-up |
| Friday | Fair | Weekend may help or hurt |
| Weekend | Variable | Good for hobbyist audiences |

### Time of Day

- **Morning (8-10am)**: Catches morning reading habits
- **Lunch (12-1pm)**: Lunch break reading
- **Evening (4-6pm)**: End of workday reading

**Recommendation:** Pick a consistent day/time. Consistency matters more than perfect timing.

---

## Managing Series Production

### Buffer Strategy

**Recommendation:** Complete at least Part 1 + 50% of remaining parts before publishing Part 1.

```
Series of 4 parts:
  Before Part 1 publishes:
    Part 1: Complete
    Part 2: Complete
    Part 3: Draft
    Part 4: Outlined
```

**Why:** Reduces pressure, allows revision, handles unexpected delays.

### Feedback Integration

Build in feedback windows:

```
Day 0: Part 1 publishes
Day 1-6: Collect feedback (comments, questions, issues)
Day 7: Part 2 publishes (can address Part 1 feedback)
```

### Publishing Checklist Per Part

Before each part goes live:

- [ ] All links verified (prev/next, external)
- [ ] Cross-references accurate
- [ ] Code examples tested
- [ ] Previous part updated with "Next" link
- [ ] Landing page updated (if manual)
- [ ] Social posts scheduled
- [ ] Email newsletter queued (if applicable)

---

## Handling Delays

### Missing a Scheduled Publication

**Best practice:** Publish late rather than skip.

**Communication:**
```markdown
*[Series note: This part was delayed from our usual Tuesday schedule.
Part 4 returns next Tuesday as scheduled.]*
```

### Extended Delay (1+ weeks)

**Communication on landing page:**
```markdown
**Series Status:** Parts 1-3 complete. Part 4 expected [date].
```

### Abandoning a Series

If you must stop mid-series:

1. Add note to landing page explaining status
2. Update last published part with status
3. Consider: Can you publish what you have as incomplete but still valuable?

```markdown
**Series Status:** This series is on indefinite hold after Part 3.
Parts 1-3 are complete and standalone. Part 4 (Production) may be
added in the future.
```

---

## Series Length vs Cadence

| Parts | Recommended Cadence | Total Duration |
|-------|---------------------|----------------|
| 3 | Weekly or Bi-weekly | 3-6 weeks |
| 4 | Weekly | 4 weeks |
| 5 | Weekly or Staggered | 5-7 weeks |
| 6 | Weekly or Bi-weekly | 6-12 weeks |
| 7 | Bi-weekly | 14 weeks |

**Guideline:** Series duration should not exceed 3 months for reader engagement.

---

## Promotion Between Parts

### Inter-Part Promotion

Between publications:
- Share individual insights from upcoming parts
- Ask questions the next part will answer
- Highlight comments/feedback from previous parts

### Series Completion Promotion

When final part publishes:
- Announce series completion
- Share landing page as comprehensive resource
- Consider: Summary post linking all parts

---

## Audience Considerations

### Technical Professionals

- Weekly works well (aligned with work week)
- Bi-weekly for very complex topics
- Prefer schedules that include weekdays so the cadence reaches readers when they are most active

### Hobbyists/Learners

- Weekly or bi-weekly both work
- Weekend publishing can be effective
- Consider: Time needed to work through exercises

### Mixed Audience

- Default to weekly
- Provide clear "level" indicators per part
- Allow readers to skip to relevant depth

# Cross-Linking Reference

Navigation patterns and Hugo implementation for series posts.

---

## In-Post Navigation

### Header Element

Place at the top of each post, immediately after the title.

**Pattern:**
```markdown
*Part 2 of 4 in the [Series Title](/series/series-slug/) series*
```

**Hugo shortcode (if available):**
```go-html-template
{{ partial "series-header.html" . }}
```

**Implementation:**
```go-html-template
{{/* layouts/partials/series-header.html */}}
{{ if .Params.series }}
<p class="series-header">
  <em>Part {{ .Params.series_part }} of {{ len (where .Site.RegularPages "Params.series" .Params.series) }}
  in the <a href="/series/{{ .Params.series | urlize }}/">{{ .Params.series }}</a> series</em>
</p>
{{ end }}
```

---

### Footer Navigation

Place at the end of each post, before comments.

**Pattern:**
```markdown
---

**Series Navigation:**
- Previous: [Part 1: Installing Hugo](/posts/hugo-from-scratch-part-1/)
- Next: [Part 3: Content Types](/posts/hugo-from-scratch-part-3/)
- [View all parts in this series](/series/hugo-from-scratch/)
```

**For first post:**
```markdown
---

**Series Navigation:**
- Next: [Part 2: Themes and Templates](/posts/hugo-from-scratch-part-2/)
- [View all parts in this series](/series/hugo-from-scratch/)
```

**For last post:**
```markdown
---

**Series Navigation:**
- Previous: [Part 3: Content Types](/posts/hugo-from-scratch-part-3/)
- [View all parts in this series](/series/hugo-from-scratch/)

This is the final part of the series.
```

---

### Hugo Shortcode Implementation

**Shortcode file:** `layouts/shortcodes/series-nav.html`

```go-html-template
{{ $series := .Page.Params.series }}
{{ $currentPart := .Page.Params.series_part }}
{{ $allParts := where .Site.RegularPages "Params.series" $series }}
{{ $sortedParts := sort $allParts "Params.series_part" }}

<nav class="series-navigation">
  <hr>
  <strong>Series Navigation:</strong>
  <ul>
    {{ range $sortedParts }}
      {{ if eq .Params.series_part (sub $currentPart 1) }}
        <li>Previous: <a href="{{ .RelPermalink }}">Part {{ .Params.series_part }}: {{ .Title }}</a></li>
      {{ end }}
    {{ end }}
    {{ range $sortedParts }}
      {{ if eq .Params.series_part (add $currentPart 1) }}
        <li>Next: <a href="{{ .RelPermalink }}">Part {{ .Params.series_part }}: {{ .Title }}</a></li>
      {{ end }}
    {{ end }}
    <li><a href="/series/{{ $series | urlize }}/">View all parts</a></li>
  </ul>
</nav>
```

**Usage in post:**
```markdown
{{</* series-nav */>}}
```

---

## Forward References

### Good Patterns

Reference future parts without creating dependency:

```markdown
For deploying this setup to production, see Part 4.
```

```markdown
Part 3 covers error handling for these edge cases.
```

```markdown
If you want to customize templates further, Part 2 goes deep on that.
```

### Preferred Forward References

Keep content available on the current page instead of gating it behind a future part:

```markdown
<!-- BAD: Cliff-hanger -->
...but the real solution is in Part 2!

<!-- BAD: Required reading -->
To understand this, you MUST read Part 3 first.

<!-- BAD: Empty promise -->
The code will be provided in the next part.
```

---

## Backward References

### Good Patterns

Keep context inline and avoid repeating content the reader already has:

```markdown
Building on the configuration from Part 1, we now add template overrides.
```

```markdown
If you haven't set up the base project yet, see Part 1 first.
```

```markdown
Using the CLI we built in Part 2:
```

### Preferred Backward References

Keep references brief and avoid re-explaining material the reader already has:

```markdown
<!-- BAD: Re-explanation -->
As we discussed extensively in Part 1, Hugo is a static site generator that...

<!-- BAD: Excessive callbacks -->
Remember in Part 1 when we set up the config? And in Part 2 when we added templates?

<!-- BAD: Assumes complete reading -->
Following the exact steps from Part 2's error handling section...
```

---

## Series Landing Page

### Purpose

Provides overview and navigation hub for entire series.

### Location

```
content/series/series-slug/_index.md
```

### Structure

```yaml
---
title: "Hugo from Scratch: Complete Series"
date: 2024-12-01
draft: false
type: series
---

A four-part series taking you from zero to a production Hugo blog.

## What You'll Learn

- Part 1: Basic Hugo setup and your first post
- Part 2: Themes, templates, and customization
- Part 3: Content types and taxonomies
- Part 4: Deployment and automation

## Prerequisites

- Basic command line familiarity
- A text editor
- 2-3 hours total

## Parts

{{</* series-list */>}}
```

### Series List Shortcode

```go-html-template
{{/* layouts/shortcodes/series-list.html */}}
{{ $series := .Page.Title | replaceRE ": Complete Series$" "" }}
{{ $allParts := where .Site.RegularPages "Params.series" $series }}
{{ $sortedParts := sort $allParts "Params.series_part" }}

<ol class="series-list">
{{ range $sortedParts }}
  <li>
    <a href="{{ .RelPermalink }}">{{ .Title }}</a>
    <span class="word-count">{{ .WordCount }} words</span>
    {{ if .Params.summary }}<p>{{ .Params.summary }}</p>{{ end }}
  </li>
{{ end }}
</ol>
```

---

## Frontmatter for Series Posts

### Required Fields

```yaml
---
title: "Hugo from Scratch: Part 2 - Themes and Templates"
date: 2024-12-08
draft: false
tags: ["hugo", "static-sites", "series:hugo-from-scratch"]
series: "Hugo from Scratch"
series_part: 2
summary: "Installing themes, overriding layouts, and creating custom partials."
---
```

### Field Descriptions

| Field | Purpose |
|-------|---------|
| `series` | Series name (used for grouping and linking) |
| `series_part` | Part number (integer, for ordering) |
| `summary` | Brief description for landing page and list views |
| `tags` | Include `series:slug` for easy filtering |

---

## URL Patterns

### Option A: Part Number in Slug

```
/posts/hugo-from-scratch-part-1/
/posts/hugo-from-scratch-part-2/
```

Advantages: Clear ordering, simple
Disadvantages: Part number in URL, less descriptive

### Option B: Descriptive Slugs

```
/posts/hugo-first-site/
/posts/hugo-themes-templates/
```

Advantages: SEO-friendly, descriptive
Disadvantages: Order not obvious from URL

### Recommendation

Use Option B with series metadata for navigation. URLs should describe content, navigation handles ordering.

---

## Cross-Series References

When one series references another:

```markdown
For the basics of Hugo templating, see the [Hugo from Scratch](/series/hugo-from-scratch/) series, particularly Part 2.
```

Prefer:
```markdown
<!-- BAD: Assumes reading order -->
After completing the Hugo from Scratch series, you're ready for this advanced content.
```

---

## Updating Series After Publication

### Adding a New Part

1. Create new post with next `series_part` number
2. Update previous "final" part's navigation
3. Landing page auto-updates if using shortcode

### Inserting a Part

Use only when the reference truly needs the future context:
1. Renumber `series_part` values for subsequent posts
2. Update all navigation references
3. Add redirects if URLs change

### Removing a Part

1. Remove post file
2. Update surrounding parts' navigation
3. Update landing page if manual content exists
4. Add redirect to landing page

# Series Plan Output Format

Standard output template for the series-planner skill.

---

## Complete Series Plan

```
===============================================================
 SERIES PLAN: "[Series Title]"
===============================================================

 Type: [Progressive Depth / Chronological Build / Problem Exploration]
 Parts: [N]
 Total Estimated: [X,XXX-X,XXX] words
 Publishing Cadence: [frequency]

 PART BREAKDOWN:

 Part 1: "[Part Title]" [XXX-XXX words]
   Scope: [What this part covers]
   Standalone value: [What reader gets from this part alone]
   Links forward: "[Teaser for Part 2]"

 Part 2: "[Part Title]" [XXX-XXX words]
   Scope: [What this part covers]
   Standalone value: [What reader gets from this part alone]
   Links back: [What was covered in Part 1]
   Links forward: "[Teaser for Part 3]"

 Part 3: "[Part Title]" [XXX-XXX words]
   Scope: [What this part covers]
   Standalone value: [What reader gets from this part alone]
   Links back: [What was covered in Parts 1-2]
   [Continue pattern...]

 Part N (Final): "[Part Title]" [XXX-XXX words]
   Scope: [What this part covers]
   Standalone value: [What reader gets from this part alone]
   Links back: [What was covered in previous parts]
   Series completion: [How this wraps up the series]

 CROSS-LINKING STRUCTURE:
   - Each part header: "Part X of [N] in the [Series Title] series"
   - Navigation footer: [Previous: Part X] | [Next: Part Y]
   - Series page: /series/[series-slug]/

 PUBLICATION SCHEDULE:
   [Date/Week 1]: Part 1 - [Brief description]
   [Date/Week 2]: Part 2 - [Brief description]
   [Continue...]

 HUGO FRONTMATTER TEMPLATE:
   ---
   title: "[Series Title]: Part X - [Part Title]"
   date: YYYY-MM-DD
   draft: false
   tags: ["[tag1]", "[tag2]", "series:[series-slug]"]
   series: "[Series Title]"
   series_part: X
   summary: "[One sentence for list views]"
   ---

===============================================================
```

---

## Standalone Value Verification Block

Include this block after each part breakdown to show verification was performed:

```
 STANDALONE VERIFICATION:
   Part 1: [PASS/FAIL] - [reason]
   Part 2: [PASS/FAIL] - [reason]
   Part 3: [PASS/FAIL] - [reason]
   [Continue for all parts...]
```

### Pass Criteria

For each part, ALL must be true:
- Reader learns something complete (not half a concept)
- Working code/config/output is possible from this part alone
- No critical information deferred to other parts
- Value proposition is clear without reading series context
- Someone landing on just this part gets something useful

### Fail Indicators

Any of these means the part fails standalone verification:
- "To understand this, read Part 1 first" as mandatory
- Part ends mid-implementation
- Core concepts explained only in earlier parts, not summarized
- "Part 2 will explain why this works"

---

## Minimal Mode Output

When `--minimal` is specified, use this abbreviated format:

```
===============================================================
 SERIES: "[Series Title]" ([Type], [N] parts)
===============================================================

 Part 1: [Title] - [Scope in 1 sentence]
 Part 2: [Title] - [Scope in 1 sentence]
 Part 3: [Title] - [Scope in 1 sentence]
 [...]

 Cadence: [frequency]
===============================================================
```

---

## Landing Page Plan Output

When `--with-landing` is specified, append this section:

```
 LANDING PAGE: /series/[series-slug]/

 Title: "[Series Title]: Complete Series"
 Description: [1-2 sentence overview]

 Structure:
   - What You'll Learn (bullet per part)
   - Prerequisites
   - Parts list (auto-generated from series metadata)

 Hugo frontmatter:
   ---
   title: "[Series Title]: Complete Series"
   date: [first part date]
   draft: false
   type: series
   ---
```

# Series Types Reference

Complete templates for each series type with examples and selection criteria.

---

## Type Selection Matrix

| Topic Signal | Best Type | Example |
|--------------|-----------|---------|
| "learn", "master", "deep dive" | Progressive Depth | "Mastering Go Concurrency" |
| "build", "create", "project" | Chronological Build | "Building a REST API" |
| "why we chose", "migration" | Problem Exploration | "From Monolith to Microservices" |
| "vs", "comparison" | Problem Exploration | "SQL vs NoSQL for Our Use Case" |
| "tutorial", "guide", "how to" | Chronological Build | "Setting Up Kubernetes" |
| "internals", "how X works" | Progressive Depth | "Linux Process Scheduling" |

---

## Progressive Depth

### Template

```
Part 1: Basics [800-1000 words]
  Scope: Surface-level understanding, get started quickly
  Audience: Complete beginners
  Outcome: Reader can use the basic form

Part 2: Intermediate [1000-1200 words]
  Scope: Common use cases, real-world patterns
  Audience: Has basics, wants practical application
  Outcome: Reader handles 80% of cases

Part 3: Advanced [1000-1200 words]
  Scope: Edge cases, optimization, debugging
  Audience: Intermediate users hitting limits
  Outcome: Reader handles complex scenarios

Part 4 (optional): Expert [800-1000 words]
  Scope: Internals, architecture, extension points
  Audience: Power users, contributors
  Outcome: Reader understands the "why" deeply
```

### Standalone Value Pattern

- Part 1: Complete for basic use
- Part 2: Complete for everyday use (may reference Part 1 concepts briefly)
- Part 3: Complete for troubleshooting (assumes competence, not Part 1-2 reading)
- Part 4: Complete for deep understanding (stands alone as architecture doc)

### Example: "Hugo from Scratch"

```
Part 1: Your First Site [900 words]
  - Install Hugo
  - Create new site
  - Add first post
  - Local preview
  STANDALONE: Working Hugo site on localhost

Part 2: Themes and Templates [1100 words]
  - Installing a theme
  - Override layouts
  - Create partials
  - Custom CSS
  STANDALONE: Themed, styled Hugo site

Part 3: Content Types and Taxonomies [1100 words]
  - Archetypes
  - Content sections
  - Categories and tags
  - Custom taxonomies
  STANDALONE: Organized content architecture

Part 4: Deployment and Automation [900 words]
  - Build process
  - Cloudflare Pages setup
  - GitHub Actions
  - Cache and performance
  STANDALONE: Production deployment guide
```

---

## Chronological Build

### Template

```
Part 1: Setup [700-900 words]
  Scope: Environment, dependencies, project structure
  Milestone: Project scaffolding complete
  Output: Runnable (even if minimal) artifact

Part 2: Core [1000-1300 words]
  Scope: Primary functionality implementation
  Milestone: Main feature working
  Output: Functional (if rough) product

Part 3: Enhancement [900-1100 words]
  Scope: Polish, secondary features, UX
  Milestone: Product feels complete
  Output: Polished, usable product

Part 4: Production [800-1000 words]
  Scope: Deployment, monitoring, maintenance
  Milestone: Live in production
  Output: Deployed, observable product
```

### Standalone Value Pattern

Each part produces working output. Reader can stop at any milestone with something functional.

- Part 1: Scaffold is valid, builds, runs (even if it does nothing)
- Part 2: Core feature works end-to-end
- Part 3: Product is "complete enough" for real use
- Part 4: Production concerns addressed

### Example: "Building a CLI Tool in Go"

```
Part 1: Project Setup [800 words]
  - go mod init
  - Directory structure
  - Basic main.go
  - First command working
  MILESTONE: `mycli --help` works

Part 2: Core Commands [1200 words]
  - Command structure
  - Flags and arguments
  - Subcommands
  - Error handling
  MILESTONE: Core functionality complete

Part 3: Configuration [1000 words]
  - Config file support
  - Environment variables
  - State persistence
  - User preferences
  MILESTONE: Tool is polished for daily use

Part 4: Distribution [900 words]
  - Cross-compilation
  - Release workflow
  - Homebrew formula
  - Documentation
  MILESTONE: Others can install and use
```

---

## Problem Exploration

### Template

```
Part 1: Problem Space [800-1000 words]
  Scope: Symptoms, constraints, requirements
  Tone: "Here's what we were dealing with"
  Outcome: Reader understands the challenge

Part 2: First Approach [900-1100 words]
  Scope: Initial solution, implementation
  Tone: "Here's what we tried"
  Outcome: Reader learns from our attempt

Part 3: Hitting Walls [900-1100 words]
  Scope: Where it failed, what we learned
  Tone: "Here's where it broke down"
  Outcome: Reader avoids same mistakes

Part 4: Resolution [800-1000 words]
  Scope: Final solution, why it works
  Tone: "Here's what actually worked"
  Outcome: Reader has proven solution
```

### Standalone Value Pattern

Even failed approaches are instructive. Each part teaches something.

- Part 1: Problem analysis is valuable for anyone facing similar symptoms
- Part 2: First approach may work for simpler cases
- Part 3: Debugging insights apply broadly
- Part 4: Final solution stands as authoritative answer

### Example: "Why We Moved from Redis to PostgreSQL"

```
Part 1: The Caching Problem [900 words]
  - Application architecture
  - Performance requirements
  - Initial cache strategy
  - Why we chose Redis initially
  STANDALONE: Caching strategy analysis

Part 2: Redis Implementation [1000 words]
  - Redis setup
  - Caching patterns we used
  - What worked well
  - Early wins
  STANDALONE: Redis caching patterns

Part 3: Scaling Issues [1000 words]
  - Memory pressure at scale
  - Consistency problems
  - Operational complexity
  - Debugging the failures
  STANDALONE: Redis pitfalls and debugging

Part 4: PostgreSQL Solution [900 words]
  - Migration strategy
  - JSONB for flexibility
  - Performance results
  - Lessons learned
  STANDALONE: PostgreSQL as cache layer
```

---

## Hybrid Types

### Investigation Report (Problem-Solution + Technical Explainer)

For complex bugs requiring deep system understanding.

```
Part 1: The Symptom [700-900 words]
Part 2: Initial Hypotheses [900-1000 words]
Part 3: Deep Dive: [System] [1000-1200 words]
Part 4: Root Cause and Fix [900-1000 words]
```

### Tutorial with Context (Walkthrough + Why It Matters)

For when the "why" is as important as the "how."

```
Part 1: Why This Approach [800-1000 words]
Part 2: Foundation [900-1000 words]
Part 3: Implementation [1000-1200 words]
Part 4: Production Considerations [800-900 words]
```

---

## Type Selection Flowchart

```
What is the primary purpose?

Is it about learning/mastering?
  └── YES: Progressive Depth

Is it about building something?
  └── YES: Chronological Build

Is it about a journey (debugging, migration, decision)?
  └── YES: Problem Exploration

Does it combine elements?
  └── YES: Consider Hybrid

Still unclear?
  └── Default to Progressive Depth (most flexible)
```

---

## Part Count Guidelines

| Series Type | Minimum | Optimal | Maximum |
|-------------|---------|---------|---------|
| Progressive Depth | 3 | 4 | 5 |
| Chronological Build | 3 | 4 | 6 |
| Problem Exploration | 3 | 4 | 4 |
| Hybrid | 3 | 4 | 5 |

**Fewer than 3:** Probably not a series. Use single post.
**More than 6-7:** Consider splitting into multiple series.

---

## Word Count Targets by Type

| Series Type | Per Part | Total Series |
|-------------|----------|--------------|
| Progressive Depth | 900-1100 | 3,500-5,500 |
| Chronological Build | 900-1200 | 3,500-6,000 |
| Problem Exploration | 850-1000 | 3,400-4,000 |
| Hybrid | 900-1100 | 3,500-5,000 |

These targets assume a direct, technical style. Adjust for different voices.