How we use Cursor with Vaiz to keep tasks, code, and decisions connected
Two real workflows from the Vaiz team: planning a feature with Cursor and delegating a website update to a cloud agent, with decisions and pull requests linked to the task.
Our work with Cursor starts in two places: a developer can ask about a Vaiz task from inside Cursor, or a task can be delegated to a Cursor cloud agent. In both cases, we want the result to remain understandable to the team: what was requested, which decisions shaped the work, what the agent produced, and what still needs attention.
Two examples from our own work on Vaiz show how this looks in practice. One follows a conversation about an AI feature. The other follows a website task delegated to a cloud agent and returned for review.
Start with a task the team can read
The first example began with a short request in Cursor:
Take a look at APP-6007.
APP-6007 was an epic for creating and configuring projects and boards through Vaiz's built-in AI chat. Its description contained the goal, a proposed implementation plan, and open questions.
Cursor's response summarized the task, its owner and status, the proposed phases, and the questions that still needed decisions. It also reported the state of the code and whether it had found relevant decisions or problems in Memory.
That made the first exchange useful before any implementation began. We could discuss the task against a shared reference, using its ID to identify the work. Our MCP connection guide covers the setup for bringing Vaiz context into Cursor.
Clarify the scope before the agent implements it
The initial plan was broader than the work we wanted to do in that task. It included a setup wizard and possible future MCP tools, as well as the capabilities of the built-in chat.
The developer narrowed the scope:
We are not building the wizard as part of this task. We are only implementing the chat capabilities. These tools will not be in MCP—only in the General Agent.
Here, “General Agent” means Vaiz's built-in AI chat. Cursor's connection to Vaiz was separate from the feature being developed.
Cursor acknowledged the change and revised its explanation around that boundary. The conversation then moved to a more specific design question: how configuring a board differs from configuring a project.
The agent described the existing operations and surfaced a consequential choice. Applying a sequence of changes one at a time could leave a board partially updated if an operation failed. A transaction could make the group of changes succeed or fail together.
This is the kind of decision we want visible while work is being planned. The task provides the starting point; the developer remains responsible for its scope and tradeoffs.
Keep decisions and unresolved issues beside the task
A later view of APP-6007 shows six Memory entries associated with the task: three decisions, one problem, one risk, and one session log.
The task gives the team a place to find the context recorded during work in Cursor.
The entries include decisions about enforcing constraints in validation and using a chat API test harness. They also record a problem with internal plan details appearing in an AI response, and a risk that board templates and validation rules could diverge. The session log describes a 50-case test run and bugs found during it.
The entries identify their author, source, linked task, type, and status.
These records preserve different parts of the work. A decision explains the approach. A problem identifies something to fix. A risk captures something to watch. The session log records what happened during a particular stretch of work.
The task can therefore carry both progress and unresolved issues. Someone returning to it has a starting point for understanding what the earlier session established.
Delegate a defined task to a Cursor cloud agent
A separate example, MR-2938, concerned updates to the Vaiz website's pricing page. The task described the requested changes, including page metadata, image descriptions, and structured data.
Its activity history records delegation to a Cursor cloud agent, with the repository, starting branch, and permission to update the task attached to the run.
The agent subsequently opened a pull request and posted a completion summary. That summary reported the changes, successful checks, and the move to Review. A person then shared a preview link and tagged a teammate.
The task's activity records both the agent's output and the next human handoff.
The agent's completion message marked the changes as ready for review. That is the useful handoff point: the team has a proposed change, a summary of the checks the agent reported, and a preview to inspect.
Return the implementation context to the team
The MR-2938 task card brings together the branch, commit, pull request, coding-agent run, and a Memory entry.
The task connects the original request with the development artifacts produced during the run.
Its session log adds a written account of the work. It describes the changes and reported validation, and links back to the task and GitHub artifacts.
A session log gives the team a readable account alongside the code links.
For work that crosses marketing and development, this makes the handoff concrete. A teammate can open the task to find the request, the agent's report, the proposed implementation, and the discussion around it.
Try the workflow on one bounded piece of work
To try this approach, choose a task with a clear outcome and enough context for someone else to act on it. Connect Cursor to Vaiz, ask it to read the task, and review its understanding before implementation.
Resolve scope questions as they emerge. When the work is ready for review, bring the result back to the task: the implementation link, a summary of checks, and any decisions or unresolved issues that the next person will need.
That is the pattern these examples illustrate: the task starts the conversation, people guide the work, and the project retains a record of what happened.
