take

Take

在 tldraw/tldraw 中找到一个 issue，实现它，并打开一个 pull request。

工作流

1. 找到 issue

用户可能通过编号、URL 或描述来引用一个 issue。

• 对于编号或 URL，直接获取该 issue：

gh issue view 123 --repo tldraw/tldraw

• 对于描述，先搜索开放的 issue：

gh issue list --repo tldraw/tldraw --search "dark mode" --state open --limit 10

• 如果没有匹配的开放 issue，搜索所有 issue：

gh issue list --repo tldraw/tldraw --search "dark mode" --state all --limit 10

如果只有一个明确的匹配项，继续。如果匹配多个 issue，请用户从 issue 编号和标题中选择。如果没有匹配项，询问是否使用 issue 技能创建一个新 issue。

2. 理解 issue

阅读完整的 issue 和评论。识别：

• Issue 类型：bug、feature、enhancement、cleanup、docs 或 task。
• 请求的行为和验收标准。
• 技术说明和受影响的文件。
• 相关讨论或澄清。

Agent 起草的 issue 可能包含 ## Confidence 和 ## Open questions 部分。将任何未回答的 Critical: 问题、_Awaiting answer._ 条目或 More Info Needed 标签视为阻塞项，除非代码库探索证明预期行为是明确的。在实现之前与用户解决阻塞项；标记为 _Deferred by user; not blocking implementation._ 的非关键问题可以保持开放。

如果 issue 缺少细节，在决定实现是否安全之前探索代码库。

3. 分配 issue

将 issue 分配给当前 GitHub 用户。如果已经分配给了其他人，询问用户是否继续。

4. 规划实现

基于以下内容创建一个简洁的实现清单：

• Issue 描述。
• 验收标准。
• 代码库探索。
• 现有的仓库模式。

5. 实现

从 main 创建一个新分支。

按清单逐项完成：

• 在编辑文件之前先阅读它们。
• 遵循现有模式。
• 保持更改聚焦于该 issue。
• 避免推测性的改进。
• 当 issue 需要时，更新文档、示例、测试或 API 报告。

6. 验证

先运行最小的相关检查。当更改涉及共享行为时，使用更广泛的检查。

典型的最终检查：

pnpm typecheck
pnpm lint

对于聚焦的包更改，优先运行相关工作区测试，然后再进行仓库范围的检查。

7. 创建 PR

使用 pr 技能。

• 用 Closes #<issue-number> 链接该 issue。
• 包含来自 issue 讨论的相关上下文。
• 包含一个清晰的测试计划。

8. 总结

以以下内容结束：

• 已实现的 issue。
• 关键更改和修改的文件。
• 执行的验证。
• PR 链接。
• 手动测试步骤（如果相关）。
• 任何无法满足的验收标准及其原因。

规则

• 当需求不明确时询问用户。不要在未回答的关键问题或未解决的 _Awaiting answer._ 占位符存在时继续实现。
• 不要猜测未指定的产品行为。
• 保持实现范围限定在该 issue 内。
• 绝不要在提交、issue 或 PR 中包含 AI 署名。