菜单
确保技术文档符合 Why-What-How 三段式结构，但用自然的标题呈现（问题-目标-方案）。检查文档逻辑是否完整，不符合则修改。当生成或审查 README、设计文档、技术方案、功能说明时使用。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | why-what-how |
| description | 确保技术文档符合 Why-What-How 三段式结构，但用自然的标题呈现（问题-目标-方案）。检查文档逻辑是否完整，不符合则修改。当生成或审查 README、设计文档、技术方案、功能说明时使用。 |
技术文档应该让读者快速明白：有什么问题、要达成什么、怎么做到。
但别把 "Why"、"What"、"How" 直接写成标题——这太模板化了。
内在逻辑用自然的标题呈现：
| 逻辑 | 自然标题选择 |
|---|---|
| Why | 问题、背景、现状、痛点、动机 |
| What | 目标、方案概述、核心思路、做什么 |
| How | 解决方案、实现、技术方案、使用方法、操作步骤 |
选择哪个标题，看上下文和文档类型。
审查文档时，检查这三层逻辑是否存在（不管标题叫什么）：
文档前 1-2 段应该回答：
缺失信号：开头直接讲功能或方案，没说为什么要做。
应该包含：
缺失信号：只讲怎么做，没说要做成什么样。
应该包含：
缺失信号：只有概念没有落地，或步骤不完整。
在文档开头补充问题描述。不要写"背景"然后列一堆条目，直接说：
## 问题
目前 [现状]，导致 [痛点]。
或融入开头段落：
# Config Sync
配置散落在多处，部署时手动同步容易漏。这个工具自动检测和同步配置变更。
在问题之后、方案之前补充目标：
## 目标
- [要达成的效果 1]
- [要达成的效果 2]
或写成段落：
做一个配置同步工具，能自动发现配置变更并同步到所有环境。
根据文档类型补充：
同一个项目，两种写法：
反例
# Data Sync
## What
一个数据同步工具。
## How
npm install data-sync
问题：不知道解决什么；标题像套模板。
正例
# Data Sync
多数据源场景下，手动同步容易遗漏，出问题难排查。
## 目标
- 自动同步数据库间的数据变更
- 增量传输，只同步差异
- 冲突时能检测并提示
## 快速开始
npm install -g data-sync
区别：
| 文档类型 | Why 可用标题 | What 可用标题 | How 可用标题 |
|---|---|---|---|
| README | 开头段落（不加标题） | 功能、特性 | 快速开始、安装、使用 |
| 设计文档 | 问题、背景 | 目标、方案概述 | 技术方案、详细设计 |
| RFC/提案 | 动机、问题 | 提案内容、目标 | 实现方案 |
| 功能说明 | 为什么做这个 | 功能说明 | 如何使用、操作指引 |