docs-update-from-diff

# Docs Update From Diff

## Overview

Inspect local diffs, derive the documentation impact, and update only the
repository's `docs/` pages. Treat the current code as the source of truth and
keep changes scoped, specific, and navigable.

Read [references/docs-surface.md](references/docs-surface.md) before editing if
the affected feature does not map cleanly to an existing docs section.

## Workflow

### 1. Build the change set

Start from local Git state, not from assumptions.

- Inspect `git status --short`, `git diff --stat`, and targeted `git diff`
  output.
- Focus on non-doc changes first so the documentation delta is grounded in
  code.
- Ignore `README.md` and other non-`docs/` content unless they help confirm
  intent.

### 2. Derive the docs impact

For every changed behavior, extract the user-facing or developer-facing facts
that documentation must reflect.

- New command, flag, config key, default, workflow, or limitation
- Renamed behavior or removed behavior
- Changed examples, paths, or setup steps
- New feature that belongs in an existing page but is not mentioned yet

Prefer updating an existing page over creating a new page. Create a new page
only when the feature introduces a stable topic that would make an existing page
harder to follow.

### 3. Find the right docs location

Map each change to the smallest correct documentation surface:

- End-user behavior: `docs/users/**`
- Developer internals, SDKs, contributor workflow, tooling:
  `docs/developers/**`
- Shared landing or navigation changes: root `docs/**` and `_meta.ts`

If you add a new page, update the nearest `_meta.ts` in the same docs section so
the page is discoverable.

### 4. Write the update

Edit documentation with the following bar:

- State the current behavior, not the implementation history
- Use concrete commands, file paths, setting keys, and defaults from the diff
- Remove or rewrite stale text instead of stacking caveats on top of it
- Keep examples aligned with the current CLI and repository layout
- Preserve the repository's existing docs tone and heading structure

### 5. Cross-check before finishing

Verify that the updated docs cover the actual delta:

- Search `docs/` for old names, removed flags, or outdated examples
- Confirm links and relative paths still make sense
- Confirm any new page is included in the relevant `_meta.ts`
- Re-read the changed docs against the code diff, not against memory
- If the diff added, moved, renamed, or removed a page under `docs/users/`,
  verify the `qc-helper` bundled skill's topic-to-path index tables
  (`packages/core/src/skills/bundled/qc-helper/SKILL.md`) are updated to
  match. This skill ships with the CLI and uses hardcoded doc-path tables at
  runtime — stale entries cause `/qc-helper` to miss the right documentation.
  Also check project-level skills under `.qwen/skills/` for hardcoded
  `docs/users/` references that may need updating.

## Practical heuristics

- If a change affects commands, also check quickstart, workflows, and feature
  pages for drift.
- If a change affects configuration, also check
  `docs/users/configuration/settings.md`, feature pages, and auth/provider docs.
- If a change affects tools or agent behavior, check both
  `docs/users/features/**` and `docs/developers/tools/**` when relevant.
- If tests reveal expected behavior more clearly than implementation code, use
  tests to confirm wording.
- If the change adds, moves, renames, or removes a docs page, also update
  hardcoded doc-path consumers: `qc-helper`'s SKILL.md index tables,
  `_meta.ts` navigation files, and any project-level skills under
  `.qwen/skills/` that reference `docs/users/` paths.

## Deliverable

Produce the docs edits under `docs/` that make the current local changes
understandable to a reader who has not seen the diff. Keep the final summary
short and identify which pages were updated.