菜单
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 页面并帮你完成安装。
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.
基于 SOC 职业分类
| 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.