Finish and integrate a development branch

How to integrate -- merge, rebase, or PR -- is a decision with a real wrong answer in this repo, not a formality to skip once the tests are green.

Also usessuperpowers

How to integrate a finished branch -- merge, rebase, or PR -- is a decision with a real wrong answer in this repo, not a formality to rubber-stamp once the tests are green. Run the changed-files audit first, make the integration decision deliberately, then verify what actually happened rather than what was supposed to happen, and prove the release wire itself before trusting that a green merge means the release is real.

Start here

One prompt to start

Implementation's done and tests pass -- audit the changed files first, then help me actually decide how this branch should get integrated (merge, rebase, or PR) rather than defaulting to whichever, and once it's in, verify the release artifact was actually produced and prove the release wire itself instead of trusting a green merge.

Needsconfab, superpowers, andon

Beats

Run these in order. Each prompt is copy-pasteable straight into Claude Code.

1. confab:confab-code-change

   Changed-files-scoped and advisory only -- it never blocks the commit -- so it belongs before the integration decision, not after.

2. superpowers:finishing-a-development-branch

   Fires once implementation is complete and tests pass, to decide how to integrate -- merge, rebase, or PR is a real decision, and making it implicitly is how branches get integrated the wrong way.

   Run this beat on its own

   implementation's done and tests pass -- help me decide how this branch should actually get integrated

3. superpowers:verification-before-completionalso in 3 other recipes

   • Rehearse a release path that has never succeeded
   • Triage an incident under time pressure
   • Incorporate external review feedback

   "It merged" and "it produced the artifact" are different claims, and only one of them is the one that matters.

4. andon:andon-verifyalso in 13 other recipes

   • Audit supply-chain pinning and dependencies
   • Investigate a job that reports success but changed nothing
   • Investigate a fix that did not stick
   • Investigate tests that pass while the code is broken
   • Root-cause a bugfix from a tracked issue
   • Build a new feature in an existing codebase
   • Collapse duplication hand-synced across N sites
   • Execute a written plan across parallel workstreams
   • Migrate a return shape or type representation
   • Propagate a vendored artifact to N copies
   • Audit your own agent and skill definitions for loop-reliability defects
   • Do oracle engineering and numerical V&V
   • Whole-branch review without re-trusting the branch's own self-assessment

   The release wire itself, proved rather than assumed just because the merge succeeded.

Worked example

Grounded in — why this beat order is trustworthy

This repo's own tagging rule: .github/workflows/cicd.yml fires on any v*.*.* tag and always publishes tools/werkstoff-cli, so a bare tag on a plugin group triggers a spurious PyPI publish -- <group>-v... tags fire plugin-release.yml instead. An integration decision with a real, irreversible wrong answer.

Do / Don't

• ✓Run the changed-files audit before making the integration decision, not after.
• ✓Decide deliberately how to integrate -- merge, rebase, or PR is a real decision in this repo, with a real wrong answer.
• ✓Verify the artifact was actually produced, not just that the merge succeeded -- those are different claims.
• ✓Prove the release wire itself with andon-verify rather than assuming it holds because the merge went through.

• ×Don't treat the integration method as a formality once tests are green -- merge, rebase, or PR is a decision with a real wrong answer here.
• ×Don't tag a plugin group without its prefix -- a bare tag fires the wrong release path and triggers a spurious PyPI publish.
• ×Don't accept 'it merged' as evidence that 'it produced the artifact' -- verify the second claim, not just the first.