linear-close

Linear 关闭

在实现经过审查后，当 PR 已合并、存在直接包含问题 ID 的提交，或压缩合并／导入的发布证据证明预期文件和内容已存在于当前 main 且 release/main CI 已通过时使用此流程。如果当前 Linear 问题 ID 与工单证据中记录的已实现问题 ID 因问题被移动到其他团队而具有不同的团队前缀，请按照相同的关闭规则手动验证旧的已实现 ID，然后关闭当前问题，并在备注中注明这两个 ID。

请阅读并遵循：

• agents/closer.md
• docs/workflow.md
• docs/agent-required-passes.md
• docs/comment-validation.md
• docs/tools.md
• templates/linear-status-comment.md

不要实现代码、合并 PR 或更改审查策略。此技能仅用于在存在已合并 PR 证据、问题 ID 提交证据或压缩合并／导入发布证据后完成工作。

运行此技能时，问题可能已经处于 Done 状态，因为实现者的关闭魔法词（Fixes HCL-123）会使 Linear 在合并时自动移动问题。请将问题已经处于 Done 视为预期情况：仍需验证证据、更新仪表板、发布关闭备注，并移除 llm-* 和 in-use。此时将状态移至 Done 不会产生任何变化。不要重新打开问题，也不要将其已处于 Done 视为错误，或视为跳过关闭流程收尾工作的理由。

声明锁

遵循 docs/workflow.md 中的声明锁规则。开始时重新读取问题；如果问题已有 in-use 标签，且本次运行不是在继续自己的声明，则停止并报告问题已被认领，不做任何更改。否则，在认领问题时添加 in-use 标签。in-use 不属于 llm-* 命名空间，因此关闭流程中移除 llm-* 的操作不会将其移除；请在最终处理时明确移除 in-use（在因阻塞或放弃而停止时也要移除）。

认领时，使用 claimed_by: linear-close 和 ISO 8601 格式的 claimed_at，将 linear-ai:claim 块（templates/linear-claim-block.md）写入问题描述。在最终处理时，移除声明块以及 in-use 标签。

Linear MCP 合约

在可用时使用以下 Linear MCP 工具：

• get_issue - 读取问题描述仪表板、标签、状态、项目、分支元数据和链接。
• list_comments - 查找最新的带标记计划／状态备注以及之前的关闭证据。
• save_comment - 发布最终的不可变带标记状态／关闭备注，或受阻关闭证据。
• save_issue - 更新问题描述仪表板，将状态移至 Done，移除所有 llm-* 标签，移除 in-use 声明，并保留累积的 sp-* 标签。

在可用时使用 Git/GitHub 证据：

gh pr view <PR> --json url,state,isDraft,baseRefName,mergeCommit,statusCheckRollup,commits > pr.json
git pull
git merge-base --is-ancestor <merge-commit> origin/main

对于直接提交关闭，请收集包含问题 ID 和已完成状态检查的提交证据：

{
  "oid": "replace-with-commit-sha",
  "subject": "fix(HCL-123): example issue commit",
  "statusCheckRollup": [
    { "name": "test", "status": "COMPLETED", "conclusion": "SUCCESS" }
  ]
}

对于压缩合并／导入发布关闭，请收集发布证据，其中包含成功的 release/main 检查，以及可针对当前主线引用进行验证的文件断言：

{
  "statusCheckRollup": [
    { "name": "release main CI", "status": "COMPLETED", "conclusion": "SUCCESS" }
  ],
  "files": [
    { "path": "dist/manifest.json", "contains": "\"version\":\"2026.06.14\"" }
  ]
}

使用以下命令验证关闭证据：

scripts/verify_closeout.ts --issue-id <ISSUE-ID> --pr pr.json --repo . --base origin/main
scripts/verify_closeout.ts --issue-id <ISSUE-ID> --commit commit.json --repo . --base origin/main
scripts/verify_closeout.ts --issue-id <CURRENT-ISSUE-ID> --implemented-issue-id <OLD-ISSUE-ID> --commit commit.json --repo . --base origin/main
scripts/verify_closeout.ts --issue-id <ISSUE-ID> --release release.json --repo . --base origin/main

