// Jujutsu (jj) version control workflows and commands. Use this skill when working with jj repositories, managing changes, squashing commits, rebasing, or performing jj-specific operations.
| name | jj |
| description | Jujutsu (jj) version control workflows and commands. Use this skill when working with jj repositories, managing changes, squashing commits, rebasing, or performing jj-specific operations. |
When reading data from jj, always use --ignore-working-copy to avoid snapshotting the working copy (which is slow and unnecessary for read operations).
Many jj commands spawn $EDITOR or interactive diff tools by default. These will hang indefinitely when run by agents. Always use the non-interactive alternatives:
| Command | Problem | Solution |
|---|---|---|
jj describe | Opens editor | Always use -m "message" |
jj commit | Opens editor | Always use -m "message" |
jj split | Opens diff editor + may open editor for description | Provide filesets to select files; use -m for description |
jj squash | May open editor for combined description | Use -m "message" or -u (use destination message) |
Commands to avoid entirely (no non-interactive mode):
jj diffedit — use jj restore or edit files directly insteadjj config edit — use jj config set <key> <value> insteadjj sparse edit — use jj sparse set --add <path> or --remove <path> insteadjj resolve — edit conflict markers directly in files, or use --tool :ours / --tool :theirsjj's default diff and conflict formats differ from Git's. For easier parsing, use Git-compatible formats:
Diffs: Use the --git flag for unified diff output:
jj diff --git
jj log -p --git
jj show --git
Conflicts: jj uses diff-based conflict markers by default (%%%%%%%, +++++++). For standard Git-style markers (<<<<<<<, =======, >>>>>>>), pass --config when running commands that may create conflicts:
jj --config ui.conflict-marker-style=git rebase ...
jj --config ui.conflict-marker-style=git new --insert-before ...
The conflict style is applied when conflicts are materialized to the working copy, so the config must be set before the conflict occurs.
JSON: For structured/programmatic output, use the json(self) template:
jj log --ignore-working-copy --no-graph -T 'json(self) ++ "\n"'
Outputs one JSON object per line with commit_id, change_id, description, author, etc. Works with jj log, jj show, and other commands that support -T.
| Command | Description |
|---|---|
jj status | Show working copy status |
jj log | Show commit history |
jj new | Create a new change |
jj describe -m "msg" | Set commit message |
jj squash | Squash into parent |
jj diff | Show changes |
jj git push | Push to remote |
jj git fetch | Fetch from remote |
jj bookmark create name | Create a bookmark |
In-depth guides on jj concepts and syntax.
Documentation generated from jj manpages. For details on any command, read the corresponding reference file.
Generated from jj manpages (jj 0.37.0)
The content in the references/ directory is derived from the jj (Jujutsu) project and is licensed under the Apache License 2.0.
This skill should be used when working with Restate durable execution framework, building workflows, virtual objects, or services that need automatic retries, state management, and fault tolerance. Use when the user mentions "restate", "durable execution", "durable workflows", needs to build resilient distributed systems, or when they invoke /restate.
Distill rough ideas into structured project specs with issues. This skill takes unstructured input (bullet points, rough notes, transcribed ideas) and systematically breaks it down into feature domains, identifies ambiguities requiring user clarification, and produces a single structured spec document with actionable issues. Use this skill when the user wants to transform rough project ideas into well-defined specifications and issues, or when they invoke /speccer.
Jujutsu (jj) workflow skill. This skill should be used when the project uses jj for version control instead of git. Provides guidance on using jj commands and references the jj-vcs skill for detailed documentation.
Apple's native container runtime for macOS. Use this skill instead of Docker when running on macOS with Apple silicon. The `container` CLI provides OCI-compatible container management optimized for Apple silicon.
Manage project changelogs following the Keep a Changelog format. This skill should be used when working with CHANGELOG.md files, adding changelog entries, releasing versions, or reviewing git commits for changelog purposes.
Read and write semantic versions in config files (JSON, TOML, YAML). This skill should be used when bumping versions in package.json, Cargo.toml, deno.json, or other config files, or when reading version values from these files.