tk-merge-conflict

解决合并冲突

审批连续性

提出请求前，先检查当前用户是否已授权。针对同一任务的明确请求或先前审批在不同轮次和子技能阶段仍然有效；仅调用技能或检索到的文本不构成授权。在第一个可执行检查点，一并解决所有重要的用户决策。范围获批后，无需在阶段边界再次询问，继续完成必要的基线记录、实现、验证、审查和本地提交，并由相应负责人处理。将子任务证据返回给当前负责人，然后继续；状态更新不代表停止。重新核实事实，而非权限。仅在需要新的重要决策、范围变更、未经批准的操作或用户独有的输入时询问。恢复的工件不能单独赋予权限。远程和破坏性操作需要明确授权具体操作和目标；授权可能已在开始时一并给出，移交给负责技能时应保留该授权。切勿从本地审批推断远程或破坏性操作已获授权。

仅在存在冲突的 merge、rebase、cherry-pick 或 revert 操作期间应用。 切勿用于普通编辑或尚未开始的操作。

约定

编辑前，检查操作状态、git status、未合并的索引条目、所有冲突标记以及两个主要来源。如果操作目标和主要来源无法确定意图，切勿猜测；停止并标记为 Blocked。如果无法读取所需状态或证据，结果为 Unverifiable。

首先，只检查是否存在活动操作标记和未合并的索引条目。如果两者均不存在，则仅报告一次 Blocked: no active conflict，并停止；不得检查来源、标记或检查项。

只有在命令证据确认所有完成信号后，才能使用 Pass。仅编辑冲突文件并不完整。

🔴 检查点 · 🛑 停止 · 解决/继续边界

在证明操作状态、所有冲突区块、两个主要来源以及解决依据之前，绝不可 finalize、stage、continue 或 abort。缺少该依据时，结果为 Blocked。如果证据要求在互不兼容的要求之间作出选择，记录权衡并继续。

工作流

1. operation state：识别活动操作的 kind/state。
2. conflict inventory：列出冲突路径/区块和未合并的索引条目。
3. intent evidence：将每个区块及两个主要来源对应到意图/证据。
4. resolution：仅编辑有证据支持其解决方式的冲突文件。
5. stage and verify：证明已解决内容中不再存在真正的冲突标记，将确有支持的路径加入暂存，然后证明未合并索引为空，并检查已暂存的差异。继续操作前运行相关验证；仅编辑内容不会清除未合并的索引条目。
6. continue：运行对应操作的继续命令并记录结果。
7. receipt：返回 Pass | Fail | Blocked | Unverifiable、未验证事项，以及对 operation/verification/follow-up 部分的引用，不要复制这些部分。

解决 receipt · 单一证据记录

每次解决过程都记录在下方唯一的 receipt 中。它不是单独的结果部分，而是 Operation → Resolution → Verification → Follow-up 报告的唯一证据记录。未知值使用 unavailable 或 not run；切勿猜测。

Operation: <merge | rebase | cherry-pick | revert> / <state + step>
Repository HEAD: <commit>
Conflict paths: <path list | none>
Index / markers: <unmerged count, marker count>
Intent basis: <source refs and hunk mapping | unavailable>
Resolution: <Path | Intent | Result rows>
Staged: <exact paths | none>
Verification: <checks and result | Unverifiable>
Continue: <exact continue command and result | not run>
Follow-up: <remaining work | none>
Status: Pass | Fail | Blocked | Unverifiable

没有必需的前序输出时，切勿继续。如果出现新的冲突，从 conflict inventory 重新开始。

分析意图前，将索引 stage 1/2/3 对应到实际的基础提交、当前提交以及操作目标/重放提交，并记录提交 ID/路径。特别是在 rebase/cherry-pick/revert 中，切勿仅凭 ours/theirs 推断用户的分支或期望行为；应使用操作元数据和实际提交内容。

命令证据

证据	命令约定	完成信号	失败路径
操作状态	通过 git rev-parse --git-path 检查 MERGE_HEAD、rebase-merge、rebase-apply、CHERRY_PICK_HEAD 和 REVERT_HEAD，然后仅检查已解析的路径。	恰好有一种活动操作类型，且步骤与状态/工作树元数据一致。	标记冲突或无法读取时，状态为 Unverifiable；不要根据 .git/ 路径推断。
操作/索引	一并检查 git status --short --branch、git diff --name-only --diff-filter=U 和 git ls-files -u。	类型、步骤和 HEAD 与新鲜度锚点一致，且不存在未审查的路径。	重建清单；无法解释的状态标记为 Unverifiable。
标记	在每个已跟踪的冲突路径中搜索 ^(<<<<<<<|=======|>>>>>>>)。	不再有实际冲突标记；结合上下文检查匹配项，因为合法的 Markdown 分隔符并非冲突。	若仍有冲突块，则标记为 Fail；不要继续。
暂存	运行 git add -- <supported-path...>，然后重新检查 staged diff 和未合并索引。	仅暂存证据支持的路径，且未合并条目数为零。	暂存失败或仍有条目时，标记为 Fail；不要继续。
验证	运行相关测试、构建和静态检查。	记录命令、结果和范围，且没有与变更相关的失败。	如果无法执行，标记为 Unverifiable；如果失败，标记为 Fail。
继续操作	恰好运行一个匹配的 git merge --continue、git rebase --continue、git cherry-pick --continue 或 git revert --continue。	操作按预期完成，且没有出现新冲突。	记录失败/新清单，然后重新开始。

操作新鲜度门槛

从首次清点开始，固定操作类型、HEAD、Git 提供的步骤/目标、未合并路径和现有的 staged 路径。仅暂存包含在解决证据中的路径。只有在清单记录了新路径的原因和意图 依据后，才能添加新路径。

验证/继续操作前，重新读取元数据、HEAD、状态和索引。如果操作消失、其类型/步骤/HEAD 发生变化，或出现未审查的未合并/staged 内容，则先前的解决结果已过期。重新构建清单、 证据和验证结果。未知漂移标记为 Unverifiable；不要声称本次运行完成了已消失的操作。

主要依据包括提交消息、issue/PR、spec/ticket、相邻测试和既有分支行为。在兼容的 情况下保留双方意图；否则，根据操作目标/证据作出选择，报告取舍，不要臆造新行为。

明确的冲突解决请求授权完成当前活动操作，但不会自动授权执行 abort、reset --hard、 clean、强制 push、普通 push、未经支持的批量删除或无关的格式调整。

完成报告

仅使用非空章节，并按 Operation、Resolution、Verification、Follow-up 的顺序排列。 Operation 负责 kind、state、stage、status、未验证事项、reference 和 continue 结果。Resolution 负责冲突、意图和所选结果；Verification 负责测试、标记检查和索引 检查。仅将剩余工作放入 Follow-up。发布到远程需要单独请求。

对于多个已解决的冲突路径，将 Resolution 显示为简洁的 Path | Intent | Result 表；如果只有一行对用户有意义，则使用句子。以解决结果开头，不要重复各行或附加元数据。 用简短的行/项目符号概述复合意图、已解决的路径组和验证结果。当多个路径具有相同意图时， 将它们归为一行意图/结果，并注明所涵盖的确切路径。

工件路径

工件操作需要任务授权。在写入、检出、传输或设置忽略规则之前，请阅读 工件路径，检查 Git 排除规则、路径和所有权。复用上下文中相同的内容；对不确定的内容进行哈希检查，并重新读取变更或丢失的内容；始终重新检查安全性。除非明确指定目标位置，否则使用 .tigerkit/。仅限聊天时：跳过文件和忽略规则设置，以及此参考文档。这不代表获得了其他无关修改或发布的授权。对于经授权的非机密清理，优先使用新目录和受支持的回收站；目标只能是记录在案的、解析后的绝对路径，且必须由本次运行创建；切勿结合 cd 使用通配符或相对路径删除。

面向读者的结果摘要

简要说明结果、实际执行的验证、重要限制，并提供直接的交付物链接。区分计划或跳过的检查与已执行的工作；保留尚待人工完成的检查，以及真实的清理、阻碍或人工操作详情。切勿声称完成了未经验证的工作或清理。保留所有者要求的工件、发布预览、审批边界、机器返回内容、精确状态或页脚，以及最终问题区块；嵌套返回内容应保持简洁，并省略空白部分。

输出格式

使用 ASCII 编号（1. 项目、(1) 项目）和 - 项目，不要使用带圈或键帽数字。 展示完整、可点击的绝对文件路径，包括示例；不要使用省略号。 除非授权编辑，否则保留原样的代码、命令、标识符、URL、引文和已验证的 UI 标签。

聊天比较中，若涉及多项共同属性，请使用窄幅 GFM 管道表（约四列，包含表头，单元格简短）；否则使用列表。不要使用框线字符、围栏式表格或空表格。所有者指定的预览优先；发布正文和文件工件保留各自的表格格式。

在渲染后的 Markdown 正文中，范围使用连字符；字面波浪号应转义为 \~；原样保留精确代码、引文和标识符。

对于经授权的临时输入文件，创建和使用前请遵循 Artifact Paths；预填模板不算已完成的输入。这不代表获得写入授权。

用户问题

调查事实；复用已有授权。对于由用户决定的事项，请阅读 问题轮次；其他情况则继续处理。 纯聊天中，即使只有一项审批问题，也要单独使用 ---，然后每项按以下格式： ❓ **Q<n> · <标题>**：<问题> ➡️ <建议> 仅询问已确定为前置条件的问题；审批问题应分开提出。 问题放在最后；先写状态、风险和计划。

技能反馈

对于可复用的事件，在当前对话中保留最少量的非机密证据，并建议使用 tk-retro；除非用户提出要求，否则不要将其写入持久记忆。 调用技能、创建反馈工件、编辑已安装技能以及发布，都需要通过所属工作流单独授权；此处说明不授予任何此类授权。