HanZephyr Record Browser GIF
Create a legible GIF of the requested UI workflow. Keep the demonstrated behavior truthful and use the bundled encoder for repeatable timing, dimensions, and size. A local recording does not by itself authorize uploads, repository pushes, or pull-request edits.
Match the recording to its claim
Identify the origin, workflow, output destination, and whether the task needs a visual demonstration or evidence of a specific running build. Use the application's real requirements: an ordinary website demonstration needs no model, model round, or API key unless its behavior actually depends on one.
For evidence tied to a commit or pull request, verify which checkout built and serves the application and record that exact commit. If the tree is dirty, preserve the edits and describe the tested tree accurately; do not label it as the clean commit. Record relevant fixture, transport, or configuration overrides. Use credentials only through the application's normal configuration, without revealing them.
A requested real-server or real-service recording must use that path. If it is unavailable, report the limitation rather than silently substituting fixtures. Explicit fixture or prototype recordings are valid demonstrations when labeled accordingly. A visual outcome alone does not prove a particular backend, tool, or recovery path; include relevant UI detail or separate runtime evidence when that path is part of the claim.
Stage and capture
Use an available browser tool or the project's existing automation setup, following its actual supported APIs and file permissions. Do not assume a particular browser skill, driver, screenshot root, or session lifetime exists. If setup is missing, identify an appropriate scoped setup or report what prevents capture.
For a reproducible demonstration, use isolated application and browser state when practical. When using an existing user session, preserve unrelated data and disclose state that materially affects the result. Do not clear the user's cookies or storage just to obtain a fresh recording. Start any required server from the verified tree and manage only the process started for this task, identified precisely rather than by a broad kill pattern.
Choose a small sequence of meaningful states, keep a consistent viewport and crop, and save ordered frames such as 00-initial.png, 01-action.png, and 02-result.png. Create the output directory first under an allowed artifact location; keep scratch frames out of source commits unless explicitly requested.
Before capture, wait for an observable condition that establishes the intended state. Prefer a unique label, changed control state, or completed response. An arbitrary delay is not proof of readiness, and a substring found anywhere in the page may match user input rather than the result. When an exact match matters, ensure the locator or predicate identifies the intended element uniquely.
For a transient state, observe its actual marker and capture it within the window in which it is visible, using the tool's supported synchronization. Do not inject fake product state to simulate live evidence. If a sequence must establish one continuous run, keep its frames from that run; restart the affected sequence after a failed capture rather than splicing unrelated outcomes. Edited or time-compressed demonstrations should make that presentation clear when it changes what viewers can infer.
Capture no secrets, personal data outside the authorized demonstration, unrelated tabs, or notifications. Save screenshot bytes directly when provided by the browser tool.
Encode
The bundled encoder uses Python's standard library and requires ffmpeg and ffprobe on PATH. Discover the project's Python environment and use its runner; no executable named python3 is assumed. Resolve the skill directory to an absolute path. For a project managed by uv, a command has this form (substitute actual paths):
uv run /absolute/path/to/record-browser-gif/scripts/encode_gif.py /absolute/path/to/frames /absolute/path/to/demo.gif --durations 1.5,1.5,3.5 --fps 10 --max-width 1200 --colors 128
Other environments should use their configured Python invocation with the same script arguments. If a dependency is missing, use any already-authorized project setup process or report the missing dependency; do not change system software merely to record a GIF.
One duration applies to every source frame, or supply one positive duration per frame. Hold the final state long enough to read. The encoder checks for at least two input frames, matching dimensions and duration counts, valid limits, accidental overwrite, encoded duration, and output byte size. Its default size limit is 5 MiB and can be changed with --max-bytes for the destination's actual constraints.
For an oversized artifact, reduce width, palette size, or frame rate while retaining readable content. Use --force only when replacing the resolved output is intended. An encoding error may leave an output file; do not present it as verified.
Verify and deliver
Read the encoder's JSON summary to check output path, source and encoded frame counts, dimensions, duration, and byte size. Inspect the encoded GIF itself for readable text, state order, sensitive content, and final hold. If the viewer displays only its first frame, decode representative frames from the GIF with the available media tools; source screenshots alone cannot verify the encoded palette or sequence.
Confirm the artifact and scratch files are in their intended locations and unrelated files were not changed. Return the usable artifact path and display it if supported. For recordings offered as runtime evidence, state the demonstrated build or tree and material recording conditions. Do not claim real-service validation when only a fixture was exercised.
Publish when requested
Follow the destination's existing media workflow, whether attachment upload, artifact hosting, repository storage, or a media branch. Choose a stable URL readable by the intended reviewers. Avoid putting large binaries into ordinary source history when a suitable established alternative exists, but do not impose a new assets branch or hosting service.
Publish only the verified artifact, confirm the uploaded bytes or checksum where supported, and verify the intended audience can retrieve the image. Private assets may require authenticated verification; an anonymous failure alone does not establish a broken member-access path. Check that the final embed renders as an image, rather than merely linking to a file-view page.
For a pull-request demonstration, reread its current head before editing the body. If it moved, assess whether the recording still supports the claim, label the recorded commit accurately, or rerecord when current-head evidence is required. Preserve unrelated body content and verify the result after publication. Avoid overwriting or deleting published media still referenced by existing reviews.