mcpField
T
technical-writing

technical-writing

github.com/blockmatic-icebox文档处理1106 次安装4 周前更新
代码仓库

关于 technical-writing

technical-writing 是面向开发者和编码 Agent 编写准确、以任务为中心文档的技能。它强调核对仓库资料、选择合适的文档层级,并进行最小且可验证的修改。

主要功能

  1. 01检查仓库规范与资料来源
  2. 02将修改定位到合适的文档层
  3. 03组织以任务为中心的文档
  4. 04依据实现核实内容
  5. 05检查准确性与可检索性

适用场景

  1. 01更新开发者文档
  2. 02记录代码支持的行为
  3. 03改善文档导航与清晰度

安装

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

$npx skills add https://github.com/blockmatic-icebox/basilic-skills --skill technical-writing

安装后在 Claude Code 中输入/technical-writing确认已加载。

详细介绍

技术写作

为开发者和编码 Agent 编写准确、以任务为中心的文档。每个章节都应易于浏览、检索和执行,不依赖未说明的上下文。

仓库须知

动笔前先阅读仓库的 AGENTS.md:了解文档层级、公开的一句话简介、能力名称、禁止使用的文案,以及 DESIGN.md 的位置。.cursor/rules/ 中的全局规则优先于本指南。关于应更新哪个层级(MDX、README 还是规则),请使用 /w-docs,不要在此重复其路由表。

文风

  • 以 you 称呼读者;步骤使用祈使动词。使用主动语态和现在时,采用具体名词。
  • 使用美式英语和牛津逗号。提及运行时名称 eve 时使用小写。
  • 每个页面和章节开篇直接给出答案或结果。每页只围绕一个主要任务。
  • 保留作者所表达的含义、细微差别和不确定性。只做必要且有效的修改;保留有力的原文。
  • 只有在描述仓库中记录的团队有意采取的行动时,才使用 we。

禁止使用填充词和夸大宣传:easy、simple、quick、just、obviously、utilize、facilitate、leverage、robust、seamless、宣传性形容词、反问句和诱导互动的文案。

禁止使用 AI 套话:总结式过渡语(With this setup complete…)、断断续续的残句、数据表式动词(provides、is configurable)、缺乏前文铺垫的开篇、模板化结尾和格言式收尾,以及为显得自然而刻意编造的具体细节。

节奏。差例:“The API is flexible. It supports many use cases. That is the value. You will like it.” 好例:“Register the route in apps/api, expose it in OpenAPI, then run the client generator so the web app picks up typed calls.”

信息来源

不要依赖训练数据判断行为。按以下顺序核实:

  1. 仓库中的所属源码、公开类型和测试
  2. 最近的 README 中提到的 CLI 帮助信息和包脚本
  3. AGENTS.md 指定文档层级中的现有 MDX 或 Markdown
  4. ADR 和架构页面——在合并后的行为与之相符前,视为意图提案
  5. 问题和用户报告——用于了解读者的问题,而非确认产品事实

若某项声明无法核实,请省略该声明,或指出缺少哪位负责人提供依据。完成的文案中不得留下 [VERIFY]。不要把提议中的行为写成已发布功能。

方法

  1. 明确文档的唯一用途和读者要完成的任务。
  2. 找到已有的主题归属页面;优先扩展该页面,而不是新建页面。
  3. 拟定大纲:结果 → 前提条件 → 顺利完成的路径 → 替代方案 → 失败情形 → 相关链接。
  4. 起草时同步依据源码核实声明。
  5. 通过自我编辑提升检索效果:在关键信息中重复完整名词;将关键事实放在当前页面,而不只放在链接后。
  6. 分轮审阅:目的和结构、准确性、完整性、文风和检索效果、差异控制(不顺手重写无关内容)。

模式

Docu MDX(仓库包含 apps/docu/content/docs/ 时):添加 title 和 description 前置内容;导航有变更时更新文件夹中的 meta.json;从相关中心页面添加指向正文的链接(不得留下孤立页面);路由变更时,在文档应用配置中添加永久重定向;仅在附近页面已使用 MDX 组件时才使用这些组件。准备发布文档变更时,最后运行 pnpm --filter @repo/docu checktypes。

README(**/README.md):遵循 .cursor/rules/base/readme.mdc——根目录 README 负责介绍产品;应用和包的 README 保持精简,并链接到技术文档。

根目录产品 Markdown(例如 PRODUCT.md、ARCHITECTURE.md,以及 AGENTS.md 指定的 DESIGN.md):使用相同文风;能力名称应与该仓库的架构信息来源一致;只有在 AGENTS.md 指明上游托管文档优先于本地项目文档时,才以其为准。

约束

  • 绝不臆造标志、端点、默认值、示例、指标或用户反应。
  • 绝不在未判断属于文档还是产品范围的情况下,将一条支持讨论扩展成新页面。
  • 绝不在通过补充章节或交叉链接就能解决问题时,重复编写宽泛指南。
  • 绝不为了叙述方便而违背所消费仓库公开的一句话简介、禁用文案或能力名称。
  • 支持证据用于识别困惑;实现和测试用于确立行为。

此技能不涉及

  • /w-docs — 修补哪个层面
  • /w-api-docs — OpenAPI 和生成的客户端
  • /w-deslop — 分支上的代码冗余
  • /w-architecture — ADR 和边界规划
  • 个人或营销风格目录(例如 gabo)

评论

支持 Markdown