BUCKYVERSE

Pluck planner handoff (copy and fill in)

Use this when handing off after xp_work pluck. Replace placeholders in angle brackets.

HARD STOP

Do NOT invoke superpowers:finishing-a-development-branch at any point in this workflow.

Do not present merge, PR, keep-branch, or discard-branch options to the user. Do not ask what the user wants to do next after verification passes. Pluck owns the entire completion path. When pre-merge verification succeeds, immediately execute the local squash-merge procedure defined below. No other completion skill may replace it.

Instructions for the chosen planner

You are continuing a pluck workflow from xp_work: queued work was selected from a tracking file, and planning mode was chosen (<native planning | superpowers:brainstorming | superpowers:systematic-debugging>). The user must have already selected this mode (or pre-declared it in the pluck message, or it was auto-selected because the item is a BUG)—do not skip that gate.

You must

  1. Claim precondition — The claim marker (**Pluck status:** In progress (started YYYY-MM-DD)) has already been committed to the base branch before this handoff. Do not re-add, edit, or remove the marker on the feature branch. The base branch is the source of truth for queue coordination.

  2. 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 pluck/.
    • If you are on the base branch, create a feature branch before implementation. Do not implement directly on the base branch.
    • The claim marker is already on the base branch. A worktree created from the base branch inherits the marker automatically. Do not add a second **Pluck status:** line on the feature 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.
    • If the mode is superpowers:systematic-debugging, run that flow first to diagnose the root cause. Once diagnosis is complete, proceed to superpowers:writing-plans to plan the fix, 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.

  3. 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.

3b. Run .skills/dev/xp_work/scripts/pluck_merge.sh — After implementation is complete and the feature branch is ready, call the deterministic merge script. This script handles sync with base, checkpoint commit, verification, squash merge with section yank from the queue file, CHANGELOG update, post-merge verification, and branch/worktree cleanup — producing one atomic commit on the base branch.

.skills/dev/xp_work/scripts/pluck_merge.sh \
  --base-branch "$BASE_BRANCH" \
  --feature-branch "$(git branch --show-current)" \
  --source-file "<SOURCEFILE>.md" \
  --entry-id "<PREFIX-N>" \
  --summary "<concise summary of what shipped>" \
  --snapshot "<path to snapshot file>" \
  --verify-cmd "<repo's canonical verification command>" \
  --worktree-path "<.worktrees/pluck-... 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 = work/<SOURCEFILE>.md, source-id = the plucked section's PREFIX-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