v3.16.0 — Reliability & Truth release

The deepest engineering pass since v3.0: a five-layer audit (orchestration, agents, skills, scripts, configs) implemented end to end. Tests 53 → 143.

Highlights

• Checkpoint/resume actually works now — the master skill saves every phase to a canonical run directory (~/.claude-marketing/{brand}/runs/{run_id}/); /contentforge:resume works for skill-started runs, honors mid-loop rework state, and reloads run metadata.
• File-based phase handoff contract — every agent reads prior artifacts by path (no more pasted drafts), with a full Pipeline Contract table: inputs → outputs → gate → loop target for all 10 phases.
• Measured quality gates — new scripts/text-metrics.py computes burstiness, Flesch-Kincaid, keyword placements, and structured-element counts; the orchestrator verifies gates instead of trusting subagent self-reports.
• Keyword-density gate retired — placement-based SEO gate (2026 practice), density advisory only; LSI-keyword advice removed.
• GEO structure protection — Phase 6 emits a protected-structure manifest; the humanizer must preserve answer blocks/tables/lists or its gate fails.
• EU AI Act Article 50 (applicable Aug 2, 2026) — AI-disclosure step in the publish path: C2PA for .docx, disclosure line for CMS, per-platform AI-label fields in social specs.
• Humanizer 29 → 35 patterns with a defined AI-signal scoring formula; "evasion" framing removed.
• Social platform refresh — TikTok (incl. photo posts), Bluesky, YouTube Shorts added; Reels 180s; X Premium limits.
• Script hardening — new scripts/_common.py: one slugifier (fixes the Cowork sync-path bug for brand names with spaces), atomic JSON writes, Windows UTF-8 guard, real exit codes; .docx generator embeds images, TOC field, page footer, nested lists.
• Truth pass — connector docs match the shipped (empty) .mcp.json, "11 quality gates" corrected to the real 10, stale version footers stripped, ~50 broken slash references fixed, fabricated example stats replaced with labeled synthetic ones.

90 new tests including release-consistency drift locks (version literals, slash-reference resolution, threshold-config alignment, phase/gate-count claims, platform-spec keys).

Full details in CHANGELOG.md.

🤖 Generated with Claude Code

v3.15.3 - README sync patch

README-sync patch — Release notes catch-up + test-coverage extension.

After v3.15.2 shipped, the user flagged that several README sections across the suite had stale version refs. CF's specific gap: Release notes still ended at v3.15.0 — v3.15.1 (release-consistency tests) and v3.15.2 (market refresh) had shipped without README updates.

Fixed (CF README)

• Added v3.15.3 (this), v3.15.2, v3.15.1 entries to "## Release notes" section
• README hero callout + Supported surfaces heading + version badge all bumped to v3.15.3

Changed

• All 9 CF version declarations 3.15.2 → 3.15.3

Notes

• DMP's v3.14.1 patch extends its tests/test_release_consistency.py with section-heading + anchor-sync checks. CF's release-consistency suite already had test_readme_supported_surfaces_section_mentions_canonical (added in v3.15.1) — that's why CF wasn't bitten by the same heading-staleness issue DMP was.
• Zero pipeline change.

---

v3.15.2 - June 2026 market-refresh sync

June 2026 market-refresh sync — model registry + MODEL-CURATOR docs refreshed (docs-only, no runtime change).

Mirrors the DMP v3.14.0 suite-wide refresh. ContentForge's content pipeline already routes through the resolver, so the alias re-pointings flow through automatically.

Added — registry-handled retired status

scripts/resolve_model.py now unconditionally rewrites retired model IDs to their replacement_id. Net effect: any cached config referencing now-dead model IDs (Gemini 2.0 family, Gemini 3 preview image variants, Veo 2/3 family) gets routed to the working replacement instead of HTTP 404. New test test_retired_falls_forward_unconditionally covers this.

Added — --check-params scanner for Anthropic param 400 protection

