luke: Skill for Claude Code

Changelog screenshots

The rules every picture follows are in the comment atop CHANGELOG.md; this is how to meet them. A release's pictures come from its own build: the commit the release's tag (v<version>, what shipped), or for a release not yet tagged, the head of its version pull request. The work is in four parts: plan the shots, stage them in a throwaway patch, build and capture on the Mac, then frame and land them.

You need the developer's Mac (a run-on-Mac tool, such as Luke's run_on_mac): the native build, the window capture, and the framer are macOS-only. The cloud workspace writes code and reviews pictures; with the workspace's file sync on, anything under its .context/ appears in the workspace's synced copy on the Mac ($S below), and nothing syncs back.

Without file sync (a Luke coding agent's sandbox), files cross through scratch refs on GitHub, never a command line, which cannot carry a patch of pictures: the cloud commits the staged worktree and pushes it to refs/luke-shots/<tag>, and the Mac fetches it into its clone and diffs it against the tag for build.sh; the Mac commits its previews and finished PNGs through a temporary index (GIT_INDEX_FILE, hash-object on absolute paths, write-tree, commit-tree) and pushes them to refs/luke-shots/out, which leaves the developer's checkout untouched. A ref outside refs/heads builds no Vercel Preview. Delete every scratch ref once the pictures land. The helpers run from a copy of origin/main's skill (git archive), not the developer's own checkout.

1. Plan the shots

Read the release's CHANGELOG.md entry and write a shot list in .context/shots/SPEC.md before any code: for each ### section, whether it gets a picture, what the picture must show, and the composition that puts that in front. Then look at the list as a set.

• A section gets a picture only where one helps. Plumbing (a shared runtime, a fix) gets none; a single row or button is a close-up, not a whole window.
• No two pictures share a composition. The 0.8.0–0.11.0 pictures fail this: seven of them are the same plan document on the left with the feature squeezed into a panel on the right. Vary the layout per shot: the sidebar folded or open, the side panel closed, wide, or full screen, a full-window view (Settings, version history), a menu, card, or palette held open.
• Vary the framing: the whole window (1600 by 1000 points) where the layout is the point, a --crop close-up where the feature is one part of it. A close-up is the framed picture zoomed in, never a cut-out: the feature stays inside the app around it (the ⌘K palette over its dimmed plan, the sidebar with the window's corner and wallpaper beyond), and it comes out exactly as tall as a whole-window picture, only narrower. The changelog page shows every picture at that one height.
• The plan document is not wallpaper. Show it only where it is the subject; elsewhere open another task, another tab, or fold it away.
• Nothing experimental gets a picture. A feature behind Settings › Experimental (the Factory, Issues, Code review, video calls, and whatever joins them) is no section's subject, even where the notes announce it, and no shot turns an experiment on (ShotSpec.experiments stays empty), so nothing an experiment draws (a sidebar row, the Code review suggestion) shows at the edge of another picture either. 0.15.0's Factory and 0.17.0's Issues pictures were taken and then removed for this.