Add DevContainer CLI guide, v2 migration guide, and full docs review

.devcontainer/CHANGELOG.md

@@ -2,6 +2,18 @@
 
 ## [Unreleased]
 
+### Added
+
+#### Documentation
+- **DevContainer CLI guide** — dedicated Getting Started page for terminal-only workflows without VS Code
+- **v2 Migration Guide** — path changes, automatic migration, manual steps, breaking changes, and troubleshooting
+- Documented 4 previously undocumented agents in agents.md: implementer, investigator, tester, documenter
+- Added missing git-workflow and prompt-snippets to configuration.md enabledPlugins example
+- Added CONFIG_SOURCE_DIR deprecation note in environment variables reference
+- Added cc-orc orchestrator command to first-session launch commands table
+- Tabbed client-specific instructions on the installation page
+- Dedicated port forwarding reference page covering VS Code auto-detect, devcontainer-bridge, and SSH tunneling
+
 ### Changed
 
 #### Performance
@@ -14,9 +26,14 @@
 - Dynamic port forwarding for all ports in VS Code — previously only port 7847 was statically forwarded; now all ports auto-forward with notification
 
 #### Documentation
+- Updated **Port Forwarding reference** — VS Code dependency warning, devcontainer-bridge platform support matrix, CLI guide cross-link
+- Slimmed **Installation page** — moved troubleshooting to dedicated reference page, CLI details to new CLI guide
+- Full documentation review — accuracy, consistency, and completeness fixes across all 30+ pages
+- Trimmed disabled ccms usage section from commands reference
+- Clarified codeforge-lsp plugin description (declarative config, not "no configuration")
+- Improved magic-docs agent explanation in agent-system plugin docs
+- Clarified plugin count as "13 local + 1 official" in reference index
 - Updated prerequisites and installation docs to support all DevContainer clients (VS Code, CLI, JetBrains Gateway, DevPod, Codespaces)
-- Added tabbed client-specific instructions on the installation page
-- Added dedicated port forwarding reference page covering VS Code auto-detect, devcontainer-bridge, and SSH tunneling
 - **Ported `.devcontainer/docs/` to docs site** — migrated content from 5 legacy reference docs into the Starlight documentation site:
   - New **Keybindings** page (Customization) — VS Code/Claude Code shortcut conflicts and resolution options
   - New **Troubleshooting** page (Reference) — 12+ problem/solution entries for build, auth, plugins, and performance issues

docs/astro.config.mjs

