issue

Issue

根据用户描述在 tldraw/tldraw 上创建 GitHub issue，然后向用户提问，以捕获足够多的意图，使该 issue 可以被处理。

使用 ../write-issue/SKILL.md 作为 issue 标题、正文、类型、标签和分类约定的标准参考。

目标不是把代码库研究到死。而是在 issue 中捕获用户的完整意图和上下文，这样以后无论是谁（或什么）接手，都能获得所需的信息。为此，你要立即创建 issue，写下对问题的简要复述，然后向用户提出能够加深这种理解的问题。

Issue 正文形态

正文始终以用户的原始描述开头，逐字引用，并加上 human emoji 注释，与其余部分用水平分隔线隔开：

🗣️: {user_description}

---

{two to five sentences that read back your understanding of the problem, expected behavior, and scope}

## Open questions

1. **{question}**
   _Awaiting answer._
2. **{question}**
   _Awaiting answer._

Confidence: {n}%, {ready_status}.

• 复述段落是 Agent 对问题的理解。它应该短到用户可以快速纠正，但又足够具体，能清楚说明预期的行为。保持面向产品：不要代码块，不要长篇实现分析，也不要逐行诊断。
• 默认不要在 issue 正文中包含实现线索。避免文件路径、函数名、行号、代码片段、可能的原因和修复方案，除非用户明确要求包含它们。接手这项工作的人可以重新发现这些技术背景。
• 让产品意图优先于代码诊断。issue 应记录用户想要什么、观察到了什么，以及他们确认的范围或行为。除非用户已确认这种表述，否则不要把根本原因或修复方向当作事实呈现。
• 每个未决问题都针对意图或上下文中的具体缺口。避免提出你自己查看代码就能回答的问题。
• 保持问题原子化。不要把用户意图问题与实现者可验证的技术检查捆绑在一起。如果用户只回答了复合问题的一部分，只有当剩余部分仍然需要用户的意图或上下文时，才让它保持未决。
• 与其让用户验证实现者可验证的未知项，不如省略它们。只有当用户自身的上下文或意图重要时才询问。
• 只有当问题确实构成阻塞——在得到回答之前该 issue 完全无法处理——才在粗体内给问题加上 Critical: 前缀，例如 **Critical: Which package should we rename?**。大多数 issue 都没有这种问题；不要把普通缺口夸大为关键问题。
• 随着用户回答，将 _Awaiting answer._ 替换为他们的回答（稍作整理），直接放在问题下方，修订复述，并根据需要增加或删除未决问题。
• 如果用户选择不回答某个非关键问题，将 _Awaiting answer._ 替换为 _Deferred by user; not blocking implementation._。不要对关键问题使用这一做法。
• 置信度行是纯文本状态行，不是章节。它反映的是该 issue 是否包含足够的用户上下文和意图可供处理，而不是对最终修复的信心。使用简短的状态短语，例如 ready to get started、still need more information 或 blocked on a critical question。

工作流

1. 收集上下文：
   • 用户的问题描述。
   • 当前分支：git branch --show-current。
   • 近期 issue：gh issue list --repo tldraw/tldraw --limit 5 --json number,title --jq '.[] | "#\(.number) \(.title)"'。
2. 做一次轻量的分类检查，而不是实现层面的调研：
   • 查找重复或密切相关的 issue。
   • 仅使用仓库上下文来选择 issue 类型、标签、里程碑和大致的受影响范围。
   • 如果需要进行浅层的代码搜索以避免提出糟糕的问题，可以去做，但不要在 issue 正文中添加文件路径、函数名、行号、代码片段、可能的原因或修复方案。
   • 任何你可以根据仓库上下文自行回答的内容，都不应成为待解决问题。
3. 对于视觉类 bug，尽可能确定一个复现目标：
   • Examples 应用：通过 pnpm dev 启动的 localhost:5420。
   • tldraw.com 应用：通过 pnpm dev-app 启动的 localhost:3000。
   • 文档站点：通过 pnpm dev-docs 启动的 localhost:3001。
   • 如果用户提供了图片，并且你有它的路径或 URL，请将其嵌入或附加到 GitHub issue 中。
   • 如果图片仅在聊天中可见且无法附加，请将其描述为视觉上下文。除非 issue 中实际包含该图片，否则不要写 "screenshot attached"。
   • 如果截图有用但在本地不可行，且用户未提供截图，请将截图请求作为你的待解决问题之一。
4. 使用 ../write-issue/SKILL.md 撰写 issue 标题和正文。正文遵循上述结构：逐字描述、复述段落、待解决问题，以及置信度状态行。
5. 创建 issue：

gh issue create --repo tldraw/tldraw --title "..." --body "..."

6. 设置 issue 类型（Bug、Feature、Example 或 Task）—— gh issue create --type 不可靠，因此请使用脚本：

skills/issue/scripts/set-issue-type.sh <issue-number> <type-name>

7. 仅在明确契合时分配里程碑：
   • Improve developer resources 适用于示例、文档、注释、起步套件和 npm create tldraw。
   • Improve automations 适用于 GitHub Actions、审查机器人、CI/CD 和自动化工作。
8. 一致地管理 More Info Needed 标签：
   • 仅当有关键问题未得到回答，或置信度行表明该 issue 仍需要更多信息时才添加。
   • 当 issue 已准备好开始处理时将其移除，即使仍存在非阻塞性的考虑事项。
9. 用 issue URL、你的复述和待解决问题列表回复用户。直接向他们提问，并以任何关键问题开头。
10. 追问用户。在每次回复后：

• 更新 issue 正文：将用户的回答写在相关问题下方，修订复述内容，重新计算置信度状态行，并根据他们的回答所揭示的新缺口或已闭合的旧缺口来添加或删除问题。
• 结合新上下文重新审视 issue 的定位。如果某个回答改变了 issue 的实际性质，请更新标题（gh issue edit --title）、issue 类型（第 6 步中的脚本）或其标签以保持一致——例如，当报告的 bug 实际上是功能请求时，或者真正的问题比标题所暗示的范围更窄时。
• 如果用户纠正了你的定位，尤其是使用了 "actually" 或 "well actually" 之类的措辞，请将其视为一个信号，围绕纠正后的区分重写复述内容。在提出更多问题之前，移除或弱化已过时的假设。

gh issue edit <issue-number> --repo tldraw/tldraw --body "..."

• 继续，每次一轮，直到复述和问题的回答包含足够多的用户意图和上下文，可以据此开展工作。

11. 当没有关键问题未回答，并且包含足够多的用户意图可以据此开展工作时，该 issue 即已就绪。只要有某个关键问题尚未解决，就绝不要宣布其已就绪，无论其余部分有多完整。

• 用户选择延后的低优先级问题可以保持未解决；就绪并不要求回答这些问题。请将它们标记为 _Deferred by user; not blocking implementation._，而不是保留 _Awaiting answer._ 占位符。
• 就绪后，移除 More Info Needed 标签，告诉用户该 issue 可以被接手，并相应设置置信度行，例如 Confidence: 84%, ready to get started. 将复述、每个问题以及置信度行保留在 issue 中，作为讨论记录。不要删除它们。

规则

• 始终先创建 issue，再向用户提问，这样用户从第一条回复起就能跟踪它。
• 只提问能够捕捉用户意图或上下文的问题。不要把你本可以自己完成的工作推给别人。
• 每次回复后都更新 issue，而不是在最后批量处理所有答案。