Calendar Planner

Calendar Planner

Build plans the team can actually execute. A 90-day calendar that fails at week three is worse than a 60-day calendar that holds. Every calendar decision starts with capacity, not ambition.

The Resource Reality Test

Run this before building any calendar. No exceptions. This is the single most important step — it prevents the #1 failure mode of content calendars: planning more than the team can produce.

Capacity Calculation

Team: {team size or description}
Cadence: {publishing cadence}
90-day total capacity: [{pieces/week} × 12 weeks = {N total pieces}]
Seasonal holds: [{N} weeks blocked]
Available weeks: [12 - holds = {N}]
Effective capacity: [{pieces/week} × {available weeks} = {N}]

Capacity Rules

State the capacity ceiling explicitly in the output. Clients need to see the math. A calendar that shows "12 pieces planned / 15 capacity = 80%" gives the user confidence. A calendar that just lists dates without capacity context creates silent anxiety about whether they can keep up.

Team Capacity Benchmarks

Use these only when exact capacity isn't documented. Always verify with the user.

Production Timeline Benchmarks

Factor these into calendar scheduling — content needs lead time.

Seasonal Planning

Seasonal Lock-In

Check before building any week:

1. Hard holds — absolute blackout periods. Nothing goes there. (From ~~docs or user input)
2. Calendar events — if ~~calendar is connected, pull upcoming events, launches, campaigns
3. Industry seasonality — relevant seasonal moments for this industry
4. Client seasonality — the client's own seasonal patterns (busy season, slow season, event season)

Seasonal Moment Rules

Common Seasonal Patterns by Industry

Use these as starting points only — verify against the client's actual industry:

Pillar Rotation Logic

A healthy 90-day calendar rotates across all pillars — no pillar dominates every week, no pillar disappears for a month.

Default Rotation

Rotation Adjustments

Pillar Balance Visualization

Show this in every calendar output:

PILLAR BALANCE (90 days)
[Pillar A]: ████████████ 35% (target: 33%) — Building (Thin pillar)
[Pillar B]: ██████████ 30% (target: 33%) — On track
[Pillar C]: ██████████ 30% (target: 34%) — On track
[Pillar D]: █████ 5% — Seasonal only

If the balance is off from default, explain why in one line.

Segment Coverage

Monthly Coverage Requirements

Every configured audience segment must be served at least once per month. Not every piece — but every segment gets at least one primary piece per month.

Segment Coverage Check

After building the calendar, verify:

• Every segment is served at least once per month
• Underserved segments (from /audit) are prioritized in Month 1
• No segment goes more than 2 weeks without primary content
• High-value segments get the highest-quality content formats

Repurposing Chains

A well-built repurposing chain doubles effective output without doubling effort. Build chains into the plan explicitly — don't leave repurposing as an afterthought.

Standard Repurposing Chains

Repurposing Rules

Repurposing Efficiency Summary

Show this in every calendar output:

REPURPOSING EFFICIENCY
Original pieces: {N}
Derived pieces: {N} (from {N} repurposing chains)
Time saved: ~{N} hours vs. creating each piece separately
Effective output: {N} total pieces from {N} originals

Monthly Theme Logic

Each month needs a theme — specific, evocative, grounded in the client's voice. Not generic editorial labels.

Theme Quality Criteria

Theme Selection Process

1. Which pillar is the primary focus for this month? (From rotation logic)
2. Is there a seasonal moment that creates a natural hook?
3. What's the strongest angle within this pillar that serves the primary segment?
4. Can the theme be expressed in language the audience would recognize and find interesting?

Contingency Planning

Every calendar needs a buffer. Things fall through — interviews cancel, drafts miss deadlines, breaking news changes priorities. Plan for it.

Buffer Week

Mark one week per month as flex — content is planned but not committed. This is your pressure relief valve.

Evergreen Standbys

Identify 2-3 evergreen pieces from content history that can republish or refresh if a planned piece falls through.

Good evergreen standbys:

• Top-performing pieces that are 3+ months old (refresh with current data)
• Foundational explainers that don't go stale
• Best-of compilations or round-ups that can be quickly updated
• FAQ or how-to content with perennial relevance

Selection criteria:

• Previously performed well (top quartile by engagement)
• Not heavily time-stamped (no "in 2024" in the headline)
• Can be refreshed in < 2 hours
• Serves a high-priority segment

Performance Weighting

If performance data exists and is recent (< 30 days from ~~email or ~~docs), use it to weight format and topic decisions.

Weighting Rules

When No Performance Data Exists

• Weight toward the client's most-used content format (from content history)
• Note that recommendations are based on content patterns, not engagement data
• Recommend establishing baseline tracking as a 30-day action

Always Do

• Run the resource reality test before building — show the math
• Check seasonal holds before placing any content
• Show pillar balance percentages across the full 90 days
• Build repurposing chains with explicit time savings
• Mark one week per month as flex/buffer
• Identify evergreen standbys from content history
• Serve every configured segment at least once per month
• Include production lead time in scheduling
• Show capacity utilization as a percentage

Never Do

• Plan content into blackout periods
• Build a calendar that exceeds 90% of publishing capacity without flagging it
• Recommend channels the client doesn't use
• Use generic seasonal moments that don't apply to the client's industry
• Let one pillar dominate the full 90 days without acknowledging the imbalance
• Plan without a contingency — something always falls through
• Present a calendar without the capacity math
• Assume repurposing takes zero time — it takes less time, not no time
• Schedule derived content more than 7 days after the source piece

Cross-Skill Dependencies

• Receives from: editorial-config (all constraints, pillar statuses, history, calendar data, performance)
• Receives from: content-strategist (priority recommendations — P1s drive Month 1 planning)
• Used by: /calendar command
• Informs: /draft (calendar-planned pieces feed into content drafting)