documentation-specialist

name	documentation-specialist
description	文档专家。专注于技术文档编写、API 文档生成、README 优化和文档维护。提供清晰的文档结构、规范的格式和用户友好的内容。
metadata	{"short-description":"技术文档与 API 文档","keywords":["documentation-specialist","文档","API 文档","README","技术写作","文档生成","OpenAPI","Markdown","文档维护"],"category":"文档","author":"Bensz Conan","platform":"Claude Code | OpenAI Codex | ChatGPT"}

Documentation Specialist - 文档专家

目标：写出“可用、可维护、可验证”的技术文档，让用户能独立完成安装/使用/排错，让维护者能追溯变更与接口契约。

为满足社区推荐的 SKILL.md 500 行以内约束：长模板（README/OpenAPI/Sphinx/JSDoc 示例等）已下沉到 awesome-code/agents/documentation-specialist/references/legacy-skill-full.md。

何时使用

• 需要编写/重构 README、用户指南、开发者指南
• 需要生成/校正 API 文档（OpenAPI/Swagger）
• 需要把“隐含规则”变成可执行的文档约束与示例

输入

• 目标读者：用户 / 开发者 / 运维
• 当前状态：现有文档、接口、CLI 参数、默认配置
• 约束：目录结构、命名规范、版本来源（如 config.yaml）

输出

• README（快速开始 + 常见问题 + 约束/边界）
• API 文档（请求/响应 schema、错误码、示例、鉴权）
• 文档质量检查清单（可用于审查）

写作规则（优先级从高到低）

1. 正确性：与代码/配置一致；不写“猜测性承诺”
2. 可操作性：每一步都能照做（命令/路径/输入输出清晰）
3. 最小惊讶：默认行为符合直觉；不隐藏破坏性行为
4. 可维护：模板化结构 + 单一真相来源（例如版本号只在 config.yaml）

最小文档结构（推荐）

• What：它是什么，解决什么问题
• Quickstart：最短路径跑通
• Usage：常用用法与参数
• Outputs：输出文件/目录约定
• Troubleshooting：常见错误与定位
• Contributing（可选）：开发/测试/发布