关于 to-linear
将单一主要来源转化为经批准、排序后的 Linear 待办列表的工作流。它确定目标项目并解析来源，审查范围重叠和依赖关系，待完整提案获批后发布并验证事项及关联。
主要功能
- 01确认唯一团队和项目目标
- 02解析并记录主要来源
- 03审查现有事项和范围重叠
- 04规划有序里程碑、事项及依赖
- 05发布前要求明确批准
- 06验证已保存事项和关联
适用场景
- 01将计划或规范拆分为 Linear 事项
- 02根据来源构建按依赖排序的待办列表
- 03避免与现有事项重复或范围重叠
- 04发布获批的事项与里程碑关系图
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/to-linear确认已加载。
附带文件agents/openai.yaml
详细介绍
转换为 Linear
将主要源内容转换为经过批准、排序的待办事项列表。起草前，请阅读并应用 $linear-ticket：它负责所有单个工单的内容、元数据、估算、变更和验证。此工作流负责目标位置选择、源内容解析、拆分、整体依赖图审查和发布顺序。将已确认的目标位置和获批方案传递给 linear-ticket。
流程
1. 确认目标位置
在分析或起草之前，按照 linear-ticket 中明确的团队／项目选择和确认流程操作。此工作流绝不能推断目标位置。本次运行中的所有工单都使用已确认的目标位置，除非用户重新开始选择。
2. 解析来源、上下文和现有工单
按以下顺序确定唯一的主要源，作为范围依据：
- 用户在调用时提供的明确来源，或明确指定用于本次运行的来源：文件、问题标识符或 URL，或粘贴的计划／规范。若引用的是问题，请获取并完整阅读其正文和评论。
- 否则，使用当前对话中最近一份已确定的计划或规范。若其中指向某个资料，请获取并完整阅读该资料。
- 否则，若根目录中存在
PLAN.md，则完整阅读。 - 否则，停止并向用户索要来源。
即使存在 PLAN.md，也以明确指定的来源为准。说明所选来源。不要将多个可能的来源合并成新的范围；若来源选择存在歧义，或矛盾会实质性改变预期结果，请先询问用户。
将 CONTEXT.md、适用的 AGENTS.md、引用来源、相关 ADR、设计、代码和测试视为辅助上下文。若它们会影响工单的准确性，请阅读。CONTEXT.md 是领域术语、边界和长期决策的权威依据，但辅助上下文不得在未说明的情况下扩展主要源的范围。
将主要源和稳定引用传递给 linear-ticket，以便处理来源信息。
对于范围较广的工作，可使用子 Agent 开展有界、独立且只读的探索，例如分别调查不同模块、搜索既有方案或检查重叠内容。它们工作期间，继续其他独立分析，然后在起草前综合所有结果。主要 Agent 负责来源选择、完整方案、用户审批以及所有 Linear 变更；绝不能通过子 Agent 并发创建或编辑 Linear 项目。
确认目标位置后，在拆分前，按照 linear-ticket 的要求对整个来源进行限定范围的清点和重叠审查。复用匹配的里程碑和已覆盖的问题；在完整方案中列出范围缩小或省略的重叠内容。起草时执行其估算发现流程，并在获批发布前暂缓写入。
3. 起草里程碑和 tracer-bullet 工单
通过 linear-ticket 起草每个拆分项，包括 Human 和预先重构工作。
拆分前，检查是否有必要的预先重构，并依据 linear-ticket 的范围规则，将符合条件的成果安排在其所支持的拆分项之前。
按照 linear-ticket 及其编号参考规划里程碑成员关系和编号。按时间顺序和拓扑顺序排列完整的里程碑集合，确保前置里程碑排在前面。对于获批插入或重新编号中包含的现有项目，也应用编号规则。
按照 linear-ticket 的前置条件规则，对完整方案进行拓扑排序。将所有里程碑视为一个依赖图：工单自身的阻塞项完成后，该工单即可执行，即使更早的里程碑仍有未完成工作。识别可供并发 Agent 执行的未阻塞前沿。对于无法作为纵向切片以绿色状态合并的广泛机械式重构，使用按顺序排列的扩展—迁移—收缩工单。
4. 与用户审核
按里程碑顺序展示选定的主要来源和完整提案。对每个里程碑，展示现有/新增状态；对每个工单，展示标题、现有/新增状态、阻塞项、开篇用户故事、交付成果、验收标准、执行者（Agent 或 Human）、标签和来源依据。为每个新增或编辑的工单提供建议估算及简要理由，并明确指出对现有估算的更改以及任何临时规模假设。明确展示省略或缩小范围的重叠项，以及初始的独立 Agent 工单并行队列。
请用户批准里程碑名称/顺序、工单顺序、粒度、用户故事、依赖关系、重叠项处理、标准、标签、适用的估算、来源依据和并行队列。未经明确批准，不得发布。
5. 发布并验证
发布前立即刷新完整范围内的清单，并通过 linear-ticket 协调新增的重叠项和已占用的编号。按已批准的时间顺序创建缺失的里程碑，保留复用的里程碑名称，除非其更改已获批准。通过 linear-ticket 按里程碑发布缺失的工单，并按标题编号升序排列；将 Backlog 作为必需的初始状态传入，并传入所有已批准字段和逐工单变更。对未经批准编辑的复用工单保持原样。
所有工单都创建后，通过 linear-ticket 单独执行原生关系处理，覆盖完整的已批准关系图。纳入每个新工单，以及每个获准修改关系的复用工单。依据完整提案协调并验证所有直接关系，包括跨里程碑依赖关系。
如有原生里程碑/工单排序功能，请使用。否则，以创建顺序和数字标题为准；验证返回的顺序，并明确报告仍需在 Linear 中手动调整的排序。切勿为了强行排序而臆造里程碑目标日期。
对每个新建或已批准编辑的工单，应用 linear-ticket 的已保存字段、估算、描述和编号验证。重新读取已保存的里程碑名称，并根据已批准的提案验证完整顺序；指出未经批准的历史冲突。在报告发布结果和未解决的问题前，纠正范围内的不匹配项。
最后以纯文本形式写出 Milestone order: <first> → <second> → <third>，随后按相同的里程碑顺序和编号升序列出工单标识符/URL。然后写出 Parallel frontier: <issues>，列出未受阻且可由独立 Agent 并行实现的工单；如果没有，则写出 Parallel frontier: none。