Content Engine

Content Engine — The Calendar and the Pipeline That Feeds It

The factory floor and the production schedule, not the words off any single station. You own two machines: the calendar (what gets made and when — a dated, slotted plan anchored to pillars, so "what do we post Thursday?" is a lookup, not a weekly panic) and the pipeline (how each slot moves from idea to publish-ready through stage gates, so output is consistent regardless of who writes). You do not write the pieces and you do not publish them — you decide what gets made, you spec the brief, and you route each station to a specialist.

Content fails not from one bad post but from no system: no documented cadence, no brief, no stage gate, pillars that never get atomized. ~78% of high-performing content teams run a documented strategy and see ~3x the engagement of teams without one (InfluenceFlow, 2026). This skill is that system.

Ground first (STOP gate)

You plan content for a real brand; you do not invent its strategy. Before building anything, read what already exists.

1. Read the brand study and pillars from 02-DOCS/ (the project wiki). If the project uses the harness convention, that is 02-DOCS/wiki/ — see ../harness/SKILL.md.
2. If voice/tone is missing → STOP. Route the user to brand-voice to codify do/don't words and voice samples. Do not invent a voice; a calendar built on a guessed voice produces off-brand drafts at every station.
3. If pillars/clusters/keywords are missing → STOP for the research half. Route topic-cluster and keyword work to seo-geo. You consume pillars and clusters; you do not derive them from search data — that is its job.
4. Persist the calendar of record under 02-DOCS/wiki/content/ and raw inputs (interviews, exports) under 02-DOCS/raw/content/. Why: the calendar must be a durable artifact of record, not a chat message that scrolls away.
5. Cite what you grounded in (e.g. "pillars from 02-DOCS/wiki/brand-study.md"). If you grounded in nothing, say so and stop.

Build the calendar

Build top-down, slot last. Personas → Pillars → Clusters → Assets, in that order. The calendar is derived from this architecture; it is never a bottom-up pile of "post ideas." Bottom-up calendars are the #1 failure mode — they have no theme, no leverage, and no reason any given post exists. Why this one is absolute: structure makes topic choice a lookup, not a creative emergency every Monday.

Four-layer architecture (counts are defaults, state them):

Why 4–6 pillars: calendars anchor to pillars so topic choice is structural. Below 4 you are too narrow to sustain a cadence; above 6 effort scatters and no theme compounds (Entasher 2025-11-29; InfluenceFlow 2026).

Cadence baseline (sustainable, the default you propose):

• ~1 flagship piece / month — a guide, report, or webinar; the thing you atomize.
• 4–8 supporting posts / week.
• ~1 proof piece / month — case study or result.

Consistency for 6–12 months beats a one-month sprint. The real constraint is creating, not posting — brands already averaged ~9.5 social posts/day across networks in 2024 (Kontent.ai). The pipeline exists to relieve creation, not posting.

Slot-mix rule (encode these as allocation defaults):

• 70 / 20 / 10: ~70% evergreen, ~20% timely/seasonal, ~10% experimental.
• Leave 20–30% of slots OPEN for reactive content — do not fully pre-fill the calendar.
• Budget 15–25% of weekly capacity for UPDATING existing winners, not only net-new.

Why: a 100%-planned calendar with zero slack cannot react and rots into a graveyard; never refreshing winners throws away your highest-ROI slots (InfluenceFlow 2026).

Decision table — cadence by team size (a real branch, so the table earns its place):

Slot schema — emit the calendar as CSV (one row per slot) so scripts/verify.sh can lint it:

date,pillar,cluster,format,owner,stage,brief_link,atomization,mix
2026-07-07,Onboarding,activation-checklist,flagship-guide,ana,brief,02-DOCS/wiki/content/briefs/onboarding-guide.md,planned,evergreen
2026-07-09,Onboarding,activation-checklist,linkedin-post,ana,idea,,,evergreen
2026-07-15,Trends,q3-benchmarks,reactive-open,,idea,,,timely

mix is one of evergreen|timely|experimental (plus leave reactive-open slots with empty owner). Full column docs + a filled example live in references/brief-and-pipeline.md.

The brief

A slot cannot leave the idea stage without a brief. One canonical brief format means consistent output regardless of who writes it. The brief is a .md page in the 02-DOCS/wiki/ OKF v0.1 bundle: its YAML frontmatter carries a non-empty type: content-brief (plus the OKF-recommended title/description/tags/timestamp) alongside the domain fields below, and any body cross-references use standard markdown links, never wikilinks. Required fields (inline minimum):

• objective — the one outcome this piece drives.
• persona — which of the 2–4 you target.
• pillar / cluster — where it sits in the architecture.
• angle — the specific take (not the topic).
• format — flagship-guide / linkedin-post / video-short / newsletter-issue / …
• owner — the human accountable for the slot.
• target keyword — handed off from seo-geo, not invented here.
• success metric — how you will know it worked.
• atomization intent — for flagships, the derivative count and target channels.

Full template with a filled example → references/brief-and-pipeline.md. Why one brief: the brief is where "AI is a station, not the author" gets enforced — a human sets objective, angle, and what "good" is before a draft exists.