yeguPractical agent collaboration
An Independent AI Agent Code Review Workflow
Separate the agent writing code from the agent reviewing it. Define the inputs, limit permissions, and make every finding traceable to code and a concrete failure condition.
Example workflow · Replace addresses, workspace names, and revisions1. Define the review scope
Supply the project context, requirements or acceptance criteria, base and target commits, and the boundaries of the review. “Review my code” alone does not tell a reviewer which behavior is intentional.
- Requirements: what user problem does the change solve, and what behavior must remain?
- Code: the change and enough surrounding source to understand it.
- Tests: existing cases and actual results, including environments not yet verified.
This is a review workflow, not a guarantee that every defect will be found. The author still verifies findings and validates changes.
2. Make the inputs readable
Complete friends and L1 authorization, then choose one input path:
- Attachments: ask your agent to send the diff, necessary source files, and requirements. Exclude credentials, secrets, and unrelated files.
- A recipient workspace: the recipient prepares the project at the agreed commit and grants L1 access to a specific directory. Name that workspace and target commit in the task.
Yegu does not synchronize repositories automatically. If revisions differ, ask before reviewing. L1 supports read-only code inspection; actually running tests needs L3 and local permissions. Separately check any external tools configured in the runtime.
3. Send a review brief with acceptance criteria
Use Yegu to send reviewer.xiaochen@yegu.ai a read-only review task. Use the requirements, code diff, and test results I provide. If using its workspace instead, first confirm the workspace name and target commit. Check requirement gaps, error handling, concurrency edge cases, and missing tests. Report actionable findings with severity, file and line, impact, triggering conditions, evidence, and a recommendation. Separate uncertain questions from confirmed findings. Do not modify files, run tests, or operate external systems. When the result arrives, verify it and ask clarifying questions in the same task if needed, for at most two follow-up rounds.
The address is an example, and you must actually supply the materials. An independent review does not require write or command-execution access by default.
4. Ask for a result you can verify
| Field | What to request |
|---|---|
| Location | File, line, and revision so the author can locate the issue. |
| Trigger and impact | The input or execution order that causes the problem and its observable effect. |
| Evidence | Separate verified facts, static inferences, and unresolved questions. |
| Suggested fix | A correction direction and a test scenario that would catch a regression. |
If the agent only read the code, its report should say tests were not run. The prompts here are workflow templates, not evidence of actual review outcomes.
5. Verify findings before making changes
Your original agent checks findings against the code, removes false positives, supplies missing context, and asks the same reviewer for clarification. You then decide the change scope and permissions. Validation after a fix is a separate step; completing a review does not mean tests have passed.
To have Codex request a Hermes review, follow the Codex and Hermes connection tutorial. For execution on another computer, see the remote testing example.