---

name: blog-editorial-calendar description: 'Operate an evidence-backed editorial queue, balance topic and format coverage, schedule approved drafts, and reconcile backlog state with the publishing system. Use when choosing or scheduling the next blog work. Trigger with "show the editorial calendar" or "pick the next topic".' argument-hint: "[status|next|add|mark-done|sync] [options]" allowed-tools: Read, WebSearch, WebFetch, Write, Edit version: 1.1.0 author: AutomateLab hello@automatelab.tech license: MIT-0 tags: [seo, editorial-calendar, content-operations, scheduling, backlog] model: inherit effort: high compatibility: Designed for Claude Code; scheduling, publication, CMS reconciliation, and backlog mutation require the content owner's approval and current platform access

Editorial Calendar Operations

Overview

Maintain a durable editorial backlog and select the next work from evidence rather than intuition. This skill balances configured topic clusters and post formats, reserves publishing slots, and reconciles local state with the real CMS before changing the queue.

It coordinates blog-topic-research and seo-blog-writer; it does not replace their research, drafting, review, or publishing controls.

Prerequisites

• An approved config.json defining target_platform, author, UTC cadence, cluster targets, format targets, and CMS tag mappings
• A writable backlog.json with stable IDs, titles, clusters, formats, evidence URLs, priorities, statuses, and scheduled timestamps
• Read-only CMS listing access for sync; separate approved write access only when the user requests scheduling or publication
• blog-topic-research for backlog replenishment and seo-blog-writer for draft production
• Topic and format target weights that each total approximately 1.0

Tool Discipline

Use Read to inspect configuration and backlog state. Use WebSearch and WebFetch only to confirm public evidence or read the authorized CMS inventory. Use Write or Edit for reviewed, secretless state updates; never write credentials, raw access tokens, or unpublished sensitive content into receipts.

Instructions

1. Parse the requested action: status, next, add, mark-done, or sync. Reject unknown actions and mutually incompatible scheduling flags.
2. Read and validate config.json and backlog.json. Confirm unique IDs, valid statuses, parseable UTC timestamps, nonnegative priorities, and target weights near 1.0.
3. Run a read-only reconciliation before selection. Match CMS records by stable CMS ID first, canonical URL second, and normalized slug only as a last resort. Report ambiguous matches instead of guessing.
4. For next, score only eligible ready items. Rank cluster deficit first, then format deficit, evidence strength, explicit priority, and oldest creation time. Record the score factors so the choice is reproducible.
5. Reserve the selected item with a stable run ID. For --draft, invoke the writer without a publish time. Otherwise choose the next free configured UTC slot or validate each explicit slot.
6. Require review before any live publish or schedule mutation. Pass the topic scaffold and approved target to seo-blog-writer; do not copy CMS credentials into the handoff.
7. Commit the state transition only after the downstream operation returns a durable draft ID, CMS ID, or explicit failure. Move ready -> reserved -> drafted -> scheduled -> published; never skip directly to published without CMS evidence.
8. For add, normalize the title and compare it with existing titles, slugs, canonical URLs, and distinctive error/version tokens. Add only evidence-backed, nonduplicate topics.
9. For mark-done, require a matching live URL or an owner-approved manual receipt. For sync, preserve local notes while updating only fields supported by CMS evidence.
10. Return the chosen work, schedule, state changes, conflicts, and next eligible slot. Leave failed or ambiguous items recoverable.

Selection Contract

Each backlog record should include:

{
  "id": "topic-0042",
  "title": "How to diagnose webhook signature failures",
  "cluster": "integrations",
  "format": "how-to-fix",
  "status": "ready",
  "priority": 2,
  "evidence_urls": ["https://example.com/verified-source"],
  "scheduled_at": null,
  "cms_id": null,
  "canonical_url": null
}

Selection must be deterministic for the same configuration, backlog, and CMS snapshot. Never fabricate traffic, demand, availability, or publication evidence.

Approval Boundaries

Ask for owner approval before scheduling, publishing, rescheduling, deleting, bulk-mutating, or overwriting reconciled backlog state. A read-only status or dry-run selection does not require CMS write access. Default to draft when publication intent is absent.

Output

Return a compact operational receipt containing:

• action, run ID, timestamp, and configuration checksum
• selected IDs and score factors
• old and new statuses
• draft, schedule, CMS ID, and canonical URL when available
• conflicts, skipped duplicates, shortfalls, and required approvals
• next eligible slot and recommended follow-up

Error Handling

Condition	Response
Missing or invalid configuration	Stop before mutation and list the exact invalid keys or totals.
CMS inventory is unavailable	Mark reconciliation unverified; allow local dry-run status but do not claim a slot is free or a post is live.
Two records match one CMS post	Preserve both records, report the collision, and require an owner decision.
Downstream drafting fails	Release the reservation or mark it blocked with the failure receipt; do not consume the slot.
Queue has no eligible topics	Report the shortfall and invoke blog-topic-research only with the approved cluster and count.
Concurrent update changes the backlog	Re-read, recompute, and require confirmation if the selected item or slot changes.

Examples

Dry-run the next two selections without publishing:

request: next 2 --draft --dry-run
result: topic-0042 (integrations deficit 0.08), topic-0017 (use-cases deficit 0.05)
mutation: none
next_slot_utc: 2026-09-12T06:00:00Z

Reconcile an already published item:

request: sync
matched: topic-0042 -> cms_id=post_918 by canonical_url
transition: scheduled -> published
conflicts: 0

Verification

• Re-run status and confirm the recorded counts equal the backlog totals.
• Confirm no two active records share a CMS ID or canonical URL.
• Confirm every scheduled timestamp fits a configured slot and no slot is double-booked.
• Confirm every published record has a CMS-derived ID or owner-approved receipt.
• Confirm a second dry-run against unchanged inputs returns the same ranking.

Resources

• Google Search Central: Creating helpful, reliable, people-first content
• Ghost Admin API overview
• WordPress REST API handbook
• RFC 3339 date and time profile

Next Steps

Review target weights monthly against actual business priorities and search performance. Revalidate platform APIs before changing the reconciliation adapter.