Skip to content
cccskills
FreePublished on GitHub

ketchup-video

Summarize work since the user’s last message as a short silent landscape video made from slides, with waiting calls listed as text beneath it. The slides use captured work artifacts, show what is done or still pending, and keep each frame focused on one point.

OriginalShow the original description

Catch the user up like /ketchup, with a short silent video of slides for what happened and the waiting calls as text under it. Use for /ketchup-video.

Run score Not tested

See how to install

Good for

  • Catching up on recent agent work in a video
  • Showing completed and pending work visually
  • Reviewing changes from screenshots or diffs

Files included (1)

  • SKILL.md2.8 KB

SKILL.md (original)

Review the instructions the agent will receive before you install.

Ketchup video

Follow /ketchup, but show what happened in a short silent video instead of its summary and visuals. Its window starts at the last message the user wrote before /ketchup-video, not before any earlier /ketchup. Writing and rendering the video, outside the repo, is the one exception to its read-only rule. The reply is ketchup's opening sentence, the embedded video, one line naming any work left that you can do yourself, and the action items. When the video shows a call's options, call each option by the name the video gives it. If the render fails, say so in one line and give only the calls.

Slides

Use the screenshots, recordings, diffs, and data the work produced, not the chat's prose about them. Before you draw, write the one sentence the user should leave with and one line per slide. Drop each slide that does not change what the user knows. Use at most 10 slides, and fewer is better. Neither note goes in the reply.

Each slide makes one point. Build the slides on one picture and change it from slide to slide, rather than cut to an unrelated one. A color or shape means the same thing on every slide. Show the work in pictures, such as how a system works, a PR stack with each PR's state, a before and after of a fix, or options side by side. Point at what changed with arrows, highlights, and motion. A slide is never a bullet list, a status list, a table, or boxes with nothing connecting them.

Keep text to the minimum. Put each label on the thing it names, in plain words a person would say, not tags like "Tests: pass". Never caption what a picture shows, and never give a fact twice, across slides or in the text under them.

Show what came of each thing the user asked for, and whether it is done, still running, failed, or not checked. Never show something done that still waits on the user. Show any bug found and fixed on the way. If a visible change has no screenshot, say so on its slide and name what changed on screen. Draw only from facts you have. Never invent a number, and never draw a screen you did not capture.

Render

Render one silent landscape video, such as an mp4, with motion between slides. Every frame is the slide itself, edge to edge. Make the frames from the slides, never by recording a screen. Hold each slide long enough to read its words, at least one second for each three words it adds. Words inside a screenshot do not count. Before you embed the video, look at one frame from each slide in the rendered file, and count the words it adds against its hold in that file. Fix any slide you cannot read in that time, render again, and check again.

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

architect

FreeSummary

Use this skill to shape non-trivial code before implementation. It grounds the design in the surrounding system, compares structurally distinct options, and creates a type and module sketch that guides coding. If implementation repeatedly conflicts with the sketch, it revisits the architecture.

  • Planning module boundaries before a feature implementation
  • Comparing design options for a non-trivial change
  • Revisiting a sketch when implementation needs repeated workarounds
backnotprop/pstack2.7KUpdated Oct 24, 2026

arena

FreeSummary

Generate several parallel candidates for the same task, compare them against concrete criteria, and choose a base to improve with selected strengths from the other candidates. The skill then verifies the synthesized result and records how it was assembled.

  • Comparing several designs for one task
  • Exploring options before making a substantial change
  • Combining the strongest parts of parallel drafts
backnotprop/pstack2.7KUpdated Oct 24, 2026

automate-me

FreeSummary

Turn a user's recurring work preferences into a personal “-mode” skill that agents can follow. The guided workflow can create a new skill or revise an existing one, using recent conversation history as optional evidence.

  • Creating a personal agent skill from recurring work preferences
  • Refreshing an existing -mode skill after work habits change
  • Capturing preferred response style and verification practices
backnotprop/pstack2.7KUpdated Oct 24, 2026

Check benchmark results before reporting a speedup or slowdown. Review the bottleneck, production settings, physical limits, errors, repeatability, real-world relevance, and whether the measured work actually ran, then report the evidence and limits.

  • Review a before-and-after benchmark
  • Check a claimed performance regression
  • Compare library or configuration choices
backnotprop/pstack2.7KUpdated Oct 24, 2026

blast-radius

FreeSummary

Assess what a code change could break beyond the visible diff. Trace less obvious effects, identify the key assumption that makes the change safe, and test that assumption by running real code before presenting risks and cleared concerns.

  • Assessing the blast radius of a proposed code change
  • Reviewing a small diff whose safety is uncertain
  • Checking downstream effects beyond direct callers
backnotprop/pstack2.7KUpdated Oct 24, 2026

bro

FreeSummary

Rewrite the agent’s previous message in concise, plain language. It removes jargon and awkward phrasing while keeping the explanation coherent and direct, so the same point is easier to understand.

  • Simplifying a technical explanation
  • Restating an unclear answer
  • Removing jargon from a reply
backnotprop/pstack2.7KUpdated Oct 24, 2026

See all skills by backnotprop

Report a problem with this skill