Problem

/design and /plan both commit to the base branch (typically main) via git add -A at their checkpoint. Unlike /implement, they cannot use worktrees because their artifacts must be on main for /implement to branch from.

If two sessions accidentally run /design or /plan simultaneously on the same repo, they race on the working tree — both run git add -A and can commit interleaved, incomplete work.

Proposed Solution

Add an atomic lockfile guard (.beastmode/.worktree-lock) to both skills:

Acquire at skill start (before any work):

( set -C; echo "$$:<skill>:$(date -Iseconds)" > .beastmode/.worktree-lock ) 2>/dev/null

set -C (noclobber) makes this atomic — if the file already exists, the command fails. The lock content includes PID, skill name, and timestamp for diagnostics.

On conflict, read the lock and STOP:

BLOCKED — another beastmode session is active on this branch.
Lock held by: 12345:design:2026-04-22T10:30:00+02:00
Wait for it to finish, or remove .beastmode/.worktree-lock if the session crashed.

Release after the checkpoint commit:

rm -f .beastmode/.worktree-lock

Why not worktrees for design/plan?

Design and plan artifacts must land on main so that /implement (which branches from main) can read them. Using a worktree would add a merge step for zero benefit — the artifacts don't conflict with source code, and these phases are interactive (human-gated), so they're naturally sequential. The lockfile is a lightweight safety net for the accidental case.

Relationship to #559

The lock file (.beastmode/.worktree-lock) should be covered by the .beastmode/.gitignore proposed in #559. The *.lock pattern in that issue already covers it.

Reference implementation

See feature/design-plan-lockfile on the fork — minimal patch to design/SKILL.md and plan/SKILL.md.