Replacing 12K LoC with a 200 LoC Skill

What does it take to replace a maintained application feature—with its dependencies, tests, and specialized code—with Markdown instructions? David Gomes’s example is Cursor’s support for parallel agents in Git worktrees. The goal is to preserve the workflow while moving much of its orchestration into instructions an agent can follow.

A Git worktree is a separate checkout associated with the same repository. Different agents can work on identical or different tasks in separate folders without overwriting one another’s files. A file in an agent’s worktree can change while its counterpart in the primary checkout remains untouched.

In Cursor’s original implementation, commands and lint runs were scoped to the agent’s checkout. Users could watch a grid of agents working in parallel, then ask an agent to open a pull request containing its worktree’s changes. Best-of-N extended that workflow to competing implementations: give several models the same prompt, compare their results, and, for a front-end project, preview the different interfaces before choosing one. This arrived alongside Cursor 2.0, released in October 2025.

The visible workflow depended on several pieces of application machinery:

• Lifecycle and context: create worktrees, manage them, and tell each agent which checkout it was operating in.
• Isolation and setup: constrain agents to their assigned checkout and run user-configured setup scripts when work began.
• Judging: evaluate the competing implementations and show a thumbs-up recommendation.
• Harness support: add system reminders and other changes that helped agents stay on track.
• Cleanup: remove abandoned worktrees before users running hundreds of them exhausted their disk space.

The revised implementation removed much of this dedicated machinery, although worktree cleanup remained a responsibility.

Gomes estimates that his deletion PR removed around 15,000 lines of code. The revised overview shows a roughly 200-line skill; these are approximate descriptions of the refactor, not a reconciled before-and-after count. His assessment of the replacement is also qualified: it is almost as good as the old feature, much lighter to maintain, and better at some workflows. The question becomes which responsibilities existing agent primitives can absorb.

The replacement combines two existing primitives: agent skills, which supply reusable instructions, and subagents, which let a parent delegate work. The first demonstration is deliberately small: invoke /worktree and assign the task “Fix a typo in the footer of the website.” The agent creates a separate checkout and performs the task there.

The worktree instructions describe a short procedure: create the checkout, run any configured setup scripts, and keep subsequent work inside that checkout. Expressed as a compact Markdown instruction body, that procedure looks like this:

# Work in a separate checkout

Task: Fix a typo in the footer of the website.

1. Create a Git worktree for this task.
2. Run the user's configured setup scripts in that worktree.
3. Make the footer correction inside that worktree.
4. Run commands and checks from that worktree.
5. Keep all task edits out of the primary checkout.

The last instruction carries much of the burden: creating a directory is a discrete action, but staying in it is a constraint that must survive the rest of the session.

Best-of-N adds coordination around that same procedure:

1. The parent starts one subagent for each requested model.
2. Each subagent creates its own worktree and works inside it.
3. The parent waits for all subagents to finish.
4. The parent compares the implementations, offers criticism or grades, and helps the user choose, preferably in a table.

Gomes describes the Best-of-N prompt as around 40 lines of Markdown, compared with perhaps 4,000 lines of code in the previous implementation. The prompt delegates orchestration to capabilities already present in the agent system.

The instruction set still has to account for the environment. It includes Windows-specific directions alongside Linux and macOS directions, tells the parent to run configured setup scripts for each worktree, and emphatically tells the model not to leave its assigned checkout. That last requirement is handled through prompting.

These commands cover both starting isolated work and managing what happens to its result.

Although Gomes calls the replacement a skill, the demonstrated implementation technically uses Cursor commands. Like skills, their prompts enter context on demand, when the user invokes them. Cursor chose commands so it could control the prompts on its backend: an improved prompt could reach the next invocation without requiring a client update. That deployment mechanism is part of this implementation, distinct from the general skill-package documentation.

The Best-of-N demonstration assigns one task to Kimi, Grok, Composer, GPT, and Opus. The parent starts five subagents, each with a separate context and its own worktree. Context separation keeps each delegated conversation distinct; the worktree supplies its separate checkout. Opus finishes later in this run, and the parent then compares all the implementations.

The comparison can identify which models took essentially the same approach and which contributed something unique. It also supports a follow-up that the previous selection interface could not express: ask the parent to combine a preferred part of Opus’s implementation with a preferred part of GPT’s. The parent can use the independent results as material for a combined implementation instead of treating them only as candidates from which to choose one.

