tk-pr-image

GitHub PR Image Upload

Handle explicit local-image evidence requests for an existing GitHub PR or an exact tk-pr-open generic manifest handoff with evidence_required: true. Only the parent handoff is an automatic trigger.

Scope

Handle one bounded upload: validate and stage local images, upload repository-scoped GitHub attachments, minimally update the PR body or selected comment, and verify the source Markdown and uploaded image objects. The default target is the PR body.

For tk-pr-open, validate the producer-neutral evidence fields and never branch on, whitelist, or require a producing skill name. If required evidence is missing or invalid, mark the evidence handoff Blocked; do not revert an already-created tk-pr-open PR.

Use references/gh-attach.md to classify and run the extension route. Read references/cdp-fallback.md only after CDP is selected or the extension route cannot use target write capability. Invoke tk-wizard only for an exact human-only host setup, authentication, permission, or restart step; preserve this skill's upload target and route across the handoff. Use tk-browser-verify for browser-controlled runtime verification.

🔴 CHECKPOINT · 🛑 STOP · Upload mutation boundary

Before any upload or PR body/comment update, reverify the explicitly selected target, valid local evidence or producer handoff, authenticated route, and requested write scope; stop as Blocked or Unverifiable when those preconditions cannot be established.

Workflow

1. Confirm origin, the current PR, and the executing repository from regular local image file(s) or a valid producer evidence handoff. Read the existing PR body.
2. Reuse the existing ## 스크린샷 heading. If absent, insert it before the AI footer or append it at the end. Preserve unrelated body content. For manifest artifacts, use the supplied criterion, role, exact display_route, state/region, viewport, and comparison in the caption; never derive them from a filename, OCR, raw URL, or producer identity. Keep visual-preservation baseline and after visibly labeled as one pair.
3. Select and execute an eligible route using gh-attach, or read CDP fallback only after CDP is selected. Repository visibility is not a routing signal, and a route that may have created remote state cannot silently fall back to the other route.
4. When the selected route needs a human-only host action, pass a bounded handoff to tk-wizard and perform no upload until its completion signal. Agent-approved reviewed extension installation remains here. Resume the exact repository, target, image set, and route after the wizard completes.
5. Update only the requested body or comment through the GitHub API or equivalent. Before Pass, verify byte-for-byte Markdown preservation, decodable image/* bytes from an authenticated fetch for every asset, and reachability of every linked upload object from the upload ref. Browser-session rendering is optional; report whether it was checked in the receipt without making it a Pass prerequisite.
6. Remove only owned staging files on every exit path.

Execution Receipt · Single Evidence Record

Record every upload attempt in the single receipt below. It is not a separate lifecycle output; it is the sole evidence record used for the ## GitHub image upload result and approval/verification decisions. Use none or unavailable for absent values; never guess.

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: Markdown byte match: <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 Manifest Handoff

When evidence_required: true, require all of the following:

• verification_status: Pass, a non-empty criterion, evidence kind, comparison result, and limitations.
• Every artifact has a role, non-empty image, absolute path, run-owned evidence directory, state/region, and viewport.
• Every image is marked inspected: true and has an exact origin-free display_route or an explicit safe omission limitation. Never reconstruct or mask a missing route.
• visual-preservation contains both a baseline and after artifact from its verified pair.

Reject arbitrary screenshots, missing paths, non-Pass results, uninspected artifacts, incomplete preservation pairs, and artifacts not tied to the current run. If required evidence is missing or invalid, return Blocked before upload.

Prohibitions

• Do not create or merge a PR, change reviewers, publish a release, or insert a comment unless the user explicitly selected that comment target.
• Do not bypass tk-browser-verify or use Orca or screen control as an automatic browser fallback.
• Do not overwrite a pre-existing draft or click comment, close-with-comment, or any other submit button.
• Do not choose a route based on public/private visibility or claim success from only a placeholder, Markdown presence, fixed delay, or unrendered API response.
• Do not log or return a signed URL, JWT, or raw secret-bearing query string. This does not prohibit a verified-safe, origin-free display_route; preserve its pathname, query, and fragment exactly as supplied by the manifest.
• Redact only secret-bearing values (signed parameters, JWTs, tokens) in displayed output; preserve rendering parameters such as raw=true. Keep the extension's generated Markdown privately for the authorized body/comment mutation and insert it verbatim, with captions outside that block; never rebuild links from redacted or summarized output. Do not copy secret-bearing originals into logs, receipts, or evidence artifacts.

Failure Handling

Return Pending while waiting for an absent-extension or unreviewed-upstream choice or a human-only tk-wizard completion signal. Return Blocked for unknown provenance, a draft, or a rejected installation without a selected CDP route. Return Unverifiable if authentication, image-byte validation, or upload-ref reachability cannot be verified; rendered-page evidence is optional. Return Fail for upload, remote ref verification, or cleanup errors. State whether the selected body/comment changed and whether an upload ref may remain.

For tk-pr-open, preserve the separate PR operation result and return the evidence state as uploaded or blocked. While required evidence remains blocked, the parent cannot claim full completion.

Result

Start the terminal response with ## GitHub image upload. Include ## Uploaded, ## Verification, and ## Cleanup when applicable. End the result-owning section with exactly one Status: Pass|Fail|Pending|Blocked|Unverifiable line. Expose asset URLs only when safe and redact signed parameters.

Artifact Paths

Create artifacts only when this skill's task authorizes them. Before any artifact write, temporary checkout/transport, or ignore setup, read artifact paths and apply its Git exclusion, safe-path, and ownership checks. Default repository-owned output to .tigerkit/; honor explicit final destinations. Conversation-only work skips this reference and performs no file or ignore setup. Artifact handling grants no unrelated mutation or publication authority.

Output Notation

Use ASCII numbering such as (1) Item or 1. Item, with a space after the marker, in generated headings, lists, choices, tables, diagrams, and summaries. Use - Item for unordered items. Do not generate Unicode circled/enclosed numbers, single-character parenthesized numbers, or keycap emoji as item markers; they can overlap adjacent text in terminal renderers. Preserve exact code, commands, URLs, quotations, identifiers, and verified UI labels unless explicitly authorized to edit them; apply this rule to the surrounding explanation instead.

In chat responses, use a GFM pipe table for comparisons where several rows share at least two comparable attributes. Use a list for single-attribute enumerations. Keep tables narrow (about four columns or fewer), with a header row and short cells so they remain readable when the host shows raw pipes. Do not draw tables with box-drawing characters, wrap a table in a code fence, or emit an empty or ceremonial table. An owner-specific preview rule, such as summarizing a publication body's table in one line, takes precedence. These chat-table rules do not govern tables inside publication bodies or file artifacts.

In Markdown-rendered chat, documents and PR/issue bodies, write ranges with a hyphen (146-149) or spell out both endpoints. Escape a literal tilde as \~ outside inline code and fenced code; preserve exact quotations and identifiers. Do not use unescaped tildes for prose ranges: GFM may render intervening text as strikethrough.

For authorized user-editable temporary input files, follow the owning skill's Artifact Paths input branch before creation and consumption. A prefilled template does not signal completed input; this rule grants no write authority.

User Questions

Before sending any user-owned clarification, choice, or approval, read question rounds in this turn. Ask the whole answerable frontier in one plain-chat round; resolve facts first, preserve existing authorization, and skip question ceremony when no decision remains. Do not use question tools for ordinary TigerKit questions.

Minimum shape, even when already familiar:

---

❓ **Q1 · <short title>**: <question and relevant choices>

➡️ <recommendation and reason, when supported>

Start the question block with a standalone horizontal rule (---) after the preceding context; do not add a ## Questions or ## 질문 heading. Separate questions with blank lines and bold ❓ **Q<n> · ...** title lines, without horizontal rules between questions. Put context before the question block and make it the final substantive block: no plan, promise, or “answer and I will proceed” line afterward, except one short reply-format hint. An approval request is its own numbered Q, never buried in the proposal. Defer approval whose scope still depends on an unresolved answer.

Skill Feedback

When a skill run reveals a reusable incident, preserve only minimal non-secret evidence and suggest a tk-retro review. Do not silently invoke it, create improvement artifacts, edit installed skills, or publish issues/PRs. Explicit implementation requests belong to the authorized change owner; this pointer grants no mutation authority.