/contentforge

name: contentforge
description: "Produce a publication-ready, fact-checked, brand-compliant, SEO-optimized content piece through the full 10-phase pipeline: every phase dispatched to a dedicated subagent (researcher, fact-checker, drafter, visual annotator, scientific validator, structurer, SEO/GEO optimizer, humanizer, reviewer, output manager) behind 10 orchestrator-verified quality gates — three-layer fact verification, the 43-pattern humanizer pass, and 5-dimension reviewer scoring (approve >=7.0) — ending in a .docx with scorecard appendices. Triggers on \"/contentforge:contentforge\", \"write an article about\", \"create a blog post\", \"produce a whitepaper\", \"I need a fact-checked, publication-ready piece\", \"run the content pipeline\". This is ContentForge's front door: reads the brand profile, then routes onward to /contentforge:publish, /contentforge:social-adapt, and /contentforge:translate."
argument-hint: "[topic]"
effort: max

ContentForge — Enterprise Content Production

Transform a content requirement into a publication-ready, fact-checked, brand-compliant, SEO-optimized piece through a 10-phase autonomous agent pipeline (plus Step 0.5 title curation) with three-layer fact verification and 10 quality gates.

Context efficiency

Pipeline phase. **Grep before Read** for `references/`, `humanization-patterns.json`, brand voice profiles. Hand subagents artifact **file paths** plus a ≤10-line summary — never reload or inline full drafts (see Context & Handoff Rules). On `/contentforge:resume`, load `run.json` plus only the artifacts the next phase contractually needs.

Execution Protocol (CRITICAL — read first)

This skill orchestrates 10 phases plus Step 0.5 (Title Curation). **Each numbered phase MUST be executed by invoking its dedicated subagent via the `Task` tool — DO NOT generate the deliverable yourself in a single inference pass.** A single-pass generation skips the quality gates, fact-checking layers, humanizer 43-pattern catalog (29 core + 6 structure/framing + 8 detector-signal), and reviewer scoring that define ContentForge.

The one exception is Step 0.5: title curation is performed **inline by the orchestrator** (no subagent), because it requires user interaction and subagents must never wait on the user. Any subagent that needs a user decision returns a `{"status": "needs_user_decision", ...}` payload to the orchestrator, which owns all user interaction (including image-generation opt-in/approval).

Portable execution lane — platforms without subagent dispatch (Codex, ChatGPT, single-context clients)

If your platform has **no subagent/Task dispatch**, the pipeline still runs — sequentially, in this conversation, with nothing waived:

1. **Each phase's contract is its agent file.** Before executing a phase, Read `agents/{NN}-{name}.md` from the plugin directory and follow it as your instructions for that phase — INPUTS, EXECUTION STEPS, OUTPUT FORMAT, and the gate. The files are plain markdown written to be executable by whoever holds them; a subagent was always just a fresh context around the same text. 2. **Same artifacts, same names, same gates.** Write every phase artifact to the run directory exactly as the Pipeline Contract specifies, checkpoint after each phase, and run every gate script. The auditability of a run must not depend on which platform produced it. 3. **What changes:** ignore per-agent `maxTurns` (they bound subagent sessions, not you); "return as your final output" means "write the artifact, then continue"; Progress Updates print inline. What does **not** change: the phase order, the loop budgets, the gate criteria, and the rule that a needs-user-decision moment stops for the user. 4. **Context discipline replaces context isolation.** Subagents exist to give each phase a clean context. Without them, do not carry a phase's working notes forward — after checkpointing a phase, work only from the artifacts on disk, exactly as a fresh subagent would. 5. **Environment names:** on Agent Plugins 1.0 hosts the plugin root is `${PLUGIN_ROOT}` and persistent data is `${PLUGIN_DATA}`; where a command below says `${CLAUDE_PLUGIN_ROOT}`, use whichever of the two names your host defines. The scripts themselves accept both data-dir spellings.

Step 0 — Initialize the run (orchestrator only, before Step 0.5)

# 1. Create the checkpoint run (returns run_id). Capture run metadata so a
#    cross-session resume can recover keyword, audience, word count, and tone.
RUN_RESULT=$(python ${CLAUDE_PLUGIN_ROOT}/scripts/checkpoint-manager.py init \
    --brand <brand-slug> --topic "<topic>" --content-type <type> \
    --keyword "<primary keyword>" --audience "<audience>" \
    --word-count <n> --tone "<tone>")
# These flags land in run.json under meta.keyword / meta.audience /
# meta.word_count / meta.tone — use those exact key names when reading them back.
# Parse RUN_ID from the JSON result's "run_id" field.

# 2. Initialize the performance tracker for this run.
python ${CLAUDE_PLUGIN_ROOT}/scripts/pipeline-tracker.py --action init \
    --brand <brand-slug> --run-id "$RUN_ID" --content-type <type> --topic "<topic>"

Rules:

• `pipeline-tracker.py` is called by the **orchestrator only** — subagents never call it.
• Step 0.5 is **exempt** from tracker calls (no `phase-start`/`phase-end` for 0.5). After the title is confirmed, checkpoint it directly (see contract table).
• **If the user supplied their own draft** (`--source-draft <path>`, or they paste/dictate their own rough words), copy it verbatim to `{run_dir}/source-draft.md` here in Step 0 and set `"source_draft": true` in `run.json`. Do not clean it up on the way in — the mess is the signal. See "Bring your own words" below.

Required Per-Phase Workflow (Phases 1–8)

For every numbered phase:

1. **Mark phase start** (orchestrator):

   python ${CLAUDE_PLUGIN_ROOT}/scripts/pipeline-tracker.py --action phase-start --brand <slug> --run-id "$RUN_ID" --phase <N>