Agent workflow

Claude Code + Cursor Setup for Reviewed Agent Work

A repeatable setup using Cursor for navigation and review, Claude Code for scoped tasks, and git worktrees for isolation.

Short answer

Use Cursor as the human review surface and Claude Code as the task executor. Put every non-trivial task on a branch or worktree, give it acceptance checks, and merge only after reviewing the diff and running the project checks.

Who this is for

Developers who want an editor-plus-agent workflow without letting parallel changes collide or bypass review.

What is changing now

Agent workflows are becoming parallel and longer-running. Worktrees, persistent instructions, tool permissions, and clear handoff notes now matter more than keeping every action inside one interface.

Problems this guide solves

  • Agent edits collide with unfinished manual work.
  • The agent receives a broad request but no acceptance criteria.
  • The final summary is trusted without inspecting the actual diff.

Step 1

Prepare the repository once

A stable setup reduces repeated explanation and unsafe improvisation.

  1. Document install, dev, test, lint, and build commands in the repository instructions.
  2. State protected files, secret locations, and actions that need approval.
  3. Make sure the repository has a clean baseline and a working test command.
  4. Open the main workspace in Cursor for navigation and review.

Step 2

Run one task in isolation

A good agent task has a boundary, evidence, and a place to fail safely.

  1. Create a branch for a normal task or a worktree for parallel and risky work.
  2. Describe the user-visible problem, relevant files, and acceptance checks.
  3. Ask Claude Code to inspect and plan before broad changes.
  4. Allow only the commands and external actions required by the task.

Step 3

Review in Cursor and merge deliberately

The agent can prepare evidence, but a person owns the release decision.

  1. Read changed files and dependency updates before reading the agent summary.
  2. Run targeted tests, then the broader checks affected by the change.
  3. Test the user flow or failure case that motivated the task.
  4. Merge, deploy to preview, and remove the worktree only after the result is accepted.

Final checklist

  • Repository commands and boundaries are documented.
  • The task runs on a branch or worktree.
  • Acceptance checks are written before editing.
  • Sensitive commands require explicit approval.
  • The diff and dependency changes are reviewed in Cursor.
  • Tests and the real user flow pass before merge.

Common questions

Do I need a worktree for every task?

No. A branch is enough for one small, sequential task. Use a worktree when an agent runs in parallel, the experiment is risky, or you need your main workspace unchanged.

Should Claude Code run inside Cursor?

It can run from Cursor's terminal, but the important separation is conceptual: the agent executes the scoped task and the editor remains your independent review surface.

What should the agent report at handoff?

Ask for changed files, commands run, test results, assumptions, unresolved risks, and the exact user flow a reviewer should verify.

Use this on one real task

Apply the checklist before changing tools again. A useful setup should make the result easier to prove, review, and recover.

Continue reading

Solve the next connected problem.