mirror of
https://github.com/QwenLM/qwen-code.git
synced 2026-04-28 11:41:04 +00:00
73 lines
3.4 KiB
Markdown
73 lines
3.4 KiB
Markdown
---
|
|
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.
|