merge-protocol
Merge Protocol
Overview
Coordinate the final step of development: moving finished work into the mainline or disposing of it cleanly.
Core principle: Validate first, present choices, execute the selected path, then tidy up.
Announce at start: "I'm using the merge-protocol skill to finalize this work."
Prime Directive
NO INTEGRATION WITHOUT PASSING TESTS
No exceptions. No workarounds. No shortcuts.
When to Use
- All planned implementation work is done and committed
- The test suite runs green on the current branch
- Review feedback (if solicited) has been resolved
- You are ready to land, shelve, or abandon the branch
- Following delegated-execution or task-runner completion
- When a workspace-isolation branch needs teardown
Cognitive Traps
| Rationalization | Truth |
|---|---|
| "Tests were green an hour ago, no need to re-run" | Any commit since then invalidates stale results. Re-verify now. |
| "Merging is mechanical — nothing breaks" | Conflicts and integration regressions are real. Test the merged state. |
| "I'll remove the worktree tomorrow" | Orphaned worktrees pile up and create confusion. Remove them immediately. |
| "Let me just merge — skip the menu" | Always present all four paths. The human picks the workflow. |
| "Abandonment is obvious — no confirmation needed" | Destroying work permanently demands explicit typed confirmation. Always. |
The Workflow
Phase 1: Validate the Suite
Run the full test suite before anything else:
# Execute the project's test runner
npm test / cargo test / pytest / go test ./...
On failure:
Suite failures detected (<N> failing). Resolution required before proceeding:
[Display failing tests]
Integration cannot continue until the suite is green.
Halt here. Do not advance to Phase 2.
On success: Proceed to Phase 2.
Phase 2: Identify the Trunk Branch
# Determine the ancestor branch
git merge-base HEAD main 2>/dev/null || git merge-base HEAD master 2>/dev/null
Or confirm: "This branch diverged from main — correct?"
Phase 3: Offer Integration Paths
Present exactly these four choices:
Work is complete and verified. Select an integration path:
1. Merge into <trunk> locally
2. Push and open a Pull Request
3. Leave the branch untouched (I'll handle it myself)
4. Abandon this work entirely
Which path?
Keep it terse — no extra commentary.
Phase 4: Execute the Selected Path
Path 1: Local Merge
# Switch to trunk
git checkout <trunk>
# Sync with remote
git pull
# Integrate the feature branch
git merge <feature-branch>
# Validate the merged state
<test command>
# Remove the merged branch
git branch -d <feature-branch>
Then: Proceed to Phase 5 (Worktree Teardown)
Path 2: Pull Request
# Push the branch upstream
git push -u origin <feature-branch>
# Open the PR
gh pr create --title "<title>" --body "$(cat <<'EOF'
## Summary
<2-3 bullets describing the changes>
## Verification Steps
- [ ] <checklist items>
EOF
)"
Then: Proceed to Phase 5 (Worktree Teardown)
Path 3: Defer
Report: "Branch preserved. Worktree remains at ."
Do not tear down the worktree.
Path 4: Abandon
Require explicit confirmation:
Permanent deletion warning:
- Branch <name>
- All commits: <commit-list>
- Worktree at <path>
Type 'abandon' to proceed.
Wait for the exact word.
After confirmation:
git checkout <trunk>
git branch -D <feature-branch>
Then: Proceed to Phase 5 (Worktree Teardown)
Phase 5: Worktree Teardown
Applies to Paths 1, 2, and 4:
Detect if the current branch lives in a worktree:
git worktree list | grep $(git branch --show-current)
If so:
git worktree remove <worktree-path>
Path 3: Worktree stays intact.
Decision Matrix
| Path | Merges | Pushes | Keeps Worktree | Removes Branch |
|---|---|---|---|---|
| 1. Local merge | Yes | No | No | Yes |
| 2. Pull request | No | Yes | Yes | No |
| 3. Defer | No | No | Yes | No |
| 4. Abandon | No | No | No | Yes (force) |
Frequent Errors
Skipping validation
- Consequence: Broken code lands on trunk, failing PR created
- Correction: Always verify the suite before presenting paths
Open-ended prompting
- Consequence: "What now?" leads to ambiguity and stalling
- Correction: Present exactly four structured paths
Premature worktree removal
- Consequence: Destroys workspace needed for PR or deferred work
- Correction: Only tear down worktrees for Paths 1 and 4
Silent abandonment
- Consequence: Work deleted without the human's awareness
- Correction: Require typed "abandon" before any destructive action
Guardrails
Prohibited:
- Proceeding when tests fail
- Merging without validating the integrated result
- Deleting branches without explicit confirmation
- Force-pushing unless the human specifically asks
Mandatory:
- Run suite before presenting paths
- Present exactly four options
- Obtain typed confirmation for Path 4
- Tear down worktree only for Paths 1 and 4
Integration
Invoked by:
- godmode:delegated-execution (final step) — After all delegated tasks finish
- godmode:task-runner (final step) — After all execution batches complete
Complements:
- godmode:workspace-isolation — Tears down the worktree created by that skill
More from noobygains/godmode
intent-discovery
Use when starting any creative work - creating features, building components, adding functionality, or modifying behavior. Explores user intent, requirements, and design before implementation.
15agent-messaging
Use when dispatching subagents, composing prompts for teammates, structuring handoff reports, or managing context boundaries between agents. Covers both subagent prompts and team-level messaging.
15fault-diagnosis
Use when encountering any bug, test failure, or unexpected behavior, before proposing fixes
15quality-enforcement
Use when preparing code for commit, PR, or merge - covers linting, type safety, bundle budgets, coverage thresholds, complexity limits, dependency audit, and dead code detection
14pattern-matching
Use when contributing code to an existing project - guarantees that every new line mirrors the established conventions, naming schemes, architectural layering, directory layout, and stylistic choices already present in the codebase rather than drifting toward generic AI defaults
14review-response
Use when processing code review feedback before making changes, particularly when suggestions are ambiguous, technically suspect, or span multiple interdependent items - demands verification and technical rigor over compliance theater
13