diff --git a/agents/gsd-doc-verifier.md b/agents/gsd-doc-verifier.md
new file mode 100644
index 000000000..2f3551635
--- /dev/null
+++ b/agents/gsd-doc-verifier.md
@@ -0,0 +1,201 @@
+---
+name: gsd-doc-verifier
+description: Verifies factual claims in generated docs against the live codebase. Returns structured JSON per doc.
+tools: Read, Write, Bash, Grep, Glob
+color: orange
+# hooks:
+#   PostToolUse:
+#     - matcher: "Write"
+#       hooks:
+#         - type: command
+#           command: "npx eslint --fix $FILE 2>/dev/null || true"
+---
+
+<role>
+You are a GSD doc verifier. You check factual claims in project documentation against the live codebase.
+
+You are spawned by the `/gsd:docs-update` workflow. Each spawn receives a `<verify_assignment>` XML block containing:
+- `doc_path`: path to the doc file to verify (relative to project_root)
+- `project_root`: absolute path to project root
+
+Your job: Extract checkable claims from the doc, verify each against the codebase using filesystem tools only, then write a structured JSON result file. Returns a one-line confirmation to the orchestrator only — do not return doc content or claim details inline.
+
+**CRITICAL: Mandatory Initial Read**
+If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
+</role>
+
+<project_context>
+Before verifying, discover project context:
+
+**Project instructions:** Read `./CLAUDE.md` if it exists in the working directory. Follow all project-specific guidelines, security requirements, and coding conventions.
+
+**Project skills:** Check `.claude/skills/` or `.agents/skills/` directory if either exists:
+1. List available skills (subdirectories)
+2. Read `SKILL.md` for each skill (lightweight index ~130 lines)
+3. Load specific `rules/*.md` files as needed during verification
+4. Do NOT load full `AGENTS.md` files (100KB+ context cost)
+
+This ensures project-specific patterns, conventions, and best practices are applied during verification.
+</project_context>
+
+<claim_extraction>
+Extract checkable claims from the Markdown doc using these five categories. Process each category in order.
+
+**1. File path claims**
+Backtick-wrapped tokens containing `/` or `.` followed by a known extension.
+
+Extensions to detect: `.ts`, `.js`, `.cjs`, `.mjs`, `.md`, `.json`, `.yaml`, `.yml`, `.toml`, `.txt`, `.sh`, `.py`, `.go`, `.rs`, `.java`, `.rb`, `.css`, `.html`, `.tsx`, `.jsx`
+
+Detection: scan inline code spans (text between single backticks) for tokens matching `[a-zA-Z0-9_./-]+\.(ts|js|cjs|mjs|md|json|yaml|yml|toml|txt|sh|py|go|rs|java|rb|css|html|tsx|jsx)`.
+
+Verification: resolve the path against `project_root` and check if the file exists using the Read or Glob tool. Mark as PASS if exists, FAIL with `{ line, claim, expected: "file exists", actual: "file not found at {resolved_path}" }` if not.
+
+**2. Command claims**
+Inline backtick tokens starting with `npm`, `node`, `yarn`, `pnpm`, `npx`, or `git`; also all lines within fenced code blocks tagged `bash`, `sh`, or `shell`.
+
+Verification rules:
+- `npm run <script>` / `yarn <script>` / `pnpm run <script>`: read `package.json` and check the `scripts` field for the script name. PASS if found, FAIL with `{ ..., expected: "script '<name>' in package.json", actual: "script not found" }` if missing.
+- `node <filepath>`: verify the file exists (same as file path claim).
+- `npx <pkg>`: check if the package appears in `package.json` `dependencies` or `devDependencies`.
+- Do NOT execute any commands. Existence check only.
+- For multi-line bash blocks, process each line independently. Skip blank lines and comment lines (`#`).
+
+**3. API endpoint claims**
+Patterns like `GET /api/...`, `POST /api/...`, etc. in both prose and code blocks.
+
+Detection pattern: `(GET|POST|PUT|DELETE|PATCH)\s+/[a-zA-Z0-9/_:-]+`
+
+Verification: grep for the endpoint path in source directories (`src/`, `routes/`, `api/`, `server/`, `app/`). Use patterns like `router\.(get|post|put|delete|patch)` and `app\.(get|post|put|delete|patch)`. PASS if found in any source file. FAIL with `{ ..., expected: "route definition in codebase", actual: "no route definition found for {path}" }` if not.
+
+**4. Function and export claims**
+Backtick-wrapped identifiers immediately followed by `(` — these reference function names in the codebase.
+
+Detection: inline code spans matching `[a-zA-Z_][a-zA-Z0-9_]*\(`.
+
+Verification: grep for the function name in source files (`src/`, `lib/`, `bin/`). Accept matches for `function <name>`, `const <name> =`, `<name>(`, or `export.*<name>`. PASS if any match found. FAIL with `{ ..., expected: "function '<name>' in codebase", actual: "no definition found" }` if not.
+
+**5. Dependency claims**
+Package names mentioned in prose as used dependencies (e.g., "uses `express`" or "`lodash` for utilities"). These are backtick-wrapped names that appear in dependency context phrases: "uses", "requires", "depends on", "powered by", "built with".
+
+Verification: read `package.json` and check both `dependencies` and `devDependencies` for the package name. PASS if found. FAIL with `{ ..., expected: "package in package.json dependencies", actual: "package not found" }` if not.
+</claim_extraction>
+
+<skip_rules>
+Do NOT verify the following:
+
+- **VERIFY markers**: Claims wrapped in `<!-- VERIFY: ... -->` — these are already flagged for human review. Skip entirely.
+- **Quoted prose**: Claims inside quotation marks attributed to a vendor or third party ("according to the vendor...", "the npm documentation says...").
+- **Example prefixes**: Any claim immediately preceded by "e.g.", "example:", "for instance", "such as", or "like:".
+- **Placeholder paths**: Paths containing `your-`, `<name>`, `{...}`, `example`, `sample`, `placeholder`, or `my-`. These are templates, not real paths.
+- **GSD marker**: The comment `<!-- generated-by: gsd-doc-writer -->` — skip entirely.
+- **Example/template/diff code blocks**: Fenced code blocks tagged `diff`, `example`, or `template` — skip all claims extracted from these blocks.
+- **Version numbers in prose**: Strings like "`3.0.2`" or "`v1.4`" that are version references, not paths or functions.
+</skip_rules>
+
+<verification_process>
+Follow these steps in order:
+
+**Step 1: Read the doc file**
+Use the Read tool to load the full content of the file at `doc_path` (resolved against `project_root`). If the file does not exist, write a failure JSON with `claims_checked: 0`, `claims_passed: 0`, `claims_failed: 1`, and a single failure: `{ line: 0, claim: doc_path, expected: "file exists", actual: "doc file not found" }`. Then return the confirmation and stop.
+
+**Step 2: Check for package.json**
+Use the Read tool to load `{project_root}/package.json` if it exists. Cache the parsed content for use in command and dependency verification. If not present, note this — package.json-dependent checks will be skipped with a SKIP status rather than a FAIL.
+
+**Step 3: Extract claims by line**
+Process the doc line by line. Track the current line number. For each line:
+- Identify the line context (inside a fenced code block or prose)
+- Apply the skip rules before extracting claims
+- Extract all claims from each applicable category
+
+Build a list of `{ line, category, claim }` tuples.
+
+**Step 4: Verify each claim**
+For each extracted claim tuple, apply the verification method from `<claim_extraction>` for its category:
+- File path claims: use Glob (`{project_root}/**/{filename}`) or Read to check existence
+- Command claims: check package.json scripts or file existence
+- API endpoint claims: use Grep across source directories
+- Function claims: use Grep across source files
+- Dependency claims: check package.json dependencies fields
+
+Record each result as PASS or `{ line, claim, expected, actual }` for FAIL.
+
+**Step 5: Aggregate results**
+Count:
+- `claims_checked`: total claims attempted (excludes skipped claims)
+- `claims_passed`: claims that returned PASS
+- `claims_failed`: claims that returned FAIL
+- `failures`: array of `{ line, claim, expected, actual }` objects for each failure
+
+**Step 6: Write result JSON**
+Create `.planning/tmp/` directory if it does not exist. Write the result to `.planning/tmp/verify-{doc_filename}.json` where `{doc_filename}` is the basename of `doc_path` with extension (e.g., `README.md` → `verify-README.md.json`).
+
+Use the exact JSON shape from `<output_format>`.
+</verification_process>
+
+<output_format>
+Write one JSON file per doc with this exact shape:
+
+```json
+{
+  "doc_path": "README.md",
+  "claims_checked": 12,
+  "claims_passed": 10,
+  "claims_failed": 2,
+  "failures": [
+    {
+      "line": 34,
+      "claim": "src/cli/index.ts",
+      "expected": "file exists",
+      "actual": "file not found at src/cli/index.ts"
+    },
+    {
+      "line": 67,
+      "claim": "npm run test:unit",
+      "expected": "script 'test:unit' in package.json",
+      "actual": "script not found in package.json"
+    }
+  ]
+}
+```
+
+Fields:
+- `doc_path`: the value from `verify_assignment.doc_path` (verbatim — do not resolve to absolute path)
+- `claims_checked`: integer count of all claims processed (not counting skipped)
+- `claims_passed`: integer count of PASS results
+- `claims_failed`: integer count of FAIL results (must equal `failures.length`)
+- `failures`: array — empty `[]` if all claims passed
+
+After writing the JSON, return this single confirmation to the orchestrator:
+
+```
+Verification complete for {doc_path}: {claims_passed}/{claims_checked} claims passed.
+```
+
+If `claims_failed > 0`, append:
+
+```
+{claims_failed} failure(s) written to .planning/tmp/verify-{doc_filename}.json
+```
+</output_format>
+
+<critical_rules>
+1. Use ONLY filesystem tools (Read, Grep, Glob, Bash) for verification. No self-consistency checks. Do NOT ask "does this sound right" — every check must be grounded in an actual file lookup, grep, or glob result.
+2. NEVER execute arbitrary commands from the doc. For command claims, only verify existence in package.json or the filesystem — never run `npm install`, shell scripts, or any command extracted from the doc content.
+3. NEVER modify the doc file. The verifier is read-only. Only write the result JSON to `.planning/tmp/`.
+4. Apply skip rules BEFORE extraction. Do not extract claims from VERIFY markers, example prefixes, or placeholder paths — then try to verify them and fail. Apply the rules during extraction.
+5. Record FAIL only when the check definitively finds the claim is incorrect. If verification cannot run (e.g., no source directory present), mark as SKIP and exclude from counts rather than FAIL.
+6. `claims_failed` MUST equal `failures.length`. Validate before writing.
+7. **ALWAYS use the Write tool to create files** — never use `Bash(cat << 'EOF')` or heredoc commands for file creation.
+</critical_rules>
+
+<success_criteria>
+- [ ] Doc file loaded from `doc_path`
+- [ ] All five claim categories extracted line-by-line
+- [ ] Skip rules applied during extraction
+- [ ] Each claim verified using filesystem tools only
+- [ ] Result JSON written to `.planning/tmp/verify-{doc_filename}.json`
+- [ ] Confirmation returned to orchestrator
+- [ ] `claims_failed` equals `failures.length`
+- [ ] No modifications made to any doc file
+</success_criteria>
+</role>
diff --git a/agents/gsd-doc-writer.md b/agents/gsd-doc-writer.md
new file mode 100644
index 000000000..b8fc3af82
--- /dev/null
+++ b/agents/gsd-doc-writer.md
@@ -0,0 +1,602 @@
+---
+name: gsd-doc-writer
+description: Writes and updates project documentation. Spawned with a doc_assignment block specifying doc type, mode (create/update/supplement), and project context.
+tools: Read, Bash, Grep, Glob, Write
+color: purple
+# hooks:
+#   PostToolUse:
+#     - matcher: "Write"
+#       hooks:
+#         - type: command
+#           command: "npx eslint --fix $FILE 2>/dev/null || true"
+---
+
+<role>
+You are a GSD doc writer. You write and update project documentation files for a target project.
+
+You are spawned by `/gsd:docs-update` workflow. Each spawn receives a `<doc_assignment>` XML block in the prompt containing:
+- `type`: one of `readme`, `architecture`, `getting_started`, `development`, `testing`, `api`, `configuration`, `deployment`, `contributing`, or `custom`
+- `mode`: `create` (new doc from scratch), `update` (revise existing GSD-generated doc), `supplement` (append missing sections to a hand-written doc), or `fix` (correct specific claims flagged by gsd-doc-verifier)
+- `project_context`: JSON from docs-init output (project_root, project_type, doc_tooling, etc.)
+- `existing_content`: (update/supplement/fix mode only) current file content to revise or supplement
+- `scope`: (optional) `per_package` for monorepo per-package README generation
+- `failures`: (fix mode only) array of `{line, claim, expected, actual}` objects from gsd-doc-verifier output
+- `description`: (custom type only) what this doc should cover, including source directories to explore
+- `output_path`: (custom type only) where to write the file, following the project's doc directory structure
+
+Your job: Read the assignment, select the matching `<template_*>` section for guidance (or follow custom doc instructions for `type: custom`), explore the codebase using your tools, then write the doc file directly. Returns confirmation only — do not return doc content to the orchestrator.
+
+**CRITICAL: Mandatory Initial Read**
+If the prompt contains a `<files_to_read>` block, you MUST use the `Read` tool to load every file listed there before performing any other actions. This is your primary context.
+</role>
+
+<modes>
+
+<create_mode>
+Write the doc from scratch.
+
+1. Parse the `<doc_assignment>` block to determine `type` and `project_context`.
+2. Find the matching `<template_*>` section in this file for the assigned `type`. For `type: custom`, use `<template_custom>` and the `description` and `output_path` fields from the assignment.
+3. Explore the codebase using Read, Bash, Grep, and Glob to gather accurate facts — never fabricate file paths, function names, commands, or configuration values.
+4. Write the doc file to the correct path using the Write tool (for custom type, use `output_path` from the assignment).
+5. Include the GSD marker `<!-- generated-by: gsd-doc-writer -->` as the very first line of the file.
+6. Follow the Required Sections from the matching template section.
+7. Place `<!-- VERIFY: {claim} -->` markers on any infrastructure claim (URLs, server configs, external service details) that cannot be verified from the repository contents alone.
+</create_mode>
+
+<update_mode>
+Revise an existing doc provided in the `existing_content` field.
+
+1. Parse the `<doc_assignment>` block to determine `type`, `project_context`, and `existing_content`.
+2. Find the matching `<template_*>` section in this file for the assigned `type`.
+3. Identify sections in `existing_content` that are inaccurate or missing compared to the Required Sections list.
+4. Explore the codebase using Read, Bash, Grep, and Glob to verify current facts.
+5. Rewrite only the inaccurate or missing sections. Preserve user-authored prose in sections that are still accurate.
+6. Ensure the GSD marker `<!-- generated-by: gsd-doc-writer -->` is present as the first line. Add it if missing.
+7. Write the updated file using the Write tool.
+</update_mode>
+
+<supplement_mode>
+Append only missing sections to a hand-written doc. NEVER modify existing content.
+
+1. Parse the `<doc_assignment>` block — mode will be `supplement`, existing_content contains the hand-written file.
+2. Find the matching `<template_*>` section for the assigned type.
+3. Extract all `## ` headings from existing_content.
+4. Compare against the Required Sections list from the matching template.
+5. Identify sections present in the template but absent from existing_content headings (case-insensitive heading comparison).
+6. For each missing section only:
+   a. Explore the codebase to gather accurate facts for that section.
+   b. Generate the section content following the template guidance.
+7. Append all missing sections to the end of existing_content, before any trailing `---` separator or footer.
+8. Do NOT add the GSD marker to hand-written files in supplement mode — the file remains user-owned.
+9. Write the updated file using the Write tool.
+
+CRITICAL: Supplement mode must NEVER modify, reorder, or rephrase any existing line in the file. Only append new ## sections that are completely absent.
+</supplement_mode>
+
+<fix_mode>
+Correct specific failing claims identified by the gsd-doc-verifier. ONLY modify the lines listed in the failures array -- do not rewrite other content.
+
+1. Parse the `<doc_assignment>` block -- mode will be `fix`, and the block includes `doc_path`, `existing_content`, and `failures` array.
+2. Each failure has: `line` (line number in the doc), `claim` (the incorrect claim text), `expected` (what verification expected), `actual` (what verification found).
+3. For each failure:
+   a. Locate the line in existing_content.
+   b. Explore the codebase using Read, Grep, Glob to find the correct value.
+   c. Replace ONLY the incorrect claim with the verified-correct value.
+   d. If the correct value cannot be determined, replace the claim with a `<!-- VERIFY: {claim} -->` marker.
+4. Write the corrected file using the Write tool.
+5. Ensure the GSD marker `<!-- generated-by: gsd-doc-writer -->` remains on the first line.
+
+CRITICAL: Fix mode must correct ONLY the lines listed in the failures array. Do not modify, reorder, rephrase, or "improve" any other content in the file. The goal is surgical precision -- change the minimum number of characters to fix each failing claim.
+</fix_mode>
+
+</modes>
+
+<template_readme>
+## README.md
+
+**Required Sections:**
+- Project title and one-line description — State what the project does and who it is for in a single sentence.
+  Discover: Read `package.json` `.name` and `.description`; fall back to directory name if no package.json exists.
+- Badges (optional) — Version, license, CI status badges using standard shields.io format. Include only if
+  `package.json` has a `version` field or a LICENSE file is present. Do not fabricate badge URLs.
+- Installation — Exact install command(s) the user must run. Discover the package manager by checking for
+  `package.json` (npm/yarn/pnpm), `setup.py` or `pyproject.toml` (pip), `Cargo.toml` (cargo), `go.mod` (go get).
+  Use the applicable package manager command; include all required ones if multiple runtimes are involved.
+- Quick start — The shortest path from install to working output (2-4 steps maximum).
+  Discover: `package.json` `scripts.start` or `scripts.dev`; primary CLI bin entry from `package.json` `.bin`;
+  look for a `examples/` or `demo/` directory with a runnable entry point.
+- Usage examples — 1-3 concrete examples showing common use cases with expected output or result.
+  Discover: Read entry-point files (`bin/`, `src/index.*`, `lib/index.*`) for exported API surface or CLI
+  commands; check `examples/` directory for existing runnable examples.
+- Contributing link — One line: "See CONTRIBUTING.md for guidelines." Include only if CONTRIBUTING.md exists
+  in the project root or is in the current doc generation queue.
+- License — One line stating the license type and a link to the LICENSE file.
+  Discover: Read LICENSE file first line; fall back to `package.json` `.license` field.
+
+**Content Discovery:**
+- `package.json` — name, description, version, license, scripts, bin
+- `LICENSE` or `LICENSE.md` — license type (first line)
+- `src/index.*`, `lib/index.*` — primary exports
+- `bin/` directory — CLI commands
+- `examples/` or `demo/` directory — existing usage examples
+- `setup.py`, `pyproject.toml`, `Cargo.toml`, `go.mod` — alternate package managers
+
+**Format Notes:**
+- Code blocks use the project's primary language (TypeScript/JavaScript/Python/Rust/etc.)
+- Installation block uses `bash` language tag
+- Quick start uses a numbered list with bash commands
+- Keep it scannable — a new user should understand the project within 60 seconds
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_readme>
+
+<template_architecture>
+## ARCHITECTURE.md
+
+**Required Sections:**
+- System overview — A single paragraph describing what the system does at the highest level, its primary
+  inputs and outputs, and the main architectural style (e.g., layered, event-driven, microservices).
+  Discover: Read the root-level `README.md` or `package.json` description; grep for top-level export patterns.
+- Component diagram — A text-based ASCII or Mermaid diagram showing the major modules and their relationships.
+  Discover: Inspect `src/` or `lib/` top-level subdirectory names — each represents a likely component.
+  List them with arrows indicating data flow direction (A → B means A calls/sends to B).
+- Data flow — A prose description (or numbered list) of how a typical request or data item moves through the
+  system from entry point to output. Discover: Grep for `app.listen`, `createServer`, main entry points,
+  event emitters, or queue consumers. Follow the call chain for 2-3 levels.
+- Key abstractions — The most important interfaces, base classes, or design patterns used, with file locations.
+  Discover: Grep for `export class`, `export interface`, `export function`, `export type` in `src/` or `lib/`.
+  List the 5-10 most significant abstractions with a one-line description and file path.
+- Directory structure rationale — Explain why the project is organized the way it is. List top-level
+  directories with a one-sentence description of each. Discover: Run `ls src/` or `ls lib/`; read index files
+  of each subdirectory to understand its purpose.
+
+**Content Discovery:**
+- `src/` or `lib/` top-level directory listing — major module boundaries
+- Grep `export class|export interface|export function` in `src/**/*.ts` or `lib/**/*.js`
+- Framework config files: `next.config.*`, `vite.config.*`, `webpack.config.*` — architecture signals
+- Entry point: `src/index.*`, `lib/index.*`, `bin/` — top-level exports
+- `package.json` `main` and `exports` fields — public API surface
+
+**Format Notes:**
+- Use Mermaid `graph TD` syntax for component diagrams when the doc tooling supports it; fall back to ASCII
+- Keep component diagrams to 10 nodes maximum — omit leaf-level utilities
+- Directory structure can use a code block with tree-style indentation
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_architecture>
+
+<template_getting_started>
+## GETTING-STARTED.md
+
+**Required Sections:**
+- Prerequisites — Runtime versions, required tools, and system dependencies the user must have installed
+  before they can use the project. Discover: `package.json` `engines` field, `.nvmrc` or `.node-version`
+  file, `Dockerfile` `FROM` line (indicates runtime), `pyproject.toml` `requires-python`.
+  List exact versions when discoverable; use ">=X.Y" format.
+- Installation steps — Step-by-step commands to clone the repo and install dependencies. Always include:
+  1. Clone command (`git clone {remote URL if detectable, else placeholder}`), 2. `cd` into project dir,
+  3. Install command (detected from package manager). Discover: `package.json` for npm/yarn/pnpm, `Pipfile`
+  or `requirements.txt` for pip, `Makefile` for custom install targets.
+- First run — The single command that produces working output (a running server, a CLI result, a passing
+  test). Discover: `package.json` `scripts.start` or `scripts.dev`; `Makefile` `run` or `serve` target;
+  `README.md` quick-start section if it exists.
+- Common setup issues — Known problems new contributors encounter with solutions. Discover: Check for
+  `.env.example` (missing env var errors), `package.json` `engines` version constraints (wrong runtime
+  version), `README.md` existing troubleshooting section, common port conflict patterns.
+  Include at least 2 issues; leave as a placeholder list if none are discoverable.
+- Next steps — Links to other generated docs (DEVELOPMENT.md, TESTING.md) so the user knows where to go
+  after first run.
+
+**Content Discovery:**
+- `package.json` `engines` field — Node.js/npm version requirements
+- `.nvmrc`, `.node-version` — exact Node version pinned
+- `.env.example` or `.env.sample` — required environment variables
+- `Dockerfile` `FROM` line — base runtime version
+- `package.json` `scripts.start` and `scripts.dev` — first run command
+- `Makefile` targets — alternative install/run commands
+
+**Format Notes:**
+- Use numbered lists for sequential steps
+- Commands use `bash` code blocks
+- Version requirements use inline code: `Node.js >= 18.0.0`
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_getting_started>
+
+<template_development>
+## DEVELOPMENT.md
+
+**Required Sections:**
+- Local setup — How to fork, clone, install, and configure the project for development (vs production use).
+  Discover: Same as getting-started but include dev-only steps: `npm install` (not `npm ci`), copying
+  `.env.example` to `.env`, any `npm run build` or compile step needed before the dev server starts.
+- Build commands — All scripts from `package.json` `scripts` field with a brief description of what each
+  does. Discover: Read `package.json` `scripts`; categorize into build, dev, lint, format, and other.
+  Omit lifecycle hooks (`prepublish`, `postinstall`) unless they require developer awareness.
+- Code style — The linting and formatting tools in use and how to run them. Discover: Check for
+  `.eslintrc*`, `.eslintrc.json`, `.eslintrc.js`, `eslint.config.*` (ESLint), `.prettierrc*`, `prettier.config.*`
+  (Prettier), `biome.json` (Biome), `.editorconfig`. Report the tool name, config file location, and the
+  `package.json` script to run it (e.g., `npm run lint`).
+- Branch conventions — How branches should be named and what the main/default branch is. Discover: Check
+  `.github/PULL_REQUEST_TEMPLATE.md` or `CONTRIBUTING.md` for branch naming rules. If not documented,
+  infer from recent git branches if accessible; otherwise state "No convention documented."
+- PR process — How to submit a pull request. Discover: Read `.github/PULL_REQUEST_TEMPLATE.md` for
+  required checklist items; read `CONTRIBUTING.md` for review process. Summarize in 3-5 bullet points.
+
+**Content Discovery:**
+- `package.json` `scripts` — all build/dev/lint/format/test commands
+- `.eslintrc*`, `eslint.config.*` — ESLint configuration presence
+- `.prettierrc*`, `prettier.config.*` — Prettier configuration presence
+- `biome.json` — Biome linter/formatter configuration
+- `.editorconfig` — editor-level style settings
+- `.github/PULL_REQUEST_TEMPLATE.md` — PR checklist
+- `CONTRIBUTING.md` — branch and PR conventions
+
+**Format Notes:**
+- Build commands section uses a table: `| Command | Description |`
+- Code style section names the tool (ESLint, Prettier, Biome) before the config detail
+- Branch conventions use inline code for branch name patterns (e.g., `feat/my-feature`)
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_development>
+
+<template_testing>
+## TESTING.md
+
+**Required Sections:**
+- Test framework and setup — The testing framework(s) in use and any required setup before running tests.
+  Discover: Check `package.json` `devDependencies` for `jest`, `vitest`, `mocha`, `jasmine`, `pytest`,
+  `go test` patterns. Check for `jest.config.*`, `vitest.config.*`, `.mocharc.*`. State the framework name,
+  version (from devDependencies), and any global setup needed (e.g., `npm install` if not already done).
+- Running tests — Exact commands to run the full test suite, a subset, or a single file. Discover:
+  `package.json` `scripts.test`, `scripts.test:unit`, `scripts.test:integration`, `scripts.test:e2e`.
+  Include the watch mode command if present (e.g., `scripts.test:watch`). Show the command and what it runs.
+- Writing new tests — File naming convention and test helper patterns for new contributors. Discover: Inspect
+  existing test files to determine naming convention (e.g., `*.test.ts`, `*.spec.ts`, `__tests__/*.ts`).
+  Look for shared test helpers (e.g., `tests/helpers.*`, `test/setup.*`) and describe their purpose briefly.
+- Coverage requirements — The minimum coverage thresholds configured for CI. Discover: Check `jest.config.*`
+  `coverageThreshold`, `vitest.config.*` coverage section, `.nycrc`, `c8` config in `package.json`. State
+  the thresholds by coverage type (lines, branches, functions, statements). If none configured, state "No
+  coverage threshold configured."
+- CI integration — How tests run in CI. Discover: Read `.github/workflows/*.yml` files and extract the test
+  execution step(s). State the workflow name, trigger (push/PR), and the test command run.
+
+**Content Discovery:**
+- `package.json` `devDependencies` — test framework detection
+- `package.json` `scripts.test*` — all test run commands
+- `jest.config.*`, `vitest.config.*`, `.mocharc.*` — test configuration
+- `.nycrc`, `c8` config — coverage thresholds
+- `.github/workflows/*.yml` — CI test steps
+- `tests/`, `test/`, `__tests__/` directories — test file naming patterns
+
+**Format Notes:**
+- Running tests section uses `bash` code blocks for each command
+- Coverage thresholds use a table: `| Type | Threshold |`
+- CI integration references the workflow file name and job name
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_testing>
+
+<template_api>
+## API.md
+
+**Required Sections:**
+- Authentication — The authentication mechanism used (API keys, JWT, OAuth, session cookies) and how to
+  include credentials in requests. Discover: Grep for `passport`, `jsonwebtoken`, `jwt-simple`, `express-session`,
+  `@auth0`, `clerk`, `supabase` in `package.json` dependencies. Grep for `Authorization` header, `Bearer`,
+  `apiKey`, `x-api-key` patterns in route/middleware files. Use VERIFY markers for actual key values or
+  external auth service URLs.
+- Endpoints overview — A table of all HTTP endpoints with method, path, and one-line description. Discover:
+  Read files in `src/routes/`, `src/api/`, `app/api/`, `pages/api/` (Next.js), `routes/` directories.
+  Grep for `router.get|router.post|router.put|router.delete|app.get|app.post` patterns. Check for OpenAPI
+  or Swagger specs in `openapi.yaml`, `swagger.json`, `docs/openapi.*`.
+- Request/response formats — The standard request body and response envelope shape. Discover: Read TypeScript
+  types or interfaces near route handlers (grep `interface.*Request|interface.*Response|type.*Payload`).
+  Check for Zod/Joi/Yup schema definitions near route files. Show a representative example per endpoint type.
+- Error codes — The standard error response shape and common status codes with their meanings. Discover:
+  Grep for error handler middleware (Express: `app.use((err, req, res, next)` pattern; Fastify: `setErrorHandler`).
+  Look for an `errors.ts` or `error-codes.ts` file. List HTTP status codes used with their semantic meaning.
+- Rate limits — Any rate limiting configuration applied to the API. Discover: Grep for `express-rate-limit`,
+  `rate-limiter-flexible`, `@upstash/ratelimit` in `package.json`. Check middleware files for rate limit
+  config. Use VERIFY marker if rate limit values are environment-dependent.
+
+**Content Discovery:**
+- `src/routes/`, `src/api/`, `app/api/`, `pages/api/` — route file locations
+- `package.json` `dependencies` — auth and rate-limit library detection
+- Grep `router\.(get|post|put|delete|patch)` in route files — endpoint discovery
+- `openapi.yaml`, `swagger.json`, `docs/openapi.*` — existing API spec
+- TypeScript interface/type files near routes — request/response shapes
+- Middleware files — auth and rate-limit middleware
+
+**Format Notes:**
+- Endpoints table columns: `| Method | Path | Description | Auth Required |`
+- Request/response examples use `json` code blocks
+- Rate limits state the window and max requests: "100 requests per 15 minutes"
+
+**VERIFY marker guidance:** Use `<!-- VERIFY: {claim} -->` for:
+- External auth service URLs or dashboard links
+- API key names not shown in `.env.example`
+- Rate limit values that come from environment variables
+- Actual base URLs for the deployed API
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_api>
+
+<template_configuration>
+## CONFIGURATION.md
+
+**Required Sections:**
+- Environment variables — A table listing every environment variable with name, required/optional status, and
+  description. Discover: Read `.env.example` or `.env.sample` for the canonical list. Grep for `process.env.`
+  patterns in `src/`, `lib/`, or `config/` to find variables not in the example file. Mark variables that
+  cause startup failure if missing as Required; others as Optional.
+- Config file format — If the project uses config files (JSON, YAML, TOML) beyond environment variables,
+  describe the format and location. Discover: Check for `config/`, `config.json`, `config.yaml`, `*.config.js`,
+  `app.config.*`. Read the file and describe its top-level keys with one-line descriptions.
+- Required vs optional settings — Which settings cause the application to fail on startup if absent, and which
+  have defaults. Discover: Grep for early validation patterns like `if (!process.env.X) throw` or
+  `z.string().min(1)` (Zod) near config loading. List required settings with their validation error message.
+- Defaults — The default values for optional settings as defined in the source code. Discover: Look for
+  `const X = process.env.Y || 'default-value'` patterns or `schema.default(value)` in config loading code.
+  Show the variable name, default value, and where it is set.
+- Per-environment overrides — How to configure different values for development, staging, and production.
+  Discover: Check for `.env.development`, `.env.production`, `.env.test` files, `NODE_ENV` conditionals in
+  config loading, or platform-specific config mechanisms (Vercel env vars, Railway secrets).
+
+**Content Discovery:**
+- `.env.example` or `.env.sample` — canonical environment variable list
+- Grep `process.env\.` in `src/**` or `lib/**` — all env var references
+- `config/`, `src/config.*`, `lib/config.*` — config file locations
+- Grep `if.*process\.env|process\.env.*\|\|` — required vs optional detection
+- `.env.development`, `.env.production`, `.env.test` — per-environment files
+
+**VERIFY marker guidance:** Use `<!-- VERIFY: {claim} -->` for:
+- Production URLs, CDN endpoints, or external service base URLs not in `.env.example`
+- Specific secret key names used in production that are not documented in the repo
+- Infrastructure-specific values (database cluster names, cloud region identifiers)
+- Configuration values that vary per deployment and cannot be inferred from source
+
+**Format Notes:**
+- Environment variables table: `| Variable | Required | Default | Description |`
+- Config file format uses a `yaml` or `json` code block showing a minimal working example
+- Required settings are highlighted with bold or a "Required" label
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_configuration>
+
+<template_deployment>
+## DEPLOYMENT.md
+
+**Required Sections:**
+- Deployment targets — Where the project can be deployed and how. Discover: Check for `Dockerfile` (Docker/
+  container-based), `docker-compose.yml` (Docker Compose), `vercel.json` (Vercel), `netlify.toml` (Netlify),
+  `fly.toml` (Fly.io), `railway.json` (Railway), `serverless.yml` (Serverless Framework), `.github/workflows/`
+  files containing `deploy` in their name. List each detected target with its config file.
+- Build pipeline — The CI/CD steps that produce the deployment artifact. Discover: Read `.github/workflows/`
+  YAML files that include a deploy step. Extract the trigger (push to main, tag creation), build command,
+  and deploy command sequence. If no CI config exists, state "No CI/CD pipeline detected."
+- Environment setup — Required environment variables for production deployment, referencing CONFIGURATION.md
+  for the full list. Discover: Cross-reference `.env.example` Required variables with production deployment
+  context. Use VERIFY markers for values that must be set in the deployment platform's secret manager.
+- Rollback procedure — How to revert a deployment if something goes wrong. Discover: Check CI workflows for
+  rollback steps; check `fly.toml`, `vercel.json`, or `netlify.toml` for rollback commands. If none found,
+  state the general approach (e.g., "Redeploy the previous Docker image tag" or "Use platform dashboard").
+- Monitoring — How the deployed application is monitored. Discover: Check `package.json` `dependencies` for
+  Sentry (`@sentry/*`), Datadog (`dd-trace`), New Relic (`newrelic`), OpenTelemetry (`@opentelemetry/*`).
+  Check for `sentry.config.*` or similar files. Use VERIFY markers for dashboard URLs.
+
+**Content Discovery:**
+- `Dockerfile`, `docker-compose.yml` — container deployment
+- `vercel.json`, `netlify.toml`, `fly.toml`, `railway.json`, `serverless.yml` — platform config
+- `.github/workflows/*.yml` containing `deploy`, `release`, or `publish` — CI/CD pipeline
+- `package.json` `dependencies` — monitoring library detection
+- `sentry.config.*`, `datadog.config.*` — monitoring configuration files
+
+**VERIFY marker guidance:** Use `<!-- VERIFY: {claim} -->` for:
+- Hosting platform URLs, dashboard links, or team-specific project URLs
+- Server specifications (RAM, CPU, instance type) not defined in config files
+- Actual deployment commands run outside of CI (manual steps on production servers)
+- Monitoring dashboard URLs or alert webhook endpoints
+- DNS records, domain names, or CDN configuration
+
+**Format Notes:**
+- Deployment targets section uses a bullet list or table with config file references
+- Build pipeline shows CI steps as a numbered list with the actual commands
+- Rollback procedure uses numbered steps for clarity
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_deployment>
+
+<template_contributing>
+## CONTRIBUTING.md
+
+**Required Sections:**
+- Code of conduct link — A single line pointing to the code of conduct. Discover: Check for
+  `CODE_OF_CONDUCT.md` in the project root. If present: "Please read our [Code of Conduct](CODE_OF_CONDUCT.md)
+  before contributing." If absent: omit this section.
+- Development setup — Brief setup instructions for new contributors, referencing DEVELOPMENT.md and
+  GETTING-STARTED.md rather than duplicating them. Discover: Confirm those docs exist or are being generated.
+  Include a one-liner: "See GETTING-STARTED.md for prerequisites and first-run instructions, and
+  DEVELOPMENT.md for local development setup."
+- Coding standards — The linting and formatting standards contributors must follow. Discover: Same detection
+  as DEVELOPMENT.md (ESLint, Prettier, Biome, editorconfig). State the tool, the run command, and whether
+  CI enforces it (check `.github/workflows/` for lint steps). Keep to 2-4 bullet points.
+- PR guidelines — How to submit a pull request and what reviewers look for. Discover: Read
+  `.github/PULL_REQUEST_TEMPLATE.md` for required checklist items. If absent, check `CONTRIBUTING.md`
+  patterns in the repo. Include: branch naming, commit message format (conventional commits?), test
+  requirements, review process. 4-6 bullet points.
+- Issue reporting — How to report bugs or request features. Discover: Check `.github/ISSUE_TEMPLATE/`
+  for bug and feature request templates. State the GitHub Issues URL pattern and what information to include.
+  If no templates exist, provide standard guidance (steps to reproduce, expected/actual behavior, environment).
+
+**Content Discovery:**
+- `CODE_OF_CONDUCT.md` — code of conduct presence
+- `.github/PULL_REQUEST_TEMPLATE.md` — PR checklist
+- `.github/ISSUE_TEMPLATE/` — issue templates
+- `.github/workflows/` — lint/test enforcement in CI
+- `package.json` `scripts.lint` and related — code style commands
+- `CONTRIBUTING.md` — if exists, use as additional source
+
+**Format Notes:**
+- Keep CONTRIBUTING.md concise — contributors should find what they need in under 2 minutes
+- Use bullet lists for PR guidelines and coding standards
+- Link to other generated docs rather than duplicating their content
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_contributing>
+
+<template_readme_per_package>
+## Per-Package README (monorepo scope)
+
+Used when `scope: per_package` is set in `doc_assignment`.
+
+**Required Sections:**
+- Package name and one-line description — State what this specific package does and its role in the monorepo.
+  Discover: Read `{package_dir}/package.json` `.name` and `.description` fields. Use the scoped package
+  name (e.g., `@myorg/core`) as the heading.
+- Installation — The scoped package install command for consumers of this package.
+  Discover: Read `{package_dir}/package.json` `.name` for the full scoped package name.
+  Format: `npm install @scope/pkg-name` (or yarn/pnpm equivalent if detected from root package manager).
+  Omit if the package is private (`"private": true` in package.json).
+- Usage — Key exports or CLI commands specific to this package only. Show 1-2 realistic usage examples.
+  Discover: Read `{package_dir}/src/index.*` or `{package_dir}/index.*` for the primary export surface.
+  Check `{package_dir}/package.json` `.main`, `.module`, `.exports` for the entry point.
+- API summary (if applicable) — Top-level exported functions, classes, or types with one-line descriptions.
+  Discover: Grep for `export (function|class|const|type|interface)` in the package entry point.
+  Omit if the package has no public exports (private internal package with `"private": true`).
+- Testing — How to run tests for this package in isolation.
+  Discover: Read `{package_dir}/package.json` `scripts.test`. If a monorepo test runner is used (Turborepo,
+  Nx), also show the workspace-scoped command (e.g., `npm run test --workspace=packages/my-pkg`).
+
+**Content Discovery (package-scoped):**
+- Read `{package_dir}/package.json` — name, description, version, scripts, main/exports, private flag
+- Read `{package_dir}/src/index.*` or `{package_dir}/index.*` — exports
+- Check `{package_dir}/test/`, `{package_dir}/tests/`, `{package_dir}/__tests__/` — test structure
+
+**Format Notes:**
+- Scope to this package only — do not describe sibling packages or the monorepo root.
+- Include a "Part of the [monorepo name] monorepo" line linking to the root README.
+- Doc Tooling Adaptation: See `<doc_tooling_guidance>` section.
+</template_readme_per_package>
+
+<template_custom>
+## Custom Documentation (gap-detected)
+
+Used when `type: custom` is set in `doc_assignment`. These docs fill documentation gaps identified
+by the workflow's gap detection step — areas of the codebase that need documentation but don't
+have any yet (e.g., frontend components, service modules, utility libraries).
+
+**Inputs from doc_assignment:**
+- `description`: What this doc should cover (e.g., "Frontend components in src/components/")
+- `output_path`: Where to write the file (follows project's existing doc structure)
+
+**Writing approach:**
+1. Read the `description` to understand what area of the codebase to document.
+2. Explore the relevant source directories using Read, Grep, Glob to discover:
+   - What modules/components/services exist
+   - Their purpose (from exports, JSDoc, comments, naming)
+   - Key interfaces, props, parameters, return types
+   - Dependencies and relationships between modules
+3. Follow the project's existing documentation style:
+   - If other docs in the same directory use a specific heading structure, match it
+   - If other docs include code examples, include them here too
+   - Match the level of detail present in sibling docs
+4. Write the doc to `output_path`.
+
+**Required Sections (adapt based on what's being documented):**
+- Overview — One paragraph describing what this area of the codebase does
+- Module/component listing — Each significant item with a one-line description
+- Key interfaces or APIs — The most important exports, props, or function signatures
+- Usage examples — 1-2 concrete examples if applicable
+
+**Content Discovery:**
+- Read source files in the directories mentioned in `description`
+- Grep for `export`, `module.exports`, `export default` to find public APIs
+- Check for existing JSDoc, docstrings, or README files in the source directory
+- Read test files if present for usage patterns
+
+**Format Notes:**
+- Match the project's existing doc style (discovered from sibling docs in the same directory)
+- Use the project's primary language for code blocks
+- Keep it practical — focus on what a developer needs to know to use or modify these modules
+
+**Doc Tooling Adaptation:** See `<doc_tooling_guidance>` section.
+</template_custom>
+
+<doc_tooling_guidance>
+## Doc Tooling Adaptation
+
+When `doc_tooling` in `project_context` indicates a documentation framework, adapt file
+placement and frontmatter accordingly. Content structure (sections, headings) does not
+change — only location and metadata change.
+
+**Docusaurus** (`doc_tooling.docusaurus: true`):
+- Write to `docs/{canonical-filename}` (e.g., `docs/ARCHITECTURE.md`)
+- Add YAML frontmatter block at top of file (before GSD marker):
+  ```yaml
+  ---
+  title: Architecture
+  sidebar_position: 2
+  description: System architecture and component overview
+  ---
+  ```
+- `sidebar_position`: use 1 for README/overview, 2 for Architecture, 3 for Getting Started, etc.
+
+**VitePress** (`doc_tooling.vitepress: true`):
+- Write to `docs/{canonical-filename}` (primary docs directory)
+- Add YAML frontmatter:
+  ```yaml
+  ---
+  title: Architecture
+  description: System architecture and component overview
+  ---
+  ```
+- No `sidebar_position` — VitePress sidebars are configured in `.vitepress/config.*`
+
+**MkDocs** (`doc_tooling.mkdocs: true`):
+- Write to `docs/{canonical-filename}` (MkDocs default docs directory)
+- Add YAML frontmatter with `title` only:
+  ```yaml
+  ---
+  title: Architecture
+  ---
+  ```
+- Respect the `nav:` section in `mkdocs.yml` if present — use matching filenames.
+  Read `mkdocs.yml` and check if a nav entry references the target doc before writing.
+
+**Storybook** (`doc_tooling.storybook: true`):
+- No special doc placement — Storybook handles component stories, not project docs.
+- Generate docs to project root as normal. Storybook detection has no effect on
+  placement or frontmatter.
+
+**No tooling detected:**
+- Write to `docs/` directory by default. Exceptions: `README.md` and `CONTRIBUTING.md` stay at project root.
+- The `resolve_modes` table in the workflow determines the exact path for each doc type.
+- Create the `docs/` directory if it does not exist.
+- No frontmatter added.
+</doc_tooling_guidance>
+
+<critical_rules>
+
+1. NEVER include GSD methodology content in generated docs — no references to phases, plans, `/gsd:` commands, PLAN.md, ROADMAP.md, or any GSD workflow concepts. Generated docs describe the TARGET PROJECT exclusively.
+2. NEVER touch CHANGELOG.md — it is managed by `/gsd:ship` and is out of scope.
+3. ALWAYS include the GSD marker `<!-- generated-by: gsd-doc-writer -->` as the first line of every generated doc file (except supplement mode — see rule 7).
+4. ALWAYS explore the actual codebase before writing — never fabricate file paths, function names, endpoints, or configuration values.
+8. **ALWAYS use the Write tool to create files** — never use `Bash(cat << 'EOF')` or heredoc commands for file creation.
+5. Use `<!-- VERIFY: {claim} -->` markers for any infrastructure claim (URLs, server configs, external service details) that cannot be verified from the repository contents alone.
+6. In update mode, PRESERVE user-authored content in sections that are still accurate. Only rewrite inaccurate or missing sections.
+7. In supplement mode, NEVER modify existing content. Only append missing sections. Do NOT add the GSD marker to hand-written files.
+
+</critical_rules>
+
+<success_criteria>
+- [ ] Doc file written to the correct path
+- [ ] GSD marker present as first line
+- [ ] All required sections from template are present
+- [ ] No GSD methodology references in output
+- [ ] All file paths, function names, and commands verified against codebase
+- [ ] VERIFY markers placed on undiscoverable infrastructure claims
+- [ ] (update mode) User-authored accurate sections preserved
+- [ ] (supplement mode) Only missing sections were appended; no existing content was modified
+</success_criteria>
diff --git a/commands/gsd/docs-update.md b/commands/gsd/docs-update.md
new file mode 100644
index 000000000..a0eab21da
--- /dev/null
+++ b/commands/gsd/docs-update.md
@@ -0,0 +1,48 @@
+---
+name: gsd:docs-update
+description: Generate or update project documentation verified against the codebase
+argument-hint: "[--force] [--verify-only]"
+allowed-tools:
+  - Read
+  - Write
+  - Edit
+  - Bash
+  - Glob
+  - Grep
+  - Task
+  - AskUserQuestion
+---
+<objective>
+Generate and update up to 9 documentation files for the current project. Each doc type is written by a gsd-doc-writer subagent that explores the codebase directly — no hallucinated paths, phantom endpoints, or stale signatures.
+
+Flag handling rule:
+- The optional flags documented below are available behaviors, not implied active behaviors
+- A flag is active only when its literal token appears in `$ARGUMENTS`
+- If a documented flag is absent from `$ARGUMENTS`, treat it as inactive
+- `--force`: skip preservation prompts, regenerate all docs regardless of existing content or GSD markers
+- `--verify-only`: check existing docs for accuracy against codebase, no generation (full verification requires Phase 4 verifier)
+- If `--force` and `--verify-only` both appear in `$ARGUMENTS`, `--force` takes precedence
+</objective>
+
+<execution_context>
+@~/.claude/get-shit-done/workflows/docs-update.md
+</execution_context>
+
+<context>
+Arguments: $ARGUMENTS
+
+**Available optional flags (documentation only — not automatically active):**
+- `--force` — Regenerate all docs. Overwrites hand-written and GSD docs alike. No preservation prompts.
+- `--verify-only` — Check existing docs for accuracy against the codebase. No files are written. Reports VERIFY marker count. Full codebase fact-checking requires the gsd-doc-verifier agent (Phase 4).
+
+**Active flags must be derived from `$ARGUMENTS`:**
+- `--force` is active only if the literal `--force` token is present in `$ARGUMENTS`
+- `--verify-only` is active only if the literal `--verify-only` token is present in `$ARGUMENTS`
+- If neither token appears, run the standard full-phase generation flow
+- Do not infer that a flag is active just because it is documented in this prompt
+</context>
+
+<process>
+Execute the docs-update workflow from @~/.claude/get-shit-done/workflows/docs-update.md end-to-end.
+Preserve all workflow gates (preservation_check, flag handling, wave execution, monorepo dispatch, commit, reporting).
+</process>
diff --git a/get-shit-done/bin/gsd-tools.cjs b/get-shit-done/bin/gsd-tools.cjs
index 65ec8bc38..e583bd5bf 100755
--- a/get-shit-done/bin/gsd-tools.cjs
+++ b/get-shit-done/bin/gsd-tools.cjs
@@ -133,6 +133,9 @@
  *   init milestone-op                  All context for milestone operations
  *   init map-codebase                  All context for map-codebase workflow
  *   init progress                      All context for progress workflow
+ *
+ * Documentation:
+ *   docs-init                            Project context for docs-update workflow
  */
 
 const fs = require('fs');
@@ -152,6 +155,7 @@ const frontmatter = require('./lib/frontmatter.cjs');
 const profilePipeline = require('./lib/profile-pipeline.cjs');
 const profileOutput = require('./lib/profile-output.cjs');
 const workstream = require('./lib/workstream.cjs');
+const docs = require('./lib/docs.cjs');
 
 // ─── Arg parsing helpers ──────────────────────────────────────────────────────
 
@@ -274,7 +278,7 @@ async function main() {
   const command = args[0];
 
   if (!command) {
-    error('Usage: gsd-tools <command> [args] [--raw] [--pick <field>] [--cwd <path>] [--ws <name>]\nCommands: state, resolve-model, find-phase, commit, verify-summary, verify, frontmatter, template, generate-slug, current-timestamp, list-todos, verify-path-exists, config-ensure-section, config-new-project, init, workstream');
+    error('Usage: gsd-tools <command> [args] [--raw] [--pick <field>] [--cwd <path>] [--ws <name>]\nCommands: state, resolve-model, find-phase, commit, verify-summary, verify, frontmatter, template, generate-slug, current-timestamp, list-todos, verify-path-exists, config-ensure-section, config-new-project, init, workstream, docs-init');
   }
 
   // Multi-repo guard: resolve project root for commands that read/write .planning/.
@@ -910,6 +914,13 @@ async function runCommand(command, args, cwd, raw) {
       break;
     }
 
+    // ─── Documentation ────────────────────────────────────────────────────
+
+    case 'docs-init': {
+      docs.cmdDocsInit(cwd, raw);
+      break;
+    }
+
     default:
       error(`Unknown command: ${command}`);
   }
diff --git a/get-shit-done/bin/lib/docs.cjs b/get-shit-done/bin/lib/docs.cjs
new file mode 100644
index 000000000..378842a23
--- /dev/null
+++ b/get-shit-done/bin/lib/docs.cjs
@@ -0,0 +1,267 @@
+/**
+ * Docs — Commands for the docs-update workflow
+ *
+ * Provides `cmdDocsInit` which returns project signals, existing doc inventory
+ * with GSD marker detection, doc tooling detection, monorepo awareness, and
+ * model resolution. Used by Phase 2 to route doc generation appropriately.
+ */
+
+const fs = require('fs');
+const path = require('path');
+const { output, loadConfig, resolveModelInternal, pathExistsInternal, toPosixPath, checkAgentsInstalled } = require('./core.cjs');
+
+// ─── Constants ────────────────────────────────────────────────────────────────
+
+const GSD_MARKER = '<!-- generated-by: gsd-doc-writer -->';
+
+const SKIP_DIRS = new Set([
+  'node_modules', '.git', '.planning', '.claude', '__pycache__',
+  'target', 'dist', 'build', '.next', '.nuxt', 'coverage',
+  '.vscode', '.idea',
+]);
+
+// ─── Private helpers ──────────────────────────────────────────────────────────
+
+/**
+ * Check whether a file begins with the GSD doc writer marker.
+ * Reads the first 500 bytes only — avoids loading large files.
+ *
+ * @param {string} filePath - Absolute path to the file
+ * @returns {boolean}
+ */
+function hasGsdMarker(filePath) {
+  try {
+    const buf = Buffer.alloc(500);
+    const fd = fs.openSync(filePath, 'r');
+    const bytesRead = fs.readSync(fd, buf, 0, 500, 0);
+    fs.closeSync(fd);
+    return buf.slice(0, bytesRead).toString('utf-8').includes(GSD_MARKER);
+  } catch {
+    return false;
+  }
+}
+
+/**
+ * Recursively scan the project root (immediate .md files) and docs/ directory
+ * (up to 4 levels deep) for Markdown files, excluding dirs in SKIP_DIRS.
+ *
+ * @param {string} cwd - Project root
+ * @returns {Array<{path: string, has_gsd_marker: boolean}>}
+ */
+function scanExistingDocs(cwd) {
+  const MAX_DEPTH = 4;
+  const results = [];
+
+  /**
+   * Recursively walk a directory for .md files up to MAX_DEPTH levels.
+   * @param {string} dir - Directory to scan
+   * @param {number} depth - Current depth (1-based)
+   */
+  function walkDir(dir, depth) {
+    if (depth > MAX_DEPTH) return;
+    try {
+      const entries = fs.readdirSync(dir, { withFileTypes: true });
+      for (const entry of entries) {
+        if (SKIP_DIRS.has(entry.name)) continue;
+        const abs = path.join(dir, entry.name);
+        if (entry.isDirectory()) {
+          walkDir(abs, depth + 1);
+        } else if (entry.isFile() && entry.name.toLowerCase().endsWith('.md')) {
+          const rel = toPosixPath(path.relative(cwd, abs));
+          results.push({ path: rel, has_gsd_marker: hasGsdMarker(abs) });
+        }
+      }
+    } catch { /* directory may not exist — best-effort */ }
+  }
+
+  // Scan root-level .md files (non-recursive)
+  try {
+    const entries = fs.readdirSync(cwd, { withFileTypes: true });
+    for (const entry of entries) {
+      if (entry.isFile() && entry.name.toLowerCase().endsWith('.md')) {
+        const abs = path.join(cwd, entry.name);
+        const rel = toPosixPath(path.relative(cwd, abs));
+        results.push({ path: rel, has_gsd_marker: hasGsdMarker(abs) });
+      }
+    }
+  } catch { /* best-effort */ }
+
+  // Recursively scan docs/ directory
+  const docsDir = path.join(cwd, 'docs');
+  walkDir(docsDir, 1);
+
+  // Fallback: if docs/ does not exist, try documentation/ or doc/
+  try {
+    fs.statSync(docsDir);
+  } catch {
+    const alternatives = ['documentation', 'doc'];
+    for (const alt of alternatives) {
+      const altDir = path.join(cwd, alt);
+      try {
+        const stat = fs.statSync(altDir);
+        if (stat.isDirectory()) {
+          walkDir(altDir, 1);
+          break;
+        }
+      } catch { /* not present */ }
+    }
+  }
+
+  return results.sort((a, b) => a.path.localeCompare(b.path));
+}
+
+/**
+ * Detect project type signals from the filesystem and package.json.
+ * All checks are best-effort and never throw.
+ *
+ * @param {string} cwd - Project root
+ * @returns {Object} Boolean signal fields
+ */
+function detectProjectType(cwd) {
+  const exists = (rel) => {
+    try { return pathExistsInternal(cwd, rel); } catch { return false; }
+  };
+
+  // has_cli_bin: package.json has a `bin` field
+  let has_cli_bin = false;
+  try {
+    const pkg = JSON.parse(fs.readFileSync(path.join(cwd, 'package.json'), 'utf-8'));
+    has_cli_bin = !!(pkg.bin && (typeof pkg.bin === 'string' || Object.keys(pkg.bin).length > 0));
+  } catch { /* no package.json or invalid JSON */ }
+
+  // is_monorepo: pnpm-workspace.yaml, lerna.json, or package.json workspaces
+  let is_monorepo = exists('pnpm-workspace.yaml') || exists('lerna.json');
+  if (!is_monorepo) {
+    try {
+      const pkg = JSON.parse(fs.readFileSync(path.join(cwd, 'package.json'), 'utf-8'));
+      is_monorepo = Array.isArray(pkg.workspaces) && pkg.workspaces.length > 0;
+    } catch { /* ignore */ }
+  }
+
+  // has_tests: common test directories or test frameworks in devDependencies
+  let has_tests = exists('test') || exists('tests') || exists('__tests__') || exists('spec');
+  if (!has_tests) {
+    try {
+      const pkg = JSON.parse(fs.readFileSync(path.join(cwd, 'package.json'), 'utf-8'));
+      const devDeps = Object.keys(pkg.devDependencies || {});
+      has_tests = devDeps.some(d => ['vitest', 'jest', 'mocha', 'jasmine', 'ava'].includes(d));
+    } catch { /* ignore */ }
+  }
+
+  // has_deploy_config: various deployment config files
+  const deployFiles = [
+    'Dockerfile', 'docker-compose.yml', 'docker-compose.yaml',
+    'fly.toml', 'render.yaml', 'vercel.json', 'netlify.toml', 'railway.json',
+    '.github/workflows/deploy.yml', '.github/workflows/deploy.yaml',
+  ];
+  const has_deploy_config = deployFiles.some(f => exists(f));
+
+  return {
+    has_package_json: exists('package.json'),
+    has_api_routes: (
+      exists('src/app/api') || exists('routes') || exists('src/routes') ||
+      exists('api') || exists('server')
+    ),
+    has_cli_bin,
+    is_open_source: exists('LICENSE') || exists('LICENSE.md'),
+    has_deploy_config,
+    is_monorepo,
+    has_tests,
+  };
+}
+
+/**
+ * Detect known documentation tooling in the project.
+ *
+ * @param {string} cwd - Project root
+ * @returns {Object} Boolean detection fields
+ */
+function detectDocTooling(cwd) {
+  const exists = (rel) => {
+    try { return pathExistsInternal(cwd, rel); } catch { return false; }
+  };
+
+  return {
+    docusaurus: exists('docusaurus.config.js') || exists('docusaurus.config.ts'),
+    vitepress: (
+      exists('.vitepress/config.js') ||
+      exists('.vitepress/config.ts') ||
+      exists('.vitepress/config.mts')
+    ),
+    mkdocs: exists('mkdocs.yml'),
+    storybook: exists('.storybook'),
+  };
+}
+
+/**
+ * Extract monorepo workspace globs from pnpm-workspace.yaml, package.json
+ * workspaces, or lerna.json.
+ *
+ * @param {string} cwd - Project root
+ * @returns {string[]} Array of workspace glob patterns, or [] if not a monorepo
+ */
+function detectMonorepoWorkspaces(cwd) {
+  // pnpm-workspace.yaml
+  try {
+    const content = fs.readFileSync(path.join(cwd, 'pnpm-workspace.yaml'), 'utf-8');
+    const lines = content.split('\n');
+    const workspaces = [];
+    for (const line of lines) {
+      const m = line.match(/^\s*-\s+['"]?(.+?)['"]?\s*$/);
+      if (m) workspaces.push(m[1].trim());
+    }
+    if (workspaces.length > 0) return workspaces;
+  } catch { /* not present */ }
+
+  // package.json workspaces
+  try {
+    const pkg = JSON.parse(fs.readFileSync(path.join(cwd, 'package.json'), 'utf-8'));
+    if (Array.isArray(pkg.workspaces) && pkg.workspaces.length > 0) {
+      return pkg.workspaces;
+    }
+  } catch { /* not present or invalid */ }
+
+  // lerna.json
+  try {
+    const lerna = JSON.parse(fs.readFileSync(path.join(cwd, 'lerna.json'), 'utf-8'));
+    if (Array.isArray(lerna.packages) && lerna.packages.length > 0) {
+      return lerna.packages;
+    }
+  } catch { /* not present or invalid */ }
+
+  return [];
+}
+
+// ─── Public commands ──────────────────────────────────────────────────────────
+
+/**
+ * Return JSON context for the docs-update workflow: project signals, existing
+ * doc inventory, doc tooling detection, monorepo workspaces, and model
+ * resolution. Follows the cmdInitMapCodebase pattern.
+ *
+ * @example
+ * node gsd-tools.cjs docs-init --raw
+ *
+ * @param {string} cwd - Project root directory
+ * @param {boolean} raw - Pass raw JSON flag through to output()
+ */
+function cmdDocsInit(cwd, raw) {
+  const config = loadConfig(cwd);
+  const result = {
+    doc_writer_model: resolveModelInternal(cwd, 'gsd-doc-writer'),
+    commit_docs: config.commit_docs,
+    existing_docs: scanExistingDocs(cwd),
+    project_type: detectProjectType(cwd),
+    doc_tooling: detectDocTooling(cwd),
+    monorepo_workspaces: detectMonorepoWorkspaces(cwd),
+    planning_exists: pathExistsInternal(cwd, '.planning'),
+  };
+  // Inject project_root and agent installation status (mirrors withProjectRoot in init.cjs)
+  result.project_root = cwd;
+  const agentStatus = checkAgentsInstalled();
+  result.agents_installed = agentStatus.agents_installed;
+  result.missing_agents = agentStatus.missing_agents;
+  output(result, raw);
+}
+
+module.exports = { cmdDocsInit };
diff --git a/get-shit-done/bin/lib/model-profiles.cjs b/get-shit-done/bin/lib/model-profiles.cjs
index 357456252..cd3e80e4b 100644
--- a/get-shit-done/bin/lib/model-profiles.cjs
+++ b/get-shit-done/bin/lib/model-profiles.cjs
@@ -22,6 +22,8 @@ const MODEL_PROFILES = {
   'gsd-ui-researcher': { quality: 'opus', balanced: 'sonnet', budget: 'haiku' },
   'gsd-ui-checker': { quality: 'sonnet', balanced: 'sonnet', budget: 'haiku' },
   'gsd-ui-auditor': { quality: 'sonnet', balanced: 'sonnet', budget: 'haiku' },
+  'gsd-doc-writer': { quality: 'opus', balanced: 'sonnet', budget: 'haiku' },
+  'gsd-doc-verifier': { quality: 'sonnet', balanced: 'sonnet', budget: 'haiku' },
 };
 const VALID_PROFILES = Object.keys(MODEL_PROFILES['gsd-planner']);
 
diff --git a/get-shit-done/workflows/docs-update.md b/get-shit-done/workflows/docs-update.md
new file mode 100644
index 000000000..75d642afe
--- /dev/null
+++ b/get-shit-done/workflows/docs-update.md
@@ -0,0 +1,1153 @@
+<purpose>
+Generate, update, and verify all project documentation — both canonical doc types and existing hand-written docs. The orchestrator detects the project's doc structure, assembles a work manifest tracking every item, dispatches parallel doc-writer and doc-verifier agents across waves, reviews existing docs for accuracy, identifies documentation gaps, and fixes inaccuracies via a bounded fix loop. All state is persisted in a work manifest so no work item is lost between steps. Output: Complete, structure-aware documentation verified against the live codebase.
+</purpose>
+
+<available_agent_types>
+Valid GSD subagent types (use exact names — do not fall back to 'general-purpose'):
+- gsd-doc-writer — Writes and updates project documentation files
+- gsd-doc-verifier — Verifies factual claims in docs against the live codebase
+</available_agent_types>
+
+<process>
+
+<step name="init_context" priority="first">
+Load docs-update context:
+
+```bash
+INIT=$(node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" docs-init)
+if [[ "$INIT" == @file:* ]]; then INIT=$(cat "${INIT#@file:}"); fi
+AGENT_SKILLS=$(node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" agent-skills gsd-doc-writer 2>/dev/null)
+```
+
+Extract from init JSON:
+- `doc_writer_model` — model string to pass to each spawned agent (never hardcode a model name)
+- `commit_docs` — whether to commit generated files when done
+- `existing_docs` — array of `{path, has_gsd_marker}` objects for existing Markdown files
+- `project_type` — object with boolean signals: `has_package_json`, `has_api_routes`, `has_cli_bin`, `is_open_source`, `has_deploy_config`, `is_monorepo`, `has_tests`
+- `doc_tooling` — object with booleans: `docusaurus`, `vitepress`, `mkdocs`, `storybook`
+- `monorepo_workspaces` — array of workspace glob patterns (empty if not a monorepo)
+- `project_root` — absolute path to the project root
+</step>
+
+<step name="classify_project">
+Map the `project_type` boolean signals from the init JSON to a primary type label and collect conditional doc signals.
+
+**Primary type classification (first match wins):**
+
+| Condition | primary_type |
+|-----------|-------------|
+| `is_monorepo` is true | `"monorepo"` |
+| `has_cli_bin` is true AND `has_api_routes` is false | `"cli-tool"` |
+| `has_api_routes` is true AND `is_open_source` is false | `"saas"` |
+| `is_open_source` is true AND `has_api_routes` is false | `"open-source-library"` |
+| (none of the above) | `"generic"` |
+
+**Conditional doc signals (D-02 union rule — check independently after primary classification):**
+
+After determining primary_type, check each signal independently regardless of the primary type. A CLI tool that is also open source with API routes still gets all three conditional docs.
+
+| Signal | Conditional Doc |
+|--------|----------------|
+| `has_api_routes` is true | Queue API.md |
+| `is_open_source` is true | Queue CONTRIBUTING.md |
+| `has_deploy_config` is true | Queue DEPLOYMENT.md |
+
+Present the classification result:
+```
+Project type: {primary_type}
+Conditional docs queued: {list or "none"}
+```
+</step>
+
+<step name="build_doc_queue">
+Assemble the complete doc queue from always-on docs plus conditional docs from classify_project.
+
+**Always-on docs (queued for every project, no exceptions):**
+1. README
+2. ARCHITECTURE
+3. GETTING-STARTED
+4. DEVELOPMENT
+5. TESTING
+6. CONFIGURATION
+
+**Conditional docs (add only if signal matched in classify_project):**
+- API (if `has_api_routes`)
+- CONTRIBUTING (if `is_open_source`)
+- DEPLOYMENT (if `has_deploy_config`)
+
+**IMPORTANT: CHANGELOG.md is NEVER queued. The doc queue is built exclusively from the 9 known doc types listed above. Do not derive the queue from `existing_docs` directly — existing_docs is only used in the next step to determine create vs update mode.**
+
+**Doc queue limit:** Maximum 9 docs. Always-on (6) + up to 3 conditional = at most 9.
+
+**CONTRIBUTING.md confirmation (new file only):**
+
+If CONTRIBUTING.md is in the conditional queue AND does NOT appear in the `existing_docs` array from init JSON:
+
+1. If `--force` is present in `$ARGUMENTS`: skip this check, include CONTRIBUTING.md in the queue.
+2. Otherwise, use AskUserQuestion to confirm:
+
+```
+AskUserQuestion([{
+  question: "This project appears to be open source (LICENSE file detected). CONTRIBUTING.md does not exist yet. Would you like to create one?",
+  header: "Contributing",
+  multiSelect: false,
+  options: [
+    { label: "Yes, create it", description: "Generate CONTRIBUTING.md with project guidelines" },
+    { label: "No, skip it", description: "This project does not need a CONTRIBUTING.md" }
+  ]
+}])
+```
+
+If the user selects "No, skip it": remove CONTRIBUTING.md from the doc queue.
+If CONTRIBUTING.md already exists in `existing_docs`: skip this prompt entirely, include it for update.
+
+**Existing non-canonical docs (review queue):**
+
+After assembling the canonical doc queue above, scan the `existing_docs` array from init JSON for files that do NOT match any canonical path in the queue (neither primary nor fallback path from the resolve_modes table). These are hand-written docs like `docs/api/endpoint-map.md` or `docs/frontend/pages/not-found.md`.
+
+For each non-canonical existing doc found:
+- Add to a separate `review_queue`
+- These will be passed to gsd-doc-verifier in the verify_docs step for accuracy checking
+- If inaccuracies are found, they will be dispatched to gsd-doc-writer in `fix` mode for surgical corrections
+
+If non-canonical docs are found, display them in the queue presentation:
+
+```
+Existing docs queued for accuracy review:
+  - docs/api/endpoint-map.md (hand-written)
+  - docs/api/README.md (hand-written)
+  - docs/frontend/pages/not-found.md (hand-written)
+```
+
+If none found, omit this section from the queue presentation.
+
+**Documentation gap detection (missing non-canonical docs):**
+
+After assembling the canonical and review queues, analyze the codebase to identify areas that should have documentation but don't. This ensures the command creates complete project documentation, not just the 9 canonical types.
+
+1. **Scan the codebase for undocumented areas:**
+   - Use Glob/Grep to discover significant source directories (e.g., `src/components/`, `src/pages/`, `src/services/`, `src/api/`, `lib/`, `routes/`)
+   - Compare against existing docs: for each major source directory, check if corresponding documentation exists in the docs tree
+   - Look at the project's existing doc structure for patterns — if the project has `docs/frontend/components/`, `docs/services/`, etc., these indicate the project's documentation conventions
+
+2. **Identify gaps based on project conventions:**
+   - If the project has a `docs/` directory with grouped subdirectories, each source module area that has a corresponding docs subdirectory but is missing documentation files represents a gap
+   - If the project has frontend components/pages but no component docs, flag this
+   - If the project has service modules but no service docs, flag this
+   - Skip areas that are already covered by canonical docs (e.g., don't flag missing API docs if `docs/API.md` is already in the canonical queue)
+
+3. **Present discovered gaps to the user:**
+
+```
+AskUserQuestion([{
+  question: "Found {N} documentation gaps in the codebase. Which should be created?",
+  header: "Doc gaps",
+  multiSelect: true,
+  options: [
+    { label: "{area}", description: "{why it needs docs — e.g., '5 components in src/components/ with no docs'}" },
+    ...up to 4 options (group related gaps if more than 4)
+  ]
+}])
+```
+
+4. For each gap the user selects:
+   - Add to the generation queue with mode = `"create"`
+   - Set the output path to match the project's existing doc directory structure
+   - The gsd-doc-writer will receive a `doc_assignment` with `type: "custom"` and a description of what to document, using the project's source files as content discovery targets
+
+If no gaps are detected, omit this section entirely.
+
+Present the assembled queue to the user before proceeding:
+
+Present the mode resolution table from resolve_modes (shown above), followed by:
+
+```
+{If non-canonical docs found, show as a table:}
+
+Existing docs queued for accuracy review:
+
+| Path | Type |
+|------|------|
+| {path} | hand-written |
+| ... | ... |
+
+CHANGELOG.md: excluded (out of scope)
+```
+
+The mode resolution table IS the queue presentation — it shows every doc with its resolved path, mode, and source. Do not duplicate the list in a separate format.
+
+Then confirm with AskUserQuestion:
+
+```
+AskUserQuestion([{
+  question: "Doc queue assembled ({N} docs). Proceed with generation?",
+  header: "Doc queue",
+  multiSelect: false,
+  options: [
+    { label: "Proceed", description: "Generate all {N} docs in the queue" },
+    { label: "Abort", description: "Cancel doc generation" }
+  ]
+}])
+```
+
+If the user selects "Abort": exit the workflow. Otherwise continue to resolve_modes.
+</step>
+
+<step name="resolve_modes">
+For each doc in the assembled queue, determine whether to create (new file) or update (existing file).
+
+**Doc type to canonical path mapping (defaults):**
+
+| Type | Default Path | Fallback Path |
+|------|-------------|---------------|
+| `readme` | `README.md` | — |
+| `architecture` | `docs/ARCHITECTURE.md` | `ARCHITECTURE.md` |
+| `getting_started` | `docs/GETTING-STARTED.md` | `GETTING-STARTED.md` |
+| `development` | `docs/DEVELOPMENT.md` | `DEVELOPMENT.md` |
+| `testing` | `docs/TESTING.md` | `TESTING.md` |
+| `api` | `docs/API.md` | `API.md` |
+| `configuration` | `docs/CONFIGURATION.md` | `CONFIGURATION.md` |
+| `deployment` | `docs/DEPLOYMENT.md` | `DEPLOYMENT.md` |
+| `contributing` | `CONTRIBUTING.md` | — |
+
+**Structure-aware path resolution:**
+
+Before applying the default path table, inspect the project's existing docs directory structure to detect whether the project uses **grouped subdirectories** or **flat files**. This determines how ALL new docs are placed.
+
+**Step 1: Detect the project's docs organization pattern.**
+
+List subdirectories under `docs/` from the `existing_docs` paths. If the project has 2+ subdirectories (e.g., `docs/architecture/`, `docs/api/`, `docs/guides/`, `docs/frontend/`), the project uses a **grouped structure**. If docs are only flat files directly in `docs/` (e.g., `docs/ARCHITECTURE.md`), it uses a **flat structure**.
+
+**Step 2: Resolve paths based on the detected pattern.**
+
+**If GROUPED structure detected:**
+
+Every doc type MUST be placed in an appropriate subdirectory — no doc should be left flat in `docs/` when the project organizes into groups. Use the following resolution logic:
+
+| Type | Subdirectory resolution (in priority order) |
+|------|----------------------------------------------|
+| `architecture` | existing `docs/architecture/` → create `docs/architecture/` if not present |
+| `getting_started` | existing `docs/guides/` → existing `docs/getting-started/` → create `docs/guides/` |
+| `development` | existing `docs/guides/` → existing `docs/development/` → create `docs/guides/` |
+| `testing` | existing `docs/testing/` → existing `docs/guides/` → create `docs/testing/` |
+| `api` | existing `docs/api/` → create `docs/api/` if not present |
+| `configuration` | existing `docs/configuration/` → existing `docs/guides/` → create `docs/configuration/` |
+| `deployment` | existing `docs/deployment/` → existing `docs/guides/` → create `docs/deployment/` |
+
+For each type, check the resolution chain left-to-right. Use the first existing subdirectory. If none exist, create the rightmost option.
+
+The filename within the subdirectory should be contextual — e.g., `docs/guides/getting-started.md`, `docs/architecture/overview.md`, `docs/api/reference.md` — rather than `docs/architecture/ARCHITECTURE.md`. Match the naming style of existing files in that subdirectory (lowercase-kebab, UPPERCASE, etc.).
+
+**If FLAT structure detected (or no docs/ directory):**
+
+Use the default path table above as-is (e.g., `docs/ARCHITECTURE.md`, `docs/TESTING.md`).
+
+**Step 3: Store each resolved path and create directories.**
+
+For each doc type, store the resolved path as `resolved_path`. Then create all necessary directories:
+```bash
+mkdir -p {each unique directory from resolved paths}
+```
+
+**Mode resolution logic:**
+
+For each doc type in the queue:
+1. Check if the `resolved_path` appears in the `existing_docs` array from the init JSON
+2. If not found at resolved path, check the default and fallback paths from the table
+3. If found at any path: mode = `"update"` — use the Read tool to load the current file content (will be passed as `existing_content` in the doc_assignment block). Use the found path as the output path (do not move existing docs).
+4. If not found: mode = `"create"` — no existing content to load. Use the `resolved_path`.
+
+**Ensure docs/ directory exists:**
+Before proceeding to the next step, create the `docs/` directory and any resolved subdirectories if they do not exist:
+```bash
+mkdir -p docs/
+```
+
+**Output a mode resolution table:**
+
+Present a table showing the resolved path, mode, and source for every doc in the queue:
+
+```
+Mode resolution:
+
+| Doc | Resolved Path | Mode | Source |
+|-----|---------------|------|--------|
+| readme | README.md | update | found at README.md |
+| architecture | docs/architecture/overview.md | create | new directory |
+| getting_started | docs/guides/getting-started.md | update | found, hand-written |
+| development | docs/guides/development.md | create | matched docs/guides/ |
+| testing | docs/guides/testing.md | create | matched docs/guides/ |
+| configuration | docs/guides/configuration.md | create | matched docs/guides/ |
+| api | docs/api/reference.md | create | new directory |
+| deployment | docs/guides/deployment.md | update | found, hand-written |
+```
+
+This table MUST be shown to the user — it is the primary confirmation of where files will be written and whether existing files will be updated. It appears as part of the queue presentation BEFORE the AskUserQuestion confirmation.
+
+Track the resolved mode and file path for each queued doc. For update-mode docs, store the loaded file content — it will be passed to the agent in the next steps.
+
+**CRITICAL: Persist the work manifest.**
+
+After resolve_modes completes, write ALL work items to `.planning/tmp/docs-work-manifest.json`. This is the single source of truth for every subsequent step — the orchestrator MUST read this file at each step instead of relying on memory.
+
+```bash
+mkdir -p .planning/tmp
+```
+
+Write the manifest using the Write tool:
+
+```json
+{
+  "canonical_queue": [
+    {
+      "type": "readme",
+      "resolved_path": "README.md",
+      "mode": "create|update|supplement",
+      "preservation_mode": null,
+      "wave": 1,
+      "status": "pending"
+    }
+  ],
+  "review_queue": [
+    {
+      "path": "docs/frontend/components/button.md",
+      "type": "hand-written",
+      "status": "pending_review"
+    }
+  ],
+  "gap_queue": [
+    {
+      "description": "Frontend components in src/components/",
+      "output_path": "docs/frontend/components/overview.md",
+      "status": "pending"
+    }
+  ],
+  "created_at": "{ISO timestamp}"
+}
+```
+
+Every subsequent step (dispatch, collect, verify, fix_loop, report) MUST begin by reading `.planning/tmp/docs-work-manifest.json` and update the `status` field for items it processes. This prevents the orchestrator from "forgetting" any work item across the multi-step workflow.
+</step>
+
+<step name="preservation_check">
+Check for hand-written docs in the queue and gather user decisions before dispatch.
+
+**Skip conditions (check in order):**
+
+1. If `--force` is present in `$ARGUMENTS`: treat all docs as mode: regenerate, skip to detect_runtime_capabilities.
+2. If `--verify-only` is present in `$ARGUMENTS`: skip to verify_only_report (do not continue to detect_runtime_capabilities).
+3. If no docs in the queue have `has_gsd_marker: false` in the `existing_docs` array: skip to detect_runtime_capabilities.
+
+**For each queued doc where `has_gsd_marker` is false (hand-written doc detected):**
+
+Present the following choice using `AskUserQuestion` if available, or inline prompt otherwise:
+
+```
+{filename} appears to be hand-written (no GSD marker found).
+
+How should this file be handled?
+  [1] preserve    -- Skip entirely. Leave unchanged.
+  [2] supplement  -- Append only missing sections. Existing content untouched.
+  [3] regenerate  -- Overwrite with a fresh GSD-generated doc.
+```
+
+Record each decision. Update the doc queue:
+- `preserve` decisions: remove the doc from the queue entirely
+- `supplement` decisions: set mode to `supplement` in the doc_assignment block; include `existing_content` (full file content)
+- `regenerate` decisions: set mode to `create` (treat as a fresh write)
+
+**Fallback when AskUserQuestion is unavailable:** Default all hand-written docs to `preserve` (safest default). Display message:
+
+```
+AskUserQuestion unavailable — hand-written docs preserved by default.
+Use --force to regenerate all docs, or re-run in Claude Code to get per-file prompts.
+```
+
+After all decisions recorded, continue to detect_runtime_capabilities.
+</step>
+
+<!-- If Task tool is unavailable at runtime, skip dispatch/collect waves and use sequential_generation instead. -->
+
+<step name="dispatch_wave_1" condition="Task tool is available">
+**Read the work manifest first:** `Read .planning/tmp/docs-work-manifest.json` — use `canonical_queue` items with `wave: 1` for this step.
+
+Spawn 3 parallel gsd-doc-writer agents for Wave 1 docs: README, ARCHITECTURE, CONFIGURATION.
+
+These are foundational docs with no cross-references needed, making them ideal for parallel generation.
+
+Use `run_in_background=true` for all three to enable parallel execution.
+
+**Agent 1: README**
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate README.md for target project",
+  prompt="<doc_assignment>
+type: readme
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**Agent 2: ARCHITECTURE**
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate ARCHITECTURE.md for target project",
+  prompt="<doc_assignment>
+type: architecture
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**Agent 3: CONFIGURATION**
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate CONFIGURATION.md for target project",
+  prompt="<doc_assignment>
+type: configuration
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+note: Apply VERIFY markers to any infrastructure claim not discoverable from the repository.
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**CRITICAL:** Agent prompts must contain ONLY the `<doc_assignment>` block, the `${AGENT_SKILLS}` variable, and the return instruction. Do not include project planning context, workflow prose, or any internal tooling references in agent prompts.
+
+Continue to collect_wave_1.
+</step>
+
+<step name="collect_wave_1">
+**Read the work manifest first:** `Read .planning/tmp/docs-work-manifest.json` — update `status` to `"completed"` or `"failed"` for each Wave 1 item after collection. Write the updated manifest back to disk.
+
+Wait for all 3 Wave 1 agents to complete using the TaskOutput tool.
+
+Call TaskOutput for all 3 agents in parallel (single message with 3 TaskOutput calls):
+
+```
+TaskOutput tool:
+  task_id: "{task_id from README agent result}"
+  block: true
+  timeout: 300000
+
+TaskOutput tool:
+  task_id: "{task_id from ARCHITECTURE agent result}"
+  block: true
+  timeout: 300000
+
+TaskOutput tool:
+  task_id: "{task_id from CONFIGURATION agent result}"
+  block: true
+  timeout: 300000
+```
+
+**Expected confirmation format from each agent:**
+```
+## Doc Generation Complete
+**Type:** {type}
+**Mode:** {mode}
+**File written:** `{path}` ({N} lines)
+Ready for orchestrator summary.
+```
+
+**After collection, verify the Wave 1 files exist on disk** using the `resolved_path` from each manifest entry:
+```bash
+ls -la {resolved_path_1} {resolved_path_2} {resolved_path_3} 2>/dev/null
+```
+
+If any agent failed or its file is missing:
+- Note the failure
+- Continue with the successful docs (do NOT halt Wave 2 for a single failure)
+- The missing doc will be noted in the final report
+
+Continue to dispatch_wave_2.
+</step>
+
+<step name="dispatch_wave_2" condition="Task tool is available">
+**Read the work manifest first:** `Read .planning/tmp/docs-work-manifest.json` — use `canonical_queue` items with `wave: 2` for this step.
+
+Spawn agents for all queued Wave 2 docs: GETTING-STARTED, DEVELOPMENT, TESTING, and any conditional docs (API, DEPLOYMENT, CONTRIBUTING) that were queued in build_doc_queue.
+
+Wave 2 agents can reference Wave 1 outputs for cross-referencing — include the `wave_1_outputs` field in each doc_assignment block.
+
+Use `run_in_background=true` for all Wave 2 agents to enable parallel execution within the wave.
+
+**Agent: GETTING-STARTED**
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate GETTING-STARTED.md for target project",
+  prompt="<doc_assignment>
+type: getting_started
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+wave_1_outputs:
+  - README.md
+  - docs/ARCHITECTURE.md
+  - docs/CONFIGURATION.md
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**Agent: DEVELOPMENT**
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate DEVELOPMENT.md for target project",
+  prompt="<doc_assignment>
+type: development
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+wave_1_outputs:
+  - README.md
+  - docs/ARCHITECTURE.md
+  - docs/CONFIGURATION.md
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**Agent: TESTING**
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate TESTING.md for target project",
+  prompt="<doc_assignment>
+type: testing
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+wave_1_outputs:
+  - README.md
+  - docs/ARCHITECTURE.md
+  - docs/CONFIGURATION.md
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**Conditional Agent: API** (only if `has_api_routes` was true — spawn only if API.md was queued)
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate API.md for target project",
+  prompt="<doc_assignment>
+type: api
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+wave_1_outputs:
+  - README.md
+  - docs/ARCHITECTURE.md
+  - docs/CONFIGURATION.md
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**Conditional Agent: DEPLOYMENT** (only if `has_deploy_config` was true — spawn only if DEPLOYMENT.md was queued)
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate DEPLOYMENT.md for target project",
+  prompt="<doc_assignment>
+type: deployment
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+note: Apply VERIFY markers to any infrastructure claim not discoverable from the repository.
+wave_1_outputs:
+  - README.md
+  - docs/ARCHITECTURE.md
+  - docs/CONFIGURATION.md
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**Conditional Agent: CONTRIBUTING** (only if `is_open_source` was true — spawn only if CONTRIBUTING.md was queued)
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate CONTRIBUTING.md for target project",
+  prompt="<doc_assignment>
+type: contributing
+mode: {create|update|supplement}
+preservation_mode: {preserve|supplement|regenerate|null}
+project_context: {INIT JSON}
+{existing_content: | (include full file content here if mode is update or supplement, else omit this line)}
+wave_1_outputs:
+  - README.md
+  - docs/ARCHITECTURE.md
+  - docs/CONFIGURATION.md
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write the doc file directly. Return confirmation only — do not return doc content."
+)
+```
+
+**CRITICAL:** Agent prompts must contain ONLY the `<doc_assignment>` block, the `${AGENT_SKILLS}` variable, and the return instruction. Do not include project planning context, workflow prose, or any internal tooling references in agent prompts.
+
+Continue to collect_wave_2.
+</step>
+
+<step name="collect_wave_2">
+**Read the work manifest first:** `Read .planning/tmp/docs-work-manifest.json` — update `status` to `"completed"` or `"failed"` for each Wave 2 item after collection. Write the updated manifest back to disk.
+
+Wait for all Wave 2 agents to complete using the TaskOutput tool.
+
+Call TaskOutput for all Wave 2 agents in parallel (single message with N TaskOutput calls — one per spawned Wave 2 agent):
+
+```
+TaskOutput tool:
+  task_id: "{task_id from GETTING-STARTED agent result}"
+  block: true
+  timeout: 300000
+
+TaskOutput tool:
+  task_id: "{task_id from DEVELOPMENT agent result}"
+  block: true
+  timeout: 300000
+
+TaskOutput tool:
+  task_id: "{task_id from TESTING agent result}"
+  block: true
+  timeout: 300000
+
+# Add one TaskOutput call per conditional agent spawned (API, DEPLOYMENT, CONTRIBUTING)
+```
+
+**After collection, verify all Wave 2 files exist on disk** using the `resolved_path` from each manifest entry:
+```bash
+ls -la {resolved_path for each wave 2 item} 2>/dev/null
+```
+
+If any agent failed or its file is missing, note the failure and continue. Missing docs will be reported in the final report.
+
+Continue to dispatch_monorepo_packages (if monorepo_workspaces is non-empty) or commit_docs.
+</step>
+
+<step name="dispatch_monorepo_packages" condition="monorepo_workspaces is non-empty">
+After Wave 2 collection, generate per-package READMEs for each monorepo workspace.
+
+**Condition:** Only run this step if `monorepo_workspaces` from the init JSON is non-empty.
+
+**Resolve workspace packages from glob patterns:**
+
+```bash
+# Expand workspace globs to actual package directories
+for pattern in {monorepo_workspaces}; do
+  ls -d $pattern 2>/dev/null
+done
+```
+
+**For each resolved directory that contains a `package.json`:**
+
+Determine mode:
+- If `{package_dir}/README.md` exists: mode = `update`, read existing content
+- Else: mode = `create`
+
+Spawn a `gsd-doc-writer` agent with `run_in_background=true`:
+
+```
+Task(
+  subagent_type="gsd-doc-writer",
+  model="{doc_writer_model}",
+  run_in_background=true,
+  description="Generate per-package README for {package_dir}",
+  prompt="<doc_assignment>
+type: readme
+mode: {create|update}
+scope: per_package
+package_dir: {absolute path to package directory}
+project_context: {INIT JSON with project_root set to package directory}
+{existing_content: | (include full README.md content here if mode is update, else omit)}
+</doc_assignment>
+
+{AGENT_SKILLS}
+
+Write {package_dir}/README.md directly. Return confirmation only — do not return doc content."
+)
+```
+
+Collect confirmations via TaskOutput for all package agents. Note failures in the final report.
+
+**Fallback when Task tool is unavailable:** Generate per-package READMEs sequentially inline after the `sequential_generation` step. For each package directory with a `package.json`, construct the equivalent `doc_assignment` block and generate the README following gsd-doc-writer instructions.
+
+Continue to commit_docs.
+</step>
+
+<step name="sequential_generation" condition="Task tool is NOT available (e.g. Antigravity, Gemini CLI, Codex, Copilot)">
+**Read the work manifest first:** `Read .planning/tmp/docs-work-manifest.json` — use `canonical_queue` items for generation order. Update `status` after each doc is generated. Write the updated manifest back to disk after all docs are complete.
+
+When the `Task` tool is unavailable, generate docs sequentially in the current context. This step replaces dispatch_wave_1, collect_wave_1, dispatch_wave_2, and collect_wave_2.
+
+**IMPORTANT:** Do NOT use `browser_subagent`, `Explore`, or any browser-based tool. Use only file system tools (Read, Bash, Write, Grep, Glob, or equivalent tools available in your runtime).
+
+Read `agents/gsd-doc-writer.md` instructions once before beginning. Follow the create_mode or update_mode instructions from that agent for each doc, using the same doc_assignment fields as the parallel path.
+
+**Wave 1 (sequential — complete all three before starting Wave 2):**
+
+For each Wave 1 doc, construct the equivalent doc_assignment block and generate the file inline:
+
+1. **README** — mode from resolve_modes; for update/supplement mode, include existing_content
+   - Construct doc_assignment: `type: readme`, `mode: {create|update|supplement}`, `preservation_mode: {value|null}`, `project_context: {INIT JSON}`, `existing_content:` (if update/supplement)
+   - Explore the codebase (Read, Grep, Glob, Bash) following gsd-doc-writer create_mode / update_mode instructions
+   - Write the file to the resolved path (README.md)
+
+2. **ARCHITECTURE** — mode from resolve_modes; for update/supplement mode, include existing_content
+   - Construct doc_assignment: `type: architecture`, `mode: {create|update|supplement}`, `preservation_mode: {value|null}`, `project_context: {INIT JSON}`, `existing_content:` (if update/supplement)
+   - Explore the codebase following gsd-doc-writer instructions
+   - Write the file to the resolved path (docs/ARCHITECTURE.md, or ARCHITECTURE.md if found at root as fallback)
+
+3. **CONFIGURATION** — mode from resolve_modes; for update/supplement mode, include existing_content
+   - Construct doc_assignment: `type: configuration`, `mode: {create|update|supplement}`, `preservation_mode: {value|null}`, `project_context: {INIT JSON}`, `existing_content:` (if update/supplement)
+   - Apply VERIFY markers to any infrastructure claim not discoverable from the repository
+   - Explore the codebase following gsd-doc-writer instructions
+   - Write the file to the resolved path (docs/CONFIGURATION.md, or CONFIGURATION.md if found at root as fallback)
+
+**Wave 2 (sequential — begin only after all Wave 1 docs are written):**
+
+Wave 2 docs can reference Wave 1 outputs since they are already written. Include `wave_1_outputs` in each doc_assignment.
+
+4. **GETTING-STARTED** — mode from resolve_modes; include wave_1_outputs: [README.md, docs/ARCHITECTURE.md, docs/CONFIGURATION.md]
+5. **DEVELOPMENT** — mode from resolve_modes; include wave_1_outputs
+6. **TESTING** — mode from resolve_modes; include wave_1_outputs
+7. **API** (only if queued) — mode from resolve_modes; include wave_1_outputs
+8. **DEPLOYMENT** (only if queued) — Apply VERIFY markers to any infrastructure claim not discoverable from the repository; include wave_1_outputs
+9. **CONTRIBUTING** (only if queued) — mode from resolve_modes; include wave_1_outputs
+
+**Monorepo per-package READMEs (only if `monorepo_workspaces` is non-empty):**
+
+After all 9 root-level docs are written, generate per-package READMEs sequentially:
+
+For each resolved package directory (from workspace glob expansion) that contains a `package.json`:
+- Determine mode: if `{package_dir}/README.md` exists, mode = `update`; else mode = `create`
+- Construct doc_assignment: `type: readme`, `mode: {create|update}`, `scope: per_package`, `package_dir: {absolute path}`, `project_context: {INIT JSON with project_root set to package directory}`, `existing_content:` (if update)
+- Follow gsd-doc-writer instructions for per_package scope
+- Write the file to `{package_dir}/README.md`
+
+Continue to verify_docs.
+</step>
+
+<step name="verify_docs">
+Verify factual claims in ALL docs — both canonical (generated) and non-canonical (existing hand-written) — against the live codebase.
+
+**CRITICAL: Read the work manifest first.**
+
+```
+Read .planning/tmp/docs-work-manifest.json
+```
+
+Extract `canonical_queue` (items with `status: "completed"`) and `review_queue` (items with `status: "pending_review"`). Both queues are verified in this step.
+
+**Skip condition:** If `--verify-only` is present in `$ARGUMENTS`, this step was already handled by `verify_only_report` (early exit). Skip.
+
+**Phase 1: Verify canonical docs (generated/updated docs)**
+
+For each doc in `canonical_queue` that was successfully written to disk:
+
+1. Spawn the `gsd-doc-verifier` agent (or invoke sequentially if Task tool is unavailable) with a `<verify_assignment>` block:
+   ```xml
+   <verify_assignment>
+   doc_path: {relative path to the doc file, e.g. README.md}
+   project_root: {project_root from init JSON}
+   </verify_assignment>
+   ```
+
+2. After the verifier completes, read the result JSON from `.planning/tmp/verify-{doc_filename}.json`.
+
+3. Update the manifest: set `status: "verified"` for each canonical doc processed.
+
+**Phase 2: Verify non-canonical docs (existing hand-written docs)**
+
+This is NOT optional. Every doc in `review_queue` MUST be verified.
+
+For each doc in `review_queue` from the manifest:
+
+1. Spawn the `gsd-doc-verifier` agent with the same `<verify_assignment>` block as above.
+2. Read the result JSON from `.planning/tmp/verify-{doc_filename}.json`.
+3. Update the manifest: set `status: "verified"` for each review_queue doc processed.
+
+Non-canonical docs with failures ARE eligible for the fix_loop. When a non-canonical doc has `claims_failed > 0`, dispatch it to gsd-doc-writer in `fix` mode with the failures array — the writer's fix mode does surgical corrections on specific lines regardless of doc type (no template needed). The writer MUST NOT restructure, rephrase, or reformat any content beyond the failing claims.
+
+**Phase 3: Present combined verification summary**
+
+Collect ALL results (canonical + non-canonical) into a single `verification_results` array:
+
+```
+Verification results:
+
+Canonical docs (generated):
+
+| Doc                    | Claims | Passed | Failed |
+|------------------------|--------|--------|--------|
+| README.md              | 12     | 10     | 2      |
+| docs/architecture/overview.md | 8 | 8   | 0      |
+
+Existing docs (reviewed):
+
+| Doc                    | Claims | Passed | Failed |
+|------------------------|--------|--------|--------|
+| docs/frontend/components/button.md | 5 | 4 | 1   |
+| docs/services/api.md   | 8      | 8      | 0      |
+
+Total: {total_checked} claims checked, {total_failed} failures
+```
+
+Write the updated manifest back to disk.
+
+If all docs have `claims_failed === 0`: skip fix_loop, continue to scan_for_secrets.
+If any doc (canonical OR non-canonical) has `claims_failed > 0`: continue to fix_loop.
+</step>
+
+<step name="fix_loop">
+**Read the work manifest first:** `Read .planning/tmp/docs-work-manifest.json` — identify ALL docs (canonical AND non-canonical) with `claims_failed > 0` from the verification results in `.planning/tmp/verify-*.json`. Both queues are eligible for fixes.
+
+Correct flagged inaccuracies by re-sending failing docs to the doc-writer in fix mode. Per D-06, max 2 iterations. Per D-05, halt immediately on regression.
+
+**Skip condition:** If all docs passed verification (no failures), skip this step.
+
+**Iteration tracking:**
+- `MAX_FIX_ITERATIONS = 2`
+- `iteration = 0`
+- `previous_passed_docs` = set of doc_paths where claims_failed === 0 after initial verification
+
+**For each iteration (while iteration < MAX_FIX_ITERATIONS and there are docs with failures):**
+
+1. For each doc with `claims_failed > 0` in the latest verification_results:
+   a. Read the current file content from disk.
+   b. Spawn `gsd-doc-writer` agent (or invoke sequentially) with a fix assignment:
+      ```xml
+      <doc_assignment>
+      type: {original doc type from the queue, e.g. readme}
+      mode: fix
+      doc_path: {relative path}
+      project_context: {INIT JSON}
+      existing_content: {current file content read from disk}
+      failures:
+        - line: {line}
+          claim: "{claim}"
+          expected: "{expected}"
+          actual: "{actual}"
+      </doc_assignment>
+      ```
+   c. One agent spawn per doc with failures. Do not batch multiple docs into one spawn.
+
+2. After all fix agents complete, re-verify ALL docs (not just the ones that were fixed):
+   - Re-run the same verification process as verify_docs step.
+   - Read updated result JSONs from `.planning/tmp/verify-{doc_filename}.json`.
+
+3. **Regression detection (D-05):**
+   For each doc in the new verification_results:
+   - If this doc was in `previous_passed_docs` (passed in the prior round) AND now has `claims_failed > 0`, this is a REGRESSION.
+   - If regression detected: HALT the loop immediately. Present:
+     ```
+     REGRESSION DETECTED -- halting fix loop.
+
+     {doc_path} previously passed verification but now has {claims_failed} failures after fix iteration {iteration + 1}.
+
+     This means the fix introduced new errors. Remaining failures require manual review.
+     ```
+     Continue to scan_for_secrets (do not attempt further fixes).
+
+4. Update `previous_passed_docs` with docs that now pass.
+5. Increment `iteration`.
+
+**After loop exhaustion (iteration === MAX_FIX_ITERATIONS and failures remain):**
+
+Present remaining failures:
+```
+Fix loop completed ({MAX_FIX_ITERATIONS} iterations). Remaining failures:
+
+| Doc               | Failed Claims |
+|-------------------|---------------|
+| {doc_path}        | {count}       |
+
+These failures require manual correction. Review the verification output in .planning/tmp/verify-*.json for details.
+```
+
+Continue to scan_for_secrets.
+</step>
+
+<step name="verify_only_report">
+**Reached when `--verify-only` is present in `$ARGUMENTS`.** This is an early-exit step — do not proceed to dispatch, generation, commit, or report steps after this step.
+
+Invoke the gsd-doc-verifier agent in read-only mode for each file in `existing_docs` from the init JSON:
+
+1. For each doc in `existing_docs`:
+   a. Spawn `gsd-doc-verifier` (or invoke sequentially if Task tool is unavailable) with:
+      ```xml
+      <verify_assignment>
+      doc_path: {doc.path}
+      project_root: {project_root from init JSON}
+      </verify_assignment>
+      ```
+   b. Read the result JSON from `.planning/tmp/verify-{doc_filename}.json`.
+
+2. Also count VERIFY markers in each doc: grep for `<!-- VERIFY:` in the file content.
+
+Present a combined summary table:
+
+```
+--verify-only audit:
+
+| File                     | Claims Checked | Passed | Failed | VERIFY Markers |
+|--------------------------|----------------|--------|--------|----------------|
+| README.md                | 12             | 10     | 2      | 0              |
+| docs/ARCHITECTURE.md     | 8              | 8      | 0      | 0              |
+| docs/CONFIGURATION.md    | 5              | 3      | 2      | 5              |
+| ...                 | ...            | ...    | ...    | ...            |
+
+Total: {total_checked} claims checked, {total_failed} failures, {total_markers} VERIFY markers requiring manual review
+```
+
+If any failures exist, show details:
+```
+Failed claims:
+  README.md:34 - "src/cli/index.ts" (expected: file exists, actual: file not found)
+  docs/CONFIGURATION.md:12 - "npm run deploy" (expected: script in package.json, actual: script not found)
+```
+
+Display note:
+```
+To fix failures automatically: /gsd:docs-update (runs generation + fix loop)
+To regenerate all docs from scratch: /gsd:docs-update --force
+```
+
+Clean up temp files: remove `.planning/tmp/verify-*.json` files.
+
+End workflow — do not proceed to any dispatch, commit, or report steps.
+</step>
+
+<step name="scan_for_secrets">
+CRITICAL SECURITY CHECK: Scan all generated/updated doc files for accidentally leaked secrets before committing. Per D-07, this runs once after the fix loop completes, before commit_docs.
+
+Build the file list from the generation queue -- include all docs that were written to disk (created, updated, supplemented, or fixed). Do not hardcode a static list; use the actual list of files that were generated or modified.
+
+Run secret pattern detection:
+
+```bash
+# Check for common API key patterns in generated docs
+grep -E '(sk-[a-zA-Z0-9]{20,}|sk_live_[a-zA-Z0-9]+|sk_test_[a-zA-Z0-9]+|ghp_[a-zA-Z0-9]{36}|gho_[a-zA-Z0-9]{36}|glpat-[a-zA-Z0-9_-]+|AKIA[A-Z0-9]{16}|xox[baprs]-[a-zA-Z0-9-]+|-----BEGIN.*PRIVATE KEY|eyJ[a-zA-Z0-9_-]+\.eyJ[a-zA-Z0-9_-]+\.)' \
+  {space-separated list of generated doc files} 2>/dev/null \
+  && SECRETS_FOUND=true || SECRETS_FOUND=false
+```
+
+**If SECRETS_FOUND=true:**
+
+```
+SECURITY ALERT: Potential secrets detected in generated documentation!
+
+Found patterns that look like API keys or tokens in:
+{show grep output}
+
+This would expose credentials if committed.
+
+Action required:
+1. Review the flagged lines above
+2. Remove any real secrets from the doc files
+3. Re-run /gsd:docs-update to regenerate clean docs
+```
+
+Then confirm with AskUserQuestion:
+
+```
+AskUserQuestion([{
+  question: "Potential secrets detected in generated docs. How would you like to proceed?",
+  header: "Security",
+  multiSelect: false,
+  options: [
+    { label: "Safe to proceed", description: "I've reviewed the flagged lines — no real secrets, commit the docs" },
+    { label: "Abort commit", description: "Skip committing — I'll clean up the docs first" }
+  ]
+}])
+```
+
+If the user selects "Abort commit": skip commit_docs and continue to report. If "Safe to proceed": continue to commit_docs.
+
+**If SECRETS_FOUND=false:**
+
+Continue to commit_docs.
+</step>
+
+<step name="commit_docs">
+Only run this step if `commit_docs` is `true` from the init JSON. If `commit_docs` is false, skip to report.
+
+Assemble the list of files that were actually generated (do not include files that failed or were skipped):
+
+```bash
+node "$HOME/.claude/get-shit-done/bin/gsd-tools.cjs" commit "docs: generate project documentation" \
+  --files README.md docs/ARCHITECTURE.md docs/CONFIGURATION.md docs/GETTING-STARTED.md docs/DEVELOPMENT.md docs/TESTING.md
+# Append any conditional docs that were generated:
+# --files ... docs/API.md docs/DEPLOYMENT.md CONTRIBUTING.md
+# Append per-package READMEs if monorepo dispatch ran:
+# --files ... packages/core/README.md packages/cli/README.md
+```
+
+Only include files that were successfully written to disk. Do not include failed or skipped docs.
+
+Continue to report.
+</step>
+
+<step name="report">
+**Read the work manifest first:** `Read .planning/tmp/docs-work-manifest.json` — use the manifest to compile the complete report covering all canonical docs, review_queue results, and gap_queue results. The manifest is the source of truth for what was processed.
+
+Present a completion summary to the user.
+
+**Summary format:**
+
+```
+Documentation generation complete.
+
+Project type: {primary_type}
+
+Generated docs:
+| File                     | Mode   | Lines |
+|--------------------------|--------|-------|
+| README.md                | create | 87    |
+| docs/ARCHITECTURE.md     | update | 124   |
+| docs/GETTING-STARTED.md  | create | 63    |
+| docs/DEVELOPMENT.md      | create | 71    |
+| docs/TESTING.md          | create | 58    |
+| docs/CONFIGURATION.md    | create | 45    |
+[conditional docs if generated]
+
+{If monorepo per-package READMEs were generated:}
+Per-package READMEs:
+| Package             | Mode   | Lines |
+|---------------------|--------|-------|
+| packages/core       | create | 42    |
+| packages/cli        | create | 38    |
+
+{If any docs failed or were skipped:}
+Skipped / failed:
+  - docs/API.md: agent did not complete
+
+{If preservation_check ran:}
+Preservation decisions:
+  - {filename}: {preserve|supplement|regenerate}
+
+{If docs/DEPLOYMENT.md or docs/CONFIGURATION.md were generated:}
+VERIFY markers: {N} markers placed in docs/DEPLOYMENT.md and/or docs/CONFIGURATION.md for infrastructure claims that require manual verification.
+
+{If review_queue was non-empty:}
+
+Existing doc accuracy review:
+
+| Doc | Claims Checked | Passed | Failed | Fixed |
+|-----|----------------|--------|--------|-------|
+| docs/api/endpoint-map.md | 5 | 4 | 1 | 1 |
+
+{For any remaining unfixed failures after fix_loop:}
+Remaining inaccuracies could not be auto-corrected — manual review recommended for flagged items above.
+
+{If commit_docs was true:}
+All generated files committed.
+```
+
+Remind the user they can fact-check generated docs:
+
+```
+Run `/gsd:docs-update --verify-only` to fact-check generated docs against the codebase.
+```
+
+End workflow.
+</step>
+
+</process>
+
+<success_criteria>
+- [ ] docs-init JSON loaded and all fields extracted
+- [ ] Project type correctly classified from project_type signals
+- [ ] Doc queue contains all always-on docs plus only the conditional docs matching project signals
+- [ ] CHANGELOG.md was NOT generated or queued
+- [ ] Each doc was generated in correct mode (create for new, update for existing)
+- [ ] Wave 1 docs (README, ARCHITECTURE, CONFIGURATION) completed before Wave 2 started
+- [ ] Generated docs contain zero GSD methodology content
+- [ ] docs/DEPLOYMENT.md and docs/CONFIGURATION.md use VERIFY markers for undiscoverable claims (if generated)
+- [ ] All generated files committed (if commit_docs is true)
+- [ ] Hand-written docs (no GSD marker) prompted for preserve/supplement/regenerate before dispatch (unless --force)
+- [ ] --force flag skipped preservation prompts and regenerated all docs
+- [ ] --verify-only flag reported doc status without generating files
+- [ ] Per-package READMEs generated for monorepo workspaces (if applicable)
+- [ ] verify_docs step checked all generated docs against the live codebase
+- [ ] fix_loop ran at most 2 iterations and halted on regression
+- [ ] scan_for_secrets ran before commit and blocked on detected patterns
+- [ ] --verify-only invokes gsd-doc-verifier for full fact-checking (not just VERIFY marker count)
+</success_criteria>
diff --git a/tests/copilot-install.test.cjs b/tests/copilot-install.test.cjs
index 744643d01..65c92627c 100644
--- a/tests/copilot-install.test.cjs
+++ b/tests/copilot-install.test.cjs
@@ -1166,6 +1166,8 @@ describe('E2E: Copilot full install verification', () => {
       'gsd-assumptions-analyzer.agent.md',
       'gsd-codebase-mapper.agent.md',
       'gsd-debugger.agent.md',
+      'gsd-doc-verifier.agent.md',
+      'gsd-doc-writer.agent.md',
       'gsd-executor.agent.md',
       'gsd-integration-checker.agent.md',
       'gsd-nyquist-auditor.agent.md',
diff --git a/tests/docs-update.test.cjs b/tests/docs-update.test.cjs
new file mode 100644
index 000000000..5f054106f
--- /dev/null
+++ b/tests/docs-update.test.cjs
@@ -0,0 +1,272 @@
+/**
+ * GSD Tools Tests - docs-update
+ *
+ * Integration tests for the docs-init gsd-tools subcommand.
+ * Covers: JSON output shape, project type detection, existing doc scanning,
+ * GSD marker detection, and doc tooling detection.
+ *
+ * Requirements: VERF-03
+ */
+
+const { test, describe, beforeEach, afterEach } = require('node:test');
+const assert = require('node:assert/strict');
+const fs = require('fs');
+const path = require('path');
+const { runGsdTools, createTempProject, cleanup } = require('./helpers.cjs');
+
+// ─── JSON output shape ────────────────────────────────────────────────────────
+
+describe('docs-init command', () => {
+  let tmpDir;
+
+  beforeEach(() => {
+    tmpDir = createTempProject();
+  });
+
+  afterEach(() => {
+    cleanup(tmpDir);
+  });
+
+  test('returns expected JSON shape', () => {
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+
+    // Top-level scalar fields
+    assert.strictEqual(typeof data.doc_writer_model, 'string');
+    assert.strictEqual(typeof data.commit_docs, 'boolean');
+    assert.strictEqual(typeof data.planning_exists, 'boolean');
+    assert.strictEqual(typeof data.project_root, 'string');
+    assert.strictEqual(typeof data.agents_installed, 'boolean');
+
+    // Array fields
+    assert.ok(Array.isArray(data.existing_docs), 'existing_docs should be an array');
+    assert.ok(Array.isArray(data.monorepo_workspaces), 'monorepo_workspaces should be an array');
+    assert.ok(Array.isArray(data.missing_agents), 'missing_agents should be an array');
+
+    // project_type object with 7 boolean fields
+    assert.ok(data.project_type && typeof data.project_type === 'object', 'project_type should be an object');
+    assert.strictEqual(typeof data.project_type.has_package_json, 'boolean');
+    assert.strictEqual(typeof data.project_type.has_api_routes, 'boolean');
+    assert.strictEqual(typeof data.project_type.has_cli_bin, 'boolean');
+    assert.strictEqual(typeof data.project_type.is_open_source, 'boolean');
+    assert.strictEqual(typeof data.project_type.has_deploy_config, 'boolean');
+    assert.strictEqual(typeof data.project_type.is_monorepo, 'boolean');
+    assert.strictEqual(typeof data.project_type.has_tests, 'boolean');
+
+    // doc_tooling object with 4 boolean fields
+    assert.ok(data.doc_tooling && typeof data.doc_tooling === 'object', 'doc_tooling should be an object');
+    assert.strictEqual(typeof data.doc_tooling.docusaurus, 'boolean');
+    assert.strictEqual(typeof data.doc_tooling.vitepress, 'boolean');
+    assert.strictEqual(typeof data.doc_tooling.mkdocs, 'boolean');
+    assert.strictEqual(typeof data.doc_tooling.storybook, 'boolean');
+
+    // planning_exists is true since createTempProject creates .planning/
+    assert.strictEqual(data.planning_exists, true);
+  });
+
+  test('bare project returns all false signals', () => {
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+
+    // All project_type fields should be false for a bare project
+    assert.strictEqual(data.project_type.has_package_json, false);
+    assert.strictEqual(data.project_type.has_api_routes, false);
+    assert.strictEqual(data.project_type.has_cli_bin, false);
+    assert.strictEqual(data.project_type.is_open_source, false);
+    assert.strictEqual(data.project_type.has_deploy_config, false);
+    assert.strictEqual(data.project_type.is_monorepo, false);
+    assert.strictEqual(data.project_type.has_tests, false);
+
+    // No docs, no workspaces, no doc tooling
+    assert.deepEqual(data.existing_docs, []);
+    assert.deepEqual(data.monorepo_workspaces, []);
+    assert.strictEqual(data.doc_tooling.docusaurus, false);
+    assert.strictEqual(data.doc_tooling.vitepress, false);
+    assert.strictEqual(data.doc_tooling.mkdocs, false);
+    assert.strictEqual(data.doc_tooling.storybook, false);
+  });
+});
+
+// ─── project type detection ───────────────────────────────────────────────────
+
+describe('project type detection', () => {
+  let tmpDir;
+
+  beforeEach(() => {
+    tmpDir = createTempProject();
+  });
+
+  afterEach(() => {
+    cleanup(tmpDir);
+  });
+
+  test('detects CLI tool from package.json bin field', () => {
+    fs.writeFileSync(
+      path.join(tmpDir, 'package.json'),
+      JSON.stringify({ name: 'my-cli', bin: { mycli: 'bin/cli.js' } }),
+      'utf-8'
+    );
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.project_type.has_cli_bin, true);
+    assert.strictEqual(data.project_type.has_package_json, true);
+  });
+
+  test('detects open source from LICENSE file', () => {
+    fs.writeFileSync(path.join(tmpDir, 'LICENSE'), 'MIT License', 'utf-8');
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.project_type.is_open_source, true);
+  });
+
+  test('detects monorepo from package.json workspaces', () => {
+    fs.writeFileSync(
+      path.join(tmpDir, 'package.json'),
+      JSON.stringify({ name: 'mono', workspaces: ['packages/*'] }),
+      'utf-8'
+    );
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.project_type.is_monorepo, true);
+    assert.ok(data.monorepo_workspaces.includes('packages/*'), 'monorepo_workspaces should contain packages/*');
+  });
+
+  test('detects tests from tests directory', () => {
+    fs.mkdirSync(path.join(tmpDir, 'tests'), { recursive: true });
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.project_type.has_tests, true);
+  });
+
+  test('detects deploy config from Dockerfile', () => {
+    fs.writeFileSync(path.join(tmpDir, 'Dockerfile'), 'FROM node:20', 'utf-8');
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.project_type.has_deploy_config, true);
+  });
+
+  test('detects API routes from src/app/api directory', () => {
+    fs.mkdirSync(path.join(tmpDir, 'src', 'app', 'api'), { recursive: true });
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.project_type.has_api_routes, true);
+  });
+});
+
+// ─── existing doc scanning ────────────────────────────────────────────────────
+
+describe('existing doc scanning', () => {
+  let tmpDir;
+
+  beforeEach(() => {
+    tmpDir = createTempProject();
+  });
+
+  afterEach(() => {
+    cleanup(tmpDir);
+  });
+
+  test('scans .md files in project root', () => {
+    fs.writeFileSync(path.join(tmpDir, 'README.md'), '# README\n', 'utf-8');
+    fs.writeFileSync(path.join(tmpDir, 'ARCHITECTURE.md'), '# Architecture\n', 'utf-8');
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.ok(data.existing_docs.length >= 2, 'existing_docs should contain at least 2 entries');
+
+    const paths = data.existing_docs.map(d => d.path);
+    assert.ok(paths.includes('README.md'), 'existing_docs should contain README.md');
+    assert.ok(paths.includes('ARCHITECTURE.md'), 'existing_docs should contain ARCHITECTURE.md');
+  });
+
+  test('detects GSD marker in existing docs', () => {
+    fs.writeFileSync(
+      path.join(tmpDir, 'README.md'),
+      '<!-- generated-by: gsd-doc-writer -->\n# README\n',
+      'utf-8'
+    );
+    fs.writeFileSync(path.join(tmpDir, 'NOTES.md'), '# Notes\n', 'utf-8');
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+
+    const readmeEntry = data.existing_docs.find(d => d.path === 'README.md');
+    assert.ok(readmeEntry, 'README.md should appear in existing_docs');
+    assert.strictEqual(readmeEntry.has_gsd_marker, true, 'README.md should have GSD marker');
+
+    const notesEntry = data.existing_docs.find(d => d.path === 'NOTES.md');
+    assert.ok(notesEntry, 'NOTES.md should appear in existing_docs');
+    assert.strictEqual(notesEntry.has_gsd_marker, false, 'NOTES.md should not have GSD marker');
+  });
+});
+
+// ─── doc tooling detection ────────────────────────────────────────────────────
+
+describe('doc tooling detection', () => {
+  let tmpDir;
+
+  beforeEach(() => {
+    tmpDir = createTempProject();
+  });
+
+  afterEach(() => {
+    cleanup(tmpDir);
+  });
+
+  test('detects Docusaurus config', () => {
+    fs.writeFileSync(path.join(tmpDir, 'docusaurus.config.js'), 'module.exports = {};', 'utf-8');
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.doc_tooling.docusaurus, true);
+  });
+
+  test('detects VitePress config', () => {
+    fs.mkdirSync(path.join(tmpDir, '.vitepress'), { recursive: true });
+    fs.writeFileSync(path.join(tmpDir, '.vitepress', 'config.ts'), 'export default {};', 'utf-8');
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.doc_tooling.vitepress, true);
+  });
+
+  test('detects MkDocs config', () => {
+    fs.writeFileSync(path.join(tmpDir, 'mkdocs.yml'), 'site_name: test', 'utf-8');
+
+    const result = runGsdTools(['docs-init'], tmpDir);
+    assert.ok(result.success, `Command failed: ${result.error}`);
+
+    const data = JSON.parse(result.output);
+    assert.strictEqual(data.doc_tooling.mkdocs, true);
+  });
+});