df-new

# New work session (Delong) Start one focused idea in its own worktree, cut from the latest `origin/staging`, on a branch Graphite tracks from the start. Build it with plain commits on that branch. This worktree becomes the stack's home: review fixes for its PRs happen here later. Related: `/df-stack-extend` stacks new work on an existing stack; `/df-stack-submit` publishes. ## When NOT to Use - To build on top of an existing stack → `/df-stack-extend`. - To fix review comments on an open PR → work in that PR's worktree (`review-pr-comments`). ## Workflow ### 1. Get into a fresh worktree ```bash MAIN_ROOT=$(dirname "$(git rev-parse --path-format=absolute --git-common-dir)") CUR_ROOT=$(git rev-parse --show-toplevel) git -C "$MAIN_ROOT" fetch origin staging ``` Pick a short kebab-case `<slug>` from the task (ask only if `$ARGUMENTS` is empty). Then: - **Already in a linked worktree that is untouched**: this is the desktop app's per-session worktree. The test is `CUR_ROOT != MAIN_ROOT`, `git status --porcelain` is empty, and `git log origin/staging..HEAD` is empty. Reuse it. Run `git reset --keep origin/staging` so it starts on latest staging. Rename the branch with `git branch -m delong/<slug>`. - **Otherwise** (main checkout, or a worktree that already has work), create a new worktree. Never stack unrelated work on top of an existing branch. ```bash WT="$MAIN_ROOT/.claude/worktrees/<slug>" git -C "$MAIN_ROOT" worktree add "$WT" -b "delong/<slug>" origin/staging ``` Then call **EnterWorktree** with `path: "$WT"` so the session moves into it. Track the branch in Graphite on `staging`: ```bash gt track --parent staging --no-interactive ``` Run `./.worktreesetup` in the background from the worktree root. The SessionStart hook does not fire for a worktree created mid-session. If the task is clearly one project, scope the setup, for example `WORKTREESETUP_PROJECTS=desktop`. ### 2. Plan Follow the repo's AGENTS.md rule. For anything non-trivial (new feature, multi-file change, bug with unknowns), run the `ce-plan` skill first. Skip planning for one-liners and mechanical changes. Use the repo's preferred skills and agents for the area (see the Skill Priority table), for example `ui-dev` for desktop UI and `backend-py-dev` for aria-web. ### 3. Build - Dispatch subagents for independent pieces of the plan. Run them in parallel when they touch different files. Give each one the worktree path as its working directory. Don't use `isolation: "worktree"`: their changes must land in this worktree. - Commit as you go with plain `git commit` on `delong/<slug>`. Stage by explicit path. Never use `git add -A` or `-a`, and never stage `flow-server/vendor/vime`. - Keep commits shaped around ideas: one refactor, one feature step, and so on. `/df-stack-submit` splits the stack along commit lines, so clean commits now mean an easy split later. - Don't run `gt submit`, and don't push. Publishing is `/df-stack-submit`'s job. - Run the touched project's typecheck, lint and tests before saying a step is done. ### 4. Hand back Report what was built, the commits, what was verified, and what wasn't. End with the next step: `/df-stack-submit` when ready for review. ## Common Pitfalls - Never check out `staging` or another stack's branch here. Base on `origin/staging`. Graphite updates local `staging` itself during `gt sync`. - Never build in the main checkout. A stack branch checked out there is skipped by every Graphite restack run from the stack's worktree. - Don't run `git stash` (it's shared across worktrees). Use a WIP commit instead. - One idea per session. If the work grows a second, unrelated idea, say so. Suggest finishing this one and starting the other with `/df-new` or `/df-stack-extend`.