You just need git and a CLI agent.

Your coding agent, on repeat.One PR at a time.

Lumpcode is a CLI that runs your coding agent over a list of work items you define: one file, a group of files, a ticket. Each run pushes a branch you open as a pull request, so you review the work as normal diffs.

Some work is too big for one chat: a migration, a ticket backlog, a test suite to build out, duplicated logic to extract...

A lump is that whole campaign, described once in your repo and worked through over many PRs.

Get startedView on GitHub

npm install -g @lumpcode/cliApache 2.0. No account needed.

Your codebase

src/components/
├── UserCard/    index.tsx  index.test.tsx
└── DataTable/   index.tsx  index.test.tsx

The lump

.lumpcode/lumps/portToVue/config.json
{
  "contextListJson": {
    "COMPONENT": "src/components/{NAME}/index.tsx",
    "TEST": "src/components/{NAME}/index.test.tsx"
  },
  "prompt": {
    "promptTemplate": "Port @{COMPONENT} to Vue 3 and update @{TEST}.",
    "command": "cursor"
  }
}

{NAME} is the component name, so each component becomes one context holding both files.

What you review

origin
  • lump/portToVue/UserCardmerged
  • lump/portToVue/DataTablePR open

38 components still to go.

Your coding agent already handles one task: one branch, one pull request. Lumpcode runs the whole list.

Use it when

  • The same refactoring logic across hundreds of files
  • An ordered ticket backlog, one PR each
  • Docs, tests, hardening or cleanup that runs for weeks

And many more: retry until your test command passes, a Jira board as the context list, one lump waiting on another to merge... See the examples.

Safe by default

  • Works only on its own lump/… branches
  • Never merges anything itself
  • Copies the repo instead of editing your checkout
  • Runs one agent at a time by default

What you do.

1

Write the lump

One config file says what to work on, what to prompt, and which agent to use. Every item it matches becomes one context.

2

Run it

Lumpcode takes the next unfinished context, runs your agent on it, then commits the result and pushes a branch. One context per branch by default; group several when the diffs are small.

3

Review, adjust, then merge

Open that branch as a pull request. Push fixes to it if the agent got something wrong, and merge when it looks right. The next run skips what you merged and picks up the next context.

A list, a prompt, an agent. Start with a JSON file. The same CLI runs TypeScript configs, multi-step pipelines, and validation that retries until it passes. Start here.

One folder. Every loop.

A lump is a folder in your repo. Add another and you have another loop, running through the same CLI. Lumpcode stores nothing of its own, so pushing a commit is the only way you ever control any of them, and changing a loop is a pull request your team reviews like any other code.

your-repo
.lumpcode/lumps/
├── normalizeUtils/     one PR per file
├── ticketBacklog/      one PR per ticket
├── docsSweep/          one PR per stale page
└── deadCode/           one PR per unused export

Any loop you can describe

File sweeps, ticket queues, doc passes, cleanup. Each item can run several prompts in order, gated on your build or tests and retried with the failure output.

Close the laptop; your remote still knows what is left

There is no database. What is finished and what remains are read from the branches and commits already on your git remote.

Use the agent you already have

Cursor, Copilot CLI, Claude Code, Codex, and OpenCode work as they are, or you can write a small module for anything else.

You could script this. Or not.

A for-loop over your files and a call to your agent gets you surprisingly far. Here is what you end up rebuilding.

Resuming

A loop is easy to write. A resumable one is not. Lumpcode reads your git remote and continues where the last run stopped.

Blast radius

A bad result is one pull request you adjust or close, not a 200-file diff to untangle. If the prompt needs tweaking, the first PR shows it.

Validation and retry

Gate each run on your build or test command and feed the failure output back to the agent, instead of finding out at review time.

Unattended

Point a separate clone at the same lump and leave it running. It keeps pushing reviewable branches while you do something else.

Then stop running it yourself.

A one-off run is how you try it. A worker is how you use it.

A second clone you never edit, even another folder on this laptop, and one command: lumpcode start. It picks up every lump in the repo and pushes branches while you do something else. This is how Lumpcode is meant to run.

Set up a worker
1

Start it once

On a clone you never develop in, run lumpcode start. It discovers every lump in the repo and works through them on a schedule.

2

Push a new lump

Nothing to deploy, register, or restart. The worker fetches your primary branch on its next pass and finds the new lump on its own.

3

Branches arrive

It works through each lump context by context and pushes a branch per run. You open the pull requests and merge from wherever you are.

origin
  • lump/ticketBacklog/LUMP-214pushed
  • lump/docsSweep/cli-commandspushed
  • lump/normalizeUtils/slugifyrunning

Pushed overnight, from three different lumps.

One worker, several lumps.

Install the CLI.

Node.js 22+, git origin push access, and a CLI agent on PATH.

CursorCopilot CLIClaude CodeCodexOpenCode

Every run calls your agent, so a lump costs whatever your agent costs. Preview what a run would do without calling the agent with lumpcode lump-plan.

The CLI. This is all you need to run a lump.

terminal
npm install -g @lumpcode/cli

Optional. Helps the agent in your editor write and update lumps. Not used when a lump runs.

terminal
npx skills add lumpcode/skills

Then call the skill with /lumpcode.