to-tickets

转换为工单

将已批准的工作转化为明确聚焦的 GitHub 工单。每张工单都是实现者唯一会阅读的内容，因此必须包含完整任务、完成标准，以及何时应停下并询问。

调用此技能仅授权创建草稿。在第 4 步用户批准草稿之前，不得向 GitHub 写入任何内容。

规则

• 只能使用用户、源材料和代码库提供的信息。不得虚构要求、优先级、标签、关联关系或审批步骤。
• 充分保留决策、限制、理由、边缘情况和研究发现，确保实现者无需重新探索。具体限制要保持具体：“不要使用药丸形按钮”应原样保留，而不是改成“避免外观过于普通”。
• 将已确认的代码位置作为切入点提及，而非工作范围。
• 不要加入“仔细思考”或“全面处理”之类的指示。
• 除非用户提出要求，否则不要编辑或关闭源工单或父工单。

1. 收集上下文

阅读源材料以及确保工单准确所需的代码。只有当答案会改变工单要求、工作拆分方式或执行顺序时，才提问。

从用户提供的信息或本地远程仓库获取目标仓库 HOST/OWNER/REPO，并在每次读取或写入 GitHub 时使用该主机。

对于拉取请求反馈，使用 python3 "<skill-path>/scripts/fetch_review_context.py" 或连接器获取讨论串，逐一对照当前代码检查每个未解决的讨论，只将仍需处理的问题写入工单。

列出代码库的标签，并根据其描述和过往用法了解其含义，而不能只看名称。除非用户或代码库另有说明，否则假定由熟悉该代码库常规设置的 Agent 来实现工单。

2. 检查重复项

使用通俗易懂的词语，针对每个计划结果搜索开放和已关闭的工单。比较目标和范围，而非标题。报告可能重复的工单及其 URL 和重合之处；未经批准，不得修改或复用现有工单。如果搜索失败，在搜索恢复正常或用户同意不经搜索继续之前，不得创建任何内容。

3. 起草工单

拆分工作

当一项工作能产生一个可整体审查的有用结果时，将其保留在一张工单中。只有在各部分可以独立完成、需要不同负责人，或必须按顺序完成以避免实际风险时，才拆分。功能工单必须涵盖该功能所需的所有层面。

只有在某项工作无法在没有另一项工作的情况下完成时，才将其标记为被另一项工作阻塞；优先顺序不构成阻塞。当替换某个接口且无法一次性更改所有调用方时，应按顺序创建工单，以添加新接口、迁移调用方，再移除旧接口。

只有在用户要求探索时，才编写研究工单。不要创建用于归组的跟踪工单或史诗工单；只有在用户要求或代码库惯例要求时，才将工单关联到现有父工单。

将人工工作单独列出

需要由人员做出的决策、审批和采取的行动，应各自放入独立工单，并明确完成标志，且使用代码库中用于人工工作的标签。即使 Agent 能够操作相关界面，这项工作仍由人员负责。不要为常规 PR 审查创建工单。

• 实现前必须完成的人工操作会阻塞实现工单。
• 对已完成工作的人工审批会被实现工单阻塞；实现工单不得将该审批列为完成条件。
• 发布前必须获得的审批会阻塞发布工作。

编写每个工单

面向不了解讨论过程的开发者撰写。使用简单、日常的词语；只有在技术术语用于准确指代某项内容（例如文件、命令或 API）时才使用。

标题：用简单的词语说明结果，无需打开工单就能理解，例如“使用退避策略重试失败的 webhook 投递”，而不是“Webhook 改进”。

正文，按以下顺序编写：

## Summary

Two to four sentences: what needs to change, why, and who is affected. A reader who stops here should know what the ticket asks for.

## Current behavior

What happens today, or the research findings for new work. Keep verified facts apart from guesses.

## Desired outcome

The behavior when the work is done. State confirmed requirements as requirements and optional ideas as tradeoffs. Do not prescribe implementation the source has not decided.

## Acceptance criteria

Plain bullets that together mean done, so the implementer works until all hold and then stops. Include required end states, such as deleted code or no remaining callers, and the full scope, such as "every payment endpoint". Name a test suite or command only when it is the evidence that matters. No implementation steps, generic "tests pass" lines, or checkboxes.

For visual changes, state what must be true on screen, such as "the nav collapses into the menu below 768 px wide with no horizontal scroll". Do not require screenshots or other files on the pull request; the implementer shares screenshots with the user in chat.

## Stop and ask

Situations specific to this ticket where continuing needs a decision the ticket does not make, such as finding a caller outside this repository.

## Execution requirements

Tools, access, or fixtures beyond the repository's usual setup.

## Risks and non-goals

What could break, and what this ticket deliberately does not do.

## Context

Links to the source discussion and related issues, and code locations to start from.

始终包含 Summary、Desired outcome 和 Acceptance criteria。只有在其他部分确有内容时才添加。不要编写内容为“None”的部分。

对于每项验收标准，判断谁可以验证，以及需要什么证据。绝不要为了适应现有工具而降低证据要求。环境缺少某项能力是需要报告的缺口，不是将工作改为由人工负责的理由。

选择标签

只使用现有标签；仅在仓库惯例支持时添加优先级或工作流标签。如果缺少所需标签，就不要添加，并说明原因。绝不要使用 blocked 标签。

当目标环境中的 Agent 仅凭工单文本就能完成并验证工单，无需在工单执行过程中由人工介入，且已知没有适用的停止条件时，添加 ready-for-agent。Stop and ask 部分列出的是如果出现就需要作出决定的情况；这不会导致工单无法就绪。绝不要给研究类、决策类或由人工负责的工单添加此标签。阻塞关系不属于工单执行过程中的步骤，因此只要该阻塞关系仍然存在，就应保留就绪工单的标签。

4. 获取批准

展示仓库、每个工单的确切标题和正文、标签及简短原因（包括 ready-for-agent 的原因）、关系和重复项检查结果。等待用户批准这些草稿。提出创建工单的请求、批准底层计划，或要求连续运行多个技能，都不算批准。恢复执行时，如果工单集未发生变化，之前的批准仍然有效；如有实质性更改，则需要重新批准。

5. 发布

在进行任何写入之前，搜索仓库的未关闭议题，检查是否有与每个已批准标题相同的议题，并复用本次工单集中已创建的议题。绝不要重复创建工单，也不要为了重试某个步骤而删除、重新打开或覆盖议题。

所有写入都使用 gh。确认每个已批准的标签都存在；如果有标签不存在，应先询问，不要创建或替换标签。然后分三个阶段处理，因为建立关系需要双方的议题编号：

1. 使用 gh issue create --body-file 创建所有议题；先创建阻塞其他工单的议题。
2. 为每个议题添加且只添加已批准的标签。
3. 使用捆绑的辅助脚本添加每个已批准的关系；该脚本会解析并验证数据库 ID：
   • 父级：python3 "<skill-path>/scripts/set_issue_relationship.py" --repo HOST/OWNER/REPO --parent PARENT --sub-issue CHILD
   • 被阻塞于：python3 "<skill-path>/scripts/set_issue_relationship.py" --repo HOST/OWNER/REPO --blocked BLOCKED --blocked-by BLOCKER

两个编号都必须属于指定仓库；对于跨仓库关系，使用 gh api，并传入各议题的数据库 ID。如果关系添加失败，绝不要改用标签或正文链接代替。

6. 报告

回读每个议题、标签和关系。返回议题 URL 和关系状态。如果有任何事项未完成，说明已完成的内容、剩余事项以及确切错误。