GitHub维基同步助手

解决什么问题

仓库 wiki 的腐化很少来自一次大改动，而是几十次小合并之后悄悄累积的：API 参数被重命名、目录结构被挪动，文档却还停留在上个版本的描述上。读者照着 wiki 操作，写出来的代码却和仓库里的实际实现对不上。

核心能力

这个技能把 GitHub Next 的 Agentic Wiki Writer 封装成一条文档维护流水线，核心逻辑分四步：

• 监听近期合并：轮询仓库中刚合并的代码更改，识别可能影响文档的改动。
• 读取模板：按 PAGES.md 模板约定确定 wiki 页面结构，首次运行时可自动生成模板。
• 增量更新：只重写受影响的 wiki 页面，而不是全量覆盖所有文档。
• 发起后续变更：当源码结构本身（目录布局、模块划分）不再匹配现有文档时，agent 会开启后续变更，而不是强行改文档去凑合代码。

配套工具还有：把每次运行的 agent 开销汇总后发布到 PR 上的 Cost Tracker（读取 token-usage.jsonl），以及对全部文档运行 Markdown 质量检查、按优先级输出违规报告的 Linter。

适用边界

• 需要 GitHub CLI、gh-aw 扩展和已启用的仓库 wiki，缺一不可。
• PAGES.md 是前置条件，仓库中没有模板时依赖首次运行的模板生成。
• 同步粒度取决于合并事件的可识别性，跨仓库的耦合变更可能捕捉不到。