linear-deliver-feature

Linear 功能交付

将此工作流用作单个 Linear 问题的综合生命周期控制器。将范围更窄的技能作为各阶段的具体实现，但状态转换由此处管理。

在更改工作流状态或代码之前，请阅读并遵循 docs/superpowers-linear-persistence.md。

首先，针对实际的 Linear 问题运行 linear-status。根据检测到的阶段恢复工作：使用检测到的标签、状态、最新的标记评论以及问题描述仪表板。只要有 Linear 证据，就不要凭记忆或用户最近一条聊天消息开始处理。

生命周期状态机

1. detect-current-state - 运行 linear-status，以识别当前阶段、缺失的证据、状态不一致之处以及建议的下一项技能。
2. capture-metadata - 查询实时 Linear 团队、项目和标签，然后使用 scripts/linear_metadata.ts capture 对其进行规范化。
3. create-issue - 运行 linear-create-issue，使用目标团队、目标项目、建议的匹配标签/标记、类型标签和一个 LLM 状态标签创建或更新问题。
4. refine-plan - 运行 linear-refine，直到问题包含标记的计划评论，且其 plan_status: ready，或明确处于已阻塞/已接受未知状态。
5. implement - 仅在计划已就绪、Superpowers 任务列表已同步到问题描述仪表板中，并且已传递或确认与直接运行时相同的必要实现者权限上下文后，才运行 linear-implement。该上下文包括工作区写入权限、包管理器和验证命令权限、Linear MCP 读写工具、分支或 PR 工作（如适用）所需的 Git/GitHub 工具，以及所需的项目 MCP 工具。进行代码更改、运行验证、在切换顶层任务之前更新仪表板；仅在遇到阻塞、准备好评审、放弃工作、验证失败、交接或无法写入变更时，才发布标记状态评论。
6. validate-comments - 针对最终计划/状态评论和问题描述仪表板运行 scripts/validate_marked_comments.ts，然后才能宣称工作流已准备好评审。
7. review-handoff - 确认 PR 或补丁已准备就绪、存在验证证据，并确保问题恰好有一个工作流状态标签：准备好评审时使用 llm-review，未准备好时使用 llm-blocked。
8. closeout - 仅在评审后，且 PR 已合并、存在直接包含问题 ID 的提交证据，或压缩/导入发布证据能够证明当前 main 包含预期的文件/内容证据且发布/main CI 已通过时，才运行 linear-close。核实已合并的 PR、直接提交或发布证据，以及主线和 CI 证据；然后将问题移至 Done，移除所有 llm-* 标签，保留累积的 sp-* 标签，更新仪表板，并发布最终结项证据。如果当前问题 ID 与工单证据中实现的问题 ID 使用了不同的 Linear 团队前缀（因为问题已移至其他团队），请按照相同规则手动核实旧实现 ID，关闭当前问题，并在结项说明中包含两个 ID。
9. final-linear-mutations - 当 Linear MCP 写入工具可用时，通过它们应用最终标签/评论；否则输出包含精确变更内容的 REQUIRED_LINEAR_MUTATIONS。

如果当前状态缺少所需证据，不要推进到下一个生命周期状态。停留在当前状态并记录阻塞项。

阶段完成交接

每个生命周期状态完成后，报告发生了哪些变化、当前状态已满足的证据、当前的 Linear 标签／状态、任何标记的评论修订，以及建议的下一步。

询问此生命周期状态是否还有其他内容要补充。如果有，请继续当前步骤，并更新相关 issue、计划、代码、验证或状态评论。如果没有，请建议进入下一工作流步骤，并指出下一个生命周期状态。

使用以下回复格式：

• 当前阶段
• 变更内容
• 证据
• 缺失的证据
• 未解决的阻碍
• 建议的下一步
• 建议的下一个技能
• 问题：进入下一步之前，还有其他内容要补充吗？

Linear MCP 合约

每个阶段的技能都必须通过 Linear MCP 执行以下操作：

• linear-status 使用 get_issue 和 list_comments。
• linear-create-issue 使用 list_teams、list_projects、list_issue_labels 和 save_issue。
• linear-refine 使用 get_issue、list_comments、save_comment 和 save_issue。
• linear-implement 使用 get_issue、list_comments、save_comment 和 save_issue。
• linear-close 使用 get_issue、list_comments、save_comment 和 save_issue。

阶段之间不得跳过验证。使用以下内容捕获实时元数据：

scripts/linear_metadata.ts capture --teams linear-teams.json --projects linear-projects.json --labels linear-labels.json

使用 CLI 风格的任务列表和 symbol 任务标记，验证带标记的评论以及 linear-ai.dashboard.v1 issue 描述仪表板：

scripts/validate_marked_comments.ts --description <issue-description-file> <comment-file>

对于结构化 intake 试运行，请使用：

scripts/intake_issue.ts --metadata <metadata.json> <input.yaml>

使用 Agent 可用的本地 JavaScript 包管理器或运行时。Bun 可以直接运行 .ts 脚本；Node/npm/pnpm/yarn 环境应通过 TypeScript 运行器（例如 tsx）运行这些脚本。

停止条件

• 如果 Linear MCP 读取工具不可用，且不存在当前元数据快照，则在 capture-metadata 阶段停止。
• 如果无法根据实时元数据选择目标团队、目标项目、建议的匹配标签／标记或类型标签，则在 create-issue 阶段停止。
• 如果缺少必需的产品事实，且不能将其视为未知项接受，则在 refine-plan 阶段停止。
• 如果验证无法证明已满足就绪计划，则在 implement 阶段停止。
• 如果 issue 无法恰好移至一个最终 LLM 状态标签，则在 review-handoff 阶段停止。
• 如果缺少 PR 合并证据、旧 ID 对应的实现证据、squash/import 发布文件／内容证据、主线证据或 CI 证据，则在 closeout 阶段停止；在有证据证明已完成收尾之前，保留 llm-review。

如果任何阶段因缺少产品事实或缺乏写入权限而受阻，请发布或输出准确的 REQUIRED_LINEAR_MUTATIONS，并停留在受阻的交接状态，不得猜测。