Personal forks of open-source apps that auto-track upstream. Each change you make is saved in plain words, in a PATCH.md. On every upstream release your changes go back on top, and when one no longer applies, an agent rebuilds it from what you wrote, in your fork's own GitHub Actions, on your Claude or ChatGPT plan.

Fork something at autofork.com, or from a terminal:

npx github:AVGVSTVS96/autofork fork pingdotgg/t3code

That forks the repo, clones it and adds the autofork workflow, plus one line under your README's title saying it's a personal fork that updates itself with autofork. That line is a patch like any other, .autofork/fork-readme; to drop it, delete the line and the folder. Set CLAUDE_CODE_OAUTH_TOKEN first (claude setup-token prints one) and it adds that secret too. Already have a fork? Run init owner/repo inside it.

Patches

Each change you keep is a folder in .autofork/:

.autofork/context-usage/
├── PATCH.md              what it does and why
└── context-usage.patch   the diff

Change the code, write the PATCH.md, and save the diff:

npx github:AVGVSTVS96/autofork save context-usage

Or just write the PATCH.md and push. The workflow has an agent build it.

Patches go on in the alphabetical order of their folder names, each on top of the ones before it. A patch the others need, like one that makes a package split out of a monorepo build on its own, needs a name that sorts first, like 0-standalone.

A PATCH.md is plain prose: what you want and why, and why it's built the way it is, not which lines it touches, so an agent can rebuild it on whatever upstream looks like next. This is the one in my T3 Code fork:

Always show the thread's context usage in the composer.

Build it on whatever T3 Code shows for context at the time. Right now that's
the compact button next to send, which only shows up once a thread gets big:
keep it there all the time with the context number, as just the icon, without
the "Full"/"Compact" text. Clicking it still makes the next send compact first.

If T3 Code knows whether the prompt cache is still warm, say so in the
button's tooltip.

Once T3 Code shows context usage all the time by default, this patch is done.

A patch can also be a whole fork you've taken over. hex-voice started as David Mokos's Expo voice app template and is mine to maintain now. Its one patch holds every change, and its PATCH.md says what to take if upstream ever moves:

If upstream ever updates, treat it as a new fork rather than the line this one
follows: bring in anything clearly valuable, judged by what these
customizations show this app cares about, like fixes, Expo and dependency
updates, and better audio, call handling or Persona animations. Leave out
what only serves the template's server, tools or web app.

Where upstream's opinions differ from ours, weigh ours more heavily: keep
hex-voice's behavior and design, and take upstream's change only where it
doesn't undo them.

Updates

When upstream publishes a release, the workflow rebuilds your fork on it. Patches that still apply go in with git. When one doesn't, or your setup or verify command fails with it, an agent rebuilds it from its PATCH.md. Git applies what still fits first and marks the conflicts, so the agent starts with only the files left to finish, and with the last lines the command printed when that's what failed. Once verify passes, the result is pushed as a signed commit.

When upstream ships its own version of one of your patches, autofork stops applying it and opens an issue on your fork. The fork takes upstream's version, and the agent isn't called for that patch again. You decide what happens next: delete the patch's folder to keep upstream's, or say in its PATCH.md how yours differs and delete its UPSTREAM.md to bring yours back.

The agent only runs when a release breaks a patch. Between releases, the workflow's hourly check is git only and ends in seconds. A rebuild that fails or runs out of time isn't retried until upstream or your fork changes; running the workflow by hand always retries.

Commit straight to your fork and the workflow leaves it alone until upstream moves. A rebuild would drop changes no patch holds, so then it stops once and lists them: save them as a patch and push, and the next run syncs.

A sync never changes .github/: it's your fork's own, and a workflow's GitHub token can't push workflow files. When upstream changes a workflow your fork keeps a copy of, autofork opens an issue, so you can bring the change over or delete your copy.

To follow a channel like nightlies, put its tag pattern in follow, like "v*-nightly.*". The fork then moves to the newest release whose tag matches, and init lists the channels upstream publishes. To follow a branch instead, set "follow": "main". Every upstream commit then gets the same treatment.

An app that updates itself, like a desktop app, updates from upstream's releases until the fork publishes its own. The skill's release steps set that up once: a release workflow that runs after each sync, the updater pointed at the fork, and builds signed so they can update without upstream's keys or certificates. My T3 Code fork works this way.

Agents

npx skills add AVGVSTVS96/autofork

Your agent then knows how to fork a repo and keep its changes as patches.

Config

.autofork/config.json:

