Menu
Operational style guide for Jujutsu (jj) VCS. Use when working with version control in a project that has a .jj directory.
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
Use when interacting with a running Unity Editor instance — sending commands, checking editor connection status, installing the Pipeline package, or evaluating C# expressions in the editor.
Use when installing, uninstalling, or upgrading Unity editors, adding or listing modules, or browsing available Unity releases.
Use for general Unity CLI operations — list or open projects, list installed editors, read CLI logs, or any other Unity CLI task not covered by a more specific skill (unity-cli-install, unity-cli-build, unity-cli-pipeline).
Use when creating or editing Unity Shader Graph assets programmatically (Unity 6.5+) — authoring custom nodes from HLSL via the Shader Function Reflection API, generating .shadergraph files, or wiring nodes by editing the graph JSON.
Use when reading the Unity Editor Console (log/warning/error entries) or detecting compile errors (C#/Burst, shader, compute shader) from a connected editor via the Pipeline package.
Use when creating a new minimal Unity project.
| name | jj |
| description | Operational style guide for Jujutsu (jj) VCS. Use when working with version control in a project that has a .jj directory. |
| trigger | A .jj directory exists in the project root and VCS operations are needed. |
| allowed-tools | ["Bash"] |
This skill covers workflow conventions, not basic usage. Apply these rules whenever performing version control operations in a jj repository.
Before modifying the working copy, set the intent on the current change:
jj describe -m "Brief description of what this change will do"
This makes the change's purpose visible immediately, rather than describing it after the fact.
Create a new change when a unit of work is finished. Before running jj new,
review the current description and update it if the actual work diverged from
the original intent:
jj describe -m "Revised description if needed"
jj new
Do this at natural boundaries: a feature is complete, a bug is fixed, a refactor is self-contained. Do not let unrelated work accumulate in a single change.
jj git push publishes changes to a shared remote. It is categorically different
from local operations like describe, new, squash, or rebase. Do not
push unless the user explicitly asks for it.
When a git-native operation is needed (e.g. git tag) and git colocation is not
active, temporarily enable it:
# Enable colocation and switch to main so git commands work as expected
jj git colocation enable
git switch main
# Perform the git operation
git tag v1.2.3
git push origin v1.2.3
# Restore
jj git colocation disable
After the git work is done, disable colocation so the repository returns to its normal state.