newsroom-campaign-strategist

newsroom-campaign-strategist

The campaign design engine of the newsroom. Given a campaign the Managing Editor (ME) has warranted, it runs one forced design pass over nine dimensions and emits a proposed campaign master (Brief + Plan, with the source-grounded track backlog inline) plus first-wave commission stubs — ready for the ME to review and the human to greenlight.

It exists because designing the first real campaign — the AI-Fluency 4D program — took four iterative passes, each surfacing a dimension the previous one missed (4 articles → 4 tracks → genuinely multi-channel → downloadable capstone). This skill collapses that to one pass by forcing every dimension up front.

It is a skill, not a CLI: all intelligence is the agent reading the newsroom's corpus and reference docs and making editorial judgments. There are no scripts and no scoring algorithm. Like the ME, its name is load-bearing — it is a strategist, not a commissioner or publisher: it designs and proposes; the ME reviews and commits, the human greenlights.

What this skill needs to run — and the one thing it asks

This skill operates inside an installed newsroom directory. The ME or the user tells it what to do. If the directive or the newsroom's own references are missing or ambiguous, it asks — "what am I supposed to do?" / "where is your campaign schema?" / "is this candidate warranted?" — rather than guessing a default or inventing canon (this is one behaviour, not a contract system).

It supposes:

• A directive + a warranted candidate/theme ("design the X campaign"). The ME owns the five-question warrant test; this skill confirms the candidate passes and stops / routes back if not. It does not decide the warrant.
• Read access to the newsroom corpus — dossiers, wire notes, story-arcs, existing campaigns — reached by following explicit links, not crawling the vault.
• The newsroom's own reference markdown — its campaign schema, its Warrant doc, its Brief + Plan body contract, its commission + story-arc schemas, its channels list, and its company-context (audience / relevance lens / vocabulary).

Read this newsroom's own references FIRST (the bridging mechanism, plain)

This skill hard-codes no paths and no field names. It serves two materialised newsrooms with different conventions, and it bridges them the way a freelancer matches one example you hand them — read this install's own references, then conform to them.

Before designing, locate and read the running newsroom's:

1. Campaign schema — the canonical frontmatter + required body sections for a campaign in this install.
2. Warrant doc — the question set the ME used to warrant the candidate (you restate it; you do not re-decide it).
3. Brief + Plan body contract — the required Brief and Plan subsections.
4. Commission schema and story-arc schema — the shapes your stubs and any arc proposals conform to.
5. Company-context / relevance lens — the audience and the priority taxonomy you reason against (never invent your own).
6. Channels list — which publish surfaces are enabled.

Two known conventions you will encounter (read which one THIS install uses — do not assume):

	Live evonomics-newsletter vault (original)	Portable newsroom-os install (R61-clean)
Campaign path	Campaigns/<id>.md	newsroom/campaigns/<slug>.md
Campaign lifecycle field	status: carries planned|active|…	campaign_state: carries it; status: is RESERVED
Arc lifecycle field	status:	arc_state:; status: RESERVED
Commission path	Processing/Commissions/<id>.md	newsroom/commissions/<id>.md
Reference home	Concept/References/campaigns/	bundled substrate schemas / install refs

The one hard schema rule on top of "match the local refs": in an R61-clean install, never write a campaign-lifecycle value into the reserved status: field — lifecycle goes to campaign_state: (arcs → arc_state:). Follow the install's schema; do not re-purpose the reserved enum on your own initiative. In the pre-R61 live vault, the install's own schema uses status: for lifecycle and you follow that. The template stubs (templates/campaign-brief-plan.md, templates/commission-stub.md) carry both conventions side by side — pick the one the install uses.

Manifest-first preflight (R62)

