核心用法
technical-writing是一款面向开发者的技术文档写作增强技能，激活后可根据用户需求生成各类专业开发文档。其核心用法覆盖四大场景：
1. README文档生成：提供Library/Package、CLI工具、API服务三类标准化模板，包含安装指南、快速开始、API参考、配置项说明等完整结构，支持自动生成徽章、环境变量表、退出码说明等细节。
2. 架构决策文档：内置ADR（Architecture Decision Record）和RFC（Request for Comments）双模板体系。ADR采用轻量级单决策格式，捕获技术选型的"为什么"；RFC支持3-10页大型设计提案，包含动机、详细设计、替代方案对比、分阶段上线计划等完整章节。
3. 运维文档体系：提供故障响应Runbook模板和事后复盘Post-mortem模板。Runbook按"症状→诊断→修复→升级"流程组织，Post-mortem包含时间线、根因分析、影响评估、行动项跟踪等关键要素。
4. 文档工程化：整合Diagram-as-Code（Mermaid/D2/PlantUML）、文档站点生成器对比（Docusaurus/Starlight/VitePress/MkDocs）、Docs-as-Code CI工作流等工程实践，支持从写作到发布的全流程自动化。
显著优点
体系化方法论支撑：引入Diataxis文档四象限理论（Tutorial/How-to/Reference/Explanation），从根本上解决"写什么、怎么写"的分类困惑，避免教程与参考文档混杂的常见错误。
生产级模板质量：所有模板均来自真实开源项目实践，包含JSDoc/TSDoc、Python Docstring、ADR工具链（adr-tools/log4brains）、Changesets版本管理等行业标准方案，而非简单的占位符填充。
零依赖安全设计：Skill本身无任何外部依赖，纯Markdown+Shell脚本实现，供应链攻击面为零。模板中的代码示例均经过安全审查标注，如Runbook中的sudo命令、README中的curl\|sh模式均有明确风险提示。
工程化集成能力：内置GitHub Actions工作流模板，支持Markdownlint格式检查、CSpell拼写检查、Lychee链接检查、文档构建等CI环节，可直接纳入现有DevOps体系。
潜在缺点与局限性
模板僵化风险：高度结构化的模板可能导致文档千篇一律，缺乏项目特色。用户若直接复制使用而不根据实际场景调整，可能产生"文档与代码脱节"的形式主义问题。
技术栈偏向性：示例以TypeScript/JavaScript、Python、Node.js生态为主，对Go、Rust、Java等语言的文档工具链覆盖相对薄弱（如仅列出rustdoc/godoc/javadoc命令，无深度使用示例）。
动态内容缺失：作为静态模板库，无法自动同步代码变更到文档（如API接口变更），需配合Typedoc/Swagger等工具实现，本身不提供实时文档同步能力。
中文本地化不足：全文为英文技术写作指南，未提供中文技术文档的本地化规范（如中英文混排格式、术语翻译标准等），国内团队需二次适配。
适合的目标群体
- 开源项目维护者：需快速建立专业级项目文档和贡献指南
- 技术团队Lead：需规范团队技术决策记录（ADR）和架构评审流程（RFC）
- DevOps/SRE工程师：需标准化故障响应文档和运维手册
- 技术写作者：需掌握开发者视角的文档工程方法论
- 初创公司技术负责人：需从零搭建文档体系而缺乏经验积累
常规使用风险
命令示例误执行风险：Runbook模板包含sudo systemctl restart、README模板包含curl -fsSL ... | sh等命令示例，虽已在安全报告中标注为低风险文档示例，但用户直接复制到生产环境仍可能导致服务中断或远程代码执行。
链接失效风险：文档中引用的外部资源（如Docusaurus官网、keepachangelog.com等）可能随时间失效，建议开启CI链接检查（已提供Lychee配置模板）。
版本过时风险：模板中推荐的工具版本（如PostgreSQL 16、React 19等）会随技术演进过时，需定期审查更新，Skill本身不提供版本自动更新机制。
敏感信息泄露风险：API文档模板中包含JWT、API Key等敏感字段的示例格式，用户若未替换占位符直接提交，可能导致凭证泄露。建议在CI中增加密钥扫描（如GitHub secret scanning）。