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.