关于 write-workflow
write-workflow 是一套分阶段的文档写作技能，可将请求路由至技术评审或文本人性化写作技能。它负责来源分析、模式管理、结果验证与复盘，并要求启动前检查依赖项。
主要功能
- 01八阶段文档工作流
- 02路由至评审与人性化技能
- 03支持手动和自动模式
- 04提供完整、增量和精简路径
- 05检查依赖并验证输出
适用场景
- 01根据设计起草技术评审文档
- 02人性化改写英文或中文文本
- 03为文档变更选择写作路径
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/write-workflow确认已加载。
附带文件reference.md
详细介绍
编写工作流
八阶段文档编写宿主。写作技能负责方法论；此宿主负责路由、来源分析、模式生命周期、路径深度以及验证／复盘。
写作技能：
tech-review-doc（仓库内，设计 → 评审）。humanizer/humanizer-zh是强依赖的外部技能（本仓库未随附），用于去除英文／中文文本中的 AI 痕迹。不是
solve-workflow/analysis-core。阶段 2 仅进行面向写作的来源分析。输出模板：reference.md。
前置技能检查
启动时，验证 frontmatter 中的每一项 dependencies。若有任何依赖缺失，立即中止并提示安装——不得静默降级。
| 缺失的技能 | 安装方式（目录 / name 必须匹配） |
|---|---|
clarifying-question-discipline、tech-review-doc、workflow-mode-lifecycle | npx skills add FuDesign2008/open-skills -g --skill <name> --yes |
humanizer | npx skills add https://github.com/blader/humanizer.git → 技能目录 humanizer |
humanizer-zh | npx skills add https://github.com/op7418/Humanizer-zh.git → 技能目录 humanizer-zh |
或者，一次性安装所有仓库内的 open-skills：npx skills add FuDesign2008/open-skills -g --skill '*' --yes（不会安装外部人性化改写技能）。
不得依赖：analysis-core、runtime-evidence-debug、hybrid-debug、browser-debug-toolkit。
**不得打包：**不得将 skills/humanizer/ 或 skills/humanizer-zh/ 添加到此仓库。
触发语句与模式
| 表述 | 模式 | 说明 |
|---|---|---|
| 「写文档」「写文档工作流」「write workflow」 | 👤 手动 | 检测文档类型 |
| 「写技术评审」「生成评审文档」 | 👤 手动 | 路由至 tech-review-doc |
| 「去AI痕迹」「人性化改写」「humanize」 | 👤 手动 | 根据语言路由至 humanizer / humanizer-zh |
| 「自动写文档」「自动模式」+ 写作意图 | 🤖 自动 | 推进流程；写作技能特定的硬暂停仍然适用 |
模式检测：「自动」→ 自动模式；否则为手动模式。运行过程中可通过「切换自动模式」/「切换手动模式」切换。
核心生命周期 → workflow-mode-lifecycle。差异：
- 完成 = 阶段 8 完成 → 恢复手动模式。
- 硬暂停（即使在自动模式下也适用）：
tech-review-doc：§1 用户批准；缺少设计路径humanizer/humanizer-zh：已确认的输入文本或文件路径（无需经过 tech-review §1 环节）
- 自动模式下，硬暂停解除后：继续执行写作技能及阶段 7–8，宿主不再额外暂停。
- 中断 → 恢复手动模式。
路径选择
| 路径 | 适用情况 | 深度 |
|---|---|---|
| 完整 | 重大评审／目标模糊／深度人性化改写 | 写作技能的完整深度 |
| 增量 | 普通文档 | 默认 |
| 精简 | 小幅且高度确定的变更 | 最少可选章节；绝不跳过验证 + 写作技能硬暂停 |
⚡ 快速参考
| 阶段 | 👤 手动模式暂停点 | 🤖 自动模式 | 必需输出 |
|---|---|---|---|
| 1 明确意图 | ⛔ 确认路由／路径／模式 | 明确时跳过 | 意图复述 + 写作技能 + 路径 |
| 2 分析来源 | ⛔ 缺口／就绪度 | 无阻碍时继续 | 清单 + 缺口 |
| 3 探索方案 | ⛔ 选项 | 自动选择 | 方案 |
| 4 评审方案 | ⛔ 确认检查清单无误 | 无问题时自动通过 | 检查清单 |
| 5 制定大纲 | ⛔ 确认 | 移交 | 大纲／人性化改写计划 |
| 6 执行写作技能 | 写作技能硬暂停 | 同样暂停；随后连续执行 | 写作技能输出 |
| 7 验证 | ⛔ 确认 | 结果合格时继续 | 验证报告 |
| 8 复盘 | 结束 | 结束 + 恢复手动模式 | 简要改进建议 |
阶段 1：明确意图
- 文档类型 / 编写器路线（见下表）。
- 路径（完整 / 增量 / 精简）和模式。
- 不清楚时使用
clarifying-question-discipline（每轮只问一个问题）。 - **人工润色语言：**主要为中文 →
humanizer-zh；主要为英文 →humanizer；不明确 → 询问一次。
| 文档类型 | 编写器 | 状态 |
|---|---|---|
| 技术评审（设计 → 产品 / QA） | tech-review-doc | 仓库内 |
| AI 去痕 / 人工润色（主要为英文） | humanizer | 外部强依赖 |
| AI 去痕 / 人工润色（主要为中文） | humanizer-zh | 外部强依赖 |
| 其他 | 询问或停止 | — |
[👤] 确认。[🤖] 路线和输入已明确时跳过确认。
输出：reference.md § 阶段 1。
阶段 2：分析来源
- **存在性：**所需输入可读（设计路径，或待人工润色的文本 / 文件）。
- **清单：**对于技术评审——标题 / 模块 / Mermaid / 多选项；对于人工润色——语言、长度、目标语气。
- **缺口：**列出后续阶段的阻碍因素。
- 此时不要编写最终输出文件（聊天中的分析笔记除外）。
[👤] 报告后停止。[🤖] 除非存在阻碍性缺口，否则继续。
阶段 3–5：按编写器配置执行
配置：tech-review-doc
- 3 图表 / §3 / §6 / §4 深度
- 4 受众检查清单（§§1–3 中不含代码）
- 5 大纲 → 交接给编写器 Step 1（§1 草稿）
配置：humanizer / humanizer-zh
- 3 范围：整篇文档还是选定内容；语气（正式 / 随意 / 技术性）
- 4 检查清单：保留事实；不虚构说法；语气一致
- 5 简短计划：输入 → 改写 → 可选的修改摘要
[👤]/[🤖] 根据快速参考暂停。
阶段 6：通过编写器执行
加载指定的编写器并严格遵循其要求。
tech-review-doc：§1 为硬性关卡；获得批准后，自动模式可连续运行。humanizer/humanizer-zh：必须确认输入；然后按该技能要求改写；不要应用技术评审 §1。
阶段 7：验证
- **
tech-review-doc：**路径 / 命名、§1 已批准、图表、§3 / §6 规则、§§1–3 语言规则。 - **
humanizer*：**事实已保留、AI 特征已减少、语气一致；如果编写器定义了质量评分，则可选用。
输出：reference.md § 阶段 7。
阶段 8：回顾
简要提出改进建议。除非有人要求，否则不要编辑技能文件。自动模式恢复为手动模式。
扩展位置（未来的编写器）
- 添加
skills/<name>/并发布。 - 除非产品要求强依赖，否则优先采用可选路线（外部人工润色工具是经过慎重选择的强依赖；但此处仍不随附）。
- 添加路线行和描述触发条件（≤1024）。
- 阶段 6 仍为“加载编写器并严格遵循其要求”。
与其他技能的关系
| 技能 | 关系 |
|---|---|
tech-review-doc | 强依赖（仓库内）；评审编写器 |
humanizer | 强依赖（外部）；英文人工润色 |
humanizer-zh | 强依赖（外部）；中文人工润色 |
clarifying-question-discipline | 强依赖 |
workflow-mode-lifecycle | 强依赖 |
solve-workflow | 同级技能——未接入 |
危险信号
- 自动模式下跳过
tech-review-doc§1 - 将 §1 关卡应用于人工润色路线
- 人工润色技能缺失时静默降级
- 声称此主机上有
analysis-core - 将完整的编写器正文内嵌到此文件中