roborev Documentation

ACP is an open protocol from Zed used for editor-to-agent communication via stdin/stdout JSON-RPC.

In the roborev ecosystem:

• roborev acts as the ACP client.
• The agent process acts as the ACP server.

roborev uses ACP to integrate agents that do not have built-in adapters. It handles launching the agent as a subprocess, negotiating session modes and models, sending prompts, and enforcing file access boundaries (read-only vs read-write) at the operation level.

When using the --panel <name> option, the review is distributed across a group of reviewers defined in a configuration panel.

Key behaviors for panel reviews:

• Synthesis Job: The command creates a 'synthesis' (parent) job that aggregates all individual reviewer results.
• Verdict: The final verdict and findings presented to the user are the synthesized results from the entire panel.
• Fixing: When using /roborev-fix, you must use the synthesis parent job ID, not an individual reviewer's job ID.
• Summary: You can use roborev show <job_id> to see a one-line summary of the reviewers (e.g., 3 reviewers: bug P, security F).

When a roborev daemon is running, Claude Chic automatically displays a live sidebar panel. This sidebar provides real-time feedback without leaving your coding session:

• Verdict Icons: Green P for pass, red F for fail.
• Progress: Animated spinners for in-progress reviews.
• Polling: Automatically polls for new results every 5 seconds.
• Interaction: Click a review to view its details inline.
• Git Integration: Supports multiple git worktrees; switching worktrees or branches automatically filters the sidebar to show only relevant reviews.

When executing a fix, the process follows a specific priority and grouping logic to ensure efficiency and correctness:

1. Severity Sorting: Fix HIGH findings first, then MEDIUM, then LOW.
2. File Grouping: Within each severity level, batch edits to the same file together to minimize context switches.
3. Multi-Review Batching: If the same file has findings from multiple different reviews, fix them all in a single edit session.
4. Verification: Always run the project's test suite (e.g., go test ./...) after fixes to ensure no regressions were introduced.
5. Audit: After closing jobs, verify their status using roborev show --job <job_id> --json to ensure closed=true is reported. Do not rely on roborev list --open for this audit.

The refine command runs AI agents without sandboxing. This allows agents to install dependencies, run builds, and execute tests, which is necessary for verifying fixes.

Risk Assessment:

• Your own branches: Low risk.
• PRs from trusted contributors: Low-Medium risk; review changes before merging.
• PRs from strangers/untrusted code: High risk. Malicious code could potentially access credentials, exfiltrate data, or modify your system.

Mitigation for untrusted code:

• Run roborev inside a container or VM.
• Use a low-privilege user account.
• Use a disposable cloud instance.

The roborev agent-hook layer (which provides mid-session fix nudges) relies on harness hooks (PreToolUse, PostToolUse, and Stop) exposed by the Claude Code CLI and Codex.

Claude Desktop does not expose these hooks, so the agent-hook layer will not run in the Desktop application. However, standard post-commit reviews will still function normally. You can verify review status using roborev status or roborev show HEAD.

ACP agents run as subprocesses and are subject to the following security constraints:

• Path validation: File operations (reads, writes, edits) are validated against the repository root using symlink-aware path resolution. Note that terminal operations in read-write mode are not path-bounded and can execute arbitrary commands.
• Mode enforcement: Write and terminal operations are blocked at the operation boundary when running in read-only mode, regardless of the agent's request.
• Bounded reads: File reads are capped at 10 MB. Terminal output is capped at 1 MB.

roborev automatically creates a repository entry when you perform any of the following actions:

1. Run roborev init in a repository.
2. Queue a review for a commit in a new repository.
3. Run any roborev command in an untracked repository.

The default display name is the directory name. You can customize this in your .roborev.toml file:

# .roborev.toml in your repo
display_name = "My Custom Name"

By default, roborev includes repository context in its prompts to improve accuracy. This context includes:

• Repository name and path
• Any project guidelines defined in your .roborev.toml file.

If you want to send a raw prompt without this metadata, use the --no-context flag.

When performing a design review, the skill evaluates two primary components:

1. Product Requirements Document (PRD) Review

• Completeness: Checks for goals, non-goals, success criteria, and edge cases.
• Feasibility: Ensures technical decisions are grounded in the existing codebase.
• Clarity: Verifies that decisions are justified and understandable.
• Missing Considerations: Looks for security, performance, and backwards compatibility concerns.

2. Task List Review

• Scoping: Ensures stages are small enough for incremental implementation.
• Ordering: Checks that dependencies are correctly sequenced.
• Coverage: Verifies that tasks cover all requirements defined in the PRD.
• Testability: Ensures verification steps are included in the tasks.