docs-sync

1---2name: docs-sync3description: Audit or update authored English SDK documentation within a requested topic or diff using implementation evidence.4---5 6# Docs Sync7 8## Overview9 10Identify documentation gaps and inaccuracies within the requested topic or diff using implementation evidence.11 12## Scope and authorization13 14For audit or proposal-only requests, report findings without editing. When the user requests updates or has approved a plan, complete the scoped edits and verification without asking again. Ask only for unresolved behavior, scope, release timing, or additional authority. Apply the repository's Documentation Release Timing policy before including unreleased behavior in `docs/`.15 16## Workflow17 181. Confirm scope and base branch19   - Identify the current branch and default branch (usually `main`).20   - Prefer analyzing the current branch to keep work aligned with in-flight changes.21   - Use a branch diff only for a branch-scoped request. A requested topic or released-doc correction remains in scope even when unrelated to the current branch diff.22   - Avoid switching branches if it would disrupt local changes. Prefer read-only inspection such as `git show main:<path>`. If a separate checkout is genuinely required, stop and obtain the explicit approval required by `AGENTS.md` before creating or switching a worktree.23 242. Build a feature inventory from the selected scope25   - Bound the inventory to the requested topic or diff. Inventory the full surface only for an explicitly comprehensive audit.26   - For branch-scoped work, inspect additions, changes, and removals relative to the intended base.27   - Focus on user-facing behavior: public exports, configuration options, environment variables, CLI commands, default values, and documented runtime behaviors.28   - Capture evidence for each item (file path + symbol/setting).29   - Use targeted search to find option types and feature flags (for example: `rg "Options"`, `rg "process.env"`, `rg "export"`).30   - When the topic involves OpenAI platform features, invoke `$openai-knowledge` to pull current details from the OpenAI Developer Docs MCP server instead of guessing, while treating the SDK source code as the source of truth when discrepancies appear.31   - For MCP SDK (`modelcontextprotocol/typescript-sdk`) or Vercel AI SDK (`@ai-sdk/*`) topics, optionally use Deepwiki MCP for quick lookups, and still treat the SDK source code as the source of truth.32 333. Doc-first pass: review existing pages34   - Walk each relevant page under `docs/src/content/docs` (excluding `docs/src/content/docs/openai`).35   - Identify missing mentions of important, supported options (opt-in flags, env vars), customization points, or new features from `packages/`.36   - Propose additions where users would reasonably expect to find them on that page.37 384. Code-first pass: map features to docs39   - Review the current docs information architecture under `docs/src/content/docs`.40   - Determine the best page/section for each feature based on existing patterns and package boundaries.41   - Identify features that lack any doc page or have a page but no corresponding content.42   - Note when a structural adjustment would improve discoverability.43 445. Detect gaps and inaccuracies45   - **Missing**: features/configs present in main but absent in docs.46   - **Incorrect/outdated**: names, defaults, or behaviors that diverge from main.47   - **Structural issues** (optional): pages overloaded, missing overviews, or mis-grouped topics.48 496. Classify the proposed complete diff50   - Use the Documentation Change Verification Tiers in `AGENTS.md` as the single source of truth.51   - Classify the complete proposed diff by its highest applicable Editorial, Content, or Structural tier before editing.52   - Keep the tier-specific verification separate from the existing eligibility rules for `$implementation-final-review`, `$code-change-verification`, `$changeset-validation`, and `$pr-draft-summary`.53 547. Report findings or continue authorized updates55   - For audit-only work, provide evidence, suggested locations, proposed edits, and required verification, then stop.56   - For an update request, complete the authorized edits using the findings and selected verification tier.57 588. Apply authorized changes (English only)59   - Edit only English docs in `docs/src/content/docs/**`.60   - Exclude `docs/src/content/docs/openai` from review and updates.61   - Do **not** edit `docs/src/content/docs/ja`, `docs/src/content/docs/ko`, or `docs/src/content/docs/zh`.62   - Keep changes aligned with the existing docs style and navigation.63   - Do not add TypeScript or TSX fenced blocks directly to MDX. Place every TypeScript or TSX snippet in a compilable source file under `examples/docs/<doc-area>/`, import it into MDX with `?raw`, and render that imported source using the existing docs pattern.64   - If code is not useful enough to maintain as a complete example, explain the behavior in prose instead of adding an unverified snippet.65   - Run the focused verification required by the highest applicable Documentation Change Verification Tier in `AGENTS.md`. When the complete diff changes a rendered TypeScript or TSX snippet source or its MDX import/rendering, run `pnpm -F docs-code build-check` and fix issues before handoff.66 67## Output format68 69Use this template when reporting findings:70 71Docs Sync Report72 73- Doc-first findings74  - Page + missing content → evidence + suggested insertion point75- Code-first gaps76  - Feature + evidence → suggested doc page/section (or missing page)77- Incorrect or outdated docs78  - Doc file + issue + correct info + evidence79- Structural suggestions (optional)80  - Proposed change + rationale81- Proposed edits82  - Doc file → concise change summary83- Unresolved decisions, only when needed84 85## References86 87- `references/doc-coverage-checklist.md`88