Best way to integrate Cursor into an existing VS Code repo with Claude Code + Codex-style multi-agent workflow and automation?

Support Help
, ,
1

Hi everyone,

I am considering adopting Cursor for an existing local repository that is currently managed in VS Code with a fairly governance-heavy AI coding workflow.

Current setup

Right now, I work in VS Code with:

  • Claude Code running in the terminal
  • Codex Chat used separately in the chat panel
  • A large, structured todo-Codex.md file that we are implementing top-to-bottom
  • Repository-level governance/instruction files such as:
    • CLAUDE.md
    • AGENTS.md
    • Claude-specific skillset/instruction files
    • Codex-specific skillset/instruction files

The current workflow is not a simple “ask AI to code” setup. It works more like a controlled multi-agent process:

  1. Planning phase
    • Claude proposes an initial implementation plan.
    • Codex reviews the plan and challenges or revises it where needed.
    • Claude does not blindly accept the review; it responds with evidence-based reasoning.
    • They debate until there is a clear implementation agreement.
  2. Implementation phase
    • Claude makes the first implementation.
    • Codex audits/reviews the changes.
    • Claude responds to the audit with evidence-based reasoning.
    • Once both sides converge, the relevant todo item is closed.
  3. Governance requirements
    • The workflow must respect repository instructions.
    • It must not silently remove or disable existing functionality.
    • It should preserve auditability.
    • It should work item-by-item from the todo list.
    • Ideally, it should produce clear evidence for why a change was made.

What I want to do with Cursor

I would like to integrate Cursor into this local repository and, if possible, reproduce or improve this workflow inside Cursor.

My main questions are:

1. How should I integrate Cursor into this existing local repo?

What is the recommended setup for opening and using an existing VS Code-based repo in Cursor while preserving the current governance structure?

Specifically:

  • Should I simply open the same local folder in Cursor?
  • How should I migrate or map CLAUDE.md, AGENTS.md, and other instruction files into Cursor’s rule/context system?
  • Should I use Cursor Rules, .cursor/rules, project rules, or another mechanism?
  • Can Cursor reliably use multiple repository instruction files as persistent context?
  • Is there a recommended way to make Cursor follow a large todo-Codex.md file item-by-item without losing context?
  • Can Cursor be configured so that it always considers certain governance files before proposing or applying edits?

2. Can Cursor automate this debate → implementation → audit workflow?

I would like to know whether Cursor can support an automated or semi-automated version of this loop:

  1. Read the next open item from todo-Codex.md
  2. Generate an implementation plan
  3. Run an internal review or second-agent critique of the plan
  4. Revise the plan if needed
  5. Implement the agreed changes
  6. Run tests/checks/static analysis
  7. Produce an audit summary
  8. Decide whether the todo item can be closed
  9. Move to the next item

Ideally, I want something close to a multi-agent workflow where one model/agent plans and implements, while another reviews or challenges it before the work is accepted.

Questions:

  • Does Cursor support this kind of multi-step automation natively?
  • Can Cursor run multiple agents or roles, such as “planner”, “implementer”, and “auditor”?
  • Can this be done with Cursor Agent, background agents, custom commands, rules, or MCP?
  • Is there a way to make Cursor automatically continue through todo items while still requiring approval gates before applying risky changes?
  • Can Cursor run terminal commands, collect evidence, and use that evidence in the final audit?
  • Can it be configured to avoid blindly accepting its own previous output?
  • Can it preserve a debate/review trail between planning and implementation?

3. Recommended architecture

For this kind of repo, what would the best Cursor-based architecture be?

For example, should I structure it as:

  • .cursor/rules/
  • dedicated planning rules
  • dedicated implementation rules
  • dedicated audit/review rules
  • a todo parser script
  • MCP tools
  • terminal-based verification commands
  • manual approval checkpoints

Or is there a better Cursor-native approach? And what should be the watch-points?

4. Limitations I should be aware of

I would also appreciate any advice on the practical limitations:

  • Context window limits with large todo/governance files
  • Whether Cursor can reliably follow long project-level procedures
  • Whether background agents are suitable for governance-heavy codebase work
  • How to avoid accidental broad edits
  • How to ensure that existing functionality is not removed or silently disabled
  • How to make review/audit output evidence-based rather than generic

