agentleFS
Sign inStart free
theonly1metheonly1me/shadowclone/.agents/skills/resolve-conflicts-by-intent/SKILL.md

resolve-conflicts-by-intent

Skill25 starsChanged 32 days agoMITView on GitHub

Use when Git reports conflicts during a merge, a rebase, or a cherry-pick. Also use it when the user says "fix the merge conflicts", "rebase onto main", or "the merge broke the build". Traces each side of a conflict to the change that it came from. Keeps both intents when they fit together, and asks when they do not. Then runs the checks on the combined result. Not for choosing what a new behavior should be (use `choose-by-consequence`).

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 10 are distinctive, and 0 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈10

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 0

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When the intents do not fit together, did you ask the user instead of picking one?

    line 19
  2. Distinctive:

    Do the checks pass on the combined result, and did you separate failures that were already on a parent?

    line 21
  3. Distinctive:

    Read the operation in progress, the conflicted paths, and the commits on each side.

    line 26
  4. Distinctive:

    Search the rest of the code for names and assumptions that either side changed.

    line 29
  5. Distinctive:

    Run the focused checks and the required merge check.

    line 30
  6. Distinctive:

    Read the combined diff against both intents, then finish the operation that the user asked for.

    line 31
  7. Distinctive:

    Keep schema changes, migrations, generated files, and tests consistent with each other.

    line 44
  8. Distinctive:

    Treat rename and delete conflicts as behavior changes.

    line 45
  9. Distinctive:

    Do not add a third design that neither side asked for.

    line 46
  10. Distinctive:

    Keep unrelated edits of the user, and follow the approval rules of the repository for Git operations.

    line 47

≈ “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

Resolve Conflicts by Intent

Use when

A merge, a rebase, or a cherry-pick stops with conflicted files. Each side of a conflict carries an intent. A correct resolution keeps each intent that still applies.

Gates

  1. For each conflicted file, can you name the commit and the intent behind each side?
  2. Does the resolution keep both intents when they fit together?
  3. When the intents do not fit together, did you ask the user instead of picking one?
  4. Did you check related names and code outside the conflict markers?
  5. Do the checks pass on the combined result, and did you separate failures that were already on a parent?
  6. Are all conflict markers gone, with no file left unmerged?

Process

  1. Read the operation in progress, the conflicted paths, and the commits on each side.
  2. For each side, read the commit message, the tests, and the design notes that explain it.
  3. Resolve each conflict in the current design. Keep the compatible parts of both sides.
  4. Search the rest of the code for names and assumptions that either side changed.
  5. Run the focused checks and the required merge check.
  6. Read the combined diff against both intents, then finish the operation that the user asked for.

Example

Situation: A rebase conflicts in a lock file. One side adds a package, and the other side updates a different package. Easy route: Take one whole side of the lock file, because a tool writes it. Hidden cost: One change is lost. The build passes on a machine that still has the old cache, and it fails for everyone else. Best route: Take the lock file from the base branch. Apply the package change from the other side again, and run the install so that the tool writes the lock file. Evidence: The new lock file has both packages. A clean install and the full check passed.

Guardrails

  • Take a whole side of a file only when nobody wants that side any more.
  • Keep schema changes, migrations, generated files, and tests consistent with each other.
  • Treat rename and delete conflicts as behavior changes.
  • Do not add a third design that neither side asked for.
  • Keep unrelated edits of the user, and follow the approval rules of the repository for Git operations.

Completion

  • Each conflicted file, with the intent that you kept from each side.
  • The check that covers the combined behavior, with its result line.
  • The operation that you finished, and the final commit hash.

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.

Check your setup, free