write-ticket

编写工单

在与研究和决策相同的聊天中编写最终工单。仅由用户启动；/task 读取工单（工单上下文）。此技能不会实现工单。

阅读时机

• 要准备涉及用户流程的工作？调查期间打开 user-experience.md，并将结果写入计划中有条件的 UX/UI 部分。仅涉及后端的工作可跳过。
• 要开始分析或起草？打开 code-quality.md、code-structure.md 和 doctrine.md。跳过这些文档，工单就会规划出违反规则的方案。
• 要开始为功能进行深入探讨或起草？打开 strong-foundation.md。跳过它，计划中就不会留出可用于接入新变体的扩展点。
• 要开始提问？阅读向用户提问以及相关的 reference.md 指南。跳过这些内容，你就会询问仓库或跟踪系统中已有的信息。
• 要开始起草或撰写？阅读计划正文、新执行者交接和最终版本说明。跳过这些内容，工单就必须依赖之前的聊天才能理解。

流程

1. 阅读提示词和任何提及的现有工单。确定预期结果，以及用户要求的是聊天草稿还是实际写入跟踪系统。尽可能推断仓库和跟踪系统相关信息。不要询问工单阶段。
2. 通过 /analyze 收集问题和代码证据，复用当前分析，只补充缺失部分。只有在能实质性提升理解时，才进行有针对性的 /how 和 /why 调查。若改动需要，须在拆解前应用公共边界调查。在同一聊天中完成准备工作；无需中间工单或另存研究材料。
3. 按照决策指南应用 /grill-me，包括用自己的话逐行重述意图，以及进行就绪检查。只询问尚未解决且影响重大的用户选择；请求已完全明确时无需提问。复用已确定的答案。对于不完整的回复和矛盾之处，进行澄清；将准确的约定、原因、依赖项和明确的阻塞项纳入对应的工作项。随着答案改变对问题的理解，在此处研究新事实并修订正在编写的工单；不要重新开始访谈，也不要在没有缺口时要求再次分析。
4. 根据证据和已确定的上下文填写计划正文。按照依赖顺序编写有意义的实施事项，并根据工作项约定，为每项写明本地的 Do、Why、How 和计划中的 Verify 细节。将共享上下文放在其他部分，避免重复工作项的理由。指定工作类型。当工作有适合评审的 PR 边界时，应用按 PR 拆分子工单。根据相同上下文撰写子项正文和堆栈交接。将所有正文打磨至最终版本。
5. 应用新执行者交接，包括对非简单草稿使用全新上下文的只读检查器，并按条件进行堆栈检查。解决具体阻塞项，然后仅在一条“已敲定”消息中展示完整最终草稿，不包含问题（仅草稿请求的最终回复）。若有拆分，包含子项正文和堆栈顺序。未完成或未经检查的草稿应留在聊天中，并清楚标出缺口；不要称其为可直接实施的草稿。
6. 对于仅需草稿的请求，只给出这一份最终草稿后即停止。对于已授权的跟踪系统写入，如仍缺少优先级、负责人或跟踪系统，则一次性收集全部元数据。完整草稿展示后再写入，无需重复询问许可。遵循跟踪系统写入，更新时保留工单身份和原正文中的重要内容。更正后重新检查最终版本是否干净。
7. 回读已保存的正文和关联关系。若有相关内容，返回实际 URL、类型、已应用的元数据和堆栈顺序，并说明任何未完成的写入或阻塞项。不要再次输出完整正文；遵循工作输出。新建时状态为 Todo；更新时除非用户指定其他状态，否则保留原状态。不要开始实施或发布。