skills/merging-worktrees/SKILL.md
Use when merging parallel worktrees back together after parallel implementation, combining parallel development tracks, or unifying branches from dispatched parallel agents. Triggers: 'merge worktrees', 'combine parallel branches', 'integrate parallel work', 'all tracks complete', 'bring everything together'.
npx skillsauth add axiomantic/spellbook merging-worktreesInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
Merge parallel worktrees into unified branch after parallel implementation.
<ROLE> Integration Architect trained in version control precision and interconnectivity analysis. Your reputation depends on merging parallel work without losing features or introducing bugs. Every conflict demands 3-way analysis. Every round demands testing. No feature left behind, no bug introduced. </ROLE><ARH_INTEGRATION> Adaptive Response Handler for conflict resolution dialogue:
MUST:
Skipping steps = lost features. Rushing = broken integrations. Undocumented decisions = confusion. </CRITICAL>
When dispatching a conflict resolution subagent:
resolving-merge-conflicts via the Skill toolIf you catch yourself resolving a conflict without having loaded the skill: STOP. Dispatch a subagent that loads it. </CRITICAL>
| Input | Required | Description |
|-------|----------|-------------|
| base_branch | Yes | Branch all worktrees branched from |
| worktrees | Yes | List: worktree paths, purposes, dependencies |
| interface_contracts | Yes | Path to implementation plan defining contracts |
| test_command | No | Defaults to project standard |
| Output | Type | Description |
|--------|------|-------------|
| unified_branch | Git branch | All worktree changes merged |
| merge_log | Inline | Decision trail for each conflict |
| verification_report | Inline | Test results and contract status |
If NO to any: STOP and address before proceeding. </analysis>
Build dependency graph:
| Round | Criteria | Example | |-------|----------|---------| | 1 | No dependencies (foundations) | setup-worktree | | 2 | Depends only on Round 1 | api-worktree, ui-worktree | | N | Depends only on prior rounds | integration-worktree |
Create merge plan:
## Merge Order
### Round 1 (no dependencies)
- [ ] setup-worktree -> base-branch
### Round 2 (depends on Round 1)
- [ ] api-worktree -> base-branch (parallel)
- [ ] ui-worktree -> base-branch (parallel)
### Round 3 (depends on Round 2)
- [ ] integration-worktree -> base-branch
<RULE>ALWAYS create checklist via TodoWrite before starting merge operations.</RULE>
Dispatch: /merge-worktree-execute
Dispatch: /merge-worktree-resolve
Dispatch: /merge-worktree-verify
| Pattern | Scenario | Resolution | |---------|----------|------------| | Same Interface | Both implemented a shared interface method | Check contract for expected behavior. Choose contract-compliant version. If both match, synthesize best parts. If neither matches, fix to match. | | Overlapping Utilities | Both added similar helper functions | Same purpose: keep one, update callers. Different purposes: rename to clarify, keep both. | | Import Conflicts | Both added imports | Merge all imports, remove duplicates, sort per project conventions. | | Test Conflicts | Both added tests | Keep ALL tests from both. Ensure no duplicate test names. Verify no conflicting shared fixtures. |
| Error | Response | |-------|----------| | Uncommitted changes in worktree | AskUserQuestion: "Worktree [path] has uncommitted changes. Options: (1) Commit with message '[suggested]', (2) Stash and proceed, (3) Abort for manual handling" | | Tests fail after merge | STOP. Do NOT proceed to next round. Invoke systematic-debugging. Fix. Retest. Only continue when passing. | | Interface contract violation | CRITICAL: "Contract violation detected. Contract: [spec]. Expected: [X]. Actual: [Y]. Location: [file:line]. MUST fix before merge proceeds." |
If merge goes wrong after commit:
# Identify pre-merge commit
git log --oneline -5
# Reset to before merge (preserve working tree)
git reset --soft HEAD~1
# Or hard reset if working tree also corrupted
git reset --hard [pre-merge-commit-sha]
# Re-attempt with lessons learned
<FORBIDDEN>
- Blind ours/theirs acceptance without 3-way analysis
- Skipping tests between rounds ("I'll test at the end")
- Treating interface contracts as suggestions
- Merging code that violates contracts
- Ignoring type signature mismatches
- Leaving worktrees or stale branches after success
- Proceeding after test failure
- Not documenting merge decisions
</FORBIDDEN>
<RULE>Before completing worktree merge, verify ALL items. If ANY unchecked: STOP and fix.</RULE>
<FINAL_EMPHASIS> Your reputation depends on merging parallel work without losing features or introducing bugs. Every conflict requires 3-way analysis. Every round requires testing. Every merge requires verification. Interface contracts are mandatory, not suggestions. No feature left behind. No bug introduced. You'd better be sure. </FINAL_EMPHASIS>
testing
Use when creating new skills, editing existing skills, or verifying skills work before deployment. Triggers: 'write a skill', 'new skill', 'create a skill', 'skill doesn't work', 'skill isn't firing', 'edit skill', 'skill quality'. NOT for: general prompt improvement (use instruction-engineering) or command creation (use writing-commands).
development
Use when you have a spec, design doc, or requirements and need a detailed implementation plan before coding. Triggers: 'write a plan', 'create implementation plan', 'plan this out', 'break this down into steps', 'convert design to tasks', 'implementation order'. Also invoked by develop during planning. NOT for: reviewing existing plans (use reviewing-impl-plans).
testing
Use when creating new commands, editing existing commands, or reviewing command quality. Triggers: 'write command', 'new command', 'create a command', 'review command', 'fix command', 'command doesn't work', 'add a slash command'. NOT for: skill creation (use writing-skills).
development
Use when about to claim discovery during debugging. Triggers: "I found", "this is the issue", "I think I see", "looks like the problem", "that's why", "the bug is", "root cause", "culprit", "smoking gun", "aha", "got it", "here's what's happening", "the reason is", "causing the", "explains why", "mystery solved", "figured it out", "the fix is", "should fix", "this will fix". Also invoked by debugging, scientific-debugging, systematic-debugging before any root cause claim.