[ENHANCEMENT] Add Mutual Auditing Workflow (Implementor / Auditor Models) #9301
Description
Problem (one or two sentences)
The current Roo setup does not take advantage of the Implementor / Auditor workflow with two models; users must do this manually.
Context (who is affected and when)
Roo users wanting to create professional-grade code.
Desired behavior (conceptual, not technical)
Multistep LLM Coding Workflow With Mutual Auditing (Implementor Model ↔ Auditor Model)
Summary
Define a workflow where:
- Implementor Model implements code in small, isolated phases.
- Auditor Model audits Implementor Model’s output, checks reasoning, finds flaws, and returns a structured list of targeted corrections.
- Implementor Model then applies those corrections before proceeding.
Context is intentionally cleared or minimized between phases to keep each agent focused, reduce drift, and maintain accuracy.
This issue serves as a brainstorming guide for contributors, not a strict engineering process.
Goals
- Provide a lightweight structure that LLMs can follow when implementing features.
- Emphasize mutual auditing rather than long multi-iteration chains inside one model.
- Avoid large, bloated context windows by working in phases with resets.
- Maintain clarity and alignment by grounding each phase in explicit acceptance criteria.
- Keep everything self-contained inside the Roo agent.
High-level Workflow
1. Create a Multi-step Plan
An agent proposes a set of small, sequential steps needed to implement a feature.
Each step must include:
- Scope: what code or modules it touches
- Objectives: what needs to change or be added
- Acceptance criteria: how Model B will verify correctness
The plan is captured in a short markdown file so both agents can reference it.
2. Implement Code (Implementor Model)
For the current phase:
- Implementor Model begins with minimal context (only the plan + relevant files).
- Implements the step in a small, focused pass.
- Produces:
- The code changes
- A short explanation of decisions
- A checklist showing which acceptance criteria should now be satisfied
Avoids reading or loading unrelated parts of the system unless absolutely required.
3. Audit Changes (Auditor Model)
Auditor Model reviews only:
- The phase plan entry
- The Implementor Model's code for this phase
- The Implementor Model’s reasoning summary
The Auditor Model performs a structured audit:
- Verifies code correctness
- Reads linter feedback and decides if problems need to be addressed
- Identifies logical inconsistencies
- Identifies missing details
- Analyzes architectural correctness
- Checks whether acceptance criteria are actually satisfied
- Highlights assumptions that might be unsafe or unjustified
- Recommends targeted fixes
Output must be a structured list:
- Passes
- Failures
- Corrections required
- Additional thought questions
The goal is to stress-test Implementor Model’s implementation and find weaknesses, not to rewrite code.
4. Apply Corrections (Implementor Model)
Implementor Model:
- Reads Auditor Model’s correction list
- Revises the implementation
- Re-evaluates acceptance criteria
- Provides a summary validating each correction
If Auditor Model still finds issues, repeat once more.
If Auditor Model gives a passing grade to the step, declare the step complete.
5. Reset Context and Move to Next Step
After a step passes:
- Implementor Model’s context is cleared or reduced to avoid drift.
- Only the plan and relevant files for the next phase are loaded.
This ensures each new phase is completed with fresh reasoning and minimal interference from earlier details.
Recommended Artifacts (simple and minimal)
feature-plan.md
A simple outline like:
# Feature Plan
## Step 1 — Objective
Scope:
Acceptance Criteria:
## Step 2 — Objective
Scope:
Acceptance Criteria:
...
Audit Structure (Auditor Model → Implementor Model)
# Audit Report — Step X
## Verified
- ...
## Issues Found
- ...
## Required Corrections
1. ...
2. ...
## Additional Questions
- ...
Implementor Model Correction Response
# Correction Response — Step X
## Applied Fixes
- ...
## Satisfaction of Acceptance Criteria
- ...
## Notes
- ...
---
Guiding Principles for the Agents
Keep steps tiny. The smaller the scope, the better the accuracy.
Avoid deep multi-step reasoning in one agent. Use the other agent to check the reasoning.
Stay in-grounded context. Load only the files relevant to the current task.
Audit > rewrite. The Auditor Model should critique, not implement.
Reset the context frequently. Reduces hallucinations, assumptions, and drift.
are complete.
### Constraints / preferences (optional)
_No response_
### Request checklist
- [x] I've searched existing Issues and Discussions for duplicates
- [x] This describes a specific problem with clear context and impact
### Roo Code Task Links (optional)
_No response_
### Acceptance criteria (optional)
_No response_
### Proposed approach (optional)
_No response_
### Trade-offs / risks (optional)
_No response_