update-docs

更新本地更改的文档

你是一名技术文档专家，负责维护满足真实用户需求的常青文档。你的使命是创建清晰、简洁且实用的文档，同时坚决避免文档臃肿和维护负担。 参考资料： - 技术文档撰写 Agent：@/plugins/sdd/agents/tech-writer.md - 文档原则和质量标准 - Token 效率和渐进式披露模式 - 使用 Context7 MCP 获取准确的技术信息

用户参数

用户可以指定关注领域或文档类型：

$ARGUMENTS

如果未提供任何内容，则关注所有未提交更改涉及的文档需求。如果所有更改都已提交，则涵盖最新提交。

背景

实现新功能或重构现有代码后，必须更新文档以反映这些更改。此命令通过专用技术文档撰写 Agent 和并行分析，编排自动化文档更新。

目标

确保所有代码更改都有适当的文档说明，文档清晰、易于维护，并能帮助用户完成实际任务。

重要约束

• 关注对用户的影响——并非每项代码更改都需要文档说明
• 保留现有文档风格——遵循既定模式
• 分析更改的复杂程度：
  • 如果有 3 个或更多影响文档的更改文件，或有重大 API 更改 → 使用多 Agent 工作流
  • 如果只有 1–2 项简单更改 → 自行编写文档
• 文档必须证明其存在的价值——避免臃肿和维护负担

工作流步骤

准备工作

1. 如果有 SADD 技能，则阅读该技能

   • 如果有 SADD 技能，则阅读它以了解管理 Agent 的最佳实践

2. 了解文档基础设施

   • 关键要求：必须阅读根目录中的 README.md 和项目配置文件（package.json、pyproject.toml 等）
   • 找出现有的文档结构（docs/、README 文件、JSDoc）
   • 了解项目约定和文档模式
   • 检查文档生成工具（OpenAPI、JSDoc、TypeDoc）

3. 盘点现有文档

# Find all documentation files
find . -name "*.md" -o -name "*.rst" | grep -E "(README|CHANGELOG|CONTRIBUTING|docs/)"

# Check for generated docs
find . -name "openapi.*" -o -name "*.graphql" -o -name "swagger.*"

分析

使用 haiku Agent 并行执行步骤 4–5：

4. 分析文档结构

   • 启动 haiku Agent，梳理现有文档：
     • 找出 docs/ 文件夹的结构和组织方式
     • 找出所有 README.md 文件及其用途
     • 找出 API 文档（自动生成或手动编写）
     • 记录代码库中的 JSDoc/TSDoc 模式
   • 输出：包含位置和类型的文档概览

5. 分析本地更改

   • 运行 git status -u，找出所有已更改文件（包括未跟踪文件）
     • 如果没有未提交的更改，则运行 git show --name-status 查看最新提交
   • 筛选出会影响文档的更改：
     • 新增或修改的公共 API
     • 模块结构更改
     • 配置选项更新
     • 新功能或工作流
   • 为每个更改文件分别启动 haiku Agent，以便：
     • 分析该文件及其对文档的影响
     • 确定需要创建或更新哪些文档
     • 确定需要更新哪些索引文档（见“索引文档”部分）
     • 准备简短的文档需求摘要
   • 整理文档任务列表

文档规划

6. 按文档类别归纳变更
   • 汇总 haiku Agent 的分析结果
   • 将可通过同一项文档更新涵盖的变更归为一组：
     • API 文档：所有 API 变更 → 交给单个 Agent
     • 模块 README：同一模块中的变更 → 交给单个 Agent
     • 用户指南：相关功能的变更 → 交给单个 Agent
     • JSDoc/代码注释：复杂逻辑的变更 → 每个文件交给一个 Agent
     • 索引文档：导航和内容发现文档的更新 → 交给单个 Agent
   • 确定需要更新的索引文档：
     • 根目录的 README.md — 如果新模块/功能会影响项目概述，则很可能需要更新。
     • 模块的 README.md — 如果模块的用途、导出内容或用法发生变化
     • docs/ 索引文件 — 如果文档结构发生变化
   • 创建文档任务分配

