Anyone tried worktree/worktrunk w/ openspec?

[XueyanZhang]

OpenSpec is awesome! I am looking to use it in parallel using git worktree. Has anyone tried it?

[kova1max]

Yes, it works well. OpenSpec never touches git: a change is a folder of Markdown under openspec/changes/<name>/, so each worktree is just a branch with its own change folder.

Recommended flow:

git worktree add ../myapp-dark-mode -b add-dark-mode   # or: wt switch -c add-dark-mode
cd ../myapp-dark-mode
# in an agent session in this worktree:
/opsx:propose add-dark-mode
/opsx:apply
# commit, open a PR with the delta spec + code, merge
# then, on main:
/opsx:archive

Rules that keep parallel work conflict-free:

1. One change per worktree, one owner per change. Separate change folders never collide. Two agents editing the same change folder conflict like any shared file, so split large work into separate changes.
2. Archive on main, after merge. Archiving folds the change's ADDED/MODIFIED/REMOVED deltas into openspec/specs/. That folder is the only shared surface, so archiving inside each worktree makes every branch rewrite it. The docs recommend archiving after merge: team-workflow.md.
3. Expect conflicts only when two changes modify the same requirement. The second archive then conflicts in openspec/specs/<capability>/spec.md. Resolve it like a normal merge conflict; it means the two changes disagree about behavior.
4. Make the slash commands available in every worktree. openspec init / openspec update write skills and commands into your tool's folder (.claude/, .cursor/, etc.). A new worktree has them only if they are committed; otherwise run openspec update in it.
5. Rebase before archiving, so the delta applies to the current specs.