BUCKYVERSE

Work-complete planner handoff (copy and fill in)

Use this when handing off after work complete:. Replace placeholders in angle brackets.

Instructions for the chosen planner

You are continuing a work-complete workflow from xp_work: an iteration item was selected from work/ITERATION.md, and planning mode was chosen (<native planning | superpowers:brainstorming>). The user must have already selected this mode (or pre-declared it in the work-complete message)—do not skip that gate.

You must

  1. Plan and deliver on the feature branch — All implementation happens on the feature branch, never on the base branch.

    • Worktree setup — Follow ../procedures/worktree-setup.md with branch-prefix iter/.
    • If you are on the base branch, create a feature branch before implementation. Do not implement directly on the base branch.
    • If the mode is native planning, produce a visible plan before implementation: use the product's built-in planning UI, or post a short bullet plan in chat and wait for explicit user approval. Silent codebase exploration without a written plan does not satisfy native planning.
    • If the mode is superpowers:brainstorming, run that flow first. Checkpoint 1: after the user approves the written spec and before invoking superpowers:writing-plans, check git status --porcelain -- <spec-path>. If dirty, stage only the spec and commit: docs: incorporate user revisions to <spec-filename>. If staging or committing fails, stop before superpowers:writing-plans. Then implement.
    • All implementation commits go on the feature branch. By the end of this step, the feature branch must contain all non-work/ changes.

  2. Execution recommendation override — When you produce a completed plan through superpowers:writing-plans, ignore any static (recommended) label in the upstream agentic-worker handoff. Read skills/dev/xp_work/assets/execution-recommendation.md, evaluate the plan you just wrote against its matrix, emit exactly one recommendation sentence with the dominant reason, and then immediately continue with the chosen skill (superpowers:executing-plans or superpowers:subagent-driven-development). Do not ask the user to choose unless the chosen skill later requires user input for a different reason.

2b. Run scripts/pluck_merge.sh — After implementation is complete and the feature branch is ready, call the deterministic merge script. Despite its name, this script is shared by both pluck and work-complete workflows. It handles sync with base, checkpoint commit, verification, squash merge with section yank from the iteration file, CHANGELOG update, post-merge verification, and branch/worktree cleanup — producing one atomic commit on the base branch.

scripts/pluck_merge.sh \
  --base-branch "$BASE_BRANCH" \
  --feature-branch "$(git branch --show-current)" \
  --source-file "ITERATION.md" \
  --entry-id "<ITER-N>" \
  --summary "<concise summary of what shipped>" \
  --snapshot "<path to snapshot file>" \
  --verify-cmd "<repo's canonical verification command>" \
  --worktree-path "<.worktrees/iter-... path, if used>" \
  --changelog "<one-line CHANGELOG entry>"

Exit codes: 0=success, 1=pre-flight, 2=sync conflict, 3=squash conflict, 4=verification failure, 5=cleanup failure. On success, stdout contains the squash-merge commit hash.

On failure: Fix the issue on the feature branch and rerun the script. The script is idempotent for completed phases.

  1. Human verification gate — Follow ../procedures/human-verification-gate.md with source = ITERATION.md, source-id = the iteration section's ITER-N. If acceptance is queued, commit the ACCEPTANCE.md entry separately.

  2. CHANGELOG — If --changelog was passed to the script, the CHANGELOG update is already included in the squash merge commit. No separate step needed.

Do not