contentforge

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.