pr-image-upload

name

pr-image-upload

description

Embed a local screenshot or GIF into a `github.com` PR (or issue) body so it actually RENDERS, driven from the CLI — no drag-drop, no committing the file, no image-hosting branch, no release/tag. One `curl` uploads the `/tmp` capture to the tenant's `user-attachments` store using nothing but `gh auth token`, and returns a real `https://github.com/user-attachments/assets/…` URL to drop into the body. Trigger as the embed half of [[create-pr]] Step 6 (after [[web-preview]] captures the visual), when a reviewer comment on a PR asks for a "live walkthrough"/screenshot during [[review-pr]], or any time you have a `/tmp` image that must appear in a PR/issue body or comment. Capture lives in [[web-preview]] — a walkthrough defaults to a GIF of the real interaction (§5), a still (§3) only for a genuinely static change; this skill only hosts + embeds it.

Embedding screenshots in a PR body from the CLI

An <img src="/tmp/…"> in a gh-created body renders broken (the host resolves it to https://github.com/tmp/… → 404), and the clean hosting options are all off the table per CLAUDE.md: don't commit the capture to the tree, don't push an image-hosting branch, don't cut a release/tag just to host a PNG.

The path that satisfies all of that is the tenant's own user-attachments store, reached with a single authenticated request. It needs an OAuth token with push access to the target repository — exactly what gh auth token returns.

Do not reach for the gh-image extension

drogers0/gh-image is a dead end on this host and no amount of flags fixes it. It hardcodes github.com throughout — its own error string is no github.com user_session cookie found in any supported browser — and it has no host override. Its whole purpose is to replay a 3-step browser-cookie upload flow, which the token route below skips entirely. Symptoms, if someone tries anyway: