jujutsu/SKILL.md
Jujutsu (jj) version control commands and workflows. Use when performing version control operations, committing changes, managing branches/bookmarks, or syncing with remotes. Always use jj instead of git.
npx skillsauth add sanurb/skills jujutsuInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Use jj instead of git for all version control operations.
jj describe to update commit messages instead of git commit --amendjj new creates a new commit on top, making previous commit immutableAlways use non-interactive forms - interactive commands open editors/diff tools.
-m Flag# CORRECT:
jj describe -m "message"
jj commit -m "message"
# BLOCKED (opens editor):
jj describe
jj commit
| Blocked Command | Alternative |
|-----------------|-------------|
| jj diffedit | jj restore or jj squash |
| jj split (no filesets) | jj split -m "msg" <files> |
| jj resolve | jj resolve --list then edit conflict markers |
| jj squash -i | jj squash (non-interactive) |
| jj restore -i | jj restore <files> |
| Any command with --tool | Use non-interactive alternatives |
# CORRECT - provide filesets:
jj split -m "first part" src/file1.ts src/file2.ts
# BLOCKED - no filesets opens diff editor:
jj split
jj split -m "message"
# View conflicts:
jj resolve --list
# Then edit conflict markers directly in files and run:
jj squash
jj status # Show working copy status
jj log # View commit history
jj diff # Show changes in working copy
jj show # Show a specific commit
jj describe -m "message" # Update current commit description
jj new # Create new commit on top of current
jj commit -m "message" # Create new commit with current changes
jj squash # Squash changes into parent commit
jj bookmark create name # Create new bookmark
jj bookmark set name # Move bookmark to current commit
jj bookmark list # List all bookmarks
jj bookmark delete name # Delete a bookmark
jj edit <commit> # Edit a specific commit
jj next # Move to child commit
jj prev # Move to parent commit
jj git fetch # Fetch from remote
jj git push # Push to remote
jj undo # Undo last operation
jj restore <files> # Restore files from parent commit
These are configured in ~/.config/jj/config.toml:
jj overview # Show diff stats and last 3 commits
jj l # Log last 15 commits with color
jj tug # Move bookmark from closest to parent
jj pull # Git fetch (alias)
jj push # Git push (alias)
jj sync # Fetch from all remotes
jj c # Commit (short)
jj ci # Commit (short for jj commit)
jj e # Edit (short)
jj s # Status (short)
jj parents # Show parents of current commit
jj merge <bookmark> # Create merge commit
Workspaces allow multiple working copies backed by a single .jj repo. Each workspace can have a different commit checked out.
# Create a workspace
jj workspace add <path> --name <name>
jj workspace add ../feature-x --name feature-x
jj workspace add ../experiment --revision main # Start from specific commit
# List workspaces
jj workspace list
# Find current workspace root
jj workspace root
# Delete a workspace (two steps)
jj workspace forget <name> # Remove from jj tracking
rm -rf <path> # Delete files manually
# Fix stale workspace (after external changes)
jj workspace update-stale
There's no jj workspace switch command - just cd into the workspace directory:
cd ../feature-x
jj log # Shows feature_x@ for current workspace
Workspaces only share version-controlled files. Files in .gitignore are NOT automatically present:
.env filesnode_modules/dist/, build/, .next/).idea/, .vscode/ if ignored)You must manually copy or symlink these to new workspaces:
# After creating workspace
cd ../new-workspace
cp ../main/.env .env
# Or symlink node_modules if compatible
ln -s ../main/node_modules node_modules
When commits contain intermediate refactors, fixes, or iterations that should be consolidated:
jj log --limit 15 # See recent commits
jj log -r "..@" # All ancestors of current commit
# Squash current commit into parent:
jj squash
# Squash specific commit into another:
jj squash --from <source-rev> --into <target-rev>
# Squash range of commits into one:
jj squash --from <oldest>::<newest> --into <target>
# Change message of any commit:
jj describe -r <rev> -m "new message"
# Edit content of a commit (moves working copy there):
jj edit <rev>
# ... make changes ...
jj new # Return to new work
When you have intermediate commits like refactors, fixes, iterations:
# 1. Review what you have
jj log --limit 10
# 2. Identify logical groupings (e.g., all loop-related work)
# 3. Squash related commits into the main feature commit:
jj squash --from <refactor-rev> --into <feature-rev>
jj squash --from <fix-rev> --into <feature-rev>
# 4. Update the final commit message to reflect all changes:
jj describe -r <feature-rev> -m "feat: complete feature with cleanup"
If you have:
abc123: feat: implement featuredef456: refactor: clean up featureghi789: fix: edge case in featureSquash them:
jj squash --from ghi789 --into abc123
jj squash --from def456 --into abc123
jj describe -r abc123 -m "feat: implement feature (cleaned up)"
# Start work
jj new # Create new change
# ... edit files ...
jj describe -m "feat: add feature"
# Review and push
jj overview # Check status
jj push # Push to remote
# Update from remote
jj sync # Fetch all remotes
development
Sets up an `## Agent skills` block in AGENTS.md/CLAUDE.md and `docs/agents/` so the engineering skills know this repo's issue tracker (GitHub, GitLab, fp, or local markdown), triage label vocabulary, and domain doc layout. Run before first use of `fp-plan`, `fp-implement`, `fp-review`, `to-issues`, `to-prd`, `triage`, `diagnose`, `tdd`, `improve-codebase-architecture`, or `zoom-out` — or if those skills appear to be missing context about the issue tracker, triage labels, or domain docs.
development
Build a throwaway prototype to flush out a design before committing to it. Routes between two branches — a runnable terminal app for state/business-logic questions, or several radically different UI variations toggleable from one route. Use when the user wants to prototype, sanity-check a data model or state machine, mock up a UI, explore design options, or says "prototype this", "let me play with it", "try a few designs".
tools
Control herdr (a terminal-native agent multiplexer) from inside it. Manage workspaces and tabs, split panes, spawn sibling agents, read pane output, and wait for state changes — all via CLI commands that talk to the running herdr instance over a local unix socket. Use when running inside herdr (HERDR_ENV=1). Do not use outside herdr.
documentation
Compact the current conversation into a handoff document for another agent to pick up.