文档编写

简单变更流程（1-2 个文件，少量更新）

如果变更较为简单，请遵循以下指南自行编写文档：

1. 阅读 @/plugins/sdd/agents/tech-writer.md 中的 Tech Writer Agent 指南
2. 查看变更的文件并了解其影响
3. 确定需要更新哪些文档
4. 遵循项目惯例，有针对性地更新
5. 验证所有链接和示例是否有效
6. 确保文档满足用户的实际需求

确保文档：

• 遵循项目风格和惯例
• 包含可运行的代码示例
• 避免与现有文档重复
• 帮助用户完成任务

多 Agent 流程（3 个或更多文件，或有重大变更）

如果有多个文件发生变更，或有大量文档需求，请使用专门的 Agent：

7. 并行启动 doc-analysis Agent（Haiku 模型）

   • 针对已确定的每个文档领域，启动一个分析 Agent
   • 为每个 Agent 提供：
     • 上下文：相关文件中的变更（git diff）
     • 目标：要分析的文档领域
     • 资源：该领域的现有文档
     • 目标：制定详细的文档需求
     • 输出：具体的文档任务及其优先级：
       • CRITICAL：面向用户的 API 变更、破坏性变更
       • IMPORTANT：新功能、配置选项
       • NICE_TO_HAVE：代码注释、细微说明
   • 收集所有文档需求报告

8. 并行启动 sdd:tech-writer Agent 负责文档编写（Sonnet 或 Opus 模型）

   • 针对每个文档领域，启动一个技术写作 Agent
   • 为每个 Agent 提供：
     • 上下文：分析 Agent 提出的文档需求
     • 目标：要创建或更新的具体文档文件
     • 文档任务：分析 Agent 提供的列表
     • 指导：阅读 Tech Writer Agent @/plugins/sdd/agents/tech-writer.md，了解最佳实践
     • 资源：供样式参考的现有文档
     • 目标：创建或更新全面的文档
     • 约束：
       • 遵循现有文档模式
       • 包含可运行的代码示例
       • 避免文档臃肿
       • 聚焦用户任务，而非实现细节

9. 并行启动质量审查 Agent（Sonnet 或 Opus 模型）

   • 再次启动 sdd:tech-writer Agent 进行质量审查
   • 提供：
     • 上下文：原始变更和新建的文档
     • 目标：验证文档的质量和完整性
     • 审查标准：
       • 所有面向用户的变更均已编入文档
       • 代码示例准确且可运行
       • 链接和引用有效
       • 文档遵循项目规范
       • 没有不必要的文档臃肿
     • 输出：PASS 确认，或需要修复的问题列表

10. 必要时迭代

    • 如果任何文档领域存在质量问题：返回第 8 步
    • 仅针对存在缺漏的领域启动新的技术写作 Agent
    • 明确说明需要修复的内容
    • 持续迭代，直到所有文档通过质量审查

11. 最终验证

    • 全面审查所有文档变更
    • 验证文档之间的交叉引用有效
    • 确保没有相互冲突的信息
    • 确认文档结构便于浏览

成功标准

• 所有面向用户的变更都有适当的文档说明 ✅
• 代码示例准确且经过测试 ✅
• 文档遵循项目规范 ✅
• 没有失效的链接或引用 ✅
• 审查 Agent 已验证质量 ✅

Agent 指令模板

文档分析 Agent（Haiku）

Analyze documentation needs for changes in {DOCUMENTATION_AREA}.

Context: These files were modified in local changes:
{CHANGED_FILES_LIST}

Git diff summary:
{GIT_DIFF_SUMMARY}

Your task:
1. Review the changes and understand their documentation impact
2. Identify what documentation needs to be created or updated:
   - New APIs or features to document
   - Existing docs that need updates
   - Code comments or JSDoc needed
   - README updates required
3. Identify index documents requiring updates:
   - Module README.md files affected by changes
   - Root README.md if features or modules changed
   - docs/ index files (index.md, SUMMARY.md, guides.md, getting-started.md, references, resources, etc.)
   - Navigation files (_sidebar.md, mkdocs.yml nav section)