In short, I am trying to understand whether Cursor can become the main interface for a controlled multi-agent coding workflow, where planning, implementation, review, and todo closure happen in a structured and auditable way.

Any examples, recommended setups, rule structures, MCP patterns, or automation approaches would be very helpful.

Thank you in advance for all the time you spent in reading and replying.

Best regards,

4

For a new project, I would avoid putting everything into one large .cursorrules file. A cleaner migration path is to split the old file into scoped .mdc rules.

Example:

.cursorrules

becomes:

.cursor/rules/project-overview.mdc
.cursor/rules/code-style.mdc
.cursor/rules/framework-rules.mdc
.cursor/rules/testing.mdc

I made a generator that can help create the new structure and still export legacy .cursorrules if needed:

8

Thank you very much for your reply.

I am checking the generator now.

One of my main concern is that i need the repo to be structurally set for all 3 of the layers (Cursor, Claude Code and Codex) individually. If i can make the automation the level i want, i can assign Codex as the 2nd auditor after Cursor’s CC and Codex.

The second being the fact that if i can automate the CC-Codex within Cursor and having the second CC and Codex (individual) running as the 2nd overseer/auditor. Any ideas about setting up such an automation?

9

I personally keep Cursor open on one screen and VS Code open on the other. This is because Cursor is not built on the most recent version of VS Code, and I’ve run into issues with how Cursor manages Source Control. So I use Cursor for agentic workflow, including configuration of agents, planning, and implementation. In Visual Studio Code, I view current working or historic commit diffs, make occasional manual edits, and manage source control. You can still drag file names from VS Code over to Cursor to add context to chats.

I’ve noticed that the Cursor’s built-in linter frequently misses errors, so I have a subagent configured to run after every set of code edits that runs console commands to check the lints as well as unit tests, resolve any issues, and create new unit tests for new implemented files or functionality. So really close to the setup you mention in #2. The benefit of the subagent is that it doesn’t have the full context of the parent agent that will be re-read after every command run, saving you on cached read tokens and lowering the cost of the chat. Likewise, if you continue the conversation with the parent chat, it doesn’t have all the debugging details polluting its context history, resulting in a cheaper, more focused conversation.

10

What you have written is, i believe, very close to what i want with additional independent Claude and Codex audits after Cursor’s triple audit since this is (and will be) the backbone of the company.

I am not sure if there are any DM’s here, but if possible and you are okay with the idea, can you share me a chat option such as Discord or any other means that doesn’t jeopardize your confidentiality that we can have a session to discuss how to set it correctly.

My fear is, while trying to get the Cursor to move the way i want, the whole runtime files will go bad and i will need to invest even more time to correct them while my requirement is to shorten the time i spend on the project.

11

I don’t have experience with getting Cursor’s rules / skills / subagents to integrate with Claude and Codex. Having come form ChatGPT, to Claude, to Cursor, and also experimented with Github Copilot, I can see how it would be nice to have a workflow that works in all the environments. But for now I’m just keeping it simple and having all my agentic workflow done in Cursor.

12

Yes, that is where i am art, trying to understand cursor so i also can use it effectively :sweat_smile:

Thank you for the subagent, it opened my eyes now trying to get skills etc in place.

Will try to understand and do hooks next.

That is what i meant, if you could help with setting it up, :sweat_smile:

14

Hey, thanks for the detailed breakdown. This workflow maps to Cursor pretty well. I’ll stick to the key points.

