Authoring

Source README.md · versioncam 0.5.3 from npm

A clip is a script, and writing one is a loop: look at the page, write, record, look at what you got, fix. versioncam ships that loop as one agent skill. There is no API key and no SDK. The model is whichever agent session runs the skill, and it reads contact sheets with the same tool it reads files with.

npx versioncam init          # .claude/skills/versioncam/ and .claude/agents/versioncam-reviewer.md
# or, for Claude Code without copying anything:
claude --plugin-dir node_modules/versioncam/plugin

init --into <dir> puts the skill directory somewhere else, for a host that reads skills from another place. Then ask for a clip:

Claude Code

/versioncam "Find a shipment by filtering the list, and show how many matched"

The first run in a repository with no versioncam.config.ts sets it up before anything else:

1. It works out how the app starts and where it is served, from its scripts and its framework’s config.
2. It asks you whether the app signs in, and how you want that handled.
3. It writes a config with a webServer, so nothing has to be running.
4. It runs doctor and inspect to prove the app starts and settles.
5. It records a three-second clip twice with stability, so no clip is written against an app that does not record the same way twice.

It commits nothing.

In a monorepo the skill first looks for versioncam.config.ts across the whole repository, wherever the session started, and then works in the directory that holds it. With several apps, it asks which. With none, the first run writes the config where versioncam init put the skill.

Every run then goes the same way. The session inspects the start page and reads versioncam dsl and your existing clips. It writes a beat sheet, then the clip, and records it in draft until versioncam review passes, three recordings at most. Then comes a contact sheet sampled at the beats, and a fresh reviewer.

The reviewer is versioncam-reviewer, new every round. It sees the picture, the beats and a five-item checklist, and nothing of how the clip was written: a reviewer that has read the author’s reasoning agrees with it. Its verdict comes back as fixes to make, and the round repeats. After six rounds at most it stops and says why. On a host that cannot register the reviewer as an agent, the same file is a subagent’s prompt. On a host with no subagents at all, it is a checklist the session applies to its own sheet, and the verdict says which.

What you get is under .versioncam/author/<id>/: the beat sheet, a summary.json, the final sheet, and for each round what the author found, its beats and the reviewer’s verdict. The clip itself goes in your clips directory. That is the part worth reading and committing.

What it costs. Six to twelve minutes and one or two rounds for a clip on the example app, most of it model latency rather than the recorder. It is not cheap and it is not instant. It is, however, unattended.

What it is not. The skill cannot sign your app in for you. It asks how you want that handled, and versioncam login is yours to run because it waits for you. It does not run git. And versioncam review only checks what needs no eyes. Whether the clip is good is the reviewer’s job, and after that, yours.