Menu
Generate or update the changelog with recent feature changes. Also triggers after /pr to ask if new features should be documented.
Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.
Based on SOC occupation classification
VJ a shader live at a party — auto-mutates the shader every minute to match the track. Reads audio features + Spotify track name from the jam page, edits the .frag via /__save-shader (HMR hot-swaps). Invoked as `/vibej` or its alias `/vj`. Usage: `/vibej [N-iterations] [shader-path-or-name]` (default 180, most-recent .frag). `/vibej stop` ends early. `/vibej tick` runs one iteration (what the cron fires).
Legacy alias for /vibej. Same skill, same behavior — VJ a shader live at a party, auto-mutating it every minute to match the track. Usage: `/vj [N-iterations] [shader-path-or-name]`. `/vj stop`, `/vj tick`. Identical to `/vibej`.
Reset the MIDI controller mapping for the Paper Cranes jam/edit page. Clears `localStorage['cranes-midi-profiles']` and reloads the tab so the next CC twist auto-assigns afresh. Usage: `/remap` (clears all profiles) or `/remap <device-name>` (clears one).
Save the current shader + knob state as a new numbered iteration. Usage: `/fork` (auto-detects shader) or `/fork <shader-path>`
Launch a jam session — open the jam page with shader + controller + Spotify/SoundCloud, share tab audio, and get ready to tweak. Usage: `/jam [shader-path] [music-url]`
Launch a live creative session — open Chrome with the shader editor + audio source, connect Claude-in-Chrome, and get ready to jam. Use `/live-session` to start, optionally pass a shader path or SoundCloud/Spotify URL.
| name | changelog |
| description | Generate or update the changelog with recent feature changes. Also triggers after /pr to ask if new features should be documented. |
| allowed-tools | Bash Read Write Edit Grep Glob Agent |
Update docs/CHANGELOG.md, README.md, and supporting docs with new features since the last changelog commit.
Current changelog:
!cat docs/CHANGELOG.md 2>/dev/null || echo "(no changelog yet)"
Current README "What's New" section:
!sed -n '/## What.s New/,/^## /p' README.md 2>/dev/null | head -30 || echo "(no What's New section yet)"
Last changelog commit:
!git log -1 --format="%H %as" -- docs/CHANGELOG.md 2>/dev/null || echo "(never committed)"
Commits since last changelog update (excluding shaders and images):
!git log $(git log -1 --format="%H" -- docs/CHANGELOG.md 2>/dev/null || echo "HEAD~50")..HEAD --no-merges --format="%h|%as|%s" -- ':!shaders' ':!public/images' ':!*.png' ':!*.jpg' ':!*.webp' ':!*.gif'
Recent merges (for PR numbers):
!git log $(git log -1 --format="%H" -- docs/CHANGELOG.md 2>/dev/null || echo "HEAD~50")..HEAD --merges --oneline | head -20
Existing feature docs:
!ls docs/*.md 2>/dev/null
/changelog)Only add what's new: Compare the commits above against what's already in the changelog. Skip anything already documented.
Focus on what a user would be excited about: New capabilities, meaningful UX improvements, and important fixes. Skip internal refactors, doc typos, CI tweaks, and code cleanup unless they change user-facing behavior.
Categorize into: Features, Fixes, or Developer Experience.
Write concise entries: Bold the feature name, dash, one-sentence description. Include PR numbers as GitHub links when available (e.g. [#98](https://github.com/loqwai/paper-cranes/pull/98)).
Link to feature docs: If a dedicated doc exists in docs/, link the entry to it. If a new feature is significant enough to warrant its own doc, create one — keep it lean (under 60 lines), focusing on non-obvious details.
Update README.md: Keep the "What's New" section near the top with the 3-5 most recent major features. This should read like highlights, not a full log — link to the changelog for the rest. Also update the Documentation table and "Fun developer features" bullets if new docs were created.
Update CLAUDE.md if new features add query params, new files, or architectural concepts. Keep additions minimal — one-line summaries with doc links.
Group changelog entries by date, newest first. Use ## YYYY-MM-DD headers.
If $ARGUMENTS specifies a time range, use that instead of "since last changelog commit".
/prAfter a PR is created, review the commits included in that PR. If the PR introduces a feature that a user would be excited about (new capability, new query param, new UI, new integration — not just a fix or refactor), ask the user:
"This PR adds [feature]. Want me to update the changelog?"
If they say yes, follow the steps above. If the PR is just a bugfix, refactor, or shader-only change, don't ask — it's not changelog-worthy.