agentleFS
jmylchreestjmylchreest/aide/skills/worktree-resolve/SKILL.md

worktree-resolve

Skill19 starsChanged 3 months agoMITView on GitHub

Resolve and merge git worktrees after swarm completion

The file

Show its rules and text

We split this skill into the rules it gives an agent

13 rules. About 0 are common, 7 are distinctive, and 6 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈7

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 6

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    Check the AIDE worktree state file for metadata and status:

    line 25
  2. Very specific:

    Run these steps for every feat/* branch from swarm:

    line 61
  3. Distinctive:

    If conflicts shown, note them for manual resolution.

    line 94
  4. Very specific:

    When merge conflicts occur, do not use -X theirs or -X ours - these blindly discard changes.

    line 107
  5. Distinctive:

    Instead, resolve conflicts intelligently:

    line 109
  6. Very specific:

    Remove all conflict markers (<<<<<<<, =======, >>>>>>>)

    line 146
  7. Distinctive:

    If you cannot resolve the conflict (logic is contradictory, tests fail after resolution, or changes are too complex):

    line 166
  8. Very specific:

    Use -X theirs or -X ours to blindly pick one side

    line 188
  9. Distinctive:

    After all branches merged:

    line 226
  10. Distinctive:

    Continue with remaining branches: - do not block on one failure

    line 302
  11. Distinctive:

    Keep backups: - create a tag before bulk operations: git tag pre-swarm-merge

    line 356
  12. Very specific:

    Don't force delete: - use -d not -D to prevent deleting unmerged work

    line 357
  13. Distinctive:

    Report all failures: - never silently skip branches

    line 358

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Worktree Resolution

Recommended model tier: balanced (sonnet) - this skill performs straightforward operations

Merge all swarm worktrees back into the main branch after testing.

Workflow

1. List Active Worktrees

git worktree list

Check the AIDE worktree state file for metadata and status:

cat .aide/state/worktrees.json

Worktree Status Values:

  • active - Agent is still working on this worktree
  • agent-complete - Agent finished, ready for merge review
  • merged - Successfully merged to main

Only merge worktrees with status agent-complete.

Example state file:

{
  "active": [
    {
      "name": "story-auth",
      "path": ".aide/worktrees/story-auth",
      "branch": "feat/story-auth",
      "taskId": "story-auth",
      "agentId": "agent-auth",
      "status": "agent-complete",
      "createdAt": "2026-02-07T...",
      "completedAt": "2026-02-07T..."
    }
  ],
  "baseBranch": "main"
}

2. For Each Worktree Branch

Run these steps for every feat/* branch from swarm:

a) Test the Branch

# Checkout the worktree
cd .aide/worktrees/<name>

# Run tests
npm test  # or appropriate test command

# Run linting
npm run lint  # or appropriate lint command

# Check build
npm run build  # if applicable

b) Review Changes

# Back in main repo
git log main..feat/<name> --oneline
git diff main...feat/<name> --stat

c) Check Merge Compatibility

# Dry-run merge check
git merge-tree $(git merge-base main feat/<name>) main feat/<name>

If conflicts shown, note them for manual resolution.

3. Merge Clean Branches

For branches that pass tests and have no conflicts:

git checkout main
git merge feat/<branch-name> --no-edit

4. Handle Conflicts (Intelligent Resolution)

When merge conflicts occur, do not use -X theirs or -X ours - these blindly discard changes.

Instead, resolve conflicts intelligently:

Step 1: Attempt merge and identify conflicts

git merge feat/<name> --no-edit
# If conflicts occur, git will list the conflicted files

Step 2: For each conflicted file, read and analyze

# Read the file with conflict markers
cat <conflicted-file>

The conflict markers show:

<<<<<<< HEAD
[changes from main branch]
=======
[changes from feature branch]
>>>>>>> feat/<name>

Step 3: Resolve as a code review expert

Act as an expert code reviewer. For each conflict:

  1. Analyze both code paths - What was each change trying to achieve?
  2. Understand the intent - Are they complementary, overlapping, or contradictory?
  3. Modify the feature branch locally to incorporate main's changes while preserving the feature's logic
  4. Edit the file to remove conflict markers and combine both sets of functionality correctly

The resolution must:

  • Remove all conflict markers (<<<<<<<, =======, >>>>>>>)
  • Preserve the functional intent of BOTH changes
  • Be syntactically and semantically correct
  • Maintain code style consistency

Step 4: Verify and complete

# Stage the resolved files
git add <resolved-file>

# Run tests to verify the resolution works
npm test  # or appropriate test command

# If tests pass, complete the merge
git commit --no-edit

Step 5: Handle failure

If you cannot resolve the conflict (logic is contradictory, tests fail after resolution, or changes are too complex):

  1. Abort the merge to restore clean state:

    git merge --abort
  2. Record the failure using aide messaging:
    ./.aide/bin/aide message send --from=resolver --to=orchestrator "CONFLICT: Cannot merge feat/<name> - <brief reason>"

Binary location: The aide binary is at .aide/bin/aide. If it's on your $PATH, you can use aide directly.

  1. Skip this branch and continue with remaining branches
  2. Report at completion - list unmerged branches in the final summary for manual review

Do NOT:

  • Force through a broken resolution
  • Use -X theirs or -X ours to blindly pick one side
  • Get stuck - always abort and report if resolution fails

Example Resolution

Conflict:

<<<<<<< HEAD
function getUser(id: string): User {
  return db.users.find(u => u.id === id);
}
=======
function getUser(id: string): User | null {
  const user = db.users.find(u => u.id === id);
  return user ?? null;
}
>>>>>>> feat/null-safety

Analysis:

  • HEAD: Basic lookup returning User
  • Feature: Added null-safety with explicit null return

Resolution:

function getUser(id: string): User | null {
  const user = db.users.find((u) => u.id === id);
  return user ?? null;
}

Feature branch improved null safety - this is additive, keep it.

5. Cleanup

After all branches merged:

# Remove each worktree
git worktree remove .aide/worktrees/<name>

# Delete merged branches
git branch -d feat/<name>

# Prune any orphaned worktrees
git worktree prune

# Clear state file
rm .aide/state/worktrees.json

6. Final Verification

# Ensure all tests pass on main
git checkout main
npm test
npm run lint
npm run build

# Check no worktrees remain
git worktree list  # Should only show main

Summary Report

After resolution, report:

## Worktree Resolution Complete

### Merged Branches
- feat/task1-agent1: ✓ (3 files, +150/-20)
- feat/task2-agent2: ✓ (5 files, +280/-45)

### Skipped (conflicts/failures)
- feat/task3-agent3: Test failures in auth.test.ts

### Final Status
- All tests passing: ✓
- Lint clean: ✓
- Build successful: ✓

Quick Commands

# List all feat branches from swarm
git branch --list 'feat/*'

# Merge all clean branches at once (risky - prefer one at a time)
for branch in $(git branch --list 'feat/*' | tr -d ' '); do
  git merge $branch --no-edit || echo "Conflict in $branch"
done

# Bulk cleanup worktrees
git worktree list | grep '.aide/worktrees' | awk '{print $1}' | xargs -I {} git worktree remove {}

# Bulk delete feat branches (only if merged)
git branch --list 'feat/*' | xargs git branch -d

Failure Handling

If merge fails:

  1. Abort immediately: git merge --abort
  2. Record the failure:
    ./.aide/bin/aide message send --from=resolver --to=orchestrator "Merge failed: feat/<name> - <reason>"
  3. Continue with remaining branches - do not block on one failure
  4. Include in final report - list all failed branches with reasons

If tests fail after merge:

  1. Revert the merge: git revert -m 1 HEAD
  2. Record the failure with aide messaging
  3. Continue with other branches

If worktree removal fails:

# Force remove if necessary
git worktree remove --force .aide/worktrees/<name>

# Prune any orphaned entries
git worktree prune

Verification Criteria

After each merge:

# Verify merge commit exists
git log -1 --oneline

# Verify no uncommitted changes
git status --porcelain  # Should be empty

# Verify tests pass
npm test  # or appropriate test command

After full resolution:

# Verify all worktrees removed
git worktree list  # Should only show main worktree

# Verify all feature branches deleted (or list unmerged)
git branch --list 'feat/*'  # Should be empty for merged branches

# Verify main is clean
git status

# Verify final tests pass
npm test && npm run lint && npm run build

Safety Notes

  • Always test each branch before merging
  • Merge one at a time to isolate issues
  • Keep backups - create a tag before bulk operations: git tag pre-swarm-merge
  • Don't force delete - use -d not -D to prevent deleting unmerged work
  • Report all failures - never silently skip branches

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.