The maintenance savings matter because worktrees serve an advanced subset of Cursor users: people who actively want parallel execution and grids of agents. Gomes does not give an adoption rate. His product judgment is that this feature should not demand a disproportionate amount of maintenance from the team.

Moving orchestration into the conversation also removes some restrictions of the former interface:

• Switch during a chat: users can discuss a task first, then invoke /worktree when they decide to move the work into a side checkout. The old workflow did not support this transition, and adding more prompt-interface settings was unattractive.
• Work across repositories: the old implementation disabled worktrees for multi-repository setups. In the new workflow, an agent working across separate front-end and back-end repositories can create a worktree for each and open a pull request in each repository.
• Judge and combine results: the parent has richer context about what its subagents did. Users can ask it to stitch together useful pieces from several implementations, whereas the old experience required choosing one model’s result.

The flexibility comes from giving the coordinator access to the task and its evolving conversation, rather than fixing every workflow in advance in the interface.

The change received mixed feedback, including from users accustomed to the old workflow. The most consequential regression is checkout discipline. Gomes says the previous implementation prevented the model from touching files outside its worktree. The replacement tells the model which directory to use and trusts it to comply.

A directory instruction is not an enforced file-access boundary. Over a long session, the model can forget where it should operate and begin changing the primary checkout. Gomes identifies weaker models as particularly susceptible to this drift. The refactor therefore changes more than where orchestration is implemented: it changes how a critical constraint is maintained, from application enforcement to model behavior.

There are also costs in how the workflow feels and how users find it:

• Visible setup: worktree creation now appears as agent activity in the chat. Gomes says the new workflow feels slower without actually being slower; he supplies no timing measurements. Users see the agent doing setup that previously appeared to have been handled for it.
• Reduced discoverability: the old dropdown exposed local, cloud, and worktree execution. With that dropdown removed, users need to know /worktree exists before they can invoke it. The team accepts some loss of discoverability for an advanced feature.

These are separate problems: hiding setup activity would not fix checkout drift, and stronger checkout discipline would not make the command easier to discover.

Cursor is pursuing two ways to improve adherence: use evaluations to improve the prompts, and add relevant tasks to reinforcement learning. Gomes says Composer 2 had no RL tasks using these prompts or this kind of operating environment. The team was adding such tasks to its training pipeline, hoping to improve later Composer releases. For other providers’ models, Cursor can share feedback with the labs but cannot directly change their training.

For the evaluation harness, Gomes uses Braintrust and agent-assisted eval authoring, then runs tasks through the headless Cursor CLI. He describes two separate scorers:

Both questions are necessary. An agent might make the requested change in its worktree and still modify the primary checkout along the way. Checking only the desired result would miss that violation.

The initial evaluations are simple and do not reproduce extremely long sessions, where Gomes sees behavior deteriorate. In these preliminary checkout-adherence tests, Gomes reports that Haiku often drifts into the primary checkout, while the tested Composer and Grok models do better. He provides no numerical scores or model-version breakdown. The observation points toward a model-dependent reliability problem within this workflow, not a general ranking of coding ability.

The next step is to make the cases more demanding, identify recurring failure patterns, and use those patterns to revise the prompts. Better system reminders are another proposed intervention: reinforce the assigned checkout during the session so the model does not lose the constraint as the conversation grows.

The roadmap includes a partial return to native implementation. Cursor 3.0 had already introduced an agent window organized around agents and chat while retaining code viewing and editing. Gomes describes a more complete native worktree experience for that window as planned work, not as a completed consequence of the release.

The reasoning is about where the workflow belongs. Users who want extensive local parallelization are likely to use an interface built around agents. In that setting, Cursor intends to provide more native worktree support while continuing to improve the instruction-based approach through evals, RL, and other training. The refactor does not eliminate the case for application code; it changes which interface and users justify that investment.

Git worktrees themselves also impose limits. They can take time to create, consume substantial disk space, and only work in Git repositories. Projects using something other than Git consequently lack this local parallelization option in Cursor. The team is investigating alternatives that do not depend on Git or Git worktrees, with details still to come. The remaining design problem is how to give concurrent agents separate working environments without inheriting all the costs and restrictions of the current primitive.