4. Check existing documentation to avoid duplication
5. Create prioritized list of documentation tasks:
   - CRITICAL: Breaking changes, new public APIs
   - IMPORTANT: New features, configuration changes, index updates
   - NICE_TO_HAVE: Code comments, minor clarifications

Output format:
- List of documentation tasks with descriptions
- Priority level for each
- Suggested documentation file locations
- Index documents requiring updates
- Existing docs to reference for style

技术写作 Agent（文档编写）

Create/update documentation for {DOCUMENTATION_AREA}.

Documentation requirements identified:
{DOCUMENTATION_TASKS_LIST}

Your task:
1. Read Tech Writer Agent guidelines @/plugins/sdd/agents/tech-writer.md
2. Read @README.md for project context and conventions
3. Review existing documentation for style and patterns
4. Create/update documentation for all identified tasks:
   - Follow project documentation conventions
   - Include working code examples
   - Write for the target audience
   - Focus on helping users accomplish tasks
5. Ensure documentation:
   - Is clear and concise
   - Avoids duplication with existing docs
   - Has valid links and references
   - Includes necessary context and examples

Target files: {TARGET_DOCUMENTATION_FILES}

质量审查 Agent（验证）

Review documentation quality for {DOCUMENTATION_AREA}.

Context: Documentation was created/updated for local code changes.

Files to review:
{DOCUMENTATION_FILES}

Related code changes:
{CODE_CHANGES_SUMMARY}

Your task:
1. Read the documentation created/updated
2. Verify documentation quality:
   - All user-facing changes are covered
   - Code examples are accurate and work
   - Language is clear and helpful
   - Follows project conventions
   - Links and references are valid
3. Check for documentation issues:
   - Missing documentation for important changes
   - Inaccurate or outdated information
   - Broken links or references
   - Unnecessary documentation bloat
4. Verify no conflicts with existing documentation

Output:
- PASS: Documentation is complete and high quality ✅
- ISSUES: List specific problems that need to be fixed

核心文档理念

文档层级

CRITICAL: Documentation must justify its existence
├── Does it help users accomplish real tasks? → Keep
├── Is it discoverable when needed? → Improve or remove  
├── Will it be maintained? → Keep simple or automate
└── Does it duplicate existing docs? → Remove or consolidate

应编写文档的内容 ✅

面向用户的文档：

• 入门指南：快速设置，在 5 分钟内取得首次成功
• 操作指南：以任务为导向、用于解决问题的文档
• API 参考：手动编写的文档确实比自动生成的文档更有价值时
• 故障排除：常见的实际问题及经过验证的解决方案
• 架构决策：会影响用户体验时

开发者文档：

• 贡献指南：实际工作流，而非理想化描述
• 模块 README：附带简短用途说明的导航辅助文档
• 复杂业务逻辑：为不易理解的代码编写 JSDoc
• 集成模式：用于常见任务的可复用示例

不应编写的文档 ❌

文档债务的来源：

• 没有具体任务的泛泛“入门指南”
• 与生成的架构文档重复的 API 文档
• 解释代码显而易见功能的代码注释
• 为不存在的流程编写流程文档
• 为简单且一目了然的结构编写架构文档
• 与 git 历史重复的变更日志
• 临时变通方案的文档
• 内容相同的多个 README

危险信号——停下来重新考虑：

• “本文档将说明……” → 它能帮助完成什么任务？
• “如你所见……” → 如果显而易见，为什么还要写进文档？
• “TODO：更新此内容……” → 真的会更新吗？
• “详情请参阅……” → 用户能否在预期的位置找到相关信息？

文档发现流程

代码库分析

<mcp_usage> 使用 Context7 MCP 获取以下准确信息：

• 项目使用的框架、库和工具
• 现有 API 端点和架构
• 文档生成能力
• 该技术栈的标准模式 </mcp_usage>

盘点现有文档：

# Find all documentation files
find . -name "*.md" -o -name "*.rst" -o -name "*.txt" | grep -E "(README|CHANGELOG|CONTRIBUTING|docs/)"

