Dw Start

dw-start — a worktree per change, built as soon as it's claimed

Mechanics plus one field write, then straight into the build: a shaped change gets its own worktree and branch, the claim is committed, and dw-next takes over. The approved CHANGE.md from dw-shape was the checkpoint — nothing here asks again.

What it reads and writes

Reads .ai/work/*/CHANGE.md (written by dw-shape) to find the unclaimed changes. Writes exactly one thing itself: the chosen change's branch: flips from unclaimed to the new branch — the claim — committed immediately. .ai/ is tracked in git, and an uncommitted claim is invisible to every other session, which is the race this protocol closes. Everything after that is dw-next's.

Workflow

1. Pick the change

• $ARGUMENTS names a slug → that change — but if its branch: is no longer unclaimed, say

which branch owns it and stop: stealing a change is the user's edit to make, never yours.

• Bare → list every CHANGE.md with branch: unclaimed, newest first, and ask.
• A description with no shaped change behind it → shape first: offer dw-shape here in the main

tree, then come back.

Then confirm the doc is committed: git status --porcelain .ai/work//. A worktree checks out committed state only — if dw-shape's commit step was skipped, do it now, the way dw-git does.

2. Create and enter

bash "${CLAUDE_PLUGIN_ROOT}/scripts/worktree.sh" create 

Run it from the main tree while it sits on the default branch. The script refuses every start it can see — a branch named ` or worktree-, locally **or on origin**, and a worktree already at .claude/worktrees/ — so a refusal means report and stop, never retry. A claimed branch: field is the one start it cannot see, which is why step 1 checks it. On stdout it prints the worktree's absolute path and nothing else; **everything it says on stderr is for you to act on**: which .worktreeinclude files it copied in, and what the worktree still needs. Enter the worktree (the EnterWorktree tool where the session offers it, else cd` to the printed path).

3. Claim, then install

• In the worktree, flip the change's branch: unclaimed to the verbatim output of

git rev-parse --abbrev-ref HEAD, change nothing else, and commit that one edit — the way dw-git does.

• Then run the project's install command before anything else — this is a required step, not an

offer, and create's readiness report names the command. A fresh worktree has no node_modules/, which is merely inconvenient, but on a repo using husky it also has no .husky/_/: that directory is generated by the install and gitignored, so git finds no hooks and every commit here skips the pre-commit gate without printing a thing. Committing before installing produces unformatted, unlinted commits that look fine.

4. Build — and the parallel recipe

If other changes are still unclaimed, first print the recipe for each: new terminal → claude -w , run while the main tree is on the default branch (the branch will be worktree-, a spelling the loop's claim matching strips) — then dw-next in that session offers the claim.

Then invoke dw-next bare and let it run: report, then every remaining task, one commit each, stopping only at a decision or an irreversible step.

Next: dw-check for a look at what got built, or dw-land once the boxes are all ticked.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: dominikwozniak
• Source: dominikwozniak/dw-solo-skills
• License: MIT

Install and usage instructions live in the source repository linked above.