Replacing Complex Feature Implementation with Prompt-Based Skills: Git Worktrees in Production
cursor · Tech · 2026 · source Agentic: yes · promotional bias: low · source-backed · extracted with prompt 0.5.6 (schema v2)
Generated from extraction.json — do not edit by hand. Every claim cites verbatim source evidence; stated means the quote directly asserts the claim, implied means it supports it indirectly.
Problem
Domain: AI coding agent worktree orchestration and product feature maintenance
Cursor's original git worktrees feature enabled parallel isolated agent work, best-of-N model comparison, judging, setup scripts, and cleanup, but it required a large codebase and maintenance burden for an advanced power-user feature.
Constraints:
- Agents needed isolated git worktrees so parallel work would not touch the primary checkout.
- Best-of-N workflows needed multiple subagents/models working on the same task and a parent comparison step.
- The old feature had to create/manage worktrees, feed context into agents, enforce isolation, run setup scripts, judge outputs, and clean up disk usage.
- The replacement needed cross-platform instructions for Windows, Linux, and macOS.
- Prompt-based isolation was weaker than programmatic isolation, especially for smaller models and long sessions.
Architecture
Cursor replaced much of the programmatic worktree and best-of-N implementation with prompt-controlled commands that behave like skills. A user invokes /worktree or best-of-N-style commands; the prompt is loaded from Cursor's backend, tells the agent how to create worktrees, run setup scripts, stay in the checkout, spawn subagents for multiple models, wait for them, compare outputs, and optionally stitch pieces together. This removed around 15,000 lines from one feature and replaced a prior 4,000-line best-of-N implementation with roughly 40 lines of markdown, while leaving isolation correctness to model behavior plus eval/RL improvements.
Diagram confidence: reconstructed (reconstructed from prose).
flowchart LR A["Cursor user command"] --> B["Backend-controlled prompt"] B --> C["Parent agent"] C --> D["Git worktree"] C --> E["Subagent pool"] D --> F["Setup scripts"] E --> D E --> G["Model providers"] D --> H["Primary checkout"] I["Eval harness"] --> D I --> H C --> J["Comparison output"]
Components
| Component | Role | Interacts with |
|---|---|---|
Cursor user command |
Slash command such as /worktree or best-of-N request that loads the worktree prompt. | Backend-controlled prompt |
Backend-controlled prompt |
Markdown instruction payload controlled by Cursor servers and loaded only when the user invokes the command. | Cursor user command, Parent agent |
Parent agent |
Creates worktrees or launches subagents, waits for results, compares implementations, and advises the user. | Backend-controlled prompt, Git worktree, Subagent pool, Comparison output |
Git worktree |
Isolated checkout where an agent performs code changes away from the primary checkout. | Parent agent, Subagent pool, Setup scripts, Primary checkout |
Subagent pool |
Parallel model-specific agents for best-of-N or multi-agent coding workflows. | Parent agent, Git worktree, Model providers |
Setup scripts |
User-configured setup steps run when an agent begins work in a worktree. | Git worktree |
Model providers |
Models such as Kimi, Grok, Composer, GPT, and Opus competing on the same task. | Subagent pool |
Primary checkout |
Main repository checkout that should not be modified by worktree agents until changes are applied. | Git worktree, Eval harness |
Eval harness |
Headless Cursor CLI and scorers checking whether work happened in the worktree and not in the primary checkout. | Primary checkout, Git worktree |
Comparison output |
User-facing table/commentary that compares model implementations and can stitch pieces together. | Parent agent |
Data flow
A user invokes /worktree with a task or asks for multiple models to compete. Cursor loads the command prompt from the backend. For a single worktree, the agent creates an isolated checkout, runs setup scripts, works inside that directory, and can apply/delete the worktree later. For best-of-N, a parent agent creates subagents for each specified model, each subagent creates and works inside its own worktree, and the parent waits for all outputs, compares them, and presents a table or combined recommendation to the user.
3 supporting quotes
Why this architecture
Cursor chose prompt-based commands because the previous implementation was a heavy maintenance burden for an advanced feature. Skills/subagents reused existing primitives, allowed backend prompt iteration without app updates, enabled multi-repo and mid-chat worktree switching, and gave the parent agent better context for comparing implementations. The tradeoff is that isolation now depends on model compliance rather than physical enforcement.
3 supporting quotes
Models used: Kimi · Grok · Composer · GPT · Opus · Haiku
Scale
- The old worktrees feature shipped around Cursor 2.0 in October of the prior year.“it all came out in around October of last year or alongside Cursor 2.0.”transcript, stated
- Removing the old feature deleted around 15,000 lines of code.“I think it was around 15,000 lines of code deleted.”transcript, stated
- The best-of-N skill was about 40 lines of markdown, versus about 4,000 lines in the prior version.“it's only around 40 lines of code, and it's all markdown. Like it's not even code and the previous version of this was maybe 4,000 lines of code.”transcript, stated
- Cursor planned to add many thousands of worktree tasks to the RL pipeline for future Composer versions.“We didn't have any tasks in all of the many, many thousands of tasks that we um used for RL actually operating in this type of environment.”transcript, stated
Alternatives considered (roads not taken)
Original programmatic worktrees feature
Rejected because: It enforced isolation strongly but required large amounts of code across worktree creation, context feeding, setup scripts, judging, harness changes, reminders, and cleanup.
Skills instead of commands
Rejected because: Cursor used commands so prompts could be controlled and iterated from the backend without requiring users to update Cursor.
Fully prompt-based isolation
Rejected because: It is accepted for the lightweight version but explicitly weaker than the old physical enforcement, so Cursor is adding evals, reminders, and RL training.
Patterns
prompt-versioning (prompt-ops)
Cursor keeps the command prompts server-side so improvements can ship without app updates.
multi-agent-orchestration (architecture)
The best-of-N command has a parent agent create subagents for different models, wait for them, and compare their work.
eval-driven-development (quality)
Cursor is adding evals that score whether models work inside their worktree and avoid modifying the primary checkout.
fine-tuning-adaptation (model-adaptation)
Cursor plans to add worktree-operation tasks into Composer's RL pipeline so future in-house models handle prompt-based worktree discipline better.
workflow-decomposition (product-architecture)
Cursor decomposed the feature into existing primitives: skills/commands, subagents, git worktrees, setup scripts, and parent-agent comparison.
Tradeoffs
Feature implementation style
Chose prompt-based commands/skills plus subagents over large custom application feature code.
Rationale: The prompt version is dramatically lighter to maintain and unlocks new flows, but relies more on model behavior.
Prompt delivery
Chose server-controlled commands over local skills requiring app updates.
Rationale: Server-side prompts allow iteration without users updating Cursor.
Best-of-N comparison
Chose parent-agent synthesis over picking one implementation over choosing a single subagent/model output.
Rationale: The parent can compare submissions, critique them, and combine pieces from different implementations.
Gotchas (what bit them)
Prompt-based worktree discipline is weaker than enforced filesystem isolation.
Root cause: The new system trusts the model to stay in the intended checkout instead of physically preventing access outside the worktree.
Resolution: Cursor is adding evals, stronger prompts/system reminders, and RL tasks for Composer.
Long sessions and weaker models drift out of the worktree.
Root cause: Models can forget operating constraints or hallucinate, especially over long interactions.
Resolution: Cursor is testing models with worktree evals and found stronger models such as Composer and Grok performed better than Haiku.
The command feels slower even if it is not actually slower.
Root cause: Users now see the agent creating the worktree in chat instead of Cursor doing setup invisibly.
Resolution: Cursor is looking at UX improvements while accepting the lightweight architecture.
Discoverability got worse.
Root cause: The visible dropdown was removed; users now must know the slash command exists.
Resolution: Cursor accepts this because worktrees are an advanced power-user feature.
Evaluation
Cursor is building evals with the headless Cursor CLI and two scorers: one checks whether the model did work inside the worktree and another checks whether it modified the primary checkout. The source also compares model behavior qualitatively across Haiku, Composer, and Grok.
Metrics: Around 15,000 lines deleted from the old feature · Around 40 lines of markdown for the new best-of-N skill · Old best-of-N implementation was about 4,000 lines · Two eval scorers: work in worktree and no work in primary checkout · Model comparison across Haiku, Composer, and Grok
3 supporting quotes
Outcomes
- Cursor deleted roughly 15,000 lines from the old worktrees feature.
- The new markdown/command implementation is much lighter to maintain.
- Users can switch into a worktree halfway through a chat.
- The new command works with multi-repo setups and can open one PR per repo.
- Best-of-N comparison improved because the parent agent can reason over subagent results and stitch pieces together.
- Cursor still needs better prompts, evals, reminders, and RL training to prevent agents from leaving their assigned worktree.
The feature targets Cursor power users rather than most users; the source explicitly says worktrees are not used by 90% of users.