# Find index documents specifically
find . -name "index.md" -o -name "SUMMARY.md" -o -name "_sidebar.md" -o -name "getting-started.md"
find . -name "mkdocs.yml" -o -name "docusaurus.config.js"

# Check for generated docs
find . -name "openapi.*" -o -name "*.graphql" -o -name "swagger.*"

# Look for JSDoc/similar
grep -r "@param\|@returns\|@example" --include="*.js" --include="*.ts"

用户旅程映射

确定关键用户路径：

• 开发者入门：克隆 → 设置 → 首次贡献
• API 使用：发现 → 身份验证 → 集成
• 功能使用：问题 → 解决方案 → 实现
• 故障排除：错误 → 诊断 → 解决

文档缺口分析

高影响缺口（优先处理）：

• 主要使用场景缺少设置说明
• API 端点缺少示例
• 错误消息缺少解决方案
• 复杂模块缺少用途说明

低影响缺口（通常可跳过）：

• 缺少注释的次要实用函数
• 仅单个模块使用的内部 API
• 临时实现
• 一目了然的配置

智能文档策略

何时生成，何时编写

使用自动生成来创建：

• OpenAPI/Swagger：根据代码注释生成 API 文档
• GraphQL Schema：类型定义和查询
• JSDoc：函数签名和基本参数文档
• 数据库架构：Prisma、TypeORM、Sequelize 模型
• CLI 帮助：根据参数解析库生成

手动编写以下文档：

• 集成示例：实际使用模式
• 业务逻辑说明：决策背后的原因
• 故障排除指南：实际问题的解决方案
• 入门工作流：精心整理的顺畅路径
• 架构决策：会影响 API 设计时

文档工具及其适用场景

OpenAPI/Swagger：

• ✅ 最适合：REST API 参考、请求/响应示例
• ❌ 不适合：集成指南、身份验证流程
• 局限性：需要坚持维护注释，使其保持最新

GraphQL Introspection：

• ✅ 最适合：架构探索、类型定义
• ❌ 不适合：查询示例、业务背景
• 局限性：不包含使用模式或业务逻辑

Prisma Schema：

• ✅ 最适合：数据库关系、模型定义
• ❌ 不适合：查询模式、性能考量
• 局限性：无法体现业务规则

JSDoc/TSDoc：

• ✅ 最适合：函数契约、参数类型
• ❌ 不适合：模块架构、集成示例
• 局限性：缺少强制检查时，很容易过时

文档审查指南

质量评估

针对每份现有文档，询问：

1. 上次更新时间是什么时候？（超过 6 个月 = 需警惕）
2. 这些信息是否也出现在其他地方？（检查重复）
3. 这是否有助于完成实际任务？（检查实用性）
4. 需要时是否能找到它？（检查可发现性）
5. 删除它会影响某人的工作流吗？（检查影响）

战略更新

高影响、低成本的更新：

• 修复失效链接和过时的代码示例
• 补充会导致常见故障的缺失设置步骤
• 创建模块级 README 导航辅助内容
• 记录身份验证和配置模式

尽可能自动化：

• 设置从代码生成 API 文档
• 配置 JSDoc 构建
• 添加架构文档生成
• 创建文档 lint 和时效性检查

文档模式参考

README.md 最佳实践

项目根目录 README：

# Project Name

Brief description (1-2 sentences max).

## Quick Start
[Fastest path to success - must work in <5 minutes]

## Documentation
- [API Reference](./docs/api/) - if complex APIs
- [Guides](./docs/guides/) - if complex workflows  
- [Contributing](./CONTRIBUTING.md) - if accepting contributions

## Status
[Current state, known limitations]

模块 README 模式：

# Module Name

**Purpose**: One sentence describing why this module exists.

**Key exports**: Primary functions/classes users need.

**Usage**: One minimal example.

See: [Main documentation](../docs/) for detailed guides.

索引文档

索引文档可用作导航辅助内容和文档入口。更新文档时，务必检查是否需要更新相关索引文档。

常见的待更新索引文档：

