메뉴
Describe and finalize work with jj-vcs — drafting a description for the current change, splitting mixed work into focused commits, and advancing to a clean working copy. Use when asked to commit, when finishing a unit of work, or when starting new work on top of undescribed changes.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
Use this skill when managing packages, external dependencies, binaries, or CLI tools in a chezmoi dotfiles repository. Handles adding/updating/removing packages in .chezmoidata/packages.yaml, creating .chezmoiexternals/ organized files, pinning versions with Renovate automation, and selecting the correct package ecosystem (Homebrew, mise, Python, Docker, chezmoi externals).
Write, debug, and optimize custom GLSL shaders for the Ghostty terminal. Covers Ghostty's Shadertoy-compatible GLSL ES 3.0 dialect, its terminal-specific uniforms (cursor position and color, focus state, event timestamps), the unsupported Shadertoy uniforms, focus-gated performance patterns, and adapting shaders from shadertoy.com. Use when creating or editing a .glsl file for Ghostty, diagnosing a shader that renders black or fails to compile, or setting custom-shader config.
Reference for deeper Jujutsu (jj) topics beyond the everyday describe/advance workflow. Load when working with conflicts, the operation log, bookmarks, revsets, fork/PR workflows, colocated Git repos, multi-remote setups, divergent changes, or jj config. Also the place to look up fileset glob syntax, non-interactive `jj split`, and bookmark advancement.
Start work on a new issue or feature by creating a jj change on the up-to-date default branch with an optional named bookmark.
Build comprehensive understanding of a problem by gathering context from GitHub issues, codebase exploration, git history, and linked references. Use when starting work on an issue or investigating a problem.
Design an implementation as a task graph with explicit dependencies, parallel phases, and agent team topology. Use after gathering context and agreeing on an approach, when the work is large enough that sequencing it badly costs real time.
| name | commit |
| description | Describe and finalize work with jj-vcs — drafting a description for the current change, splitting mixed work into focused commits, and advancing to a clean working copy. Use when asked to commit, when finishing a unit of work, or when starting new work on top of undescribed changes. |
Produce a clean atomic history ending on a fully clean working copy. In jj the working copy is
already a commit, so "committing" is really two questions: is this change described well, and
should @ advance.
Run these together — the description depends on all three:
jj diff # what actually changed
jj log -r "ancestors(@, 10)" --template builtin_log_oneline # this repo's style
jj status # @'s current description
If @ holds unrelated changes, separate them rather than writing a description that lists two
things:
jj split -m "message" <files> # peel off part of @
jj squash --use-destination-message <files> # fold files into the parent
It should complete the phrase "This commit will…", and explain why in the body — the diff already shows what. One or two sentences.
Match the style you saw in the log. Where that log uses conventional commits, follow it; where
it doesn't, don't introduce it. The verb carries meaning worth keeping consistent: "add" for
something wholly new, "update" for an enhancement to what exists, "fix" for a bug. Add
Fixes #NN when an issue closes.
For multi-line messages, use a heredoc so quoting doesn't mangle the body:
jj commit -m "$(cat <<'EOF'
Description here.
Co-Authored-By: Claude <noreply@anthropic.com>
EOF
)"
@'s state@ right now | Command |
|---|---|
| Already well described | jj new — or jj new -m "next plan" |
| Needs a description, ready to move on | jj commit -m "..." — describes and advances |
| Needs a description, more work coming | jj desc -m "..." |
Then run jj status in the same message to confirm where you landed. When this is a handoff
into new work, jj new -m "<goal of the new work>" starts it named.
Don't jj git push unless asked.