核心用法
本技能提供一套完整的 How-To 指南写作框架，专为目标明确的任务型文档设计。使用者需遵循固定的模板结构：以 "How to [目标]" 命名标题，依次编写前置条件、分步骤操作、验证方法、故障排查和后续指引。技能强调与 docs-style 核心写作规范的配合使用，并通过 Diataxis 指南针工具确保文档类型选择正确（区分于教程、参考文档和概念解释）。
核心写作流程包括：锁定具体目标 → 罗列完整前置条件 → 拆分原子步骤 → 设定可观察的成功标准 → 补充常见故障方案。每个步骤须以动词开头，仅包含单一动作，并在关键节点展示预期结果。
显著优点
1. 框架成熟度高：直接采用业界验证的 Diataxis 文档分类法，避免文档类型混淆导致的用户迷失。
2. 实用导向明确：严格区分 "告知如何做" 与 "解释为何如此"，确保用户能快速达成目标而非陷入概念学习。
3. 模板即拿即用：提供完整的 Markdown 模板和组件代码（Steps、Accordion、CodeGroup 等），显著降低写作启动成本。
4. 质量门禁清晰：设定 "Hard gates" 五道硬性检查（目标锁定、前置条件闭合、步骤原子化、成功可观测、清单完成），从源头保障文档质量。
5. 用户视角转换：强制要求从产品中心语言转向用户中心表达，提升文档可读性和亲和力。
潜在缺点与局限性
1. 适用范围受限：仅适用于任务型 How-To 场景，无法覆盖教程、参考文档或概念解释等其他文档类型，需配合其他技能使用。
2. 依赖外部技能：核心写作原则依赖 docs-style 技能，类型判断依赖 Diataxis 指南针，单独使用功能不完整。
3. 组件系统绑定：模板中大量使用了特定组件语法（如 <Steps>、<AccordionGroup>），可能与目标平台的文档系统不兼容，存在迁移成本。
4. 灵活性不足：严格的 "How to" 标题格式和步骤原子化要求，对于复杂流程或探索性任务可能显得过于僵化。
适合的目标群体
- 技术文档工程师：需要系统性地为产品构建操作指南体系的专职写作者
- 开发者体验（DX）团队：负责优化开发者上手路径、降低支持工单量的工程师
- 开源项目维护者：希望为社区贡献标准化、高质量文档的项目 owner
- SaaS 产品经理：需要编写清晰配置指南、降低客户成功团队负担的产品人员
常规使用风险
1. 版本依赖风险：组件语法和模板结构可能随 docs-style 或平台更新而变化，长期维护需关注上游变更。
2. 过度简化风险：严格遵循 "单步单动作" 原则可能导致复杂流程被过度拆分，反而增加用户阅读负担。
3. 前置条件遗漏："Hard gates" 虽要求闭合前置条件，但实际执行中仍可能因环境差异遗漏特定依赖，导致用户中断。
4. 类型误判风险：若未正确使用 Diataxis 指南针，可能将本应作为教程或参考文档的内容误写为 How-To，造成用户期望错位。