mcpField
D
developer-docs-planning

developer-docs-planning

github.com/lvtd-llc文档处理143 次安装7 周前更新
代码仓库

关于 developer-docs-planning

用于在动笔前规划开发者文档的技能,将用户需求对应到内容类型、范围、负责人、研究和发布背景。提供文档计划、决策、功能调研、场景文档及 Agile 协作流程。

主要功能

  1. 01按用户任务匹配文档类型
  2. 02确定范围、大纲与负责人
  3. 03识别信息源和依赖项
  4. 04规划调研与验证
  5. 05记录决策和待解决问题
  6. 06将文档纳入 Agile 工作

适用场景

  1. 01为产品功能制定文档计划
  2. 02判断哪些文档能支持用户任务
  3. 03写作前调研某项功能
  4. 04协调文档与版本发布

安装

复制下面的命令,在终端中运行。

$npx skills add https://github.com/lvtd-llc/skills --skill developer-docs-planning

安装后在 Claude Code 中输入/developer-docs-planning确认已加载。

包含的文件

除 SKILL.md 外,安装时一起下载的参考资料和脚本。

guidelines.md
references/core/
knowledge.md
workflows/
create-doc-plan.md
integrate-docs-agile.md
make-doc-decision.md
plan-scenario-docs.md
research-feature-docs.md

详细介绍

开发者文档规划

使用此技能,在起草文档之前决定要创建哪些开发者文档。它会将用户需求映射到内容类型、范围、提纲、负责人、发布背景、调研工作和决策记录。

此技能源自 Docs for Developers: An Engineer's Field Guide to Technical Writing,尤其是第 2 章“规划文档”。它还扩展了 Christopher Gales 和 Splunk Documentation Team 的 The Product Is Docs: Writing Technical Documentation in a Product Development Group 中的改写指南,尤其是第 2 章“敏捷”、第 6 章“文档决策”、第 13 章“技术写作者的调研”、第 14 章“场景驱动的信息开发”和第 22 章“与产品管理团队协作”。请勿将书中的原文复制到用户输出中。来源:https://link.springer.com/book/10.1007/978-1-4842-7217-6

快速入门

  1. 加载 guidelines.md,选择最精简且有用的参考资料集。
  2. 确认用户目标、受众、产品界面和发布背景。
  3. 根据用户任务选择内容类型,而非按内部组织结构选择。
  4. 使用 workflows/create-doc-plan.md 制定完整计划。
  5. 如果任务涉及决策、调研、场景规划或敏捷集成,请使用相应的专用工作流。
  6. 输出提纲,列明文档类型、目的、负责人、事实来源、依赖项和验证方式。

默认输出

规划文档时,请返回:

  1. 受众和目标 - 文档面向哪些人,以及必须实现什么目标。
  2. 内容类型决策 - 推荐的文档及其适用原因。
  3. 文档提纲 - 页面或章节、各自的目的和顺序。
  4. 决策或调研依据 - 已知证据、假设和未解决的问题。
  5. 事实来源映射 - 代码、API 架构、产品负责人、支持数据或设计来源。
  6. 发布和审核计划 - 负责人、审批和时间安排。
  7. 待解决问题 - 阻碍文档准确性的决策。

目录

需求从此处开始
了解文档类型references/core/knowledge.md
应用规划规则references/core/knowledge.md
查看计划示例references/core/knowledge.md
制定文档计划workflows/create-doc-plan.md
做出文档决策workflows/make-doc-decision.md
写作前调研功能workflows/research-feature-docs.md
规划场景驱动的文档workflows/plan-scenario-docs.md
将文档集成到敏捷工作中workflows/integrate-docs-agile.md
按任务选择入口guidelines.md

核心原则

  • 根据用户任务选择内容类型。
  • 每份文档都应围绕一个主要目标。
  • 将计划视为轻量级工程产物,而非形式主义。
  • 尽早揭示决策、假设和事实来源缺口。
  • 如果文档计划像迷宫一样复杂,请考虑产品或信息架构是否过于复杂。

评论

支持 Markdown