feat(skills): add docs audit and update helpers

.qwen/skills/docs-update-from-diff/SKILL.md

@@ -0,0 +1,73 @@
+---
+name: docs-update-from-diff
+description: Review local code changes with git diff and update the official docs under docs/ to match. Use when the user asks to document current uncommitted work, sync docs with local changes, update docs after a feature or refactor, or when phrases like "git diff", "local changes", "update docs", or "official docs" appear.
+---
+
+# 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
+
+## 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.
+
+## 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.

.qwen/skills/docs-update-from-diff/references/docs-surface.md

@@ -0,0 +1,39 @@
+# Docs Surface Map
+
+Use this file to choose the correct destination page under `docs/`.
+
+## Primary sections
+
+- `docs/users/overview.md`, `quickstart.md`, `common-workflow.md`
+  Good for entry points, first-run guidance, and broad user workflows.
+- `docs/users/features/*.md`
+  Good for user-visible features such as skills, MCP, sandbox, sub-agents, commands, checkpointing, and approval modes.
+- `docs/users/configuration/*.md`
+  Good for settings, auth, model providers, themes, trusted folders, `.qwen` files, and similar configuration topics.
+- `docs/users/integration-*.md` and `docs/users/ide-integration/*.md`
+  Good for IDEs, GitHub Actions, and editor companion behavior.
+- `docs/users/extension/*.md`
+  Good for extension authoring and extension usage.
+- `docs/developers/*.md`
+  Good for architecture, contributing workflow, roadmaps, and SDK overviews.
+- `docs/developers/tools/*.md`
+  Good for tool behavior, tool contracts, and implementation-facing explanations.
+- `docs/developers/development/*.md`
+  Good for contributor setup, deployment, tests, telemetry, and automation details.
+
+## Navigation rules
+
+- Root navigation lives in `docs/_meta.ts`.
+- Section navigation lives in the nearest `_meta.ts`, for example:
+  - `docs/users/_meta.ts`
+  - `docs/users/features/_meta.ts`
+  - `docs/developers/_meta.ts`
+  - `docs/developers/tools/_meta.ts`
+- If you create a page and do not add it to the right `_meta.ts`, the docs will be incomplete even if the markdown exists.
+
+## Placement heuristics
+
+- Put the change where a reader would naturally look first.
+- Update multiple pages when a single feature appears in setup, reference, and workflow docs.
+- Prefer adjusting a nearby existing page instead of creating a top-level page for a small delta.
+- Avoid duplicating long explanations across pages; add one source page and update nearby pages with short pointers if needed.