关于 technical-writing
technical-writing 是面向开发者和编码 Agent 编写准确、以任务为中心文档的技能。它强调核对仓库资料、选择合适的文档层级,并进行最小且可验证的修改。
主要功能
- 01检查仓库规范与资料来源
- 02将修改定位到合适的文档层
- 03组织以任务为中心的文档
- 04依据实现核实内容
- 05检查准确性与可检索性
适用场景
- 01更新开发者文档
- 02记录代码支持的行为
- 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.”
信息来源
不要依赖训练数据判断行为。按以下顺序核实:
- 仓库中的所属源码、公开类型和测试
- 最近的 README 中提到的 CLI 帮助信息和包脚本
AGENTS.md指定文档层级中的现有 MDX 或 Markdown- ADR 和架构页面——在合并后的行为与之相符前,视为意图提案
- 问题和用户报告——用于了解读者的问题,而非确认产品事实
若某项声明无法核实,请省略该声明,或指出缺少哪位负责人提供依据。完成的文案中不得留下 [VERIFY]。不要把提议中的行为写成已发布功能。
方法
- 明确文档的唯一用途和读者要完成的任务。
- 找到已有的主题归属页面;优先扩展该页面,而不是新建页面。
- 拟定大纲:结果 → 前提条件 → 顺利完成的路径 → 替代方案 → 失败情形 → 相关链接。
- 起草时同步依据源码核实声明。
- 通过自我编辑提升检索效果:在关键信息中重复完整名词;将关键事实放在当前页面,而不只放在链接后。
- 分轮审阅:目的和结构、准确性、完整性、文风和检索效果、差异控制(不顺手重写无关内容)。
模式
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)