python scripts/resolve_model.py --check-params <file> flags unsafe temperature / top_p / top_k near Claude Opus 4.7+ targets. Pre-flight scan of contentforge/scripts/*.py was clean.

Added — model registry rebuilt against vendor primary docs

47 entries verified against Anthropic / OpenAI / Google deprecation pages. Notable adds: claude-opus-4-8, gpt-5.5 family, gpt-image-2, gemini-3.1-pro-preview. Notable retired/deprecated: Gemini 2.0 family (shutdown 2026-06-01), Veo 2/3 family (shutdown 2026-06-30), Gemini 2.5 family (shutdown 2026-10-16), Imagen 4 (deprecated 2026-06-15).

Added — docs/MODEL-CURATOR.md refresh

Aliases table refreshed; new § Parameter compatibility — Claude Opus 4.7 and later explains the HTTP 400 risk.

Changed

• All 9 version declarations bumped 3.15.1 → 3.15.2
• README "Just shipped" callout updated for v3.15.2
• Registry last_updated 2026-06-28

Tests

• 53/53 passing

---

v3.15.1 - release-consistency test suite

Test-infrastructure polish — release-consistency suite.

A short follow-up to v3.15.0 that hardens the release pipeline against the kinds of cross-manifest drift that escaped earlier ships. Inspired by DMP's v3.13.1 polish round.

Added — Release-consistency test suite (tests/test_release_consistency.py, +30 tests)

The suite catches drift before it reaches users by checking:

• All 7 platform manifest versions are in sync (5 Claude-family + Hermes plugin.yaml + OpenClaw)
• The Hermes __init__.py PLUGIN_VERSION constant matches the canonical version
• The README version badge matches the canonical version
• The README ## Supported surfaces (vX.Y.Z) section heading matches the canonical version
• The README "Just shipped — vX.Y.Z" hero callout matches the canonical version
• The CHANGELOG's most recent ## [X.Y.Z] header matches the canonical version
• All 5 Claude-family manifest descriptions are byte-identical
• Every Claude-family description mentions the actual 21 skills count
• The README test-count badge matches the actual count of def test_* methods
• All 7 native platform install commands appear verbatim in the README
• All 12 critical README sections (Why ContentForge, Supported surfaces, Quick start, What ContentForge does, Architecture, Connectors, Troubleshooting, Updating, FAQ, Cross-platform compatibility, Release notes, plus an 8-platform name-mention check) are present
• Every internal anchor link in the README resolves to a real heading

Test count: 23 → 53. All passing.

Changed

• README test badge bumped: tests-23%2F23 → tests-53%2F53
• README hero "Just shipped" callout updated to mention v3.15.1 + new test count
• All 8 version declarations bumped to 3.15.1: .claude-plugin/plugin.json, .codex-plugin/plugin.json, .cursor-plugin/plugin.json, .github/plugin/plugin.json, gemini-extension.json, openclaw.plugin.json, plugin.yaml, __init__.py

Why this matters

The v3.15.0 ship surfaced two patterns we hadn't tested for and almost shipped broken:

1. Manifest version-string drift across the 7 platform files when a release rushes
2. Section-heading staleness when the canonical version moves but the heading doesn't follow

Both are now caught by pytest tests/test_release_consistency.py (or python -m unittest discover -s tests). Zero runtime behavior change.

---

v3.15.0 - native Hermes Agent + OpenClaw

Multi-harness expansion: native Hermes Agent + native OpenClaw + test suite.

Brings ContentForge into parity with DMP v3.13.0+ on cross-platform support. Every claim verified against primary platform docs.

Added — Native Hermes Agent plugin

• plugin.yaml at repo root with required fields (name, version, description, author, license, homepage). Zero env vars, zero global hooks (matches the rest of the suite's policy).
• __init__.py at repo root exposing register(ctx) that Hermes calls at plugin load. Walks the skills/ directory and exposes all 21 ContentForge skills via ctx.register_skill(name, path). Defensive coding throughout — stdlib only; if Hermes API differs from spec, the adapter logs and degrades gracefully instead of crashing. Includes an audit() introspection function for pre-install sanity checks.
• Install command: hermes plugins install indranilbanerjee/contentforge.
• Spec source: https://hermes-agent.nousresearch.com/docs/guides/build-a-hermes-plugin
• Targets Hermes Desktop v0.15.2 (public preview June 2 2026).

Added — Native OpenClaw manifest

• openclaw.plugin.json at repo root with required id + configSchema, optional name/description/version/skills: ["./skills"]. OpenClaw auto-detects our existing .claude-plugin/plugin.json as a Claude-compatible bundle fallback, but shipping the native manifest enables ClawHub marketplace eligibility + first-class discoverability.
• Install command: openclaw plugins install git:github.com/indranilbanerjee/contentforge.
• Spec source: https://docs.openclaw.ai/plugins/manifest

Added — Test suite (0 → 23, all passing)

• tests/test_hermes_adapter.py (12 tests) covering plugin.yaml schema (name / version / semver / description / provides_hooks: [] / requires_env: []), adapter import smoke, register() against mock ctx (all skills register), graceful degradation when ctx is missing register_skill / is None, version consistency between plugin.yaml and init.py.
• tests/test_openclaw_manifest.py (11 tests) covering manifest existence, id required + kebab-case + matches Claude plugin name, configSchema validation, skills field points at ./skills directory that exists, version matches canonical Claude plugin, no unexpected top-level fields, cross-manifest version consistency.
• tests/run_all.py runs everything: python tests/run_all.py → 23/23 passing.

Changed

• All 5 platform manifests bumped to v3.15.0. Description (where it changes) reflects new Hermes + OpenClaw support.
• README "Supported surfaces" table now has 8 rows (added Hermes Agent + OpenClaw).
• Added "Works on 35+ additional Agent Skills platforms" callout pointing at the skills/ folder for any Agent-Skills-compatible client.

Why no breaking changes — each platform reads its own manifest path

• plugin.yaml read ONLY by Hermes
• __init__.py executed ONLY by Hermes (Claude Code doesn't auto-execute Python files)
• openclaw.plugin.json read ONLY by OpenClaw
• Auto-connecting MCPs unchanged (still empty .mcp.json)
• Global hooks unchanged (still empty hooks/hooks.json)
• Skill descriptions unchanged
• Claude Code + Cowork behavior byte-identical to v3.14.0

v3.14.0 - distribution + context-efficiency polish

Distribution & context-efficiency polish — discoverability + leaner pipeline-phase loads.

Changed

• Plugin descriptions trimmed to ~150 chars across all 5 manifests (.claude-plugin/, .codex-plugin/, .cursor-plugin/, .github/plugin/, gemini-extension.json). Install-UI now reads as one clear sentence across Claude Code, Codex, Cursor, Copilot CLI, and Antigravity. Long-form positioning lives in README + interface.longDescription (Codex). Inspired by the Understand-Anything distribution pattern (35k★).
• Skill count corrected from "19" to actual "21" in plugin manifests + per-platform manifests.
• README hero rewritten pain-first. Opens with the real scenario the plugin solves ("You need to ship 30 articles this quarter that pass GPTZero, sound human, cite real sources…") then states what the plugin does.
• GitHub repo topics curated to 20-max with platform-skill topics added: cursor-plugin, copilot-cli-plugin, gemini-cli-extension joined claude-code / claude-plugin / openai-codex / agent-skills for discoverability via GitHub's topic browser.
• Context-efficiency callout added to the 10 heaviest skills (cf-style-guide, cf-social-adapt, cf-brief, contentforge, cf-analytics, cf-connect, cf-publish, cf-template, cf-audit, cf-integrations). Tells the agent to grep-before-read references/ and humanization-patterns.json, pass earlier-phase outputs by path + line range (not by reloading), and on /contentforge:resume load only the failed phase's state.

Unchanged

• 21 skills (all frontmatter intact, names match folders, all pass Codex [a-z0-9-]+ regex)
• 13 specialist agents
• 9 commands
• 11-phase pipeline + 11 quality gates + per-phase checkpointing
• 29-pattern AI-detection humanizer
• C2PA .docx signing
• Shared model curator + dual-copy save under ~/Documents/ContentForge/<brand>/
• Zero global hooks, zero auto-connecting MCPs (.mcp.json remains gitignored)

How to update

/plugin update contentforge@neels-plugins
/reload-plugins

If on Cowork / claude.ai / Desktop: Plugins panel → Update.

---

v3.13.0: real native manifests for 5 verified agent surfaces

Real native manifests for 5 verified agent surfaces. Replaces the v3.11/v3.12 era invented manifests (correctly removed in v3.12.11) with verified-real native manifests against the platforms' published schemas.

Supported surfaces (v3.13.0)

Surface	Manifest path	Install command
Claude Code (CLI + IDE extensions) + Anthropic Cowork	.claude-plugin/plugin.json	/plugin install contentforge@neels-plugins (Cowork: Plugins UI)
OpenAI Codex (CLI + IDE + App)	.codex-plugin/plugin.json	codex plugin marketplace add indranilbanerjee/neels-plugins then codex plugin install contentforge@neels-plugins
Cursor 2.5+	.cursor-plugin/plugin.json	/add-plugin contentforge@https://github.com/indranilbanerjee/contentforge in any Cursor Agent chat
GitHub Copilot CLI	.github/plugin/plugin.json	copilot plugin marketplace add indranilbanerjee/neels-plugins then copilot plugin install contentforge@neels-plugins
Google Antigravity 2.0 (CLI + IDE)	gemini-extension.json at repo root	agy plugin install https://github.com/indranilbanerjee/contentforge

Not changed

• Zero changes to skills (19), commands, agents (13), scripts, hooks, MCP
• ContentForge behavior in Claude Code + Cowork byte-identical to v3.12.11
• v3.12.10's three Cowork-with-Drive flows untouched
• C2PA signing, humanizer, fact-checker, internal linking, .docx export — all unchanged

See CHANGELOG.md for full per-platform caveats.

v3.12.11: honest positioning — Claude Code + Cowork only

Text-only honesty cleanup. Zero functional change for Claude Code + Cowork users.

A May 2026 deep research pass confirmed that the v3.11 / v3.12 era .codex-plugin/, .cursor-plugin/, .antigravity/ manifests and the GitHub Copilot CLI auto-discovery claim did not match the platforms' actual install specs:

• Antigravity uses gemini-extension.json at repo root — not .antigravity/plugin.json.
• OpenAI Codex uses the .codex-plugin/plugin.json path (correct), but the schema we hand-rolled was invented. Real schema: developers.openai.com/codex/plugins/build.
• Cursor plugin format we shipped was not a real Cursor manifest path.
• GitHub Copilot CLI auto-discovery of .claude-plugin/plugin.json was unverified.

Supported surfaces from v3.12.11 onwards: Claude Code (CLI + IDE extensions) + Anthropic Cowork.

Real OpenAI Codex / Cursor / GitHub Copilot CLI / Google Antigravity 2.0 support is on the roadmap. Research saved at memory/{antigravity,codex}-plugin-spec-may-2026.md for future build-out.

Removed

• .antigravity/plugin.json — wrong path entirely
• .codex-plugin/plugin.json — schema was invented
• .cursor-plugin/plugin.json — invented format
• docs/cross-platform-install.md — documented install commands that did not work

Changed (text-only)

• .claude-plugin/plugin.json — description rewritten; misleading keywords dropped; version 3.12.10 → 3.12.11
• README.md — hero, badges, install matrix, cross-platform compatibility table row, Release notes, and credits updated; "5 platforms" badge removed
• .github/PULL_REQUEST_TEMPLATE.md — platform checkbox list reduced to Claude Code + Cowork
• SECURITY.md — scope and reporting fields updated to Claude Code + Cowork only

Not changed

• Zero changes to skills/ (19), commands/, agents/ (13), scripts/, hooks/hooks.json, .mcp.json, .mcp.json.connectors-reference
• Plugin behavior in Claude Code + Cowork byte-identical to v3.12.10
• v3.12.10's three Cowork-with-Drive flows (cross-session checkpoint resume, brand-profile read-back, multi-team namespace isolation) untouched
• C2PA signing, humanizer, fact-checker, internal-linking, .docx export — all unchanged

See CHANGELOG.md for the full history. Historical v3.11.0 / v3.12.0 entries are preserved as historical record.

v3.12.10 — Closes Cowork+Drive roadmap (profile read-back + cross-session resume + multi-team)

[3.12.10] - 2026-05-26

Closes the three v3.12.9 roadmap items + fixes the /plugin scope error.

v3.12.9 shipped Cowork-with-Drive routing for the final .docx but deferred three items: (1) cross-session checkpoint resume, (2) Drive-as-input read-back of existing brand profiles, (3) multi-team namespace isolation. v3.12.10 ships all three. Also fixes a long-standing documentation error: the /plugin slash command family was wrongly documented as working in Cowork — it doesn't (only Claude Code CLI + IDE extension).

Added

• scripts/drive-sync-state.py — single source of truth for the local-side state that backs the Cowork+Drive routing. Three concerns: (a) Cowork+Drive root config (per-environment, set by cf-cowork-setup), (b) brand profile sync state (hash-based — local profile.json SHA-256 vs last-uploaded hash; agent uses this to decide whether to call the Drive MCP), (c) per-run checkpoint pending list (which phase artifact files still need uploading). All actions are JSON in / JSON out. Stdlib only. Architecture note: Python scripts cannot directly call MCP tools (MCPs are exposed to the agent, not subprocess), so this script manages the local state and the agent (output-manager / resume / cf-style-guide) reads it and performs the actual Drive transfers via the connected MCP.
• _shared/cf_drive_sync_test_harness.py — 15 tests against the drive-sync-state script, covering: config round-trip, never-uploaded vs uploaded vs modified profile states, per-run pending lifecycle (add → list → mark-uploaded), aggregate list-runs-needing-sync query, brand-slug consistency for names with spaces, content-hash stability, error handling for missing pending file, plus 2 integration tests that verify checkpoint-manager auto-marks files for Drive sync when Cowork is configured AND skips marking when running locally. All 15 pass.

Changed — three v3.12.9 roadmap items now closed

• scripts/checkpoint-manager.py save_phase() — automatically marks every saved artifact + _manifest.json as pending Drive upload when a Cowork+Drive config exists. Returns a drive_sync_hint block in the save response so the agent knows to consume the pending list. Local-mode (no Cowork config) is unchanged — no sync overhead. Closes roadmap item 2.
• agents/08-output-manager.md — new Step D0b consumes _sync-pending.json for the current run, iterates over pending files, uploads each via the Drive MCP to {drive_root}/_runs/{run_id}/<file>, and calls drive-sync-state.py --action mark-uploaded to record the Drive file ID. Now the full per-phase checkpoint history is in Drive — a future Cowork session can pull it for resume. Closes roadmap item 2 (orchestration side).
• commands/resume.md — new Step 0 runs in Cowork+Drive mode: before listing local runs, the agent uses the Drive MCP to list {drive_root}/_runs/, identifies any in-progress runs that aren't yet in the local sandbox, downloads their checkpoint files from Drive into ~/.claude-marketing/{brand}/runs/{run_id}/, and then lets the normal checkpoint-manager.py resume flow take over. Resume now works across Cowork sessions / browser tabs / sandbox recycles. Closes roadmap item 2 (resume side).
• skills/cf-style-guide/SKILL.md — new Step 0 (Drive read-back) and Step 6.5 (Drive write-back). On entry in Cowork+Drive mode, agent searches Drive for {drive_root}/_brands/{brand-slug}/profile.json; if found, downloads and marks synced (skipping the whole creation flow). On create/update, uploads the new profile to Drive. Closes roadmap item 1.
• skills/cf-cowork-setup/SKILL.md — Step 4 now asks the user for the Drive root folder name (default: ContentForge). Different teams pick different folder names → automatic namespace isolation. Config is written via drive-sync-state.py --action write-config (the canonical writer; format stays in sync with everything else that reads the config). Closes roadmap item 3.

Fixed — /plugin scope documentation error

Multiple docs claimed /plugin works in Cowork — verified wrong via Indranil's live Cowork testing on 2026-05-26. Corrected in:

• README.md — Quick start hero block, "Installs on 5 surfaces" table row, and step 1 of Quick Start all now correctly say: /plugin works only in Claude Code (CLI + IDE extension). In Cowork, use the Plugins panel in the UI. The Updating section is similarly corrected — Cowork is now explicitly named alongside claude.ai web and Claude Desktop as environments where /plugin doesn't work.
• MEMORY note — corrected. New rule: /plugin works ONLY in Claude Code (CLI + IDE extension). Cowork uses UI panel.

(CHANGELOG entries for prior versions are historical records and left intact even where they reference the old wrong rule.)

Architecture explanation (for future contributors)

The Python ↔ agent split in this release matters. Python scripts running in Cowork's sandbox cannot directly call MCP tools — those are exposed only to Claude (the orchestrator). So every "upload to Drive" operation is split across two layers:

1. Python side (drive-sync-state.py, checkpoint-manager.py) — writes state markers to local sandbox FS saying "these files need uploading to Drive" or "this brand profile differs from last-synced hash".
2. Agent side (output-manager, cf-style-guide, resume command) — reads those markers, performs the actual Drive read/write via whichever Drive MCP is connected (Anthropic platform integration, Pipedream, Composio, Zapier, Make), then calls back into Python (mark-uploaded / mark-downloaded) to update the sync state.

This split keeps Python scripts pure (no MCP dep, fully testable from local Claude Code) while still letting Cowork orchestrate Drive transfers via MCP. The 15-test harness exercises the Python side end-to-end; the agent side is documented in the skill/command/agent definitions but only fully exercisable in actual Cowork (because the MCP tools aren't visible from local).

Verified

• All 15 drive-sync state tests pass (config round-trip, profile hash transitions, checkpoint pending lifecycle, multi-run aggregation, brand-slug edge cases, hash stability, error handling, 2 checkpoint-manager integration tests)
• scripts/plugin-metadata.py --section environment correctly detects Cowork sandbox vs local Claude Code
• scripts/checkpoint-manager.py save returns a drive_sync_hint block that correctly reports cowork_drive_configured: true/false based on the live config state
• All previous CF v3.12.x test harnesses still pass (no regression)
• README counts still come from scripts/plugin-metadata.py (introduced v3.12.8 — no hardcoded staleness)

What still needs Cowork-side validation (you / Shreea)

These flows are documented and the Python side is tested, but the actual MCP interactions can only be verified in a live Cowork session:

• Brand profile read-back: start fresh Cowork session for a brand that was previously set up; verify cf-style-guide pulls profile.json from Drive instead of re-creating
• Checkpoint resume across sessions: start a content run in Cowork session A, complete Phase 1-3, close session, open Cowork session B, run /contentforge:resume, verify it picks up at Phase 4
• Multi-team namespace: two teams (or two test runs) using different drive_root_folder_name values; verify their data doesn't mix

If any of these fail in live testing, the bug is in the agent orchestration layer (not the Python side, which is fully tested).

v3.12.9 — Cowork-first: outputs auto-route to Google Drive

[3.12.9] - 2026-05-26

Architectural pivot: Cowork is now the recommended environment for marketing teams, with proper Google Drive routing for outputs.

User feedback during v3.12.8 testing was direct: Cowork is the friendliest Anthropic surface for non-CLI users (most marketing teams), Claude Code CLI is too technical for everyday team use, and "I want my team to use these things on the plugin in Cowork". v3.12.8 documented Cowork as "partial support" with the workaround being "use local Claude Code instead" — which contradicts how teams actually want to work.

v3.12.9 fixes this properly by adding environment-aware output routing: when ContentForge detects it's running in Cowork AND a Google Drive MCP is connected (Anthropic platform integration, Pipedream, Composio, Zapier, or Make), file outputs are uploaded to Drive instead of the ephemeral sandbox. The pipeline runs identically; only the delivery target changes. Teams can now use Cowork as their primary ContentForge surface with full output persistence.

Added

• skills/cf-cowork-setup/SKILL.md — /contentforge:cf-cowork-setup one-shot setup wizard. Verifies Cowork environment, checks for a Drive MCP (Anthropic platform integration preferred), creates the canonical Drive folder layout (My Drive/ContentForge/_brands/, _runs/, brand subfolders auto-created on first run), and stores the configuration so subsequent sessions auto-route. Run this once after install in Cowork; from then on, every /contentforge:create-content lands in Drive automatically. Includes the explicit "if no Drive MCP found" recovery path (Cowork → Settings → Integrations → Google Drive, 60 seconds).

Changed

• agents/08-output-manager.md — new Step D0 runs BEFORE the existing backend dispatch. Probes scripts/plugin-metadata.py --section environment. If cowork-sandbox is detected, scans the available tools list for any Drive MCP (Anthropic platform, Pipedream, Composio, Zapier, Make heuristics). When Drive is available, the agent uploads the final .docx to My Drive/ContentForge/{brand}/{content_type}/{YYYY-MM}/{slug}.docx via the MCP tool, captures the Drive URL, and surfaces it in the completion card — skipping the local-filesystem dispatch entirely. When no Drive MCP is available in Cowork, the completion card prominently warns the user that the file is ephemeral and offers three recovery paths (download from Cowork file panel, connect Drive integration, or switch to local Claude Code).
• commands/brand-setup.md — Step G.0 now runs the environment probe BEFORE the connector probe. The decision matrix splits on Cowork vs local: in Cowork with a Drive MCP, the brand profile is saved to Drive (My Drive/ContentForge/_brands/{brand-slug}/profile.json) so it persists across sessions and is team-shareable. In Cowork without Drive, the user is warned that local-only output is ephemeral and walked through the integration setup. Local Claude Code behavior is unchanged.
• skills/cf-environment/SKILL.md — the Cowork capability matrix is now split into two columns: "Cowork + Drive" (recommended for teams, all checkmarks) and "Cowork alone" (single-session only, warning). Removed the "for full functionality, switch to local Claude Code" framing — Cowork+Drive IS the full team setup as of v3.12.9.
• README.md cross-platform compatibility section rewritten to lead with "Anthropic Cowork + Google Drive — ✅ Recommended for teams" as the first row. Added a clear "How to pick" decision guide: marketing teams → Cowork+Drive; solo developers / content engineers → local Claude Code; strict on-prem data policies → local Claude Code. The previous v3.12.8 framing of "Cowork = Partial Support, use local instead" is replaced — Cowork is the recommended path for ContentForge's actual target audience.

Why this matters

ContentForge's target users are marketing operators producing client deliverables at scale — not CLI-native developers. The original local-Claude-Code-first design implicitly assumed the user could navigate ~/Documents/ContentForge/ in File Explorer and was comfortable with terminal tools. Teams trying to roll ContentForge out to non-technical contributors hit this immediately: "How do I install Claude Code on every marketer's laptop?" The answer is now: you don't — they all use Cowork in a browser, which they already have, and outputs land in your team's shared Drive automatically.

What still needs work (honest roadmap)

• Cross-session checkpoint resume in Cowork — the per-phase checkpoint files (scripts/checkpoint-manager.py) currently write to ~/.claude-marketing/{brand}/runs/{run-id}/ in the sandbox. For /contentforge:resume to work across Cowork sessions / browser tabs, the checkpoint manager needs to write to Drive too. This is the next iteration (v3.12.10).
• Drive-as-input — brand setup currently uploads the brand profile JSON to Drive but the read-back path (subsequent sessions reading the existing profile from Drive instead of regenerating it) requires cf-style-guide updates. Also queued for v3.12.10.
• Multi-team isolation — when multiple ContentForge users share the same Drive _brands/ folder, there's no per-user namespacing yet. Fine for an in-house team sharing one Drive; needs work for an agency running 50+ clients.

Verified

• Output-manager agent definition has the explicit Step D0 logic with detection heuristics for the 5 known Drive MCPs + a heuristic fallback for any tool name combining "drive" with "create"/"upload"/"write"
• brand-setup.md Step G.0 decision matrix covers all 6 combinations (Cowork+mcp, Cowork+none, Local+mcp, Local+service_account, Local+both, Local+none)
• README "How to pick" guide concretely names the three personas (marketing teams, solo developers, on-prem)
• cf-cowork-setup skill has explicit "if no Drive MCP" recovery (the 60-second Settings → Integrations path)
• All counts in cf-help still come from scripts/plugin-metadata.py (no regression to hardcoded values)