Skip to content
cccskills
FreePublished on GitHub

evidence

Produce visual PR evidence — a screenshot or video — whenever a change has on-screen impact. Tests are never a substitute; a change can be backend by cause and visible by effect. Capture via the project's e2e harness on a pu box, or by driving a live kolu with the chrome-devtools MCP; host on a GitHub release and post a `## Evidence` comment. Triggers on "post evidence", "screenshot the change", "record a video of this", "show it working", "prove it", or finishing any change whose effect is visible on screen.

The English summary is being prepared. Showing the original description.

Works withGitHub
See how to install

Files included (2)

  • SKILL.md4.0 KB
  • CAPTURE.md5.2 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

evidence — PR screenshots & video

The gate — answer this first

If someone exercised what this change affects, would the screen look DIFFERENT — before vs. after?

  • YES → a visual artifact is mandatory. Static (end-state, single moment, before↔after) → screenshot. Motion (transition, flow, live update, animation) → video. A value-over-time element — a running timer, live counter, anything whose job is to change on its own — is motion: a frozen clock and a live one are pixel-identical in one frame, so watch it tick. A screenshot is a complete deliverable, not a runner-up to video.
  • NO → skip with one explicit PR line: No visual impact: <why>. Silent skips are not allowed; neither is manufacturing a tenuous pixel for a change whose screen truly doesn't differ.

Excuses that don't hold (each was tried on a real PR and rejected):

  • "Backend change, no UI surface." Backend by cause can be visible by effect — trace the effect to the screen, not the cause to a layer.
  • "No scenario exercises it." That decides how you capture, never whether.
  • "It's a CLI/TUI — here's a transcript." A terminal is an on-screen surface, and a pasted transcript is not a visual artifact. Record the real binary with vhs/asciinema.
  • "The tests prove it." Tests accompany the artifact, never replace it.
  • "I reconstructed the output — close enough." A synthesized artifact (formatter output posted as a recording, mocked data, a stub's clip) is a fabrication, and it hides the very bug evidence exists to expose. The artifact comes from really executing the change end-to-end against real data — and read the real output to confirm the feature works before posting.

Capture

Runs on an ephemeral pu box (see the pu skill), never locally, so evidence reflects a clean CI-like build of the PR's commit.

Prefer the existing Cucumber + Playwright e2e harness — KOLU_EVIDENCE=1 turns on video recording (see packages/tests/support/hooks.ts) and you select a scenario by name. It's the default because the clip comes from the same code CI runs. The one thing to avoid building is a parallel capture harness that duplicates the step library; everything else is fair game when the harness can't reach the state: pull a still from a recorded clip, drive a live kolu with the chrome-devtools MCP and take_screenshot, vhs for a TUI, ordinary shell setup for on-disk preconditions. Never skip for lack of a canned path.

Delegate capture to a subagent so the main context stays clear: brief it with the box, branch, image-or-video, the scenario or live state, a <slug>, the PR number, and the release tag; it returns the markdown it posted.

Commands, harness details, transcode settings, and vhs gotchas: CAPTURE.md.

Host & post

  • evidence-assets is the one fixed release tag. It already exists; verify it does, never create another, never derive a tag from the PR number.
  • The local filename IS the asset name — copy back as /tmp/<slug>.png, not a decorated name, or every …/download/evidence-assets/<slug>.png embed 404s.
  • GIF embeds inline (keep under GitHub's ~10 MB limit); MP4 links via the shared player (juspay.github.io/video-evidence). PNG embeds like a GIF.
  • Use a single-quoted heredoc when posting so backticks and $ survive.
  • Tear the box down when finished: pu destroy "$host".

Reviews

No reviews yet. Tell others what you thought.

Comments

No login needed. Share how it worked for you, ask a question, or note where it did not run.

No comments yet. Be the first to write one.

Comments are published right away. Do not include personal information such as email addresses or phone numbers. Up to 2 URLs.

0 / 1,000 characters

This form is protected by reCAPTCHA, and the Google Privacy Policy and Terms of Service apply.

More skills from this repository

Write a kolu blog post grounded in the real build history — mine the Claude Code session logs behind a feature for the actual story (for large efforts, fan out over the transcripts with an ultracode workflow), draft it in the author's voice, and wire it into the Astro site. Use when asked to write a blog post or engineering essay about something that was built, especially one that should read as a narrative of what actually happened rather than invented marketing copy.

The English summary is being prepared. Showing the original description.

juspay/kolu82Updated Oct 22, 2026

ci

Free

Run this repo's CI end-to-end — kolu's policy on top of the odu runner: banned opt-out flags, x86_64-linux pinning, pool upkeep, fail-fast surfacing, e2e timing evidence, and the green-gate. Triggers on "run CI", "drive CI", "re-run the pipeline", "close the red check", "warm the pool". Runner mechanics live in the `/odu` skill.

The English summary is being prepared. Showing the original description.

juspay/kolu82Updated Oct 22, 2026

Launch the kolu dev server on two RANDOM free ports so it never collides with the running production `kolu.service`, remember the ports for the rest of the session, and tear down only the dev instance. Load before running the app locally — for evidence capture, driving a live kolu with the chrome-devtools MCP, or any `just dev` you'd otherwise run by hand. Triggers on "run kolu locally", "launch the dev server", "boot kolu", "drive a live kolu", "start the app to screenshot it", or before pointing chrome-devtools at a local kolu.

The English summary is being prepared. Showing the original description.

juspay/kolu82Updated Oct 22, 2026

Classify, write, and audit documentation per Diátaxis (diataxis.fr) — the four-quadrant method (tutorials · how-to guides · reference · explanation). Encodes the compass as a decision procedure, each quadrant's contract as hard rules, and an executable mixed-mode audit. Project-agnostic; the per-repo doc-location mapping lives in a repo rule of the project's own (kolu: the Kolu overlay below). Use when writing any user-facing doc, structuring a docs site, or auditing existing docs for mixed modes.

The English summary is being prepared. Showing the original description.

juspay/kolu82Updated Oct 22, 2026

The Dock's agent-state folds — one fenced source of truth in @kolu/terminal-vocab, the load-bearing order≠colour split, and the one "is something happening" question. Use when editing agentProjection or the canvas dock.

The English summary is being prepared. Showing the original description.

juspay/kolu82Updated Oct 22, 2026

E2E test conventions — semantic selectors, arrange-steps that prove the process started, runtime markers that cannot match the shell echo, and absolute-path tool invocations. Use when writing or changing a .feature scenario under packages/tests.

The English summary is being prepared. Showing the original description.

juspay/kolu82Updated Oct 22, 2026

See all skills by juspay

Report a problem with this skill