agentleFS
TJaenichenTJaenichen/claude-code-harness/skills/project/merge-main/SKILL.md

merge-main

Skill0 starsChanged 3 months agoMITView on GitHub

Fetch and merge origin/main into the current branch and resolve conflicts.

5 other projects use a version of this.

Adopted by

Most recently taken up by

The file

Show its rules and text

We split this skill into the rules it gives an agent

14 rules. 0 are common, 11 are distinctive, and 3 are very specific to this project.

  • 0

    Common

    Most of the 5 edited versions we read keep these.

  • 11

    Distinctive

    This author's own choices. Worth a look.

  • 3

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Run git rev-parse --abbrev-ref HEAD to get the current branch name.

    line 17
  2. Distinctive:

    Run git status --porcelain to check for uncommitted changes.

    line 18
  3. Distinctive:

    If there are uncommitted changes, stop and warn the user.

    line 19
  4. Distinctive:

    Run git fetch origin to get the latest remote state.

    line 23
  5. Very specific:

    Run git log --oneline HEAD..{main-branch} --count (use git rev-list --count HEAD..{main-branch}) to see how many commits are incoming.

    line 24
  6. Distinctive:

    If 0 commits incoming, report "Already up to date" and stop.

    line 25
  7. Distinctive:

    If the merge reports conflicts:

    line 30
  8. Very specific:

    Run git diff --name-only --diff-filter=U to list conflicted files.

    line 31
  9. Distinctive:

    Both sides changed: Use your best judgment based on the code context.

    line 37
  10. Distinctive:

    After all conflicts are resolved, run git commit --no-edit to complete the merge.

    line 40
  11. Distinctive:

    If there are uncommitted changes, do not proceed — ask the user first

    line 67
  12. Distinctive:

    If a conflict resolution is ambiguous, flag it clearly in the report so the user can review

    line 68
  13. Very specific:

    Always use --no-edit on merge/commit to avoid interactive editors

    line 69
  14. Distinctive:

    After completion, do NOT push — leave that to the user

    line 70

“Common” is measured: kept by at least 6 in 10 of the 5 edited versions of this file we could read. “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

Merge Main into Current Branch

Merge the latest origin/main (or origin/master) into the current working branch, handle conflicts, and produce a summary report.

Your Task

Execute the following steps in order:

1. Pre-flight checks

  1. Run git rev-parse --abbrev-ref HEAD to get the current branch name.
  2. Run git status --porcelain to check for uncommitted changes.
    • If there are uncommitted changes, stop and warn the user. Ask if they want to stash or commit first. Do NOT proceed with a dirty working tree.
  3. Determine the main branch: check if origin/main exists (git rev-parse --verify origin/main). If not, fall back to origin/master.

2. Fetch and merge

  1. Run git fetch origin to get the latest remote state.
  2. Run git log --oneline HEAD..{main-branch} --count (use git rev-list --count HEAD..{main-branch}) to see how many commits are incoming.
    • If 0 commits incoming, report "Already up to date" and stop.
  3. Run git merge {main-branch} --no-edit.
  4. Capture the merge output.

3. Handle conflicts

If the merge reports conflicts:

  1. Run git diff --name-only --diff-filter=U to list conflicted files.
  2. For each conflicted file: a. Read the file to see the conflict markers (<<<<<<<, =======, >>>>>>>). b. Analyze the conflict:
    • Theirs-only changes (our side is unchanged around the conflict): accept theirs.
    • Ours-only changes (their side is unchanged around the conflict): accept ours.
    • Both sides changed: Use your best judgment based on the code context. Prefer combining both changes when they don't overlap logically. If the conflict is complex or ambiguous, resolve it conservatively and flag it in the report. c. Edit the file to remove conflict markers and apply the resolution. d. Run git add {file} to mark it resolved.
  3. After all conflicts are resolved, run git commit --no-edit to complete the merge.

4. Post-merge report

Generate a clear report with:

## Merge Report: {main-branch} → {current-branch}

### Summary
- **Incoming commits:** {count}
- **Conflicts:** {count} ({list of files, or "None"})
- **Status:** {Merged cleanly | Merged with conflict resolution}

### Incoming Commits
{list of commits from git log --oneline HEAD..origin/main BEFORE the merge, i.e., the commits that were brought in}

### Conflict Resolutions (if any)
For each resolved conflict:
- **{filename}**: {brief description of what conflicted and how it was resolved}

### Files Changed
{git diff --stat HEAD~1 summary showing files changed, insertions, deletions}

Important

  • Never force-push or reset — this skill is purely additive (fetch + merge)
  • If there are uncommitted changes, do not proceed — ask the user first
  • If a conflict resolution is ambiguous, flag it clearly in the report so the user can review
  • Always use --no-edit on merge/commit to avoid interactive editors
  • After completion, do NOT push — leave that to the user

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.