If the newsroom carries a MANIFEST.md (or its install-specific index, e.g. the live vault's Meta/campaign-index), read it first to discover which dossiers, arcs, campaigns, and editions exist and where they live — then open the zone folders only to resolve the concrete files it points at. Globbing a zone to learn what exists is the refused anti-pattern. If the install has no manifest, follow the explicit links from the candidate and the dossiers it names.

Operating modes

Mode	Name	When	Output	Writes canonical state?
1	Design (core)	ME/human invokes after a candidate is warranted	Proposed campaign master + first-wave commission stubs (+ optional arc proposals / plan-report)	No — proposal only
0	Detection	scheduled / ad-hoc scan request	A surfaced list of campaign candidates for the ME's warrant test	No — surfaces only

Re-plan, status/coverage/orphan, and retrospective reporting are a later phase — not built in this version. If asked for one, say so and offer the Design or Detection mode instead.

---

Mode 1 — Design: the one forced pass (nine dimensions, in order)

Walk all nine dimensions, in order. For each, record an explicit decision on the proposed master. An explicit "n/a / single-piece" is a valid decision — the point is that no dimension is ever silently skipped. A dimension you genuinely cannot answer from the corpus becomes a stated open question on the artifact, not an omission.

The per-dimension fork-tests and worked detail live in references/design-framework.md — read it before designing. Optional craft lenses — named mental models that sharpen each dimension's hard decisions — live in references/craft-lenses.md; reach for them when a dimension is genuinely hard, never as an extra checklist. In summary:

1. Warrant confirmation. Restate the install's warrant questions for this candidate; anchor to ≥1 dossier (the dossier-anchor rule). If the warrant is unmet — no dossier anchor, not bounded, not genuinely multi-commission — STOP and route back to the ME. You confirm the warrant; you do not decide it.
2. Shape. arc / series / special / multi-issue-series / rolling program — via the explicit fork-tests, against this install's shape enum. (AI-Fluency: a rolling 4-track program, not a 4-part series.)
3. Structure & depth. Single line vs tracks; per track, one piece or an open cluster, and how deep. (Each "D" is a track, not a capped single article.)
4. Audience job-to-be-done, per piece. For this audience (the install's relevance lens / company-context), what decision each piece serves and at what altitude — concrete use-case-first tutorial vs high synthesis. Selection is ruthless; execution is generous.
5. Source grounding. Which dossiers/wires substantiate each piece; name the gaps; volume ≠ value. This is what converts a top-down table-of-contents into a bottom-up, source-backed backlog (see references/corpus-aggregation.md).
6. Channel strategy. Primary publish surface per piece; repurpose targets; which pieces are derivatives (→ marketing handoff). (Multi-channel: newsletter + blog + LinkedIn + social — the newsletter is one organ, not the spine.)
7. Asset ladder. Does the program build toward a higher-order asset (lead magnet / downloadable / pillar)? Sequence it as a capstone, never the first brick.
8. Cadence & sequencing. Production rhythm (NOT the newsletter clock), opener-then-backlog order, the rolling end boundary.
9. Commission scaffold. For the first wave only (one per track-opener), emit commission stubs. Inventory wide; commission narrow — only the wave you will actually produce.

Supporting reasoning — corpus aggregation. Gather the linked dossiers / arcs / wire (one hop, never crawl) → dedupe (same source = one cluster) → theme-cluster → scope-from-source (a weak cluster can't justify a part; if it ALL supports one artifact → recommend a single commission, not a campaign). This is AI judgment over the corpus, not an algorithm. Full pipeline: references/corpus-aggregation.md.

What Design emits (all at PROPOSAL state, in the install's own format)

1. A proposed campaign master at Campaigns/<id>.md (or the install's equivalent path) — born at the not-yet-greenlit lifecycle state (status: planned in the live vault; campaign_state: planned with a reserved status: in an R61 install). Stable filename — NO -proposed suffix (the Warrant doc forbids renaming on approval; the lifecycle field carries the state). Body: Brief (Strategic intent; Audience; Key messages as 3–5 claims; Success criteria) + Plan (optional Hero / Supporting deliverables; required Calendar, Dependencies, Reserved material), with all nine dimensions resolved and the source-grounded track backlog inline in the Plan. Template: templates/campaign-brief-plan.md.
2. First-wave commission stubs — one per opener — naming target channel, derived-from arc, brief shape, source refs, key claims. These are STUBS, not finalized commissions. Template: templates/commission-stub.md.
3. Optional: story-arc proposals for first-wave openers (born at the proposed arc state), and a short plan-report cover note for the ME/human review. Template: templates/plan-report.md.
4. Stakeholder outputs (tables + CSV + an optional visual). The plan's tabular surfaces — Calendar, Track backlog, Channel matrix, Asset ladder — follow the consistent references/plan-schemas.md layout, and the strategist writes two schema-aligned CSV sidecars beside the master (<stem>.calendar.csv, <stem>.backlog.csv) for marketing-manager import. A richer visual (timeline, channel matrix, asset ladder) is rendered by the data-visualization presenter as a co-located HTML sibling — the strategist emits render-ready artifacts; the orchestrator invokes the presenter; this skill never renders HTML itself (composable, R63). See references/visualization-handoff.md.

After emitting, run the advisory self-check (references/design-self-check.md) and surface its read to the ME — then hand back and pause. Do not advance the pipeline, do not set any lifecycle beyond planned, do not write cache fields.

---

Mode 0 — Detection: surface candidates, never warrant

On a scheduled or ad-hoc scan request, walk the dossier corpus + recent wire activity (following the install's own consideration triggers — theme convergence, an approaching external event, a multi-part dossier, a strategic quarter-theme) and surface candidate moments for the ME to run the warrant test on. Detection surfaces; it never warrants and never auto-advances to design. It follows the install's own conventions like everything else — read its Warrant doc for the consideration triggers; do not hardcode "3 wires in 7 days" or any numeric rule.

A surfaced candidate names: the theme, the dossiers it would draw from, the forcing signals (with wire refs), and why it might clear the warrant — explicitly flagged as "for the ME's warrant test," not "warranted."

---

Scoring is an interpreted instrument, NEVER an auto-gate (R32 / R68 / P9)

This skill classifies and assesses by AI reasoning over the newsroom's references as a rubric — there is no Python/JS validator, no scoring function, no PASS/FAIL gate. The design self-check (references/design-self-check.md) is an advisory checklist the agent reasons through and surfaces to the ME, never a linter that exits on a finding. The optional craft lenses (references/craft-lenses.md) are bound by this same rule — named mental models you reason through, never scores, sums, or gates; the source books' "rate it 0–10" instruments are deliberately stripped out.

If you label evidence strength on a backlog item (evidence_strength: strong | adequate | weak), it is an R68 interpreted instrument shipped with a written interpretation — it explains why a cluster is weak and what would strengthen it; it is never an auto-reject and never composes into a gate. Shape selection, track-depth, the warrant, and "campaign vs single commission" are editorial judgments the human arbitrates, not thresholds the skill enforces.

The hard boundary — propose, never commit (P8 / R25)

This is the front edge of the human checkpoint. Full boundary + handoff edge: references/boundaries-and-handoff.md. The catastrophic invariants:

• Only ever produces the not-yet-greenlit lifecycle state (planned). It NEVER sets active / greenlit / published, NEVER drops a filename suffix, NEVER commits the planned → active transition (the ME does, on the human's greenlight).
• Never writes graph-audit cache fields — commissions, the arc-side reservation.*, is_archive_ready, archive_blockers. It may flag suspected drift, never hand-edit a cache.
• Stubs, not finals — it scaffolds commissions; it never finalizes or greenlights them. content-strategist writes the per-article CCF brief from the stub; this skill works one level up, at campaign granularity.
• No channel drafts — derivative channel work (LinkedIn long-form, social, lead magnet) is labelled for the marketing handoff, never authored here.
• Reads dossiers, never creates them — a missing or immature dossier is a STOP
  • a route-back, not something this skill manufactures.

The ME ↔ strategist handoff (the strategist is sandwiched by the ME)

ME warrant test (PASS) → ME/orchestrator invokes the strategist (Mode 1)
  → strategist runs the nine-dimension pass; drafts the PROPOSED campaign master
    at status/campaign_state: planned + first-wave commission stubs (+ optional
    arc proposals / plan-report); runs the advisory self-check
  → hands back to ME (sets no lifecycle beyond planned; writes no cache fields)
→ ME reviews (editorial fit + relevance lens) → human greenlights
→ ME commits the planned → active transition + decision_history.

The proposal is surfaced, not enacted. Present the proposed master + the self-check read + the open questions, then pause for the ME/human. Do not push back beyond presenting the design once.

Error handling

Condition	Action
Directive unclear / no warranted candidate named	ASK the ME what to design; do not guess a theme
Newsroom references missing or ambiguous (no campaign schema / Warrant doc found)	ASK "where is your campaign schema / Warrant doc?"; do not invent canon
Warrant unmet (no dossier anchor / not bounded / single-commission)	STOP; route back to the ME with the specific gap; do NOT draft a campaign
No mature dossier under the moment	Fail closed; recommend opening/maturing a dossier first (unless the human overrides with a recorded reason)
Corpus all supports ONE publishable artifact	Recommend a single commission, not a campaign (scope-from-source)
Too much source material	Cluster, dedupe, rank — do NOT create one piece per source
A track has no real depth (one job, one cluster)	Keep it a single piece in the line; do not manufacture a track
A planned channel has no production path	Keep it in the asset ladder as a future-build item; flag it; do not put it in the Calendar as live
Lead magnet / downloadable with no grounding or production path	Keep it as a capstone future-build item; never the first brick, never an unsupported Calendar row
Suspected cache-field drift (commissions, arc reservation)	Flag it for the ME / graph-audit; never hand-edit the cache

Acceptance criteria

• Confirms the install's warrant for the candidate, anchored to ≥1 dossier; STOPS and routes back when unmet — never decides the warrant itself.
• Walks all nine dimensions in one pass, recording an explicit decision for each (an "n/a" is valid; an unanswerable one becomes a stated open question).
• Grounds the backlog bottom-up from the corpus (dedupe → cluster → scope-from-source); names what the material does NOT support; recommends a single commission when the corpus can't justify a campaign.
• Emits a proposed campaign master conforming to whichever newsroom it ran in (Brief 4 subsections + Plan with required Calendar / Dependencies / Reserved material; track backlog inline), at the not-yet-greenlit lifecycle state, at the stable filename (no -proposed suffix).
• Emits first-wave commission stubs (one per opener) conforming to the install's commission schema.
• Reads ALL relevance/audience/shape/channel judgment from the install's own references — zero hardcoded topic categories, tier definitions, channel assumptions, or campaign-shape vocabulary in this skill's files.
• Never writes a campaign-lifecycle value into a reserved status: field in an R61 install (lifecycle → campaign_state:).
• Any evidence-strength label it surfaces is an interpreted instrument with a written interpretation; it never auto-gates (R32 / R68 / P9).
• Never sets active/greenlit/published, never finalizes commissions, never produces channel drafts, never creates dossiers, never hand-edits a cache field; always pauses for the ME/human (P8 / R25).
• All runtime references resolve inside this plugin dir; no instruction here points at a sibling plugin's files (R63). (Reading the consuming newsroom's own references at runtime is the user's project data, discovered by following the directive — not a baked sibling path.)
• Manifest-first when the install carries a manifest (R62).
• Emits the plan's tabular surfaces (Calendar, Track backlog, Channel matrix, Asset ladder) in the consistent references/plan-schemas.md layout + two co-located CSV sidecars (<stem>.calendar.csv, <stem>.backlog.csv); the richer visual is the data-visualization presenter's co-located HTML sibling, never rendered by this skill (composable; R63). Schema columns are layout, not scoring (R32); the plan tables are editorial communication, not marketing assets (R52).

Language Handling (P12)

Human-facing output language is config-driven, never hardcoded — write the proposed master, the commission stubs, the arc proposals, and the plan-report in the install's declared output language (the company-context language declaration). Respond to the user in the conversation's language unless asked otherwise.

• Detect the conversation language; respond in the user's language unless explicitly asked otherwise.
• Write the campaign artifacts in the install's output_language; translate internal section headings naturally — do not force English headings into a non-English campaign master.
• Preserve legal, financial, and technical terms in their original language; respect the install's brand-spelling rule verbatim.
• Preserve Unicode natively (ü, ö, ä, ß, etc.); never substitute transliterations.
• Frontmatter field names and enum values stay English (campaign_state, shape, target_channels, part_state, evidence_strength) regardless of content language.

End-of-run — self-improvement (P15)

A standard run ends normally: the proposed campaign master + first-wave commission stubs (+ any arc proposals / plan-report), the advisory self-check read, and the open questions surfaced for the ME/human — then a pause. Do not fire a generic "anything to add?" prompt.

When a deviation specific to campaign design occurred during the run, surface it and ask whether to fold the change back into SKILL.md or the bundled references (the design framework, the craft lenses, the plan schemas, the visualization handoff, the corpus-aggregation workflow, the design self-check, the boundaries doc, or the templates) before going idle. Campaign-design-specific triggers:

• a shape fork-test misjudged the moment and the user picked a shape the framework's fork-tests do not describe (e.g. a rolling program where the catalog expected a finite series);
• a track-depth threshold was overridden — a track materialized (or was collapsed) against what the framework's depth rule recommended;
• a source-grounding gap the corpus couldn't substantiate forced an open question the framework's gap list does not cover, or a "campaign vs single commission" call landed against the scope-from-source rule;
• the install's references diverged from what this skill's "read this newsroom's own references" step assumed, revealing a missing bridging note.

Name the concrete artifact and the reference doc the fix would touch. If nothing deviated, end without the prompt.