仅当问题被移动后当前问题键与已实现问题键具有不同的 Linear 团队前缀时，才使用 --implemented-issue-id。对于 PR 证据，请包含 PR 提交，以便辅助工具验证某个提交提及了旧的已实现 ID。关闭备注必须说明 <CURRENT-ISSUE-ID> 是从 <OLD-ISSUE-ID> 移动而来或在其名下实现，并且已根据旧 ID 手动验证实现、主线和 CI 证据。

使用以下命令验证最终带标记的备注和问题描述仪表板：

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

使用 Agent 可用的本地 JavaScript 包管理器或运行时：Bun 可直接运行 .ts 脚本；Node/npm/pnpm/yarn 环境应通过 tsx 等 TypeScript 运行器执行脚本。

收尾要求

将问题移至 Done 前，必须证明以下所有事项：

• 关联 PR 已合并
• 或直接提交证据中包含问题 ID
• 或对于跨团队转移的问题，PR 提交证据或直接提交证据中包含原已实现问题 ID，且当前问题 ID 的团队前缀不同
• 或 squash/import 发布证据证明预期文件路径和内容已存在于当前主分支上
• 或对于父级跟踪问题，每个子问题均为 Done，且有经过验证的收尾证据，并且父级审核关卡已确认父级要求均已覆盖
• 主线包含合并提交、直接包含问题 ID 的提交、等效的远程主线证据、预期的发布文件/内容证据，或（对于父级跟踪问题）子问题经过验证的主线证据
• 合并 PR、合并提交、直接包含问题 ID 的提交或发布/主线证据的 CI 已完成且成功；对于父级跟踪问题，每个子问题经过验证的 CI 证据即满足此要求
• 最终仪表板/状态证据不与收尾结论相矛盾
• 所有 llm-* 工作流状态标签和 in-use 占用标签都将被移除
• 累积的 sp-* 标签将予以保留

如果缺少任何必需证据，请勿关闭问题。发布受阻证据，或输出 REQUIRED_LINEAR_MUTATIONS。

最终处理

成功收尾必须：

• 如果问题描述中有标记的仪表板区块，则更新该区块
• 发布一条最终的、不可变的标记状态/收尾评论；如果收尾使用了团队变更后的旧已实现问题 ID，则同时包含两个 ID；如果收尾使用了 squash/import 发布证据，则包含经过验证的文件/内容和发布/主线 CI 证据
• 将 Linear 状态移至 Done（如果关闭用魔法词已将其移至该状态，则无需操作）
• 移除 llm-refine、llm-ready、llm-active、llm-blocked 和 llm-review
• 移除 in-use 占用标签
• 保留累积的 sp-* 标签，例如 sp-clarify、sp-plan、sp-tdd、sp-implement、sp-verify 和 sp-review

当关闭的问题是子问题时，在同一轮最终处理中应用 docs/workflow.md 中的父级和子问题规则。如果仍有未完成的子问题，则根据剩余同级问题汇总父级的 llm-* 状态和状态。如果这是最后一个未完成的子问题，则运行父级审核关卡：确认合并后的子问题工作是否完整覆盖父级要求和验收标准；如果已覆盖，将父级移至 llm-review 和 In Review，以便进行其自身的收尾；如果仍有差距，则对父级应用 llm-refine 并记录差距。

如果 Linear MCP 写入工具不可用，请勿声称标签、状态、仪表板或评论已更新。请输出 REQUIRED_LINEAR_MUTATIONS，其中包含确切的问题描述、最终收尾评论、标签和状态变更，包括任何父级汇总变更。

步骤完成交接

收尾完成或受阻时，报告变更内容、合并证据、CI 证据、仪表板/状态证据、当前 Linear 标签/状态以及建议的下一步。

询问用户是否还要为此收尾步骤补充内容。如果是，则继续当前步骤，检查该收尾证据或更新收尾报告。如果否，则建议进入下一工作流步骤，通常是 linear-status，以确认问题已关闭或检查是否还有遗留问题。

用户回答“不”后，询问用户是否要继续执行建议的下一项技能。明确说出建议的下一项技能，并等待用户确认；不要自动运行它。

使用以下回复格式：

• 当前阶段
• 变更内容
• 证据
• 缺失证据
• 未解决的阻塞项
• 建议的下一步
• 建议的下一项技能
• 问题：继续之前，是否还有内容要补充？
• 问题：是否要继续执行建议的下一项技能？