mcpField
W
write-issue

write-issue

github.com/tldraw开发51.1k406 次安装今天更新
代码仓库

关于 write-issue

write-issue 是用于编写和维护 tldraw/tldraw GitHub issue 的技能，规定标题、类型、标签、正文和分流方式，也包含 Agent 起草 issue 时的意图复述流程。

主要功能

  1. 01具体且符合句式大小写的标题
  2. 02Issue 类型与标签指引
  3. 03错误报告与功能请求模板
  4. 04Agent 起草 issue 的意图复述
  5. 05新建与过期 issue 分流

适用场景

  1. 01编写可复现的错误报告
  2. 02整理包含备选方案的功能请求
  3. 03规范 issue 标题和元数据
  4. 04审查过期 issue

安装

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

$npx skills add https://github.com/tldraw/tldraw --skill write-issue

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

详细介绍

编写和维护 GitHub issue

tldraw/tldraw 中 issue 的规范。

标题规范

  • 句子式大小写 - 仅首词和专有名词大写
  • 不要类型前缀 - 使用 GitHub issue 类型，而不是 Bug:、Feature:、[Bug] 等
  • 增强功能用祈使语气 - "Add padding option" 而不是 "Adding padding option"
  • Bug 用描述性表述 - 描述症状："Arrow bindings break with rotated shapes"
  • 具体明确 - 不打开 issue 正文也能读懂
好的标题
  • Arrow bindings break with rotated shapes
  • Add padding option to zoomToFit method
  • Pinch zoom resets selection on Safari
差的标题
  • Bug: arrow bug（有前缀，含糊）
  • [Feature] Add new feature（有前缀，含糊）
  • Not working（含糊）
标题清理转换
  1. 去掉前缀：Bug: X → X
  2. 修正大小写：Add Padding Option → Add padding option
  3. 使用祈使语气：Adding feature X → Add feature X
  4. 具体明确：Problem → [Describe the actual problem]
  5. 将非英文标题翻译为英文

Issue 类型

在创建 issue 后通过 GitHub GraphQL API 设置（--type 标志不被可靠支持）：

类型用于
Bug某些功能未按预期工作
Feature新能力或改进
Example请求新增 SDK 示例
Task内部任务或琐事

标签

谨慎使用（每个 issue 1-2 个）作为元数据，而非分类。

常用标签
标签用于
good first issue适合新手的范围明确的问题
More Info Needed需要补充信息
sdk影响 tldraw SDK
dotcom与 tldraw.com 相关
a11y无障碍
performance性能改进
apiAPI 变更
自动化标签（不要手动添加）

keep、stale、update-snapshots、publish-packages、major、minor、skip-release、deploy triggers

Issue 正文规范

Bug 报告
  1. 清晰描述哪里出了问题
  2. 复现步骤
  3. 预期行为与实际行为
  4. 相关时提供环境细节（浏览器、操作系统、版本）
  5. 适用时提供截图/录屏
功能请求
  1. 问题陈述 - 这解决了什么问题？
  2. 建议方案 - 它应该怎样工作？
  3. 考虑过的替代方案
  4. 使用场景
示例请求
  1. 要演示哪个 API/模式
  2. 为什么它有用
  3. 建议的做法
  4. 它属于哪个示例类别
Agent 起草的 issue（问题回读与待解决问题）

由 /issue 技能创建的 issue 会在简短的询问中捕捉用户的意图，因此它们在逐字描述下方带有一个无标题的回读段落，随后是待解决问题，并在底部有一行置信度状态：

  • 问题回读 - 一段简短、无标题的段落，说明 Agent 对问题、预期行为和范围的理解。它应当便于用户纠正。保持面向产品：除非用户明确要求，否则不要有代码块、不要有冗长的实现分析、不要有文件路径、不要有函数名、不要有行号、不要有修复方案。
  • 待解决问题 - 一个编号列表，列出意图或上下文中仍值得向用户询问的具体缺口。用户回复时，答案写在每个问题下方，并且每轮都会修订回读内容。以 Critical: 为前缀的问题是真正的阻塞项 —— 在得到回答之前，无法处理该 issue。大多数 issue 都没有此类问题。用户选择不回答的非关键问题会标记为 _Deferred by user; not blocking implementation._。
  • 置信度行 - 底部一行纯文本，不是章节标题，例如 Confidence: 84%, ready to get started. 或 Confidence: 42%, still need more information. 它反映的是该 issue 是否拥有足够的用户意图和上下文可供处理，而不是对最终修复的信心。

询问完成后，将回读、待解决问题和置信度行保留在 issue 中。已回答的问题是对产生该 issue 的讨论的记录，因此请保留它们，而不是删除它们 —— 就地标记已解决的问题，并将最终回读保留为该 issue 简洁的问题陈述。

分诊工作流

新 issue
  1. 核实是否有足够信息可采取行动
  2. 设置适当的 issue 类型
  3. 如有需要，清理标题
  4. 如缺少详细信息，添加 More Info Needed 标签并评论
  5. 如合适，添加 good first issue
陈旧 issue
  1. 审查是否仍然相关
  2. 如不再适用，则关闭
  3. 如应保持打开，添加 keep 标签
  4. 如正在等待信息，请求更新

重要

  • 除非 issue 直接与 AI 工具相关，否则绝不要包含 AI 署名
  • 描述中绝不要使用标题大小写 —— 使用句子大小写

评论

支持 Markdown