Support uploading non-image files (PDF, zip, etc.) (#24)

* Support uploading non-image files (PDF, zip, etc.)

GitHub's internal attachment endpoint already accepts non-image files; it
routes them to a separate storage backend that finalizes at a different path.
Use the policy response's asset_upload_url for the finalize PUT instead of the
hardcoded /upload/assets/{id} (which 404'd "Invalid Asset" for files), and
render a download link [name](url) for non-images vs the image embed ![name](url).

- upload: finalize via policy.asset_upload_url (required + root-relative); add
  renderMarkdown branching on the image/ content-type prefix
- generalize "image" -> "file" in CLI help, identifiers, and docs (the gh image
  command and gh-image repo name are unchanged)
- tests: non-image full-flow finalize routing, renderMarkdown table, asset_upload_url
  validation, and .pdf content-type detection

Closes #23

* Fix content_type for text uploads (charset param) and .log

GitHub's /upload/policies/assets validates content_type against an
allowlist and against the file extension, rejecting mismatches with 422.
detectContentType sent Go's mime.TypeByExtension result verbatim, which
broke two cases:

- Text types (.txt, .md, .csv, .log) resolve to e.g. "text/plain;
  charset=utf-8"; GitHub's allowlist only accepts the bare media type,
  so every text upload failed. Strip parameters via mime.ParseMediaType.
- .log resolves to text/plain, but GitHub's extension table expects
  text/x-log and 422s on ".log != text/plain". Add a small override
  map for extensions where GitHub disagrees with Go's mime table.

Verified end-to-end against real GitHub: .log, .txt, .md, .csv, .json,
.pdf, .zip, .mp4 all upload. Updated TestDetectContentType to assert
parameter stripping and the .log override (incl. case-insensitivity).

* Render videos as inline players via bare asset URL

GitHub renders a user-attachments video asset as an inline <video> player
when its URL appears on its own line; link or embed syntax only produces a
link. renderMarkdown now emits the bare URL for video/* content types
(images still embed, other files still link). Confirmed end-to-end: the
rendered comment HTML for an uploaded .mp4 is a <video controls> element.

Updates TestRenderMarkdown (video/mp4, video/quicktime) and the README/
SKILL output descriptions.

* Render from GitHub's asset content_type, not the local guess

The render form (image embed / video player / download link) was decided
from the locally-detected content type threaded through Upload ->
finalizeUpload -> renderMarkdown. The policy response already carries the
content type GitHub assigned the asset, which is the exact signal GitHub's
renderer uses, so finalizeUpload now reads policy.Asset.ContentType
directly. This drops the threaded parameter and guarantees the output form
matches how GitHub actually displays the asset (e.g. an SVG GitHub treats
as a file renders as a link, not a broken embed).

requestPolicy now validates asset.content_type is present, since the
render decision depends on it. detectContentType is unchanged -- it still
supplies the content_type the policy request and S3 upload must send.

* Clarify finalize render-decision comment (asset content_type is our echo)

* Update banner: 'Upload files to GitHub' (covers non-image uploads)

Author: drogers0

README.md

@@ -1,9 +1,9 @@
 <p align="center">
-  <img src="https://github.com/user-attachments/assets/92463e67-b897-4212-91b4-a4f9b80ec4d4" alt="gh-image banner" width="640">
+  <img src="https://github.com/user-attachments/assets/d3455b90-f94f-4013-a00a-ebaff090635e" alt="gh-image banner" width="640">
 </p>
 
 <p align="center">
-  <em>Drop images into GitHub issues, PRs, and READMEs, straight from the command line.</em>
+  <em>Drop images and files into GitHub issues, PRs, and READMEs, straight from the command line.</em>
 </p>
 
 <p align="center">
@@ -17,11 +17,14 @@
 
 ---
 
-GitHub has no public API for image uploads. The web UI uses an internal endpoint that produces `user-attachments` URLs whose visibility is scoped to the repository they were uploaded to. `gh-image` replicates that flow as a `gh` CLI extension, so you can drop a screenshot into a bug report, README, or Slack thread without leaving the terminal — and images on private repos stay private.
+GitHub has no public API for the attachment uploads its web UI accepts via drag-and-drop. That internal endpoint produces `user-attachments` URLs whose visibility is scoped to the repository they were uploaded to. `gh-image` replicates that flow as a `gh` CLI extension, so you can drop a screenshot — or any GitHub-supported file like a PDF, zip, or log — into a bug report, README, or Slack thread without leaving the terminal, and uploads on private repos stay private. Images render as inline embeds, videos as inline players, and other files as download links.
 
 ```console
 $ gh image screenshot.png
 ![screenshot.png](https://github.com/user-attachments/assets/88f4599a-…-bc24)
+
+$ gh image report.pdf
+[report.pdf](https://github.com/user-attachments/files/123456/report.pdf)
 ```
 
 ## Installation
@@ -52,21 +55,25 @@ Requires Go 1.26+.
 # Upload an image (infers repo from the current git workspace)
 gh image screenshot.png
 
-# Upload multiple images at once
+# Upload multiple files at once (images or anything GitHub accepts)
 gh image hero.png diagram.png chart.png
 
+# Upload any GitHub-supported file (PDF, zip, log, …) — renders as a download link
+gh image report.pdf
+
 # Target a specific repository
 gh image screenshot.png --repo owner/repo
 ```
 
-Each successful upload prints a ready-to-paste markdown reference on its own line:
+Each successful upload prints a ready-to-paste reference on its own line — an inline embed for images, a bare URL for videos (which GitHub renders as an inline player), and a download link for other files:
 
 ```
 ![hero.png](https://github.com/user-attachments/assets/…)
-![diagram.png](https://github.com/user-attachments/assets/…)
+https://github.com/user-attachments/assets/…
+[report.pdf](https://github.com/user-attachments/files/…/report.pdf)
 ```
 
-If any upload fails, the error is printed to stderr and the process exits non-zero — other images in the batch still upload.
+If any upload fails, the error is printed to stderr and the process exits non-zero — other files in the batch still upload.
 
 ### Pipe directly into an issue, PR, or comment
 
@@ -84,7 +91,7 @@ Happens consistently after the third click."
 
 ## Use with AI agents
 
-`gh-image` is packaged as an [agent skill](https://agentskills.io), so AI coding agents can upload and embed images for you — just ask in natural language, e.g. *"attach this screenshot to the PR"* or *"file an issue and add this image."*
+`gh-image` is packaged as an [agent skill](https://agentskills.io), so AI coding agents can upload and embed images or attach files for you — just ask in natural language, e.g. *"attach this screenshot to the PR"* or *"file an issue and attach this log."*
 
 ```bash
 npx skills add drogers0/gh-image
@@ -165,10 +172,10 @@ jobs:
 2. Fetches the target repository's page to obtain an `uploadToken` from the embedded JS payload.
 3. Requests an S3 upload policy from `/upload/policies/assets`.
 4. Uploads the file directly to S3 using the presigned form fields.
-5. Calls back to GitHub to finalize the asset.
-6. Prints `![name](url)` to stdout.
+5. Calls back to GitHub to finalize the asset, using the finalize endpoint GitHub returns in the policy (`/upload/assets/{id}` for images, `/upload/repository-files/{id}` for other files).
+6. Prints the reference to stdout: `![name](url)` for images, the bare URL for videos (GitHub renders it as an inline player), or `[name](url)` for other files.
 
-The final URL is the standard `https://github.com/user-attachments/assets/<uuid>` format — visibility inherits from the target repository, so a private-repo upload requires authentication to view.
+The final URL is `https://github.com/user-attachments/assets/<uuid>` for images and `https://github.com/user-attachments/files/<id>/<name>` for other files — visibility inherits from the target repository, so a private-repo upload requires authentication to view.
 
 For the full architecture, see **[documentation/architecture.md](documentation/architecture.md)**. For the reverse-engineered upload protocol, see **[documentation/github-image-upload-flow.md](documentation/github-image-upload-flow.md)**.
 

banner.png

@@ -2,7 +2,7 @@
 
 ## Overview
 
-`gh-image` is a Go CLI tool distributed as a `gh` extension. It uploads images to GitHub using the same internal API that the web UI uses when you drag-and-drop or paste an image. The tool resolves a GitHub session (from a flag, env var, or browser cookie store), negotiates upload tokens, performs an S3 presigned upload, then prints the resulting markdown image reference to stdout.
+`gh-image` is a Go CLI tool distributed as a `gh` extension. It uploads files — images and other GitHub-supported attachments like PDFs and zips — to GitHub using the same internal API that the web UI uses when you drag-and-drop or paste an attachment. The tool resolves a GitHub session (from a flag, env var, or browser cookie store), negotiates upload tokens, performs an S3 presigned upload, then prints the resulting markdown reference to stdout (an image embed for images, a download link for other files).
 
 ## Project Structure
 
@@ -43,12 +43,12 @@ gh-image/
 ## CLI Surface
 
 ```
-gh image [--repo owner/repo] [--token <value>] <image-path>...
+gh image [--repo owner/repo] [--token <value>] <file-path>...
 gh image extract-token
 gh image check-token [--token <value>]
 ```
 
-- **Default mode** uploads one or more image files and prints markdown references to stdout. Flags may appear before or after positional args; use `--` to pass filenames that begin with `-`.
+- **Default mode** uploads one or more files and prints markdown references to stdout. Flags may appear before or after positional args; use `--` to pass filenames that begin with `-`.
 - **`extract-token`** reads the session cookie from the browser and prints the raw token value to stdout (status info to stderr). Useful for piping into CI secrets.
 - **`check-token`** resolves a token using the standard precedence (flag → env → browser) and verifies it against GitHub, printing the authenticated username on success.
 
@@ -148,9 +148,9 @@ HTTP client plus a `baseURL` (production `https://github.com`); tests point
 // production base URL.
 func NewClient(sessionCookie *http.Cookie) *Client
 
-// Upload uploads an image file to GitHub and returns the asset URL,
+// Upload uploads a file to GitHub and returns the asset URL,
 // sanitized filename, and a ready-to-paste markdown reference.
-func (c *Client) Upload(owner, repo string, repoID int, imagePath string) (*Result, error)
+func (c *Client) Upload(owner, repo string, repoID int, path string) (*Result, error)
 ```
 
 #### Token Retrieval (`token.go`)
@@ -165,7 +165,7 @@ func (c *Client) getUploadToken(owner, repo string) (string, error)
 
 #### Upload Orchestration (`upload.go`)
 
-Coordinates the full flow for a single image:
+Coordinates the full flow for a single file:
 
 ```
 Get upload token
@@ -179,7 +179,9 @@ uploadToS3()           ──→  POST {s3_upload_url}
         │                    Multipart form with presigned fields + file
         │                    No GitHub auth needed
         ▼
-finalizeUpload()       ──→  PUT /upload/assets/{asset_id}
+finalizeUpload()       ──→  PUT {asset_upload_url}
+        │                    Path from policy: /upload/assets/{id} (images)
+        │                    or /upload/repository-files/{id} (other files)
         │                    Uses asset_upload_authenticity_token from step 1
         ▼
     Returns asset href URL
@@ -210,7 +212,7 @@ Responsibilities:
 - **Manual arg parsing** so that flags can appear before or after positional args, with `--` as an explicit terminator for filenames starting with a dash.
 - **Subcommand dispatch** for `extract-token` and `check-token`, with validation that disallowed flag combinations are rejected before any work is done.
 - **Session resolution** via `resolveSessionCookie`, which applies the flag → env → browser precedence and wraps raw token values into a properly scoped `*http.Cookie`.
-- **Multi-image upload loop**: each positional path is uploaded independently. A failure on one image is reported to stderr and the loop continues; the process exits non-zero if any upload failed.
+- **Multi-file upload loop**: each positional path is uploaded independently. A failure on one file is reported to stderr and the loop continues; the process exits non-zero if any upload failed.
 
 ## Data Flow
 
@@ -221,12 +223,12 @@ flowchart TD
 
     Start --> Session
 
-    subgraph PerImage ["For each image"]
+    subgraph PerImage ["For each file"]
         direction TB
         Token["<b>Fetch uploadToken</b><br/>GET /:owner/:repo"]
         Policy["<b>Request Policy</b><br/>POST /upload/policies/assets"]
         S3["<b>Upload to S3</b><br/>POST policy.upload_url<br/><i>(no GitHub auth)</i>"]
-        Finalize["<b>Finalize</b><br/>PUT /upload/assets/:id"]
+        Finalize["<b>Finalize</b><br/>PUT {asset_upload_url}"]
         Print["<b>Print markdown</b><br/>to stdout"]
 
         Token -- "uploadToken" --> Policy
@@ -296,4 +298,4 @@ git push --tags
 ## Future Considerations
 
 - **Clipboard image support:** Accept image data from clipboard (`gh image paste --repo o/r`) instead of requiring a file path.
-- **Token caching:** The `uploadToken` could be cached briefly to avoid fetching the repo page on every upload within a multi-image batch. The presigned S3 policy expires in ~30 minutes, so reuse is safe within that window.
+- **Token caching:** The `uploadToken` could be cached briefly to avoid fetching the repo page on every upload within a multi-file batch. The presigned S3 policy expires in ~30 minutes, so reuse is safe within that window.

documentation/architecture.md

@@ -2,9 +2,9 @@
 
 ## Overview
 
-GitHub does not provide a public API for uploading images to issues/PRs. The web UI uses an internal 3-step flow involving GitHub's servers and S3. This document describes exactly how that flow works, reverse-engineered from HAR captures.
+GitHub does not provide a public API for uploading attachments (images or files like PDFs and zips) to issues/PRs. The web UI uses an internal 3-step flow involving GitHub's servers and S3. This document describes exactly how that flow works, reverse-engineered from HAR captures. The flow is identical for images and other files; only the finalize path and the resulting URL/markdown differ (noted in Step 3 and Final Result).
 
-Images uploaded this way are scoped to the repository's visibility — private repo images require authentication to view (unlike GitHub Release assets, which are always public on public repos).
+Attachments uploaded this way are scoped to the repository's visibility — private repo uploads require authentication to view (unlike GitHub Release assets, which are always public on public repos).
 
 ## Prerequisites
 
@@ -92,7 +92,7 @@ This token serves as the `authenticity_token` for the upload policy request (Ste
 ```
 
 **Key fields in response:**
-- `asset.href` — The final URL where the image will be served
+- `asset.href` — The final URL where the attachment will be served
 - `asset.id` — Used in the finalize step
 - `form` — All fields needed for the S3 upload (presigned)
 - `upload_url` — The S3 endpoint to POST to
@@ -131,9 +131,12 @@ This token serves as the `authenticity_token` for the upload policy request (Ste
 
 ### Step 3: Finalize the Upload
 
-**Request:** `PUT https://github.com/upload/assets/{asset_id}`
+**Request:** `PUT https://github.com{asset_upload_url}`
 
-Where `{asset_id}` is `asset.id` from the Step 1 response.
+Where `asset_upload_url` is taken verbatim from the Step 1 response. GitHub routes the
+finalize to a different path per file type: `/upload/assets/{id}` for images and
+`/upload/repository-files/{id}` for other files (PDF, zip, …). Use the server-provided
+path rather than hardcoding one.
 
 **Content-Type:** `multipart/form-data`
 
@@ -163,14 +166,17 @@ Where `{asset_id}` is `asset.id` from the Step 1 response.
 
 ## Final Result
 
-The `href` value is the permanent image URL:
+The `href` value is the permanent attachment URL. Its shape depends on the file type:
 ```
-https://github.com/user-attachments/assets/{uuid}
+https://github.com/user-attachments/assets/{uuid}        # images
+https://github.com/user-attachments/files/{id}/{name}    # other files (PDF, zip, …)
 ```
 
-This can be embedded in any GitHub markdown (PR descriptions, issue bodies, comments) as:
+It can be referenced in any GitHub markdown (PR descriptions, issue bodies, comments). Images
+embed inline; other files render as a download link:
 ```markdown
 ![alt text](https://github.com/user-attachments/assets/{uuid})
+[report.pdf](https://github.com/user-attachments/files/{id}/report.pdf)
 ```
 
 ## Authentication Summary
@@ -197,7 +203,7 @@ POST /upload/policies/assets  (authenticity_token = uploadToken)
  └─> asset_upload_authenticity_token (in JSON response)
       │
       ▼
-PUT /upload/assets/{id}  (authenticity_token = asset_upload_authenticity_token)
+PUT {asset_upload_url}  (authenticity_token = asset_upload_authenticity_token)
 ```
 
 Each step produces the token needed for the next GitHub-authenticated step. The S3 upload (Step 2) uses a self-contained presigned policy and needs no GitHub tokens.