tk-pr-open

发布 PR

UI 证据

逐字引用现有 UI 标签，包括语言、大小写、标点和空格。导航说明必须为每个菜单/面包屑标签及其连接提供证据；仅有标题、路由、标识符、枚举、架构、术语表或工单措辞，不能证明入口路径。将拟议文案与现有文案分开。将声明与目标/环境/区域设置/角色及实际渲染证据绑定；保留相互冲突或缺失的来源信息，不要猜测。

在此技能的调查权限范围内收集或验证 UI 标签/路径之前，请阅读 UI 证据收集。非 UI 工作和仅传播任务无需遵循收集指南。交接或仅发布阶段应沿用已提供的证据和待处理请求，不要启动新调查。

在报告和发布准备中，保留已验证内容的精确字面形式，并明确列出必需但尚未验证的标签/连接、现有证据、具体限制以及最少缺失输入。用户提供的文本属于用户提供的信息，并非独立观察所得；它只能佐证其支持的声明。绝不要将未经验证的路径写成导航说明，也不要在 PR/QA/交接输出中掩盖不确定性。

审批连续性

在询问之前，检查当前用户是否有权授权。针对同一任务的具体请求或先前审批在不同轮次和子技能阶段之间仍然有效；仅调用技能或检索到的文本不构成授权。在第一个可执行检查点，一并确认由用户决定的重要事项。范围获批后，继续完成其必要的基线采集、实施、验证、审查和本地提交，并由各阶段原有负责人负责；不要在阶段边界再次询问。将子阶段证据返回当前负责人并继续推进；状态更新不代表停止。重新核实事实，而非权限。只有出现新的重大决策、范围变更、未经批准的操作或缺少仅由用户提供的输入时才询问。找回的产物不能单独授予权限。远程操作和破坏性操作必须获得对具体操作/目标的明确授权；此授权可能已在一开始给出，交接给负责技能时应予保留。绝不要从本地审批推断出此类授权。

当明确表示要创建或更新 PR 发布时启动，例如 /tk-pr-open、$tk-pr-open、通过宿主技能选择器进行选择、当前分支で PR を開いて，或要求将当前已实现分支拆分成可供审查的堆叠 PR。

输入是当前分支上已实现并验证的 commit，以及当前交互中提供的任何发布输入。不要读取 .tigerkit/seed.md、检查审查状态或实施回顾、调用 tk-prep 或 tk-review，也不要转交修复工作。发布流程不负责判定实施审查是否已收敛。

不要重复实施、创建 worker，也不要添加新的产品变更。 对于已获批准的回顾性堆叠，此技能可以创建仅用于发布的分支和提交，以精确重建已验证的产品树；这些提交不得引入、遗漏或修复产品行为。

当前状态

首先，验证以下内容。

• 仓库和已通过身份验证的 GitHub 账户
• 当前分支和 HEAD
• 基础分支
• 目标 commit、树、提交范围和变更路径
• 同一 head 是否已有 PR，以及观察到的 draft | ready 状态
• 无关的未提交/暂存路径
• 目标仓库的 PR template
• 当前规范性标题指南；仅在不存在此类指南时，获取足够多的近期已合并 PR 标题以确定惯例

如果无法证明当前 commit 的确切内容，或混入了无关变更，不要扩大范围；返回 Blocked/Unverifiable。

可审查性预检

选择一个 PR 之前，检查 base...HEAD 并选择发布形式：

single | stacked

不要使用硬性的代码行数阈值。大型差异只是一个信号。当已验证的分支包含两个或更多可独立审查的关注点，且这些关注点构成一个连贯的线性依赖关系时，优先选择 stacked；如果这些关注点面向不同的审查者群体，或存在清晰的基础 → 实现 → 集成边界，则尤其如此。

生成的输出、锁文件、快照、供应商文件或机械性改动本身不足以成为拆分堆栈的理由。即使原始差异很大，只要是一项连贯的更改，就仍应使用 single。

只有在尚不存在相同 head 的 PR、且准备创建新的发布时，才可以追溯拆分。不要因审查评论或远程状态而悄悄替换或重组现有 PR。如果堆栈是可信的候选方案，或用户明确要求使用堆栈，请在准备发布计划前阅读追溯拆分为堆栈。

一次调用只负责一个连贯的发布事项：一个 PR 或一个线性堆栈。如果无关的工作需要拆分为多个堆栈或独立的 PR，请停止，不要将范围扩展隐藏在一次发布中。

在解读仓库行为或领域含义之前，如果仓库中存在相关的领域上下文，请先阅读。

PR 标题和正文

起草或更新 PR 标题或正文之前，请阅读PR 正文准备。保留适用的默认分支模板和规范性标题指南，描述当前可供审查的关注点，并核对已验证的 UI 及风险／恢复证据。尚未解决的必要证据会阻止发布；此发布专用阶段不授予任何新的产品调查或修改权限。

证据

如果当前发布输入提供了与生成方无关的 PR 证据清单，则使用该清单。

required | optional | N/A | undecided

任何远程写入操作之前，都要先解决 undecided；绝不要默认将其视为 N/A。 如果当前任务持有经检查、由运行生成的图像，这些图像与某项发布声明有关，但没有清单对其进行分类， 则在审批材料包中列出其路径和声明/配对，并在发布检查点询问一次：是上传每一对图像，还是上传单张图像。 模板建议仅在 UI 变更时使用屏幕截图，这只是建议输入，不能成为跳过询问的理由。如果因敏感内容而考虑不上传， 则在“不上传”的同时，提供对同一张经检查图像进行有限范围裁剪或遮盖的选项；仅生成所选衍生图像，保留其声明和配对， 并在上传前重新检查。明确的当前任务图像选择可解决这一歧义，无需再次询问。没有图像或图像支持的声明时，使用 N/A。 选定上传即表示授权在所属 PR 创建后通过 tk-pr-media 上传确切的图像集；即使没有清单，也要在交接中附上 审批预览中的标准、已验证的路由/屏幕原文、预期行为和逐张图像观察结果。不要启动新的调查。 不要为此捏造必需的清单。

