tk-pr-media

GitHub PR 媒体上传

处理针对现有 GitHub PR 的明确本地图片/视频证据请求，或包含 evidence_required: true 的精确 tk-pr-open 通用清单交接。只有父级交接会自动触发。

可选动态补充材料

对于选定的 MP4，请阅读 原生视频附件；该文档负责不同的视频上传、字节和播放器检查，而不是仅针对图片的扩展步骤。有效的可选补充材料需包含媒体类型、归本次运行所有的路径、标准/标题、时长/视口、已检查的帧和采样警告；绝不要要求它冒充必需的图片清单。仅当 publication_selected: true，或用户明确选中了该特定素材/目标时，才上传该素材。

对于选定的 GIF 帧序列，请使用带有 --gif 的已审核扩展、明确的 .gif 名称，以及与帧序列匹配的延迟时间。在 v0.7.0 中，不带 --json 并单独捕获 stderr。保留所有帧数上限/缩减/超限警告，验证实际图片/GIF 字节和多个解码后的帧；若声称可以播放，则检查动画。5MiB 目标不是硬性限制；应说明超限情况和时间调整。现有的必需截图对保持不变。

范围

处理一次有明确边界的上传：验证并暂存本地图片，上传仓库范围内的 GitHub 附件，以最小改动更新 PR 正文或选定的评论，并验证源 Markdown 和已上传的图片对象。默认目标为 PR 正文。

对于 tk-pr-open，验证与生成方无关的证据字段，绝不要根据生成技能名称进行分支处理、将其列入白名单或要求提供该名称。如果缺少必需证据或证据无效，请将证据交接标记为 Blocked；不要撤销已经创建的 tk-pr-open PR。

使用 references/gh-attach.md 对扩展路线进行分类并执行。仅在选定 CDP 后，或扩展路线无法使用目标写入能力时，才阅读 references/cdp-fallback.md。仅在需要精确的人为主机设置、身份验证、权限或重启步骤时，才调用 tk-wizard；交接期间保留本技能的上传目标和路线。使用 tk-browser-verify 进行浏览器控制的运行时验证。

🔴 检查点 · 🛑 停止 · 上传变更边界

在进行任何上传或更新 PR 正文/评论之前，重新验证明确选定的目标、有效的本地证据或生成方交接、已认证的路线以及请求的写入范围；如果无法确认这些前提条件，请停止并标记为 Blocked 或 Unverifiable。

工作流