Integration of the repo and governance files

  • Just open the same local folder in Cursor. It’s a VS Code fork, so you don’t need to migrate anything.
  • Cursor automatically reads AGENTS.md in the repo root and also any nested ones in subfolders. It can also pick up CLAUDE.md and .claude config. So your instructions stay consistent across Cursor, Claude Code, and Codex as one shared layer.
  • For governance rules, use .cursor/rules/*.mdc with frontmatter that controls when a rule loads: alwaysApply: true for rules that must always be in context, globs: to load only when specific files are touched, and description: to help relevance-based loading. Docs: Rules | Cursor Docs
  • Important: don’t make a big todo-Codex.md an always-apply rule. It burns context every turn. Keep it as a normal file the agent reads or greps only when needed, and handle one item per session so context doesn’t drift.

Loop planning to implement to audit
This works natively:

  • Plan mode is a read-only phase for research and planning before any edits.
  • Custom agents or subagents in .cursor/agents/*.md. You can set up planner, implementer, and auditor, each with its own prompt and its own model. The parent agent can spawn a reviewer subagent on a different model. That gives cross-model critique so the model doesn’t just rubber-stamp its own output. Docs: Subagents | Cursor Docs
  • Hooks in .cursor/hooks.json to auto-run tests or lint after edits, do checks before submit, and block quiet removal of functionality.
  • Bugbot as an independent PR reviewer, a second audit layer.
  • Approval gates: keep auto-run turned off for risky commands, or use allow and deny lists, so dangerous changes require explicit approval.

Leland_Hepworth described this exact pattern with a linter subagent in comment 9, it’s a solid practical example. Also check these community threads: [Guide] Thin Self-Review Hooks for Cursor | The Model Is the Auditor (Windows + Linux) and How are people handling context across different AI coding tools?.

About using external Claude Code and Codex as extra auditors
Honestly, Cursor doesn’t fully orchestrate independent external Claude Code or Codex CLI as part of its loop. They stay separate tools you run yourself. What Cursor does give you is the shared instruction layer AGENTS.md and CLAUDE.md, so all three layers follow the same rules. If you want a second external audit after the internal Cursor loop, you’ll need to run it manually or via your own script on top of the PR.

Watch points

  • Context: keep always-apply rules lightweight, and load big files only on request. Long single sessions get summarized and lose detail, so do one todo item per session.
  • Background or Cloud agents can work for autonomous runs, but give them strict rules plus verification hooks plus a PR gate. Also note Free tier has limits for Cloud or Background agents, but rules, AGENTS.md and CLAUDE.md, Plan mode, subagents, hooks, commands, and MCP are available.

Let me know if you want to go deeper on any of these points.

15

First of all, thank you for the detailed explanation.

I have the AGENTS.md set, CLAUDE.md set as well as the .codex/ and .claude/ and the .cursor/

So, the todo-Codex is the todo list for the agent i am building. It is roughly some 18.000 lines and roughly 500 checkpoints. It isn’t an always-apply rule, it is a, well, todo list.

I have “responder”, “codex-auditor”, “diagnoser”, “final-plan”, “implementer”, “planner”, “reviewer” and “verifier” as agents/subagents. However, i couldn’t understand enough if how to use subagents effectively and efficiently. From my understanding, that is (subagents) where cursor excel and help keep tokens under control.

About the Claude and Codex external auditors, what i meant is, is it feasible to run Claude (as initial planner and implementer) and Codex (as auditor/overseer) LLM’s within cursor (currently the planning and implementing related parts designate Claude Code and debate/overseer/audit side designate Codex in model selection) and make the implementation plan preparation THEN having independent Codex and Claude to audit a second time via VS Code (not Cursor).

Also, how good is Cursor’s own LLM “Composer 2.5”? I didn’t see it at any of the benchmark sites i follow.

16

Glad the subagents were useful. I’ll go through the three questions.

Subagents, how to use them effectively

The key idea is that each subagent runs in its own separate context window and returns only the final result to the parent agent, not all the noisy process stuff like command logs, diffs, and debugging. That’s how you save tokens, the parent doesn’t drag the messy work into its own history.

In practice:

  • Push heavy or noisy work into subagents, like lint and test loops, searching a large codebase, and research. Exactly like Leland_Hepworth described in comment 9, his verifier subagent runs lint and tests, and the parent stays clean.
  • Keep each subagent narrow and specific, one clear prompt, one task. The narrower the scope, the more predictable the result.
  • 8 agents is probably too much to start with. It helps to separate two ideas: primary agents, roles you switch between yourself like planner, implementer, auditor, and subagents, which the parent delegates to automatically or via /name. You don’t need to make every role a separate subagent, some are better as primary modes.
  • You can call them explicitly with a slash like /verifier confirm ... or add a description in the frontmatter so the parent pulls the right one based on relevance. The files live in .cursor/agents/*.md. Docs: Subagents | Cursor Docs

About using external Claude and Codex as a second audit

It’s the same situation as I mentioned above: Cursor doesn’t orchestrate external Claude Code or the Codex CLI as part of its loop. Inside Cursor you can assign different models to different subagents, for example Claude for planner and implementer, and another model for auditor, which gives you cross model critique in one workflow. But a truly independent second pass via external Claude or Codex in VS Code needs to be run manually or via your own script on top of the PR. The glue is a shared AGENTS.md or CLAUDE.md layer so all three tools follow the same rules.

Composer 2.5

This is Cursor’s proprietary agent model, tuned for agentic coding: long running tasks, tool choice, intent understanding, speed. You won’t see it on third party benchmarks because it’s proprietary and only available inside Cursor. From experience, it’s very good for fast agent loops and tool calling. For governance heavy work with deep reasoning, many users still keep frontier models on critical roles like planning and audit, and use Composer for quick implementation steps. I’d try it on the implementer role in your loop and compare it to what you use now.

Let me know if you want to break down a specific subagent structure for your 500 checkpoints.

17

This is very close to the workflow I have been working on.

For a repo with AGENTS.md, CLAUDE.md, .cursor rules, Codex, Claude Code, and a large todo file, I would avoid trying to make every tool own the workflow independently. I would keep one canonical governance layer and make each tool a thin adapter.

The structure I would use is:

  • AGENTS.md as the canonical project constitution
  • CLAUDE.md pointing back to AGENTS.md
  • .cursor/rules/*.mdc as lightweight Cursor adapters
  • task.md or todo-Codex.md as the task ledger, but not always loaded into context
  • small role agents such as planner, implementer, verifier, and auditor
  • tests/lint/build commands as the harness before any task is marked done

For a very large todo file, I would not ask the agent to hold the whole file in context. I would make each session handle one checkpoint: read the next item, create a short plan, implement, run checks, write evidence, then mark the item done or blocked.

I packaged this pattern into a small open-source initializer called Cosmosmith:

It creates AGENTS.md, task.md, proposal/design templates, and adapters for Claude Code, Cursor, Copilot, OpenCode, and Trae:

npx cosmosmith@latest init --all

It is not meant to replace Cursor subagents. The idea is to give Cursor, Claude Code, and Codex the same shared project rules and task protocol, so the workflow stays auditable across tools.

I would be very interested in feedback from people in this thread, because this discussion is exactly the kind of governance-heavy multi-agent workflow Cosmosmith is trying to support.

20

Good input, thanks. The pattern you’re describing, one canonical governance layer plus thin adapters for each tool, is exactly what I suggested above. Keep AGENTS.md as the single source of truth, have CLAUDE.md point to it, and use .cursor/rules/*.mdc as lightweight adapters for Cursor. And the one checkpoint per session approach for a big todo file is also right. Don’t load the whole ledger into context, just read the next item when needed.

On the generator tools themselves, as a team we don’t vendor third party tools or officially recommend them, but the approach is valid. You can build all of this using native Cursor pieces with no external dependencies: rules, .cursor/agents/*.md, hooks, plan mode. Docs for reference: Rules | Cursor Docs and Subagents | Cursor Docs

@DGLYRT if you want, I can outline a concrete subagent structure for your ~500 checkpoints. What roles should be primary modes vs delegated subagents, and how to split planner, implementer, auditor across models. Let me know.

21

Thanks, that distinction makes sense.

I am not expecting Cursor to vendor or officially recommend any third-party generator. I agree the core workflow should be possible with native Cursor pieces: rules, .cursor/agents/*.md, hooks, and plan mode.

The way I would structure the ~500 checkpoint case is:

  • AGENTS.md as the canonical project constitution
  • .cursor/rules/governance.mdc as the Cursor adapter
  • task.md or checkpoints/*.md as the ledger, but only load one checkpoint per session
  • planner as the primary mode for selecting the next checkpoint and writing the short execution plan
  • implementer as a delegated subagent for scoped code changes
  • verifier/auditor as delegated subagents for tests, lint, build output, and evidence
  • reviewer as a higher-reasoning pass only for architecture, security, or cross-checkpoint drift

So each session becomes:

  1. Read AGENTS.md and the next checkpoint only
  2. Planner writes a small plan
  3. Implementer executes
  4. Verifier runs the harness
  5. Auditor records evidence and marks the checkpoint done or blocked
  6. Move to the next checkpoint in a new session

That keeps context small and makes the workflow auditable.

For context, Cosmosmith is my experiment around generating the governance/adapters layer:

I also have a related project called Techneering, which is more about the execution-discipline layer: spec drafting, implementation, TDD, verification, audit, release, and archive as Claude Code / Codex skills:

I see them as reference implementations of the pattern, not dependencies Cursor needs to adopt. The useful part is probably the separation:

  • governance layer: rules, task ledger, adapters
  • execution layer: spec-to-code loop, verification gates, review/audit

Would be interested to see how you would map those roles into native Cursor subagents.

22

Ok, here’s a concrete structure for your ~500 checkpoints. The key is to split two role types: primary modes you switch manually and delegated subagents the parent calls automatically. Your 8 agents basically collapse into something like this.

Primary modes you switch between:

  • planner works in Plan mode, read-only, studies the repo and the next item, then writes a plan. Model: a frontier model with strong reasoning.
  • implementer makes changes based on the agreed plan. A good pick is Composer 2.5 (fast tool-calling) or Claude.
  • auditor does the final check before closing the item. Use a frontier model, ideally different from the implementer, so you get real cross-model critique instead of self-review.

Your responder and final-plan are probably not separate agents. They’re more like phases inside planner or auditor. Don’t create extra modes just for them.

Delegated subagents the parent calls automatically, each with its own context window:

  • verifier runs lint, tests, and build, then returns only pass/fail plus the relevant output lines to the parent. Exactly like Leland_Hepworth described in comment 9. The model can be cheap and fast.
  • reviewer your codex-auditor gives independent critique of the plan or diff using a different model. It returns a list of issues, no noise.
  • diagnoser is only called when verifier fails. It digs into the cause and returns the root cause. Separate context so you don’t dump debug logs into the parent.

The idea is to push heavy and noisy work tests, codebase search, debugging into subagents. The parent gets a clean result and keeps its history small. That’s the main way to keep tokens under control.

For a big todo list 18k lines, 500 items:
One session equals one checkpoint. The loop per item:

  • planner reads the next item from todo-Codex.md regular read or grep, not an always-apply rule and writes a short plan
  • reviewer critiques the plan cross-model
  • planner revises if needed
  • implementer applies changes
  • verifier runs checks and writes evidence
  • if fail, diagnoser, then back to implementer
  • auditor confirms, mark the item done or blocked
  • start a new session for the next item

Don’t keep the whole ledger in context. Read only the current item, otherwise a long session gets summarized and loses details.

Model split, starter setup:

  • planner and auditor use different frontier models for cross-critique
  • implementer uses Composer 2.5 or Claude
  • verifier uses a fast, cheap model

Agent files live in .cursor/agents/*.md, invoked via /verifier ... or via the description in frontmatter for relevance-based pickup. Docs: Subagents | Cursor Docs and Rules | Cursor Docs

For external Claude or Codex as a second audit, it’s the same situation I mentioned above. Cursor won’t orchestrate them inside its loop, so you run an independent second pass on top of the PR yourself or with your own script. A shared rule layer AGENTS.md or CLAUDE.md keeps all three tools aligned.

Tell me if you want me to write specific prompts for verifier and reviewer. There are a couple of nuances to keep the audit evidence-based instead of generic.

23

Thanks, this is very helpful. I agree with most of this structure.

The split between primary modes and delegated subagents makes sense to me:

  • planner / implementer / auditor as the primary modes
  • verifier / reviewer / diagnoser as delegated subagents
  • one checkpoint per session
  • only read the current todo item, not the whole 18k-line ledger
  • use a different frontier model for auditor/reviewer so the critique is not just self-review

I also agree that responder and final-plan probably should not be separate agents. They feel more like phases of planner or auditor.

The extra layer I am thinking about is where the durable state lives.

For a 500-checkpoint project, I would not want the parent chat to be the memory layer. I would externalize the workflow into repo artifacts:

  • Prompt: shared project rules and role contracts
  • Context: the current checkpoint, linked specs, decisions, relevant files, logs
  • Harness: lint, tests, build, CI, browser checks, release gates
  • Loop: plan → review → implement → verify → diagnose → audit → record evidence

So the Cursor subagents handle execution, but the repo files hold the durable memory and audit trail.

In that setup, verifier should not only return pass/fail to the parent. It should also produce evidence that can be written back to the checkpoint: commands run, relevant output, failure reason, and remaining risk.

Same for reviewer: I would want it to return evidence-based findings, not generic advice. Ideally each finding points to a file, diff, task requirement, or violated acceptance check.

So yes, I would be interested in specific prompts for verifier and reviewer, especially prompts that keep them evidence-based and concise.

The constraints I would want are:

  • verifier returns only command, result, key output lines, and evidence
  • reviewer returns only concrete issues, severity, location, and suggested fix
  • diagnoser is only called after verifier fails
  • auditor decides whether the checkpoint can close based on recorded evidence, not chat confidence
  • all durable conclusions should be written back to the task ledger or checkpoint notes

I think your Cursor-native structure plus an external Prompt / Context / Harness / Loop layer would handle both sides: token control inside Cursor, and long-term consistency across many checkpoints.

24

Agree with the direction: externalize durable state into repo artifacts, and keep subagents as execution only. That’s exactly how it should be: the parent chat shouldn’t be the memory layer, evidence lives in the task ledger or checkpoint notes. Below are concrete prompts for verifier and reviewer, optimized for concise, evidence-based output.

verifier .cursor/agents/verifier.md a fast, cheap model:

You are a verifier subagent. You run the project harness and report facts only.

Steps:
1. Run the relevant checks for the current checkpoint (lint, tests, build). Prefer scoped runs over the full suite when possible.
2. Do NOT fix code. Do NOT propose changes. Only observe and report.

Return ONLY this structure, nothing else:
-  Command(s) run: <exact commands>
-  Result: PASS or FAIL
-  Key output: <only the lines that prove pass/fail, max ~15 lines>
-  Failure reason: <one sentence, only if FAIL>
-  Remaining risk: <one sentence, or "none">

No summaries of the codebase. No generic advice. No restating the task.

reviewer .cursor/agents/reviewer.md a frontier model, different from the implementer:

You are a reviewer subagent. You give evidence-based critique of a plan or diff.

Rules:
-  Every finding MUST point to a concrete location: file path, diff hunk, task requirement, or a violated acceptance check. No location, no finding.
-  No generic advice ("consider adding tests"). Only issues you can tie to the actual code/plan.
-  If there are no concrete issues, say so explicitly.

Return ONLY a list of findings, each as:
-  Severity: blocker | major | minor
-  Location: <file:line or task requirement id>
-  Issue: <what is wrong, one or two sentences>
-  Suggested fix: <concrete action>

Then one line: "Removed/disabled functionality check: <none found | list>".

A couple nuances to make this actually stick:

  • verifier returns evidence to the parent, but writing to the ledger should be done by the parent or auditor, not by the subagent. The subagent lives in its own context window and should only return the result. Persistence happens at the parent level, which writes command, result, output, failure, and risk into checkpoint notes. That keeps evidence durable and tokens under control.
  • Call diagnoser only after a FAIL from verifier, in a separate context, so debug logs don’t leak into the parent. It returns root cause back to the implementer.
  • auditor closes the checkpoint based on the written evidence, not chat confidence, which is what you described. Give it an explicit instruction to read checkpoint notes and decide done or blocked only from them.

Subagents mechanics .cursor/agents/*.md, separate context per agent, return only the result are described here: Subagents | Cursor Docs

Your Prompt, Context, Harness, Loop layer on top of native subagents is a solid setup. Cursor keeps token control inside the session, and repo files keep long-term consistency across 500 checkpoints. Let me know if you want to tune the prompts for your specific stack and harness test, lint, build commands and we can tailor them.

25

Thanks, this is exactly the kind of structure I was looking for. The distinction that verifier/reviewer return evidence, but the parent or auditor writes durable state back to the ledger, is especially useful.

I agree that subagents should stay execution-only:

  • verifier observes the harness and reports facts
  • reviewer gives evidence-based findings
  • diagnoser only runs after verifier fails
  • auditor closes the checkpoint based on recorded evidence, not chat confidence

One additional idea I have been thinking about is treating the long task file less like a normal document and more like an executable task stream.

The analogy in my mind is the JVM program counter. When a CPU time slice is interrupted, bytecode does not restart from the beginning. The runtime knows the current instruction position and resumes from there.

For a large task.md or todo-Codex.md, I think a similar pattern could work:

  • the full task ledger is the instruction stream
  • the current checkpoint/task id is the program counter
  • the parent agent is the scheduler
  • subagents are execution units
  • verifier/auditor evidence is the committed state
  • the next session resumes from the recorded checkpoint pointer

So instead of asking the agent to read the whole 18k-line ledger, the workflow reads a bounded window: one task, or a small batch of tasks, around the current pointer.

That would give two benefits:

  1. context control, because each session only reads the current task window
  2. resumability, because the workflow can continue after session resets without rediscovering where it was

This seems complementary to your Cursor subagent structure. Subagents keep noisy execution isolated, while the checkpoint pointer keeps the long task stream recoverable.

Yes, I would be interested in tuning the prompts for a concrete harness. I think the next useful pieces would be:

  • an auditor prompt that reads checkpoint notes and decides done/blocked only from evidence
  • a diagnoser prompt that returns root cause without dumping logs into the parent
  • a task ledger/checkpoint format that stores the current pointer and evidence cleanly
26

Since you’ve already put together 8 agents responder, codex-auditor, diagnoser, final-plan, implementer, planner, reviewer, verifier, let me turn this into a working structure for your about 500 checkpoints. The key is to split two types: primary modes (roles you switch between yourself) and subagents (the parent delegates automatically, each in its own isolated context).

Primary modes (you switch manually, .cursor/agents/*.md):

  • planner works in Plan mode, read-only, reads the next item from todo-Codex.md, and writes a plan. Model: frontier deep reasoning.
  • implementer makes changes based on the agreed plan. Model: Composer 2.5 for speed, or frontier for harder items.
  • auditor does the final acceptance for a checkpoint, and checks that functionality wasn’t removed or disabled. Model: frontier, ideally different from implementer for cross-model critique.

Subagents (delegated automatically, isolated context, saves tokens):

  • verifier runs lint/tests/build and returns only pass/fail to the parent. Exactly the Leland_Hepworth pattern from comment 9. Set readonly: false but keep the scope narrow.
  • reviewer and codex-auditor give independent critique of the plan or diff on another model and return only findings. readonly: true.
  • For searching the codebase and heavy shell logs, use the built-in subagents Explore and Bash. You don’t need to configure them, Cursor wires them up automatically.

What to do with the rest: responder, final-plan, diagnoser are more like phases of one role than separate agents. Fold final-plan into planner, diagnoser into verifier, and responder into implementer. Eight nodes are expensive in context and hard to debug. Start with 3 modes plus 2 to 3 subagents.

For 500 checkpoints: one checkpoint equals one session. Don’t load the whole todo-Codex.md into context and don’t make it always-apply. The loop per item is: planner reads the next item, then reviewer critiques the plan, then implementer builds it, then verifier runs checks, then auditor decides close or blocked, then you write evidence in markdown, then move to the next item. Long single sessions get summarized and lose detail, so splitting by items isn’t optional, it’s required.

The description in frontmatter controls when the parent auto-pulls the right subagent, or you can call explicitly via /verifier .... Docs: Subagents | Cursor Docs and Rules | Cursor Docs

About external second-pass auditing Claude Code or Codex in VS Code after the Cursor loop, the position is the same as above. Cursor won’t orchestrate those. You run them manually or via your own script on top of the PR, and the shared layer is AGENTS.md or CLAUDE.md. If you want, I can draft specific .md templates for planner, verifier, and auditor for your repo.