@@ -91,6 +91,14 @@ export default defineConfig({
 							{ label: "Overview", slug: "getting-started" },
 							{ label: "Requirements", slug: "getting-started/requirements" },
 							{ label: "Installation", slug: "getting-started/installation" },
+							{
+								label: "DevContainer CLI",
+								slug: "getting-started/devcontainer-cli",
+							},
+							{
+								label: "Migrating to v2",
+								slug: "getting-started/migrating-to-v2",
+							},
 							{
 								label: "Your First Session",
 								slug: "getting-started/first-session",

docs/src/content/docs/customization/configuration.md

@@ -94,6 +94,8 @@ The `enabledPlugins` section controls which plugins are active:
     "notify-hook@devs-marketplace": true,
     "ticket-workflow@devs-marketplace": true,
     "codeforge-lsp@devs-marketplace": true,
+    "git-workflow@devs-marketplace": true,
+    "prompt-snippets@devs-marketplace": true,
     "frontend-design@claude-plugins-official": true
   }
 }

docs/src/content/docs/features/agents.md

@@ -30,7 +30,7 @@ CodeForge **entirely replaces** all six built-in agents with enhanced custom spe
 
 The redirect is fully transparent — you can use either the built-in name or the custom name interchangeably. Asking Claude to "explore the codebase" triggers the same enhanced explorer agent whether the system selects the `Explore` type or the `explorer` type.
 
-Beyond the six replacements, CodeForge adds **11 entirely new specialists** that have no built-in equivalent: architect, researcher, test-writer, refactorer, doc-writer, migrator, security-auditor, dependency-analyst, git-archaeologist, perf-profiler, debug-logs, and spec-writer. These are available only in CodeForge.
+Beyond the six replacements, CodeForge adds **15 entirely new specialists** that have no built-in equivalent: debug-logs, dependency-analyst, doc-writer, documenter, git-archaeologist, implementer, investigator, migrator, perf-profiler, refactorer, researcher, security-auditor, spec-writer, tester, and test-writer. These are available only in CodeForge.
 
 :::tip[Why This Matters]
 The redirect happens at the hook level, not the prompt level. This means the upgrade is enforced — not suggested. Even if Claude's internal routing tries to use a stock Explore agent, the hook intercepts the call and swaps in the enhanced explorer before any code executes. The result is a strictly better agent every time, with zero user effort.
@@ -122,6 +122,18 @@ A technical writing specialist that creates and maintains README files, API docu
 "Document the public API for the user service module. Include usage examples and parameter descriptions."
 :::
 
+### documenter
+
+<span class="badge badge--orange">Full</span> <span class="badge badge--blue">Opus</span> <span class="badge badge--purple">documentation-patterns</span> <span class="badge badge--purple">specification-writing</span>
+
+A documentation and specification lifecycle agent. Handles READMEs, API docs, inline documentation, and architectural guides alongside the full spec workflow — creating, refining, reviewing, and closing specifications. Carries 7 frontloaded skills covering both documentation patterns and all spec operations. Unlike doc-writer, the documenter works directly (no worktree isolation) and owns the spec lifecycle. Never modifies source code logic.
+
+**When activated:** "Document this module," "write a README," "create a spec and document the feature," specification lifecycle tasks that combine docs and specs.
+
+:::tip[documenter vs doc-writer]
+Use **doc-writer** for pure documentation tasks (READMEs, docstrings, API docs) where worktree isolation is preferred. Use **documenter** when documentation and specification work are interleaved — it has the full spec skill set (spec-new, spec-refine, spec-review, spec-update, spec-check) built in.
+:::
+
 ### explorer
 
 <span class="badge badge--green">Read-only</span> <span class="badge badge--blue">Haiku</span>
@@ -158,6 +170,30 @@ A git history forensics specialist that traces code evolution, finds when bugs w
 "Trace the history of the authentication middleware. When was it introduced, who has modified it, and what were the major changes?"
 :::
 
+### implementer
+
+<span class="badge badge--orange">Full (worktree)</span> <span class="badge badge--blue">Opus</span> <span class="badge badge--purple">refactoring-patterns</span> <span class="badge badge--purple">migration-patterns</span> <span class="badge badge--purple">spec-update</span>
+
+A full-stack implementation agent that handles all code modifications: writing new features, fixing bugs, refactoring existing code, and executing migrations. Runs tests after every edit via a Stop hook to catch regressions immediately. Works in a git worktree so your main branch stays clean. The broadest-scope implementation agent — use the more focused refactorer, migrator, or test-writer when the task is clearly within one domain.
+
+**When activated:** General implementation tasks, feature building, bug fixes, "implement this," multi-file changes that span domains.
+
+:::tip[Try this]
+"Implement the user notification preferences feature. Add the database model, API endpoints, and update the settings page."
+:::
+
+### investigator
+
+<span class="badge badge--green">Read-only</span> <span class="badge badge--blue">Sonnet</span> <span class="badge badge--purple">debugging</span> <span class="badge badge--purple">git-forensics</span> <span class="badge badge--purple">performance-profiling</span> <span class="badge badge--purple">dependency-management</span> <span class="badge badge--purple">documentation-patterns</span> <span class="badge badge--purple">ast-grep-patterns</span>
+
+A comprehensive read-only research agent that consolidates six analysis domains: codebase exploration, web research, git history forensics, dependency auditing, log analysis, and performance profiling. Carries 6 frontloaded skills — more than any other agent — making it the go-to for complex investigations that cross domain boundaries. Never modifies files.
+
+**When activated:** Complex multi-domain investigations, "investigate why," "research and analyze," tasks that combine codebase analysis with git history or dependency research.
+
+:::tip[investigator vs specialists]
+Use the **investigator** when an investigation spans multiple domains (e.g., "why is this slow" might need codebase analysis, git history, and performance profiling). Use a focused specialist (researcher, debug-logs, git-archaeologist, perf-profiler, dependency-analyst) when the domain is clear.
+:::
+
 ### migrator
 
 <span class="badge badge--orange">Full (worktree)</span> <span class="badge badge--blue">Opus</span> <span class="badge badge--purple">migration-patterns</span>
@@ -242,6 +278,18 @@ A specialist for configuring the Claude Code terminal statusline. Converts shell
 "Convert my current PS1 prompt to a Claude Code statusline. Include git branch, Python version, and working directory."
 :::
 
+### tester
+
+<span class="badge badge--orange">Full (worktree)</span> <span class="badge badge--blue">Opus</span> <span class="badge badge--purple">testing</span> <span class="badge badge--purple">spec-update</span>
+
+A test suite creation and verification agent. Analyzes existing code, writes comprehensive tests, and ensures all tests pass before completing via a Stop hook. Supports pytest, Vitest, Jest, Go testing, and Rust test frameworks. Works in a git worktree. Functionally equivalent to test-writer with the addition of the spec-update skill for closing the spec loop after writing tests.
+
+**When activated:** "Write tests for," "add test coverage," "create integration tests," test creation tasks.
+
+:::tip[tester vs test-writer]
+These agents are nearly identical. **tester** includes the spec-update skill for spec-driven workflows. **test-writer** is the built-in replacement agent. Both produce the same quality of tests — use whichever surfaces based on your request.
+:::
+
 ### test-writer
 
 <span class="badge badge--orange">Full (worktree)</span> <span class="badge badge--blue">Opus</span> <span class="badge badge--purple">testing</span>
@@ -264,24 +312,28 @@ A senior test engineer that analyzes existing code and writes comprehensive test
 | debug-logs | Read-only | Sonnet | -- | -- | debugging |
 | dependency-analyst | Read-only | Haiku | -- | Yes | dependency-management |
 | doc-writer | Full | Opus | Worktree | -- | documentation-patterns  |
+| documenter | Full | Opus | -- | -- | documentation-patterns, specification-writing, spec-new, spec-update, spec-review, spec-refine, spec-check |
 | explorer | Read-only | Haiku | -- | -- | ast-grep-patterns |
 | generalist | Full | Inherited | -- | -- | spec workflow |
 | git-archaeologist | Read-only | Haiku | -- | -- | git-forensics |
+| implementer | Full | Opus | Worktree | -- | refactoring-patterns, migration-patterns, spec-update |
+| investigator | Read-only | Sonnet | -- | -- | documentation-patterns, git-forensics, performance-profiling, debugging, dependency-management, ast-grep-patterns |
 | migrator | Full | Opus | Worktree | -- | migration-patterns |
 | perf-profiler | Read-only | Sonnet | -- | Yes | performance-profiling |
 | refactorer | Full | Opus | Worktree | -- | refactoring-patterns |
 | researcher | Read-only | Sonnet | -- | -- | documentation-patterns |
 | security-auditor | Read-only | Sonnet | -- | Yes | security-checklist |
 | spec-writer | Read-only | Opus | -- | -- | specification-writing |
 | statusline-config | Full | Sonnet | -- | -- | -- |
+| tester | Full | Opus | Worktree | -- | testing, spec-update |
 | test-writer | Full | Opus | Worktree | -- | testing |
 
 ## Access Levels at a Glance
 
 | Access Level | Agents |
 |-------------|--------|
-| **Read-only** | architect, claude-guide, debug-logs, dependency-analyst, explorer, git-archaeologist, perf-profiler, researcher, security-auditor, spec-writer |
-| **Full** | bash-exec, doc-writer, generalist, migrator, refactorer, statusline-config, test-writer |
+| **Read-only** | architect, claude-guide, debug-logs, dependency-analyst, explorer, git-archaeologist, investigator, perf-profiler, researcher, security-auditor, spec-writer |
+| **Full** | bash-exec, doc-writer, documenter, generalist, implementer, migrator, refactorer, statusline-config, tester, test-writer |
 
 :::note[About Model Selection]
 Agents use different Claude models based on task complexity. Opus handles the most demanding tasks (architecture, refactoring, test writing, migration). Sonnet covers analytical tasks that need strong reasoning (security audits, research, debugging). Haiku powers fast, focused tasks (exploration, dependency analysis, git history). The generalist inherits whichever model the main session is using.
@@ -291,10 +343,10 @@ Agents use different Claude models based on task complexity. Opus handles the mo
 
 Several agents include built-in safety hooks:
 
-- **Read-only bash guard** — The architect, explorer, security auditor, dependency analyst, and git-archaeologist all have a PreToolUse hook that blocks any Bash command that could modify files or state.
+- **Read-only bash guard** — The architect, explorer, investigator, security auditor, dependency analyst, and git-archaeologist all have a PreToolUse hook that blocks any Bash command that could modify files or state.
 - **Git-readonly guard** — The git-archaeologist has a specialized guard that only permits read-only git subcommands (log, blame, show, diff, reflog, etc.).
 - **Post-edit test verification** — The refactorer runs tests automatically after every single Edit operation. If tests fail, the change is immediately reverted.
-- **Stop verification** — The test-writer has a Stop hook that verifies all written tests pass before the agent completes.
+- **Stop verification** — The test-writer and tester have a Stop hook that verifies all written tests pass before the agent completes. The implementer has a similar Stop hook that runs regression checks.
 
 ## Related
 

docs/src/content/docs/getting-started/devcontainer-cli.md

@@ -0,0 +1,134 @@
+---
+title: DevContainer CLI
+description: Run CodeForge from the command line without VS Code — build, connect, and manage containers using the devcontainer CLI.
+sidebar:
+  order: 4
+---
+
+The DevContainer CLI lets you build and run CodeForge containers without VS Code. Use it when you prefer terminal-only workflows, work on headless servers, or need DevContainer support in CI/CD pipelines.
+
+## Install the CLI
+
+```bash
+npm install -g @devcontainers/cli
+```
+
+Requires Node.js 16.13+ or 18+ (when installing via npm). Verify the installation with `devcontainer --version`.
+
+## Build and Start
+
+From your project root (where `.devcontainer/` lives):
+
+```bash
+devcontainer up --workspace-folder .
+```
+
+The first build takes several minutes — it pulls the base image, installs all features, and runs post-start setup. Subsequent starts reuse cached layers and complete in seconds.
+
+:::caution[Don't interrupt the first build]
+If the build is interrupted, Docker may cache a partial state. Rebuild from scratch:
+```bash
+devcontainer up --workspace-folder . --remove-existing-container
+```
+:::
+
+## Connect to the Container
+
+The recommended way to get a shell inside the container:
+
+```bash
+devcontainer exec --workspace-folder . zsh
+```
+
+This uses the devcontainer CLI's exec command, which respects the container's configured user and environment. You can also use `docker exec` directly — run `docker ps` to find the container name:
+
+```bash
+docker exec -it <container-name> zsh
+```
+
+## Run Commands
+
+Execute commands without entering an interactive shell:
+
+```bash
+# Run check-setup to verify the installation
+devcontainer exec --workspace-folder . check-setup
+
+# Launch a Claude Code session
+devcontainer exec --workspace-folder . cc
+
+# List installed tools
+devcontainer exec --workspace-folder . cc-tools
+```
+
+## Port Forwarding
+
+VS Code auto-forwards container ports to your host automatically. **The CLI does not.** You need an explicit forwarding mechanism.
+
+:::caution[No automatic port forwarding]
+Unlike VS Code, the devcontainer CLI does not auto-forward ports. Services running inside the container (like the Claude Dashboard on port 7847) won't be accessible on your host unless you set up forwarding manually.
+:::
+
+**Recommended:** Install [devcontainer-bridge](https://github.com/bradleybeddoes/devcontainer-bridge) (`dbr`) for dynamic, automatic port forwarding that works with any terminal client. CodeForge pre-installs the container side — you only need the host daemon:
+
+```bash
+# On your host machine
+dbr host-daemon
+```
+
+**Alternative:** Use SSH tunneling for specific ports:
+
+```bash
+ssh -L 7847:localhost:7847 <container-user>@<container-host>
+```
+
+See [Port Forwarding](/reference/port-forwarding/) for the full setup guide and comparison of all forwarding mechanisms.
+
+## Key Differences from VS Code
+
+| Capability | VS Code | DevContainer CLI |
+|------------|---------|------------------|
+| Port forwarding | Automatic | Manual — use `dbr` or SSH tunneling |
+| Extensions panel | GUI in sidebar | Not available |
+| Ports panel | Visual port management | Not available — use `docker port` or `dbr` |
+| Terminal management | Integrated tabs | Manual — use tmux for parallel sessions |
+| File editing | Built-in editor | Use your preferred editor (vim, nano, etc.) |
+
+## Rebuilding
+
+When you change `devcontainer.json` or feature configurations, rebuild:
+
+```bash
+# Rebuild using cached layers (fast)
+devcontainer up --workspace-folder .
+
+# Full rebuild from scratch (slow, but fixes cache issues)
+devcontainer up --workspace-folder . --remove-existing-container
+```
+
+## Stopping the Container
+
+The devcontainer CLI doesn't have a dedicated stop command. Use Docker directly:
+
+```bash
+# Find the container name
+docker ps
+
+# Stop the container
+docker stop <container-name>
+
+# Or stop and remove it
+docker rm -f <container-name>
+```
+
+## Tips
+
+- **Use tmux** for parallel sessions inside the container. CodeForge installs tmux by default — run `tmux` after connecting to get split panes and persistent sessions.
+- **Connect external terminals** using the scripts in `.codeforge/scripts/` — `connect-external-terminal.sh` (macOS/Linux) or `connect-external-terminal.ps1` (Windows PowerShell).
+- **Combine with `dbr`** for the closest experience to VS Code — automatic port forwarding without needing VS Code running.
+
+## Next Steps
+
+- [Your First Session](/getting-started/first-session/) — start using CodeForge with Claude Code
+- [Port Forwarding](/reference/port-forwarding/) — detailed forwarding setup guide
+- [Installation](/getting-started/installation/) — full installation walkthrough

docs/src/content/docs/getting-started/first-session.md

@@ -2,7 +2,7 @@
 title: First Session
 description: Walkthrough of your first Claude Code session inside a CodeForge DevContainer.
 sidebar:
-  order: 4
+  order: 6
 ---
 
 You've installed CodeForge and the container is running. Now it's time to launch your first Claude Code session and see everything in action. This guide walks you through what happens when you start a session, what to try first, and how the different systems work together.
@@ -24,6 +24,7 @@ The `cc` command is a CodeForge alias that launches Claude Code with the correct
 | `cc` | Full CodeForge session with system prompt, plugins, and all configuration |
 | `claude` | Same as `cc` — an alias for convenience |
 | `ccw` | Writing-focused session using the writing system prompt (great for documentation) |
+| `cc-orc` | Orchestrator mode — delegation-first approach, useful for complex multi-agent tasks |
 | `ccraw` | Raw Claude Code session with no CodeForge configuration — useful for debugging |
 
 :::tip[When to use ccraw]