{
  "upstream": "pingdotgg/t3code",
  "follow": "releases",
  "setup": "pnpm install --no-frozen-lockfile --ignore-scripts",
  "generated": ["pnpm-lock.yaml"],
  "verify": "pnpm --filter @t3tools/web typecheck"
}

key
upstream	owner/repo, or any git URL
follow	releases (the release GitHub marks as upstream's latest, or its newest version tag when it has no GitHub releases), a channel (a tag pattern like v*-nightly.*: the newest release whose tag matches) or a branch. Default: releases, or the default branch if upstream has no releases
setup	the command that installs dependencies in the rebuild, like pnpm install --no-frozen-lockfile. It runs before verify and the agent, and again once the patches under them change, and the agent is told it ran
generated	files setup writes, like lockfiles. They're left out of patches and rebuilt by setup once the patches are in, so they never conflict
verify	the command that checks a build
agent	the command that rebuilds a patch, prompt on stdin. Default: Claude Code when CLAUDE_CODE_OAUTH_TOKEN is set, otherwise Codex when it's signed in (a CODEX_AUTH secret holding ~/.codex/auth.json)
green	when following a branch, false takes upstream's newest commit even when its checks failed

.github/workflows/autofork.yml is yours too: change how often it checks, and set up the tools setup and verify need (Node, Bun, Rust) before the autofork step, with your package manager's cache on so setup is quick. The action takes heal: false to apply what still fits without calling the agent, if you want rebuilds on one schedule and heals on another. With Codex, give it codex-auth-url and id-token: write so a refreshed sign-in is saved back to the secret.

Commands

$ npx github:AVGVSTVS96/autofork --help
autofork: Customized forks that maintain themselves.
Personal forks of open-source apps that auto-track upstream.

Usage:
  autofork fork <owner/repo>    fork it on GitHub, set it up and push
  autofork init <owner/repo>    set up a fork you already have, from inside it
  autofork save <id>            save your changes as the patch in .autofork/<id>
  autofork status               your patches, and changes no patch holds yet
  autofork sync                 rebuild on upstream; an agent heals what breaks

Options for fork and init:
  --follow <what>               releases (upstream's Latest), a channel of them
                                by tag, like 'v*-nightly.*', or a branch.
                                Default: releases, or the default branch if
                                upstream has none
  --setup <command>             the command that installs dependencies
  --generated <files>           files setup writes, like lockfiles, comma
                                separated: rebuilt by setup, never patched
  --verify <command>            the command that checks a build

Roadmap

autofork keeps forks current today. The agent behind it is meant to grow into automatic maintenance of any codebase, and autofork is its first packaging: set up in one step, with an app to see and manage your forks and what they cost.

Just landed

• Forks whose upstream can't pass verify on its own, like a package split out of a monorepo: when verify fails, the sync finds the patch that breaks it, even when that's the one that makes the package build, instead of stopping at upstream. init and fork take --setup and --generated.
• Rebuilds that start where git leaves off, from a field report on a large fork: the agent gets the patch applied as far as it goes with conflict markers, only the files left to finish, verify's last lines when it failed, and dependencies installed by setup, and lockfiles are rebuilt instead of patched.
• Workflows a fork keeps from upstream, like its release workflow: a sync opens an issue when upstream changes one, since a sync leaves .github/ to the fork.
• Rebuilds checked by upstream's own checks on the code they touch, and verify picked from upstream's CI so it covers what the patches change.
• Release steps for apps that update themselves that sign for whatever the updater checks, with Electron as one example.
• Patches that still apply but fail verify, rebuilt by the agent like ones that no longer apply, instead of failing the sync until someone steps in.

What we're building next

• Limits on what the agent spends, set by you: rebuilds a month, spend a month and spend per rebuild, with defaults like 10 rebuilds, $200 a month and $20 a rebuild at API prices. A run near the limit finishes instead of being thrown away.
• What each fork's rebuilds cost, from their token counts at API prices.
• A dashboard on autofork.com to see your forks and what each costs, and set its budget.
• How often a fork checks upstream, set by you and run on time. GitHub's scheduled runs can start hours late.
• An option to re-check every change against what you asked for on each new release, not only when a release breaks it.
• A first install of a fork's app on a Mac that needs no developer certificate from you.

Open question

• Whether autofork.com only shows forks that run themselves in their own Actions, or can also run the same engine for you.

History

• May 2026: pi-patcher keeps patches to the pi coding agent working across updates. Proof of concept.
• June: PATCH.md, the format.
• July: herdr, the first fork rebuilt from patches. Proof of concept.
• October: forks of Claude Code's plugins, Buzz and T3 Code, in daily use.
• October: autofork.

Contributing

See CONTRIBUTING.md.

License

MIT