agentleFS
oaustegardoaustegard/claude-skills/generating-patches/SKILL.md

generating-patches

Skill158 starsChanged 8 months agoMITView on GitHub

Generates git patch files from codebase modifications for local application. Use when user mentions patch, diff, export changes, bring changes back, apply locally, or after editing uploaded codebases.

The file

We split this skill into the rules it gives an agent

6 rules. About 0 are common, 5 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

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

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    Verify git is available and the working directory is a git repository (or can be initialized as one):

    line 18
  2. Distinctive:

    If working with an uploaded codebase that lacks git history, initialize and create a baseline commit before making edits:

    line 24
  3. Distinctive:

    After completing edits, generate a unified diff:

    line 34
  4. Distinctive:

    No changes detected: Verify files were actually modified.

    line 72
  5. Very specific:

    Always output to /mnt/user-data/outputs/ with a descriptive filename.

    line 78
  6. Distinctive:

    When requested, generate a pull request description from the patch:

    line 118

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

Generating Patches

Generate portable git patch files from codebase modifications, enabling users to apply Claude's edits to their local repositories.

When to Use

Activate after modifying files in an uploaded codebase when the user needs to transfer changes back to their local environment. Typical workflow: user uploads zip → Claude edits files → this skill exports changes as a patch.

Prerequisites

Verify git is available and the working directory is a git repository (or can be initialized as one):

git status 2>/dev/null || git init

If working with an uploaded codebase that lacks git history, initialize and create a baseline commit before making edits:

git init
git add -A
git commit -m "Baseline: original uploaded state"

Generating the Patch

After completing edits, generate a unified diff:

# For uncommitted changes (working tree modifications)
git diff > /mnt/user-data/outputs/changes.patch

# If changes are staged but not committed
git diff --cached > /mnt/user-data/outputs/changes.patch

# For both staged and unstaged
git diff HEAD > /mnt/user-data/outputs/changes.patch

For committed changes (preserves commit messages and metadata):

# All commits since baseline
git format-patch --stdout baseline..HEAD > /mnt/user-data/outputs/changes.patch

# Or specify number of commits
git format-patch --stdout -n 3 > /mnt/user-data/outputs/changes.patch

Handling Edge Cases

Binary files: Git diff excludes binaries by default. Warn the user if binary files were modified:

git diff --name-only --diff-filter=M | xargs file | grep -v "ASCII\|UTF-8\|empty"

Large patches: For extensive changes, consider splitting by directory or file type:

git diff -- "*.py" > /mnt/user-data/outputs/python-changes.patch
git diff -- src/ > /mnt/user-data/outputs/src-changes.patch

No changes detected: Verify files were actually modified. Common issues:

  • Edits made to copies outside the git tree
  • Files not tracked by git (need git add first)

Output Requirements

Always output to /mnt/user-data/outputs/ with a descriptive filename. Provide the download link:

[Download changes.patch](computer:///mnt/user-data/outputs/changes.patch)

User Instructions

Include these instructions with every patch delivery:


To apply this patch locally:

cd /path/to/your/repo

# Preview changes (dry run)
git apply --check changes.patch

# Apply to working tree
git apply changes.patch

If using format-patch output (includes commit metadata):

git am changes.patch

Troubleshooting:

  • git apply --reject changes.patch — applies what it can, writes .rej files for conflicts
  • git apply -R changes.patch — reverses a previously applied patch
  • git apply --3way changes.patch — enables three-way merge for conflicts

Optional: PR Description

When requested, generate a pull request description from the patch:

# Extract summary of changes
echo "## Summary"
git diff --stat
echo ""
echo "## Changes"
git diff --name-only | while read f; do echo "- \`$f\`"; done

Combine with a brief description of what was changed and why, suitable for GitHub PR body.

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.