carveout

Named for the corporate carve-out: one unit split off from a company so it can stand on its own. carveout does that for one feature of a repository, and takes the work back when it is done.

Before / After

🔓 Without carveout: they get the repo

$ git clone git@github.com:acme/closed-repo
709 files · 245,456 lines of TypeScript
every package, infra/, .github/workflows/
their branch runs CI with your secrets

🔒 With carveout: they get one folder

$ carveout handoff \
    packages/jira/src/selection-jql.ts
Verdict: ready: it installs, builds, and its
  tests pass before any edit
Tests: 15 of 15 test(s) pass before any edit
Shows 15 files, 2,980 lines
Names: 3 rename(s) hide the repository's

✅ The work comes back

$ carveout patch ../returned --output change.patch
carveout: 2 changed, 0 new and 0 deleted files
$ git apply change.patch && npm test -w packages/jira
ℹ tests 165
ℹ pass 165
ℹ fail 0

🚫 A shortcut does not

$ carveout patch ../returned
carveout: kept out:
  packages/jira/src/selection-jql.ts,
  could pass a test without the code
  passing it (process.execArgv matched
  against a test runner)
exit 6

Same task. 15 files out of 709. The shortcut held before anything ran it.

A real hand-off on sandbox-factory, 2026-11-11. The 15 files are the entry point, its test, and 13 pure modules copied so that test runs on real code. Everything else the slice touches is a .d.ts stub with a recording mock: declarations, never bodies. Those 13 modules were pricing code. plan lists every copied file before anything is written, and --private keeps a folder out: here that shows 245 lines, and 7 tests then fail on the mocks before any edit. You choose.

Install

npx skills add lunox-work/carveout -g

In Claude Code, the repository is also a plugin marketplace: /plugin marketplace add lunox-work/carveout, then /plugin install carveout@carveout. It holds two skills: carveout, the hand-off, and carveout-gate, impact and gate for a change made in the repository.

Then ask your coding agent (Claude Code, Codex, Cursor, or any agent that loads skills): "hand src/billing to a contractor". It plans the slice, shows you what goes out, and cuts it once you agree. Without a skill, use the CLI:

npx -y carveout handoff src/billing/quote.ts --task task.md --out ../quote-slice

Needs Node 22.12+ and a TypeScript repository (npm, pnpm or Yarn; node:test or Vitest). Code that came back runs only in Docker; without it, carveout runs none of it unless you pass --no-sandbox.

Try it in 60 seconds

# maintainer, at the repository's root
npx -y carveout plan    apps/api/src/billing --depth 1 --with-tests   # what the folder would hold; writes nothing
npx -y carveout handoff apps/api/src/billing --task task.md --out ../billing-slice

# contractor: npm ci, edit, npm test, send the folder back

# maintainer, on the folder that came back
npx -y carveout patch ../billing-slice --output billing.patch   # runs none of its code
less billing.patch                                               # read all of it
git switch -c contrib/billing && git apply --3way billing.patch  # then a PR: CI decides

How it works

• Out. You name a file or a folder. carveout copies it, and what it imports up to a depth you choose, at the same paths. Every module it imports from the rest becomes a .d.ts stub with a recording mock, so the folder installs, builds and tests on its own.
• Nameless. A hand-off is written in pseudonyms: the repository's package names, scope, remote, authors and your Git identity are renamed (LunoxCart becomes AcmeCart). Only your receipt maps them back, and it never leaves your machine.
• Ready before it ships. check runs the folder as the contractor will. It says the folder is ready (its tests pass before any edit) or names the tests that fail on the mocks and what would run them on real code.
• Back. carveout patch turns the folder's edits into a patch in your names. It trusts nothing in the folder: the receipt decides what a patch may carry. It runs none of their code.

What comes back, and what is held

The policy reads syntax, not intent: code that special-cases a test's own inputs passes it. Read the whole patch before anything runs it, and run its first CI with no secrets. The full policy is in the reference.

Proof

• What a slice shows. Over 8 slices of a 245k-line repository, a default cut copies a median of 0.7% of the source (0.03 to 2.4%). With the hand-off's tests and pure code, 11% (0.3 to 24%). Stub declarations come on top and are not counted (hero-exposure.mjs).
• The round trip. 52 real commits replayed through a slice all come back as patches that apply, 49 byte-identical. On a repository that moved on, 27% apply plain and 89% with git apply --3way.
• Agents in a folder. Six agents, each given only a public hand-off folder, delivered their tasks. Each patch applied in the repository's names and passed the owner's hidden acceptance tests.
• Folders that stand alone. Ten of eleven slices from three repositories install, build and test on their own with the hand-off's flags. The eleventh fails on a narrowed inferred type (Limits).
• What it does not win. A slice does not make an agent cheaper or better: it read 17 to 24% more input and passed hidden tests 5 to 10 points less often than the same agent in the whole repository. A pass in the slice matched the verdict after the merge in 74% of replays, nearly every miss the safe way (the slice failed, the repository passed). The slice is a pre-check; your CI is t