How I use Sol as an orchestrator in Cursor

Start with a brief, not a task

I do not begin with “build this” or “fix that.” I start by asking Sol to make the change legible. Before anyone edits a file, I want a short brief that names the user-facing outcome, the relevant parts of the codebase, the constraints, and the evidence that would show the work is done.

That first pass is useful even when I am working alone. It separates the request from the solution I happened to imagine first. A request to “improve onboarding,” for example, may involve an existing activation event, a form state that is already shared with another screen, and an analytics convention that should not change. Those are not implementation details to discover halfway through the work. They are the edges of the assignment.

I ask Sol to inspect before it proposes. The goal is not a long specification; it is a decision record I can disagree with. If the problem or success criteria are still vague, I clarify them with a person before I create more work. Agents are good at filling empty space. They should not be allowed to silently choose the product decision hidden inside an empty space.

Delegation gets safer when “done” is something a person can inspect, not something an agent can merely claim.

Create bounded assignments

Once the brief is stable, I use Sol to turn it into small assignments. The unit is not a vague role like “research” or “frontend.” It is a question or a change with clear boundaries. One assignment may map the current data flow. Another may implement a component behind an existing interface. A third may identify the tests that prove the behavior still works.

Each assignment should be narrow enough that its owner can explain what changed and what did not. I include the files or systems it may touch, the assumptions it can rely on, the constraints it must preserve, and the exact evidence I expect back. For an implementation task, that evidence is usually a concise summary, the diff, and the commands run. For an investigation, it is a recommendation with links to the code that supports it.

The most important boundary is between assignments that could overwrite or invalidate each other. I do not ask two agents to redesign the same component from different angles and hope the results will compose. If work shares a seam, I either sequence it or give one owner responsibility for the seam. Parallelism is helpful when it reduces waiting, not when it moves a disagreement until after the code exists.

Bring the work back together

Delegation is not the finish line. When the reports come back, I return to Sol with the original brief and the evidence from each assignment. I ask it to compare the proposed changes against the acceptance criteria, look for contradictions between the pieces, and name the checks that still need to run. That lets the review begin from the intended outcome instead of from whichever diff is largest.

Sol is especially useful at this stage because it can keep several kinds of evidence in view: the request, the files that define the current behavior, the implementation report, a test result, and the questions that remain open. But I do not confuse a coherent summary with proof. I still read the critical diff, run the relevant checks, and exercise the path a real person will use.

A green test suite can show that existing expectations still hold. It cannot always show that the chosen change solved the right problem, that an error state is understandable, or that an adjacent workflow was not made more confusing. The final review is where I slow the system down. I want the result to be technically sound, but I also want to be able to explain why this was the right change to ship.

If the evidence is incomplete, that is a useful result too. I keep the uncertainty visible, decide who needs to resolve it, and avoid converting “probably fine” into an invisible product decision. A good orchestrator helps surface that gap; it does not make the gap disappear.

The prompt I come back to

I adapt this prompt to the project, then keep the brief and the acceptance criteria nearby as the work moves. It asks Sol to make the plan reviewable before it becomes executable.

You are orchestrating a change in this repository.

First inspect the relevant code and summarize the current behavior. Do not edit yet.

Then propose a small work plan. For each assignment, include:
- the outcome it owns
- the files, systems, or decisions in scope
- dependencies and handoff points
- what must not change
- the evidence required to call it done

Keep assignments bounded and non-overlapping. Sequence work that shares a seam.

When work returns, compare every report and diff against the original brief. Identify conflicts, missing evidence, and the exact verification still needed. Do not treat an agent's summary as proof; use tests, code review, and the user-facing behavior to decide whether the change is ready.

I do not expect the prompt to make the process automatic. Its value is that it keeps the same questions in view: What are we trying to change? Who owns each piece? What evidence would change our mind? Those questions are useful whether the work is one small fix or a larger project with several people involved.