I agree Cursor already has many of the ingredients here: Agent mode, Plan Mode, todos, Skills, Cloud Agents, Automations, checkpoints, queued messages, and auto-run controls. Those are all useful. But I don’t think they are equivalent to a real first-class /goal mode.
The missing thing is not “can the agent do multiple steps?” Cursor can already do that. The missing thing is a persistent goal contract: an explicit objective, explicit completion criteria, durable progress state, and a control loop that keeps evaluating whether the goal is actually complete, genuinely blocked, or still needs more work.
A Skill can describe this behavior, but it is still prompt text. It does not own lifecycle state. It cannot reliably enforce “do not stop until the goal is satisfied or blocked.” It cannot expose a goal status, persist across sessions, show a completion audit, or provide a native resume/continue behavior.
Plan Mode is also not enough. Plan Mode is great for decomposition, review, and turning work into steps, but a plan is not the same as an autonomous completion contract. Plans help the agent know what to do; Goal Mode would define when the agent is allowed to stop.
Cloud Agents are not enough either. Cloud Agents solve the execution environment problem: run elsewhere, run longer, work in parallel, continue while my laptop is disconnected. But running in the cloud is not the same as having first-class goal semantics. A cloud agent can still stop early, drift from the original objective, complete a plan without satisfying the actual goal, or mark work done without a clear evidence trail.
Automations are useful too, but they trigger work. They do not make a single run maintain a durable objective and repeatedly judge itself against a definition of done.
So I think /goal should be a real feature, not just a Skill pattern. It could still compose with all the existing pieces:
- Plan Mode creates or refines the implementation plan.
- Todos track the current breakdown.
- Skills provide project-specific workflows and quality bars.
- Cloud Agents provide the long-running/background execution environment.
- Automations can start goals on schedules or events.
- Checkpoints make the work recoverable.
- But Goal Mode owns the lifecycle: active, paused, blocked, resumed, complete.
The feature I would want is something like:
/goal Fix the failing CI and open a ready PR. Done means all relevant checks pass locally or in CI, the PR description explains the fix, and any remaining failure is proven unrelated.
Then Cursor should keep a visible goal object attached to the agent run:
- Objective
- Completion criteria
- Current plan/todos
- Evidence collected so far
- Status: active, waiting, blocked, complete, failed, paused
- Last self-evaluation
- Reason for stopping
- Resume/continue button
- Optional budget limits for time, tool calls, tokens, or spend
Most importantly, when the agent stops, it should have to say which completion criteria are satisfied and what evidence proves that. If it is blocked, it should state the exact blocker and the smallest user input needed to continue. That is very different from “the model decided it was probably done.”
This matters because long-running agent work fails in predictable ways: premature stopping, objective drift, hidden uncertainty, vague “done” claims, and loss of context between turns. A first-class Goal Mode would make Cursor much safer and more trustworthy for serious delegation. It turns “try this prompt and hope the agent keeps going” into “track this objective until the definition of done is met or a real blocker is reached.”
For small tasks, normal Agent mode is fine. For serious work, especially multi-step engineering work, /goal is the right abstraction. The current pieces are close, but they still put too much responsibility on the user to simulate persistence and stopping rules through prompting. This deserves to be a native Cursor feature.