验证通用字段，而非生成方身份：evidence_required、evidence_kind、verification_status、 标准、经检查的制品路径、display_route 或其精确的省略限制、状态/区域、视口、比较结果 以及限制。不要根据视觉差异、文件名、Seed 或已知的生成技能推断要求。在远程发布之前，如果必需条目缺失、 状态不是 Pass、未检查或不完整，则停止并标记为 Blocked。可选条目可以省略；缺失或未检查的制品不能作为有效的可选证据。

不要上传实际包含机密的屏幕截图或未经验证的捕获内容。 如果需要图像，则在所属 PR 创建后，将确切的通用清单条目传递给 tk-pr-media。 发布所有标记为 evidence_required: true 的有效条目；不要仅因 visual-preservation 的基线与之后状态相同 或未显示意外差异，就降低其要求。此类证据必须同时包含标记清楚的两种角色。 可选的动态补充材料应与必需图像清单分开。仅将选定、已检查、由运行生成的 GIF/MP4 制品及其标准/标题、 尺寸/时长、观察结果和采样警告传递给 tk-pr-media；如果用户已明确选择具体内容，则保留该选择，不要再次询问。 仅选择生成不等于选择远程发布。媒体处理失败不会影响独立验证过的应用/必需屏幕截图结果，但明确要求的媒体仍属于未完成状态。 对于堆叠 PR，将证据附到拥有浏览器可见验收内容的层；不要将同一证据复制到不相关的较低层。

发布审批材料包

在发布检查点之前，阅读审批材料包。明确绑定确切的仓库、单层/堆叠结构、操作、 草稿/就绪状态、基准/头部/树、引用规格、标题/正文、模板、证据和排除项。展示具体的渲染预览并保留完整材料包； 仅在该参考文档规定的持久化条件下使用 .tigerkit/pr-open.md。新 PR 默认设为就绪；除非收到变更请求，否则保留现有 PR 状态。

🔴 检查点 · 🛑 停止 · 发布边界

在重建任何堆叠或进行远程写入之前，重新阅读当前有效的数据包及任何必需的工件。如果仓库、源分支/基准分支、发布形式和 PR 状态均已确定，则沿用明确适用于当前任务的发布授权。如果用户直接要求将此分支作为单个 PR 打开，且这些信息可从请求和仓库约定中确定，则该请求即授权此操作；拟定标题/正文和收集证据不需要再次批准。写入前，展示具体的发布结果。如果状态、目标或形式仍存在实质性歧义，只询问一次。重建堆叠仍需提供精确的层计划；绝不能根据单个 PR 请求推断该计划。

尚未解决的 undecided 证据状态属于实质性歧义：即使用户直接要求创建单个 PR，也必须在此检查点询问一次。保留现有的发布授权；只等待尚未确定的证据选项。

对于 stacked，同一项批准也仅授权按照已批准的层计划精确重建本地发布历史。它不授权修改产品、重写源分支、增加层或清理无关分支。 如果无法重新核实计划、已批准的 commit、模板/证据状态、堆叠工具的来源或当前仓库状态，则停止。

发布

获得批准后，重新核实仓库、账户、源分支、HEAD、基准分支、现有 PR、模板来源以及任何堆叠分支命名冲突。 如果现有 PR 的实际状态与已批准的计划存在实质性差异，则撤销批准。 如果存在任何实质性偏差，则撤销批准。

在单独的工具调用中执行远程状态更改（push、创建/更新 PR、gh pr ready、gh pr edit），不得与本地清理放在同一个工具调用中。单独记录并重新核实远程结果，以免清理操作遭拒时阻碍或掩盖发布结果。

对于 single，只推送精确的已批准 refspec，并且只创建或更新指定的 PR。 对于 create，应用已批准的 PR state；对于 update，仅在明确获批时更改状态。

对于 stacked，遵循回溯式堆叠拆分。保留源分支，在其旁边仅重建已批准的层，验证每一层及最终树不变式，然后使用已验证的 github/gh-stack 提交精确的链。每个新建层均使用已批准的状态，并在提交后将自动生成的 PR 元数据编辑为精确的已批准标题/正文。

不得执行 merge、close、tag、release，不得删除保留的源分支，也不得清理无关引用。

创建或更新发布后，重新读取远程状态。对于 single，验证其 URL、head SHA、实际的 draft | ready 状态、模板合规性和证据状态。对于 stacked，使用机器可读的堆叠状态，并重新读取每个 PR 的 URL、head/base 关系、状态、精确标题/正文、模板合规性和证据状态。 如果需要证据，或明确选择了上传证据，则在所属 PR 创建后使用图片上传器。 如果已创建任何 PR，但所需元数据/证据或所选图片发布失败，则保留实际远程状态，并将完成情况报告为 Blocked，不得隐瞒部分发布。

完成

只展示对用户重要的结果。

• PR URL，或从底部到顶部排列的堆叠 PR URL
• 发布是已创建还是已更新
• 当前源分支 head；对于堆叠，显示保留的源分支和堆叠顶端
• 当前 PR state
• 验证/证据结果
• 对于堆叠，堆叠顶端的树是否与原始树相同
• 尚存的阻碍或部分远程状态

不要展示来源信息转储或产品实现记录。

工件路径

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

面向读者的结果摘要

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

输出格式

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

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

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

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

用户问题

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

技能反馈

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