把「了解新技术 → 不断追问 → 整理成文档」这条链的尾部收敛成一篇合规、准确、易懂的技术文档。学习与追问全程是普通对话，本 skill 只在你明确要「整理/沉淀/改这篇」时介入。
触发边界：只有用户明确表达「整理成文档 / 沉淀一下 / 把这篇改成符合规范」时才用。普通的技术提问、追问、讨论 —— 继续正常对话，不要触发。
两条入口
| 入口 | 素材来源 | 典型说法 |
| ------------ | ------------------ | ------------------------------- |
| 对话沉淀 | 当前对话的问答内容 | 「把刚才聊的整理成一篇指南」 |
| 改造存量文档 | docs/ 下已有文档 | 「把这篇改成符合规范 / 审校下」 |
两条入口共用同一套流程、同一套规范、同一套发布条件。
规范来源（不复述）
所有命名、结构、格式、示例规范以 tech-docs-guide skill 为唯一事实源。本 skill 不复述任何格式规则，一律「遵循 tech-docs-guide」。改动格式只改 tech-docs-guide 一处。
执行流程
- [ ] Step 1 起草：把素材整理成初稿，结构/命名/风格遵循
tech-docs-guide。文件名<主题>-guide.md（小写、连字符；不是NNN-xxx.md）。 - [ ] Step 2 准确性核实（硬步骤）：对涉及 API、配置、命令、版本特性的内容，用 web fetch 核对官方文档。无法核实的，显式标注「未验证」。本仓库主题（Docker/ESLint/Zod/MCP 等）演进快，此步不可省。
- [ ] Step 3 派 reviewer subagent 审校：派一个独立 subagent（新鲜上下文，未参与起草），对照
tech-docs-guide规范 + 技术准确性，产出问题清单：- 阻塞问题（不解决不能发布）/ 非阻塞问题（建议优化）/ 风险点（下一轮重点深挖）
- 每条带：具体问题、位置、改进建议
- 综合判断：直接通过 / 修改后复审 / 需用户确认
- [ ] Step 4 主 agent 直接改：按问题清单修改（无独立 modifier，主 agent 上下文最全）。优先阻塞问题，再非阻塞。改动严格围绕问题单，不擅自扩大主题。涉及事实/来源的，补证据或显式标注无法验证。
- [ ] Step 5 问题驱动循环：是否再来一轮不看固定轮数，看阻塞问题是否清零、是否达到发布条件。复审要检查上一轮问题是否处理妥当、是否引入新问题，并对高风险区深挖。连续多轮无实质进展 → 中止并输出问题清单。
- [ ] Step 6 发布校验：逐条核对发布条件（见下）。
index.md与格式化由 PostToolUse hook 自动产出，本步只校验结果，不重复执行命令。
用户介入条件
默认自动推进。出现以下情况，中止自动流程、回退用户确认：
- 需求不清、来源冲突、关键事实无法验证
- reviewer 标记「需用户确认」
- 连续多轮无实质进展
发布条件
满足以下全部才能发布；任一不满足 → 拒绝发布，返回问题清单：
- ✓ reviewer 无遗留阻塞问题
- ✓ 技术事实已 web fetch 官方文档核实，或显式标注未验证部分
- ✓ 文件名符合
<主题>-guide.md - ✓ 结构/风格符合
tech-docs-guide - ✓
index.md已含新条目且check:home通过（由 hook 产出） - ✓ Prettier 干净（由 hook 产出）
- ✓ 面向通用技术读者，概念解释充分、流程清晰
与其他自动化的分工
- 本 skill：内容质量（蒸馏、准确性、审校循环）
- PostToolUse hook：机械产物（重建
index.md、Prettier 格式化） - pre-push
check:home：最后兜底，拦截未更新的index.md - CodeRabbit：commit 后审 diff/结构
四者职责正交，不重叠。