Using jj Workspaces

Overview

jj workspaces are independent working copies backed by the same underlying repository. Unlike git worktrees, they're not tied to a branch — they're tied to a revision, which jj can move freely. Every workspace sees the others in jj log (each marked with its own @ pointer), and any command auto-snapshots the working copy, so context-switching never requires stashing.

This makes workspaces an ideal unit of isolation for sub-agent driven development: spin up one workspace per parallel task, let each agent iterate in its own directory, and merge back through jj's usual revision graph instead of branch-and-merge ceremony.

Core principle: Sibling-directory workspaces + clean shared base + verified green starting point = reliable parallel isolation.

Announce at start: "I'm using the using-jj-workspaces skill to set up an isolated workspace."

Interception: Redirecting Git-Worktree Requests

Several skills in this toolkit (notably using-git-worktrees, and the skills that call it — brainstorming Phase 4, subagent-driven-development, executing-plans, finishing-a-development-branch) assume the repo is plain git. In a jj-managed repo those instructions produce the wrong kind of isolation: a git worktree locks a branch, misses jj's revision semantics, and won't appear in jj log, which breaks the multi-workspace coordination the rest of the workflow depends on.

Interception rule: If any skill, plan, or user request asks you to "create a git worktree", invoke the using-git-worktrees skill, or otherwise set up isolated parallel work, run the detection step below first. When jj is in use, this skill takes precedence and you should follow it instead of using-git-worktrees.

Detection