game-screenshot-showcase-and-store-packaging

Game Screenshot Showcase and Store Packaging

Overview

Capture and package Unity screenshots through an approval-gated workflow: discover the target moments, propose the exact checklist, capture only after approval, review the images visually, and package approved outputs without overwriting raw evidence or taking storefront actions.

Provenance

This workflow is conceptually inspired by ParthJadhav/app-store-screenshots (MIT). No source text or code was copied into this skill.

When to use

Use for Unity PlayMode feature capture, showcase contact sheets, approved slide decks, and report-only screenshot packaging for Steam, mobile stores, or WebGL listings.

When NOT to use

Do not use for qualitative playtest synthesis without capture/package scope; route that work to playtest-evidence. Do not use to upload assets, sign binaries, accept legal terms, log into storefront accounts, or press submit; route publication readiness to store-submission-checklist. If the core question is runtime execution proof, Unity build proof, or a missing HUD/widget, route to build-and-runtime-verification, unity-batchmode-build-verification, or unity-ui-rendering-debugging.

Required inputs and context discovery

Collect the Unity project root, target scenes or entry points, feature beats to capture, viewport/device targets, locale, intended store/platform, approved evidence/output roots, privacy redaction rules, reviewer identity, and whether a Unity Editor or PlayMode runner is actually available.

Safety and risk level

This workflow may write new evidence files and report-only HTML/JSON outputs, but it must never overwrite raw captures, delete rejected evidence, traverse outside approved roots, consume credentials, or perform upload/signing/submission. Redact or exclude player names, email addresses, account IDs, chats, or other sensitive content that appears in screenshots.

Workflow

1. Discover. Completion criterion: the exact feature moments, scenes, capture roots, device targets, and no-touch paths are named, and adjacent concerns are routed to playtest-evidence, build-and-runtime-verification, unity-batchmode-build-verification, unity-ui-rendering-debugging, or store-submission-checklist when they are the real owner.
2. Propose the interactive checklist. Completion criterion: an explicit capture-plan is prepared with ordered flows, viewport, locale, timeout, reviewer, and approval state, and no capture starts before human approval.
3. Capture only after approval. Completion criterion: Unity Editor or PlayMode capture runs only after approval, raw files are preserved as immutable evidence, and each capture yields a capture-record with hash, byte size, dimensions, build/editor snapshot, runtime result, visual review placeholder, and limitations. If Unity Editor, PlayMode, or the approved runtime path is unavailable, this phase is BLOCKED; do not substitute old screenshots, mocked renders, or compile confidence.
4. Visual review. Completion criterion: approved and rejected captures remain traceable through verify-capture results and an HTML contact sheet, and runtime verdicts stay separate from visual verdicts. A visually strong image with weak runtime evidence is not a runtime PASS; a runtime PASS does not auto-approve composition, crops, or messaging.
5. Package. Completion criterion: only approved showcase selections become a showcase-deck and store-export-manifest, store readiness stays separate from runtime and visual verdicts, and packaging remains report-only with no resizing, upload, signing, or submission.