superpowers-finishing-a-development-branch
Use when all tasks in a plan are complete — run the full ship pipeline from code to merged PR: detect base branch, verify clean working tree, merge base with conflict gate, run tests with hard gate on
SKILL.mdskills/superpowers-finishing-a-development-branch/SKILL.md
GitHubShip — Finish and Publish
Core principle: Never skip tests or reviews. Completeness first.
This skill replaces the old "4 options" flow with a full automated pipeline that ends with a PR.
Step 0: Detect Base Branch
BASE_BRANCH=$(git symbolic-ref refs/remotes/origin/HEAD 2>/dev/null | sed 's|refs/remotes/origin/||')
CURRENT_BRANCH=$(git branch --show-current)
echo "Base: ${BASE_BRANCH:-main}"
echo "Feature: $CURRENT_BRANCH"
Step 1: Verify Clean Working Tree
git status --porcelain
If dirty:
- Offer to stash:
git stash push -m "wip: ship pipeline $(date)" - Or commit as WIP:
git commit -m "WIP: ship pipeline $(date)" --allow-empty
Proceed only with a clean tree.
Step 2: Merge Base
git fetch origin "$BASE_BRANCH" --quiet 2>/dev/null || true
echo "Merging base into feature branch..."
git merge "origin/$BASE_BRANCH" --no-edit
If merge conflicts → STOP. Report conflicts. Do not proceed.
Step 3: Run Tests
Run the project's test suite:
# Run the test command (adjust to project)
npm test 2>&1 || pytest 2>&1 || bun test 2>&1 || cargo test 2>&1 || true
If tests fail:
- First check: are failures in the current branch? → Fix them
- Second check: are failures pre-existing on base? → Report but don't block
- If unclear → STOP. Do not ship with failing tests.
Hard gate: If the current branch has failing tests, fix them before proceeding.
Step 4: Coverage Audit
Trace every code path in the diff and map user flows:
git fetch origin "$BASE_BRANCH" --quiet 2>/dev/null || true
BASE_SHA=$(git rev-parse "origin/$BASE_BRANCH")
HEAD_SHA=$(git rev-parse HEAD)
git diff "$BASE_SHA..$HEAD_SHA" --stat
- Codepath tracing — For each changed function, trace: happy path, nil/null, error, empty state
- User flow mapping — Map changed code to user-facing flows it affects
- Gap identification — Which paths have no test?
- Gap remediation — Write tests for critical gaps now, or flag informational gaps
Step 5: Plan Completion Audit
Read the implementation plan (if one exists):
ls docs/superpowers/plans/*.md 2>/dev/null | head -5
cat docs/superpowers/plans/*.md 2>/dev/null | head -200 || echo "No plan found"
Check if all plan items are addressed in the diff:
| Plan Item | Status |
|---|---|
| [item 1] | DONE / NOT DONE / PARTIAL |
| [item 2] | DONE / NOT DONE / PARTIAL |
If any NOT DONE items exist: STOP and report. Do not ship incomplete work.
Step 6: Pre-Landing Review
Run superpowers-requesting-code-review against the diff. If it finds CRITICAL issues, fix them first.
Step 7: Version Bump
Auto-detect bump type:
echo "Changes since last version tag:"
git log --oneline $(git describe --tags --abbrev=0 2>/dev/null || echo "origin/$BASE_BRANCH")..HEAD --format="%s" | head -20
| Type | Trigger |
|---|---|
| MICRO | Docs, comments, typos, formatting |
| PATCH | Bug fixes, minor improvements |
| MINOR | New features, breaking changes |
| MAJOR | Breaking changes, API redesign |
Auto-decide MICRO and PATCH. Ask the user for MINOR and MAJOR.
# Auto-bump MICRO/PATCH
CURRENT_VERSION=$(git describe --tags --abbrev=0 2>/dev/null || echo "v0.0.0")
echo "Current version: $CURRENT_VERSION"
echo "Suggested bump: [MICRO/PATCH] — [reason]"
Step 8: CHANGELOG
Generate changelog from commit history since last version:
git log --oneline $(git describe --tags --abbrev=0 2>/dev/null || echo "origin/$BASE_BRANCH")..HEAD --format="%s"
Categorize commits into:
- Added — New features
- Changed — Changes to existing functionality
- Fixed — Bug fixes
- Improved — Performance, refactoring, quality
- Docs — Documentation
If CHANGELOG.md exists, prepend new entries. Format:
## [VERSION] — YYYY-MM-DD
### Added
- [feature description] — #[PR]
### Fixed
- [fix description] — #[PR]
Step 9: TODOs Update
cat TODOS.md 2>/dev/null || echo "No TODOs.md found"
- Mark completed TODOs as done
- Remove TODOs that are no longer relevant
- Flag TODOs that reference code that no longer exists
Step 10: Commit
Split into bisectable logical chunks:
git add -p
echo "Files staged:"
git diff --cached --stat
Commit message format:
git commit -m "[type]: [brief description]
[Longer description if needed]
Reviewed with: superpowers-requesting-code-review"
For multiple commits: commit related changes together, unrelated changes separately.
Step 11: Push
git push -u origin "$CURRENT_BRANCH"
Step 12: Create PR
echo "Creating PR from $CURRENT_BRANCH to $BASE_BRANCH..."
gh pr create \
--base "$BASE_BRANCH" \
--head "$CURRENT_BRANCH" \
--title "[VERSION] — [summary]" \
--body "$(cat <<'EOF'
## What changed
[auto-generated from changelog]
## Review evidence
- [x] Tests pass
- [x] Coverage audit complete
- [x] Plan items addressed
- [x] Code review passed
## TODOs updated
[yes/no — checked]
## Checklist
- [ ] Approved
- [ ] CI green
- [ ] Ready to merge
---
_Shipped with superpowers_
EOF
)"
Step 13: Review Readiness Dashboard
Before presenting the final summary, confirm all gates:
REVIEW READINESS DASHBOARD
══════════════════════════════════════════
Test results: [PASS / FAIL] · [N] failures
Coverage audit: [COMPLETE / INCOMPLETE] · [N] gaps
Plan completion: [DONE / N items pending]
Code review: [PASSED / N issues] · [N] critical
TODOs updated: [YES / NO]
Version bumped: [VERSION]
CHANGELOG updated: [YES / NO]
PR created: [URL]
══════════════════════════════════════════
VERDICT: [READY TO MERGE / BLOCKED — see above]
Step 14: Document Sync (optional)
If the project has documentation that references the changed code:
- Update README if API/behavior changed
- Update ARCHITECTURE.md if structure changed
- Update inline code examples
- Commit docs changes separately
Key Rules
- Never skip tests — hard gate, no exceptions
- Never merge with failing tests in the current branch
- Never skip the review — critical issues must be fixed
- Never ship incomplete work — plan audit gates shipping
- Auto-decide MICRO/PATCH — only ask for MINOR/MAJOR
When to Stop
Stop and ask for user input when:
- Tests fail in current branch
- Merge conflicts exist
- Critical review issues found
- Plan items are NOT DONE
- MINOR or MAJOR version bump needed
- More than 3 AUTO-FIX items needed (batch for approval)
Integration
- Called by:
superpowers-subagent-driven-development(final step) - Calls:
superpowers-requesting-code-review(Step 6) - Pairs with:
superpowers-using-git-worktreesfor isolated ship pipeline