tk-github-image-upload-to-pr

GitHub PR 图片上传

处理针对现有 GitHub PR 的明确本地图片证据请求，或包含 evidence_required: true 的精确 tk-pr-open 通用清单交接。只有父级交接会自动触发。 需要选择路线或进行安装前确认时，优先使用宿主的原生结构化提问界面（Claude Code：AskUserQuestion；Codex：request_user_input；Hermes：clarify）。若不可用，则在普通聊天中询问相同选项，并在选择完成前不要进行任何更改。

范围

处理一次有明确边界的上传：验证并暂存本地图片，上传仓库范围内的 GitHub 附件，以最小改动更新 PR 正文或选定评论，并验证源内容和渲染结果。默认目标为 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 回退。仓库可见性不是路线选择依据，且可能已创建远程状态的路线不能静默回退到另一条路线。
4. 如果选定路线需要人工执行仅限宿主的操作，则向 tk-wizard 提交范围明确的交接，并在收到完成信号前不要上传。经 Agent 批准的扩展安装仍由此处处理。向导完成后，继续使用完全相同的仓库、目标、图片集和路线。
5. 仅通过 GitHub API 或等效方式更新所请求的正文或评论。在标记为 Pass 前，验证源 Markdown、渲染后的 HTML/页面证据、每个资源链接以及上传引用。
6. 在所有退出路径中，只删除自己创建的暂存文件。

执行回执 · 单一证据记录

在下方的单一回执中记录每次上传尝试。它不是单独的生命周期输出，而是用于 ## GitHub image 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: <source body/comment | rendered HTML/page | 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，且 criterion、证据类型、比较结果和限制均非空。
• 每个工件都有 role、非空 image、绝对路径、由本次运行拥有的证据目录、状态／区域和视口。
• 每张图片都标记为 inspected: true，并且具有精确且不含来源的 display_route，或明确说明安全省略的限制。切勿重建或掩盖缺失的路由。
• visual-preservation 同时包含来自已验证配对的基线工件和之后的工件。

拒绝任意截图、缺失路径、非 Pass 结果、未经检查的工件、不完整的保留配对，以及未关联当前运行的工件。若所需证据缺失或无效，则在上传前返回 Blocked。

禁止事项

• 除非用户明确选择了评论目标，否则不得创建或合并 PR、更改审核者、发布版本或插入评论。
• 不得绕过 tk-browser-verify，也不得使用 Orca 或屏幕控制作为自动浏览器备用方案。
• 不得覆盖已有草稿，也不得点击评论、附带评论关闭或其他任何提交按钮。
• 不得根据公开／私有可见性选择路由，也不得仅凭占位符、Markdown 是否存在、固定延迟或尚未渲染的 API 响应声称成功。
• 不得记录或返回签名 URL、JWT 或包含原始机密的查询字符串。此规定不禁止使用已验证安全且不含来源的 display_route；必须完全保留清单提供的路径、查询和片段。

失败处理

等待缺失扩展或未经审核的上游选择，或等待仅限人工完成的 tk-wizard 完成信号时，返回 Pending。对于来源为 unknown、草稿，或未选择 CDP 路由的安装遭拒，返回 Blocked。如果两个路由都没有身份验证或渲染证据，则返回 Unverifiable；对于上传、远程引用验证或清理错误，返回 Fail。说明所选正文／评论是否已更改，以及是否可能仍有上传引用。

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

结果

终端响应必须以 ## GitHub image upload 开头。适用时，包含 ## Uploaded、## Verification 和 ## Cleanup。以恰好一行状态结尾，且该行必须位于拥有结果的章节末尾：Status: Pass|Fail|Pending|Blocked|Unverifiable。仅在安全时公开资源 URL，并对签名参数进行脱敏。

工件路径

默认将仓库所有的输出放在 .tigerkit/：临时文件放在 tmp/<skill>/<run-id>/，验证证据放在 evidence/<skill>/<run-id>/，说明放在 explanations/，经验总结放在 study/<topic>/。保留现有的所有者专属路径和用户明确选择的最终目标路径。此策略不会授予新的写入权限，也不要求创建任何工件。使用 .tigerkit/ 前，先验证仓库根目录、确认其下没有已跟踪文件，并确认 Git 忽略规则有效覆盖该目录。拒绝符号链接逃逸；保留无关的现有文件。如果路径不安全或无法确定仓库，则停止文件处理分支并返回 Blocked | Unverifiable，不得编辑忽略规则，也不得回退到操作系统临时目录。原子替换可以使用目标文件系统上由本次运行拥有的同级临时文件；成功后清理该文件。外部工具缓存和隔离测试夹具仍按其工具自身的生命周期管理。