generating-patches/SKILL.md
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.
npx skillsauth add oaustegard/claude-skills generating-patchesInstall 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.
Generate portable git patch files from codebase modifications, enabling users to apply Claude's edits to their local repositories.
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.
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"
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
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:
git add first)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)
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 conflictsgit apply -R changes.patch — reverses a previously applied patchgit apply --3way changes.patch — enables three-way merge for conflictsWhen 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.
development
--- name: verifying-claims description: Check that a document's claims about code are actually true by reading the prose, the code, and the tests and reporting (or fixing) where they disagree. Use whenever the user wants to verify a README, guide, spec, or docstring still matches the code; whenever they mention documentation drift, doc-code sync, "is this still accurate", stale docs, or keeping docs/tests/code consistent; before publishing or merging a docs change; or as a periodic doc-accuracy
tools
Query, filter, and transform Markdown structurally with mq — a jq-like CLI for Markdown. Use to extract headings/sections/code-blocks/links from .md files, build a table of contents, pull code blocks of a given language, slice or reshape LLM prompt/output Markdown, or batch-transform docs. Triggers on "extract sections from this markdown", "get all the code blocks", "jq for markdown", "mq", or any structural query over Markdown that grep/Read can't do cleanly.
development
Composes single-file HTML artifacts (PR review writeups, status reports, incident postmortems, slide decks, design systems, prototypes, flowcharts, module maps, feature explainers, kanban boards, prompt tuners) from a small JSON spec instead of hand-written HTML/CSS/JS. Use when the user asks to "compare options side-by-side", requests an HTML version of a report or review or deck, asks for a flowchart, status update, postmortem, design system reference, interactive prototype, custom editor — or explicitly says "HTML artifact", "single HTML file", "self-contained HTML". Skip for ad-hoc HTML snippets (forms, emails, embedded widgets) where there's no template fit.
development
DAG workflow runner that encodes control flow in code, not prose. Use when a procedure has 3+ steps with branching, retries, or validation that must be enforced — gates as `when=`, edge contracts as `validate=`, predicate loops as `retry_until=`. The runner owns the graph; the LLM provides leaves. Also covers parallel execution, checkpoint resume, detached side-effects.