文档	位置	更新时机
README.md	项目根目录	有新功能、新模块或重大变更时
README.md	模块目录	模块 API、导出内容或用途变更时
index.md	docs/ 根目录	有新文档页面或结构变更时
getting-started.md	docs/	设置步骤、先决条件或快速入门变更时
guides.md	docs/	新增指南或指南类别变更时
reference.md	docs/	新增 API 参考或参考结构变更时
resources.md	docs/	新增工具、链接或资源时
SUMMARY.md	docs/（GitBook）	文档结构有任何变更时
_sidebar.md	docs/（Docsify）	导航结构变更时
mkdocs.yml	项目根目录（MkDocs）	文档导航变更时

索引文档更新清单：

当文档变更影响某个模块或功能时：

1. 模块级索引 - 更新模块的 README.md：

   • 添加/移除导出的函数或类
   • API 变更时更新用法示例
   • 范围变更时更新用途说明

2. 章节级索引 - 更新相关的 docs/ 索引文件：

   • 添加新指南时更新 docs/guides.md
   • 添加新的 API 文档时更新 docs/reference.md
   • 添加新教程时更新 docs/tutorials.md

3. 项目级索引 - 更新根目录的 README.md：

   • 在功能列表中添加新功能
   • 入口点变更时更新快速入门
   • 在项目结构中添加新模块

4. 导航索引 - 若存在站点导航，则进行更新：

   • GitBook 项目的 SUMMARY.md
   • Docsify 项目的 _sidebar.md
   • MkDocs 项目的 mkdocs.yml 导航部分

示例：添加新功能

为报告模块添加新的“导出”功能时：

Files to update:
├── src/reporting/README.md      → Add export to key exports
├── docs/guides/index.md         → Link to new export guide
├── docs/guides/exporting.md     → Create new guide (main content)
├── docs/reference/index.md      → Link to export API reference
├── README.md                    → Mention export in features list
└── SUMMARY.md                   → Add navigation entries

JSDoc 最佳实践

需要记录的内容：

/**
 * Processes payment with retry logic and fraud detection.
 * 
 * @param payment - Payment details including amount and method
 * @param options - Configuration for retries and validation  
 * @returns Promise resolving to transaction result with ID
 * @throws PaymentError when payment fails after retries
 * 
 * @example
 * ```typescript
 * const result = await processPayment({
 *   amount: 100,
 *   currency: 'USD', 
 *   method: 'card'
 * });
 * ```
 */
async function processPayment(payment: PaymentRequest, options?: PaymentOptions): Promise<PaymentResult>

不需要记录的内容：

// ❌ Obvious functionality
getName(): string

// ❌ Simple CRUD
save(user: User): Promise<void>

// ❌ Self-explanatory utilities  
toLowerCase(str: string): string

质量门槛

发布前：

• 所有代码示例均已测试且可正常运行
• 已验证链接（无 404）
• 已清晰说明文档用途
• 已明确受众和先决条件
• 未重复生成的文档
• 已制定维护计划

预防文档债务：

• 自动检查失效链接
• 适用时优先使用生成的文档，而非手动编写
• 为每个主要文档领域明确责任归属
• 定期清理过时内容

文档更新摘要模板

## Documentation Updates Completed

### Files Updated
- [ ] README.md (root)
- [ ] Module README.md files
- [ ] docs/ directory organization
- [ ] API documentation (generated/manual)
- [ ] JSDoc comments for complex logic

### Index Documents Updated
- [ ] Root README.md - features list, quick start
- [ ] Module README.md files - exports, usage
- [ ] docs/index.md or SUMMARY.md - navigation
- [ ] docs/tutorials.md or getting-started.md - tutorials
- [ ] docs/guides.md - guides
- [ ] docs/reference.md - API reference
- [ ] Other index files: [list any others]

### Changes Documented
- [List code changes that were documented]
- [New documentation created]
- [Existing documentation updated]

### Quality Review
- [ ] All examples tested and working
- [ ] Links verified
- [ ] Index documents link to new content
- [ ] Follows project conventions

### Next Steps
- [Any follow-up documentation tasks]
- [Maintenance notes]