用途：面向技术写作场景，帮助撰写清晰、完整、对用户友好的技术文档，遵循行业实践与结构化内容模型。核心原则是按受众写作，追求清晰、可访问、可操作，使用标准化的文档模式。
适用时机：在 docs/ 目录处理 .md 文件、创建或编辑 README、编辑文档文件或标记、讨论文档结构/信息架构/风格指南、编写带示例与参数表的 API 文档、撰写用户指南/教程/快速入门、起草发布说明或变更日志、组织规范或技术提案时自动启用。
内容类型：概念类（说明是什么与为何重要）、参考类（API 文档、语法指南、参数表）、流程类（用编号列表与动名词标题逐步完成任务）、故障排查、快速入门（5 分钟内、不超过 600 词）、教程（端到端真实示例、对话式语气）、发布说明（按功能、修复、破坏性变更分类）。
结构与风格要点：层级结构最多 4 级导航，内容顺序为概念→参考→流程→故障排查；标题用句子式大小写，流程用动名词；简介 1-2 句；使用主动语态、短句（少于 25 词）；代码用反引号，界面元素加粗，占位符用全大写描述性名称（如 YOUR_API_KEY）；流程用编号列表，非顺序信息用项目符号；链接使用描述性文本，不用“点击此处”或裸 URL；谨慎使用 Note、Tip、Important、Warning、Caution，其中 Warning 与 Caution 仅用于数据丢失或安全风险；代码示例应可运行并含预期输出。
流程写作：步骤以祈使动词开头，一步一个动作，关键步骤后给出预期结果，步骤尽量少于 10 步，可选步骤以“Optionally”明确标注，并包含“开始前/先决条件”章节。
工作流：理解受众 → 选择内容类型 → 组织结构 → 应用风格指南 → 确保内容准确 → 审阅迭代。关键规则：不虚构或假设源资料之外的信息，缺口需向用户询问，不生成占位或推测内容。
不应使用：创意写作或营销文案、代码实现、项目管理文档、内部团队聊天或非正式笔记、学术论文或研究文档。
限制：资料未提供价格、平台支持范围、安装命令或与其他工具的集成方式，暂未提供。