/cf-environment

name: cf-environment
description: "Detect where ContentForge is running (Cowork sandbox, local Claude Code on Windows/Mac/Linux, uncertain sandbox, or unknown) and report a capability matrix for that surface — which connector transports work, where files actually land, and whether /contentforge:resume survives sessions. Triggers on \"/contentforge:cf-environment\", \"will this work in Cowork\", \"where did my files save\", \"why is my Documents folder empty after a run\", \"check capabilities before a long pipeline\". Runs scripts/plugin-metadata.py --section environment and scans the session for Drive MCPs; pairs with /contentforge:cf-cowork-setup when Cowork+Drive wiring is missing. Diagnostic only — it reports the environment's limits and changes nothing."
argument-hint: "[--verbose]"
effort: low

/contentforge:cf-environment

Detect where ContentForge is running and report which of its capabilities work in that environment. ContentForge has different real-world behavior on each surface because filesystem access, MCP transports, and subprocess invocation all differ.

When to use this skill

• User asks "will my files actually save to my Documents folder?"
• User asks "does this work in Cowork?"
• User reports that `~/Documents/ContentForge/` is empty after a run
• Before kicking off a long (20-60 min) content pipeline, to set expectations
• During brand-setup, to decide between MCP-Drive and service-account routes

Behavior

Step 1 — Run the environment probe

python scripts/plugin-metadata.py --section environment

This returns JSON with `environment` (one of `cowork-sandbox`, `claude-code-windows`, `claude-code-mac`, `claude-code-linux`, `linux-sandbox-uncertain`, `unknown` — six possible values), filesystem indicators, a `cowork_warning` field that's non-null when a sandbox (confirmed or suspected) is detected, and a `signals` object (`strong` / `weak` lists) showing exactly which detection heuristics fired — useful for `--verbose` or when a user disputes the classification.

Step 2 — Present the capability matrix for the detected environment

Render one of the matrices below based on the JSON `environment`. The six values map to three matrices: `cowork-sandbox` AND `linux-sandbox-uncertain` both use the Cowork matrix (uncertain gets a one-line caveat first, see below); `claude-code-windows` / `-mac` / `-linux` share the local matrix; `unknown` gets its own fallback.

`cowork-sandbox`

Cowork is **the recommended environment for teams** as of v3.12.9 — it has the friendliest UX, lowest setup friction, and works for non-CLI users. But it requires one extra setup step (connecting Google Drive) because the sandbox filesystem doesn't persist. After Drive is wired, everything works.

**Also check: is a Drive MCP available in this session?** Scan your available tools for `mcp__*drive*` or the Anthropic-platform Drive integration. The capability matrix below splits on that.

=== ContentForge in Cowork ===

| Capability                                  | Cowork + Drive   | Cowork alone   |
|---------------------------------------------|-------------------|----------------|
| /plugin commands                            | YES               | YES            |
| HTTP MCP connectors (Slack, HubSpot, ...)   | YES               | YES            |
| npx / stdio MCP connectors                  | NO                | NO             |
|                                             |                   |                |
| Final .docx delivery                        | -> Drive folder   | -> sandbox (gone after session) |
| Brand profile persistence                   | -> Drive          | sandbox only   |
| Per-phase checkpoint files                  | -> Drive          | sandbox only   |
| /contentforge:resume across sessions        | YES (via Drive)   | NO             |
| Team sharing of outputs                     | YES (Drive)       | NO             |
| Files visible to user without download      | YES (Drive)       | NO             |
| Full 10-phase pipeline                      | YES               | LOGICAL ONLY -- outputs sandbox-only |

**If Cowork + Drive:** This is the recommended team setup. Run `/contentforge:cf-cowork-setup` once to wire the Drive folder layout, then use ContentForge normally. Every `.docx`, brand profile, and run record lands in `My Drive/ContentForge/...` where your team can access it from anywhere.

**If Cowork without Drive:** Connect Drive first. Easiest path: Cowork → **Settings** → **Integrations** → **Google Drive** → Connect (60 seconds). Then run `/contentforge:cf-cowork-setup`. Until that's done, generated files will only exist for the current session and won't be retrievable after you close the chat.

Local Claude Code (CLI or IDE extension) is the alternative if you don't want to use Drive — files land directly in `~/Documents/ContentForge/<brand>/...` on your machine. But for team usage, Cowork+Drive is simpler.

`linux-sandbox-uncertain`

Only weak signals fired (e.g., a container marker plus a Docker-style username or a local socks5h proxy) — not a confirmed Cowork session marker. This could be a real cloud sandbox the detector doesn't yet recognize by name, or a local Linux container / WSL setup with no sandbox risk at all. Treat it as a possible sandbox rather than guessing wrong in either direction.

Show this line first, before anything else:

> Detection was uncertain (weak sandbox signals only — see the probe's cowork_warning): treating this environment as a possible cloud sandbox. Verify where your files land before relying on them.

Then render the exact same matrix as `cowork-sandbox` above (including the Drive-MCP scan and the "If Cowork + Drive" / "If Cowork without Drive" branches) — capabilities-wise, an unconfirmed sandbox must still be treated as if writes might not reach the host.

`claude-code-windows`, `claude-code-mac`, `claude-code-linux`

=== ContentForge in local Claude Code (