★ FEATURED ARTICLE 后端认证鉴权前端【免费下载链接】hexclaveThe user infrastructure platform. You choose the frontend, backend, and database. Hexclave handles everything else.项目地址https://gitcode.com/gh_mirrors/stack/hexclave点击查看免费下载在 Hexclave 仓库的pr-visual-writeup技能中将代码 PR 变成图文并茂的可视化描述是一套完整的工程流程先对本地 dev server 并行截图与录制滚动动画再把这些素材托管到 GitHub gist最后通过gh pr edit写入 PR 描述。本篇文章聚焦其中最关键的一环——只用 PATPersonal Access Token把截图与 GIF 托管到公共 gist并在 PR 正文中以gist.githubusercontent.com/.../raw/file形式内联渲染完整覆盖创建、克隆、推送、URL 清单、校验、更新与清理的全流程。读完本文你将掌握一套不触碰浏览器 Cookie、可重复执行的 PR 可视化素材托管方案并理解它与user-attachments上传路径的本质差异。本篇文章以仓库内技能参考文档 gist-upload.md 为骨架并结合 SKILL.md、upload_gist.sh、convert_clips.sh 等配套脚本进行源码级展开。为什么选 gist 而不是user-attachments把图片拖进 PR 编辑器时GitHub 实际使用的是user-attachments上传端点。这个端点要求浏览器会话 Cookie而不仅仅是 PAT。市面上像gh-image这类工具的做法是抓取 Chrome 的 cookie jar 来冒充浏览器——那个 Cookie 的作用域比 PAT 更宽属于用户敏感凭据未经用户明确同意不应使用。Gist 托管则提供了仅凭 PAT 就能完成的等价方案gh gist create只需要gistscope 的 PAT向 gist 仓库执行git push只需要 PAT配合 credential helper 注入gist.githubusercontent.com/user/id/raw/file形式的 raw URL 可以在 PR 正文中内联渲染为图片和 GIF。代价trade-off在于gist 托管的.webm无法获得 GitHub 的原生视频播放器那是user-attachments独占的特性。因此滚动动画素材需要转换成.gif才能内联播放仓库配套脚本 convert_clips.sh 正是为此设计的。在 Hexclave 的pr-visual-writeup技能中这一原则被明确固化为三条信任边界见 SKILL.md 的 A note on trust boundaries凭据用途使用策略PATgh auth token获取gist 推送、gh pr edit、gh pr diff可放心使用dev server 会话 Cookie登录本地 dashboard仅限本机无碍github.com 浏览器会话 Cookiegh-image等工具提取除非用户显式同意否则不使用整个 gist 托管流程刻意停留在 PAT 区域内这是它作为 PR 可视化流水线托管层的重要安全前提。前置条件在动手之前确认以下条件满足已安装并登录GitHub CLIgh且 PAT 至少拥有gistscope本地有git与ffmpegGIF 转换阶段需要按技能约定在/tmp/pr-N-visuals/下准备好shots/PNG 截图与clips/GIF 滚动动画两个素材目录把your-username、NPR 编号、$GIST_ID替换为实际值。完整操作流程1. 创建公共 gist带占位 README# 1. Create a public gist with a placeholder README. GIST_URL$(gh gist create --public --desc PR #N screenshots scroll clips \ -f README.md - PR #N assets | tail -1) GIST_ID$(basename $GIST_URL) echo $GIST_ID /tmp/pr-N-visuals/gist-id.txt要点--public是必需的——公共 gist 的 raw URL 才能被 GitHub PR 正文内联渲染私有 gist 的 raw URL 需要鉴权无法在他人视角的 PR 页面上正常显示--desc描述建议带上 PR 编号便于日后检索用-f README.md附带一个占位文件保证 gist 非空通过tail -1取出 gist 页 URL再用basename提取GIST_ID并写入gist-id.txt供后续更新复用。2. 本地克隆HTTPS读操作无需凭据# 2. Clone locally (HTTPS, no creds needed for read). cd /tmp rm -rf gist-$GIST_ID git clone https://gist.github.com/$GIST_ID.git gist-$GIST_ID克隆的是 gist 对应的 git 仓库地址gist.github.com/id.git只读拉取走 HTTPS 即可无需认证。克隆前先清理同名的旧目录避免残留冲突。3. 暂存全部素材并提交# 3. Stage every asset. cd gist-$GIST_ID cp /tmp/pr-N-visuals/shots/*.png /tmp/pr-N-visuals/clips/*.gif ./ git add -A git -c user.emailnoreplygithub.com -c user.nameyour-username \ commit -m Add PR N visuals注意 gist 仓库是扁平结构不要建立子目录——所有 PNG 与 GIF 一律放到根目录这样 raw URL 才能直接写成/raw/filename。提交时通过-c临时指定user.email与user.name避免污染全局 git 配置。4. 用 PAT 经 credential helper 推送# 4. Push with PAT via credential helper. gh auth token prints the PAT. TOKEN$(gh auth token) git -c credential.helper \ -c credential.helper!f() { echo usernameyour-username; echo password$TOKEN; }; f \ push这段命令是整套方案的精髓值得拆解credential.helper等号后为空白会清空已配置的 credential helper紧接着用一个内联 shell 函数作为新的 credential helper向 git 提供username与password即 PAT这样 PAT只存在于这一次进程的命令行环境中不会写入~/.gitconfig也不会落入系统的 credential store避免了令牌被持久化落盘。一个值得注意的细节向 gist 仓库推送时GitHub 要求以PAT 作为密码而不是留空这正是自定义 helper 存在的原因。5. 构建 URL 清单推送完成后逐文件生成 raw URLUSERyour-username for f in /tmp/pr-N-visuals/shots/*.png /tmp/pr-N-visuals/clips/*.gif; do base$(basename $f) echo $base https://gist.githubusercontent.com/$USER/$GIST_ID/raw/$base done /tmp/pr-N-visuals/urls.txt这里的关键设计是raw URL 不带 commit SHA裸的/raw/file路径永远解析到最新版本这意味着后续想修正某张截图时只需重新推送到同一 gistPR 正文无需任何改动urls.txt供撰写 PR body 时复制粘贴使用。6. 嵌入前校验 URLcurl -sI -L https://gist.githubusercontent.com/$USER/$GIST_ID/raw/users-light.png | head -3 # Expect: HTTP/2 200 and content-type: image/png (or image/gif)用curl -sI -L发起 HEAD 请求并跟随重定向确认返回HTTP/2 200且content-type为image/png或image/gif。每种素材类型抽查一个即可——gist 的 raw 服务行为是一致的不需要逐个验证。文件大小与画质控制gist 存在明确的体积约束需要在上游素材处理阶段就控制好单文件 10 MB 上限总量控制在 10 MB 左右是合理水位如果截图矩阵很大多页面 × 多主题 × 多视口应下调截图质量或缩小页面矩阵GIF 膨胀非常快推荐目标为单条 100–400 KB通过三组参数约束fps8、scale960、片长控制在 5 秒以内。仓库配套脚本 convert_clips.sh 正是按这些参数实现的ffmpeg -y -i $f \ -vf fps8,scale960:-1:flagslanczos,split[s0][s1];[s0]palettegen[p];[s1][p]paletteuse \ $out /dev/null 21其中split palettegen paletteuse是经典的两步式 GIF 调色板优化在 8fps、960px 宽的组合下既保证播放流畅又能把体积压到 400 KB 以内。脚本会并行处理目录下所有.webm并在完成后打印每个产物的实际体积du -h。后续更新 gist若需要补充截图或修正某一张cd /tmp/gist-$(cat /tmp/pr-N-visuals/gist-id.txt) cp new-file.png ./ git add -A git -c user.email... -c user.name... commit -m Update git -c credential.helper!f() { echo username...; echo password$(gh auth token); }; f push已存在的/raw/fileURL继续有效并自动指向最新版本新增文件会获得新的 URL复用之前保存的gist-id.txt无需重新走创建流程。清理与生命周期gist 在显式删除之前会一直存在。若 PR 合并后用户希望删除gh gist delete $GIST_ID但必须向用户预警删除 gist 会同时破坏 PR 正文里的所有图片链接所有内联图片都会变成死链。所以默认建议保留——这些素材是 PR 历史的一部分日后回看时依然可读。仓库配套脚本把流程脚本化参考文档给出的是手工逐条执行的完整配方Hexclave 仓库进一步把它封装成了可直接调用的脚本 upload_gist.sh用法如下upload_gist.sh PR #1338 visuals /tmp/pr-1338-visuals/shots /tmp/pr-1338-visuals/clips脚本内部按set -euo pipefail严格模式执行核心逻辑与手工配方一一对应通过gh api user --jq .login自动取用户名gh auth token取 PATgh gist create --public --desc $DESC -f README.md创建 gist 并解析出GIST_ID用mktemp -d建临时目录并克隆trap ... EXIT保证退出时清理不递归、只拷贝顶层文件for f in $d/*保持 gist 扁平结构拷贝前[ -f $f ] || continue跳过非文件条目单次提交git add -Acommit然后执行与手工配方完全相同的 credential-helper 推送把GIST_ID写入./gist-id.txt逐文件输出basename\traw-url供复制。对比可见脚本就是把参考文档的配方参数化描述 目录列表并额外做了空目录/缺失目录的防御校验如无文件则报错退出no files found in input directories。gist-id.txt落在调用目录方便后续更新时读取。在 pr-visual-writeup 技能中的位置从技能整体链路SKILL.md看gist 上传是六阶段流水线的Phase 4——UploadScope确定 PR、路由、dev server、鉴权方式与新增 UI 选择器Capture并行按 页面 × 主题 × 视口 捕获 after 截图新 UI 打红框再切到 base 分支捕获 before 基线Process并行convert_clips.sh把滚动视频.webm批量转成可内联播放的.gifUpload一个 gist、一次 commit、全部文件输出 raw URL 清单Compose set按 pr-body-template.md 组织 before/after 表格gh pr edit N --body-file md写入 PR 描述Restoregit checkout orig-branchgit stash pop恢复用户工作树。gist 托管与撰写模板之间有几条强约束需要联动遵守见 pr-body-template.md不要混用托管源一部分图片走user-attachments、一部分走 gist会让评审者困惑选定一条路径并贯彻到底不要用 HTMLvideo或details嵌视频GitHub 会净化这些标签除非视频托管在user-attachments应使用 gist 上的 GIF以图片形式渲染alt 文本用基础文件名如users-after-light即使 gist 日后被删除评审者也能从 broken-image 的 alt 中分辨 before/after 单元格。常见问题与注意事项gh gist create需要什么 scope仅gistscope这是最小授权面gh auth token打印的 PAT 可直接用作推送密码。为什么不让 PAT 进 gitconfig通过credential.helper置空 内联 helper 的组合令牌只活在单次命令进程里不落盘、不进凭据库降低泄露面。为什么 raw URL 不带 SHA裸/raw/file恒指向最新版后续修图只需重新推送PR 正文零改动。GIF 还是太大怎么办从fps8、scale960与片长 5s三个方向同时压缩若截图总量逼近 10 MB应削减页面矩阵或降低分辨率而不是试图压单张。私有 gist 可以吗不可以直接用于 PR 正文内联展示——未登录/非成员访问私有 gist raw URL 会鉴权失败必须使用公共 gist。以上便是 Hexclave 仓库pr-visual-writeup技能中基于 Gist 与 PAT 的 PR 截图/GIF 托管完整方案它用最小的凭据授权面仅 PAT完成了user-attachments浏览器 Cookie 才能做到的事情并且从创建、推送、校验到更新、清理都有清晰的、可脚本化的操作路径。赞分享后端认证鉴权前端【免费下载链接】hexclaveThe user infrastructure platform. You choose the frontend, backend, and database. Hexclave handles everything else.项目地址https://gitcode.com/gh_mirrors/stack/hexclave点击查看免费下载相关推荐oh-my-openagent 的 GitHub PR 附件上传规范基于 Web Attachment Flow 的临时证据图片托管方案oh my openagent 的 GitHub PR 附件上传规范基于 Web Attachment Flow 的临时证据图片托管方案 本文是 oh my人工智能AI Agent代码智能体多智能体MCP ClientsAgent 编排从HandyJSON迁移到SmartCodable无缝过渡的完整指南从HandyJSON迁移到SmartCodable无缝过渡的完整指南 SmartCodable是基于Swift Codable的数据解析库主打简单易用与真实Opengist终极自托管Git驱动Pastebin解决方案完全替代GitHub GistOpengist终极自托管Git驱动Pastebin解决方案完全替代GitHub Gist 想要一个完全掌控在自己手中的代码片段分享平台吗Openg后端上一篇End-To-End快速入门简单实现数字签名和验证下一篇OpenVoice语音克隆实战如何用30秒音频复制任何人声音创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
阅读完成 · 觉得有帮助？