1. 从常规本地图像文件或有效的产出方证据交接中确认 origin、当前 PR 和正在执行操作的仓库。读取现有 PR 正文。
2. 沿用现有的 ## 스크린샷 标题。若不存在，则在 AI 页脚之前插入该标题，或将其附加到末尾。保留无关的正文内容。对于清单中的产物，在说明文字中使用提供的判定标准、角色、准确的 display_route、状态／区域、视口和对比结果；切勿从文件名、OCR、原始 URL 或产出方身份推断这些信息。将 visual-preservation 的基线和之后状态明确标注为一组。对于每一组，无论是否有清单，都要添加一个标题，注明已验证的路由／屏幕；一句描述预期行为的话；诸如 수정 전／수정 후 的角色表头；一行图片；以及其下方一行说明文字，描述每张图片中的观察结果。保留提供的证据；若缺少路由／屏幕证据，应明确说明，不得捏造。暂存文件名不能充当表头、说明文字或充分的描述。
3. 使用 gh-attach 选择并执行符合条件的路由，只有在选择 CDP 后才阅读 CDP fallback。仓库的可见性不是路由选择依据；如果某路由可能已创建远程状态，则不得悄然回退到另一条路由。
4. 当所选路由需要仅限人工执行的主机操作时，将范围明确的交接传给 tk-wizard，并在收到其完成信号前不得上传。经 Agent 批准并审核过的扩展程序安装仍由此处处理。向导完成后，使用完全相同的仓库、目标、图像集和路由继续操作。
5. 仅通过 GitHub API 或等效方式更新请求修改的正文或评论。在标记为 Pass 前，重新读取目标并验证：每个生成的图片标记都按字节原样且仅出现一次；图片组的角色／说明文字仍正确对应；通过经过身份验证的获取方式取得的每个资源都包含可解码的 image/* 字节；并且从上传引用可访问每个已链接的上传对象。可选择检查浏览器会话中的渲染效果；在回执中说明是否已检查，但不得将其作为标记为 Pass 的前置条件。
6. 无论通过哪条退出路径，都只删除自己拥有的暂存文件。每项删除操作都必须使用本次运行中已记录的、完整解析后的绝对暂存路径字面值；不得通过命令替换、读回路径文件，或将通配符结果传给 head 或 tail 来推导目标。如果不知道准确的字面路径，则列出候选项并停止。

执行回执 · 唯一证据记录

在下方的唯一回执中记录每次上传尝试。它不是单独的生命周期输出，而是用于 ## GitHub media upload 结果及审批／验证决策的唯一证据记录。对于缺失的值，使用 none 或 unavailable；切勿猜测。

Repository: <owner>/<repo>
PR / Target: <pr-number> / body | existing comment <comment-id>
Source images: <absolute path list>
Route: gh-attach | CDP
Entry: <exact reviewed command | browser route>
Generated Markdown: <asset refs | none>
Remote ref: <refs/uploads/issues/<pr-number> | none | unknown>
Verification: image-token byte match and single occurrence: <Pass | Fail | unavailable>; image bytes/type: <Pass | Fail | unavailable>; upload ref reachability: <Pass | Fail | unavailable>; rendering: <checked | not performed | unavailable>
Changed: <body/comment changed | unchanged | unknown>
Cleanup: <owned staging path removed | failed | not applicable>
Status: Pass | Fail | Pending | Blocked | Unverifiable

证据清单交接

当 evidence_required: true 时，必须满足以下所有条件：

• verification_status: Pass，且判定标准、证据类型、对比结果和限制说明均非空。
• 每个产物都包含角色、非空的图像、绝对路径、由本次运行拥有的证据目录、状态／区域和视口。
• 每张图像都标记为 inspected: true，并且包含准确且不含来源信息的 display_route，或明确说明安全省略该信息的限制。切勿重建或遮蔽缺失的路由。
• visual-preservation 必须包含来自已验证图像组的一份基线产物和一份之后状态产物。

拒绝随意提供的屏幕截图、缺失路径、非 Pass 结果、未经检查的产物、不完整的保留配对，以及未关联到本次运行的产物。如果所需证据缺失或无效，则在上传前返回 Blocked。

禁止事项

• 除非用户明确选择了评论目标，否则不要创建或合并 PR、变更审阅者、发布版本或插入评论。
• 不要绕过 tk-browser-verify，也不要将 Orca 或屏幕控制用作自动浏览器回退方案。
• 不要覆盖已有草稿，也不要点击评论、带评论关闭或任何其他提交按钮。
• 不要根据公开/私有可见性选择操作路径，也不要仅凭占位符、存在 Markdown、固定延迟或未经渲染的 API 响应声称操作成功。
• 不要记录或返回签名 URL、JWT 或含原始密钥的查询字符串。此限制不适用于经过验证、无来源信息的 display_route；请严格保留清单提供的路径名、查询和片段。
• 仅对含密钥的值（签名参数、JWT、令牌）进行脱敏；保留 raw=true 等渲染参数。生成的每个图像 Markdown 标记都必须逐字节保持不变，包括其替代文本、URL 和渲染参数；可重新排列表格布局，并将说明文字置于图像下方。绝不要根据脱敏或概述后的输出重新构建链接。不要将含密钥的原始内容复制到日志、回执或证据文件中。

失败处理

等待缺少扩展或未经审查的上游选择，或等待仅限人工完成的 tk-wizard 完成信号时，返回 Pending。如果来源为 unknown、存在草稿，或在未选择 CDP 路径的情况下安装被拒绝，则返回 Blocked。如果无法验证身份验证、图像字节校验或上传引用的可访问性，则返回 Unverifiable；渲染页面证据为可选项。上传、远程引用验证或清理出错时，返回 Fail。说明所选正文/评论是否发生变更，以及上传引用是否可能仍然存在。

对于 tk-pr-open，保留单独的 PR 操作结果，并将证据状态返回为 uploaded 或 blocked。所需证据仍被阻止时，父级不得声称已全部完成。

结果

终端响应以 ## GitHub media upload 开始。适用时，包含 ## Uploaded、## Verification 和 ## Cleanup。结果所属章节以且仅以一行状态结尾：Status: Pass|Fail|Pending|Blocked|Unverifiable。仅在安全时公开资源 URL，并对签名参数进行脱敏。

工件路径

工件操作需要任务授权。在写入/检出/传输/设置忽略规则之前，请阅读工件路径，检查 Git 排除规则、路径和所有权。复用上下文中内容完全相同的文件；对不确定内容进行哈希校验，并在发生变更/丢失时重新读取；始终重新检查安全性。除非明确指定目标位置，否则使用 .tigerkit/。仅聊天：跳过文件/忽略规则设置和此参考文件。此授权不包括无关的变更/发布权限。优先使用全新目录；经授权进行非机密清理时，优先使用受支持的移至废纸篓方式；目标只能是已记录、解析后的绝对路径且由本次运行拥有，绝不可结合 cd 使用通配符或相对路径删除。

面向读者的结果摘要

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

输出格式

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

对于包含多个共同属性的聊天对比，使用窄版 GFM 管道表格（约四列，含表头，单元格简短）；其他情况使用列表。不要使用框线字符、围栏代码块或空表格。优先采用所有者专属的预览格式；发布正文和文件产物保留各自的表格格式。

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

对于获准使用的临时输入文件，创建和读取前遵循 Artifact Paths；预填模板不算已完成的输入。这不授予任何写入权限。

用户问题

调查事实；重复使用已有授权。对于由用户决定的事项，阅读 问题轮次；其他情况直接继续。 纯聊天中，即使只有一个审批事项，也应先单独输出 ---，然后每项按以下格式呈现： ❓ **Q<n> · <title>**: <question> 和 ➡️ <recommendation>。 只询问已确定为前置条件的问题；审批另行处理。 问题放在最后；先说明状态、风险和计划。

技能反馈

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