audit-content
CommandAudit your content library for freshness decay and coverage gaps. \"audit my content library\"
Print the path to the ContentForge output folder and open it. \"where is my output folder\"
$ npx -y skills add indranilbanerjee/contentforge --agent claude-code
description: "Print the path to the ContentForge output folder and open it. \"where is my output folder\"" argument-hint: "[brand] (omit to use the active brand)"
Show the user where ContentForge actually saves the finished `.docx` files, and (when supported) open that folder in the OS file manager. This is the answer to "where did my file go?" — a real question from the v3.12.2 user-feedback cycle.
User runs `/contentforge:output-folder`, or asks any variant of "where did my file save", "I can't find the output", "open output folder".
ContentForge writes two copies of every finished `.docx`:
1. **Internal tracking copy** at `~/.claude-marketing/{brand}/tracking/outputs/{year}/{month}/{slug}_v1.0.docx`. This is the system-of-record for `/contentforge:cf-analytics`, `/contentforge:cf-audit`, etc. It lives inside a dotfolder that Windows hides by default — users rarely find it. 2. **User-visible published copy** at `ContentForge/{brand}/{content_type}/{YYYY-MM}/{slug}.docx` inside your Documents folder (`~/Documents`, or the redirected `OneDrive\Documents` on Windows with OneDrive; the script prints the real path). If `$CONTENTFORGE_PUBLISH_DIR` is set it replaces the whole `~/Documents/ContentForge/{brand}` prefix — see the warning in Configuration below. This is the copy to surface.
The published copy was added in v3.12.3 specifically because end users reported "the file isn't saving on local drive" — it was saving, just somewhere they couldn't see.
The published-output directory resolves exactly as `local-tracker.py get_publish_dir()` does — first non-empty wins:
1. `--publish-dir` override, if passed 2. `$CONTENTFORGE_PUBLISH_DIR/` if the env var is set — **note: no `{brand}` segment is appended in this branch** 3. `~/Documents/ContentForge/{brand-slug}/` otherwise
A `{content_type-slug}` segment is appended after that base in every branch.
So when the env var is set, the resolved folder is `$CONTENTFORGE_PUBLISH_DIR/{content_type}/` — the same tree for every brand. Report the path that actually resolves; do not invent a `{brand}` segment that isn't there.
Default to the active brand if no argument was provided. If neither is available, prompt: "Which brand's output folder? Run `/contentforge:output-folder <brand>` or set up a brand with `/contentforge:brand-setup`."
Always show the path explicitly in the conversation so the user can copy/paste it even if the OS open step fails:
📂 ContentForge output folder for {brand}:
{absolute_path}
Subfolders are organized by content type (article / blog / whitepaper / faq / research_paper / video_script / case_study / newsletter)
and by month (YYYY-MM). The newest run is in the latest month folder.Pick the platform-appropriate command. The plugin runs on Windows (most users), macOS, and Linux:
# Windows
start "" "{absolute_path}"
# macOS
open "{absolute_path}"
# Linux
xdg-open "{absolute_path}"If the open step fails (no display, headless environment, no associated handler), don't error — the user already has the path from Step 2.
`~/Documents/ContentForge/{brand}/` is created the first time a pipeline run finishes Phase 8. If the folder is missing, say:
The output folder doesn't exist yet — that means no `/contentforge:create-content` run
has completed for "{brand}" yet. Run a pipeline first, then come back here.
Expected location after the first successful run:
{absolute_path}Do NOT create the folder pre-emptively — empty folders are noise.
End users (or admins setting up a shared workstation) can redirect the visible-copy location with the `CONTENTFORGE_PUBLISH_DIR` env var:
# Persistent — add to your shell profile export CONTENTFORGE_PUBLISH_DIR="$HOME/Dropbox/Marketing/ContentForge" # Per-run CONTENTFORGE_PUBLISH_DIR="/mnt/team-share/ContentForge" /contentforge:create-content ...
> **Warning — `CONTENTFORGE_PUBLISH_DIR` is shared across all brands.** > The default path includes a per-brand folder (`~/Documents/ContentForge/{brand}/...`), but > the env-var branch does **not** append the brand. Every brand publishes into the same > `$CONTENTFORGE_PUBLISH_DIR/{content_type}/{YYYY-MM}/` tree, so two brands producing a > piece with the same slug in the same month will collide. If you run more than one brand, > either leave the env var unset or point it at a per-brand location (for example, set it > per-run rather than in your shell profile).
The internal tracking copy (under `~/.claude-marketing/`) is unchanged — that stays as the plugin's system-of-record. The env var only affects the published copy.
🌐 Read this in: English · हिन्दी · 中文 · 日本語 · 한국어 · Español · Português · العربية · اردو · தமிழ் · বাংলা · Русский You need to ship 30 articles this quarter that sound human, cite real sources, link into your funnel, and survive an editor who checks.
Audit your content library for freshness decay and coverage gaps. \"audit my content library\"
Set up brand voice, terminology and compliance rules by interview. \"set up a new brand\"
Generate a content brief for a keyword or topic: intent, competitors, outline. \"brief this keyword\"
Create a full content piece through the 10-phase pipeline. \"create content about X\"
Publish finished content to Webflow or WordPress with a preview first. \"publish to our CMS\"
Resume an interrupted ContentForge pipeline run from its last checkpoint. \"pick up where the pipeline stopped\"
Initialize the current project with Scientific Writer - a deep research and writing tool that combines AI-driven research with…