Project review
Five review lenses run in parallel over your codebase, each measuring with your repo's own tooling and citing its evidence.
Project review fans out a set of agents across your codebase, each measuring one thing with your repo's own tooling, and returns a single report where every number says where it came from.
It is the answer to "what shape is this codebase actually in" when you don't have a week to find out.
The five lenses
Each runs as its own agent, in parallel:
- Dependency health — stale majors, unmaintained packages, advisories with published fixes.
- Test coverage & gaps — coverage by area, and which untested paths actually matter. A static scan; it never runs your tests.
- Architecture & coupling — fan-in, dependency cycles, modules that have become shared mutable surface.
- Security surface — IPC validation, credential handling, CSP, untrusted content paths.
- Dead code — unreachable files, unused exports, subsystems nothing depends on.
Run all five or pick the ones you care about. You can also narrow a review to chosen folders, which is the difference between a useful answer and a 400-finding wall on a large repo.
The dead-code lens is the one to think about before running. It invokes your ecosystem's static dead-code analyzer (knip, or the equivalent), which may be fetched from the package registry. Analyzers read code rather than execute it, but you are still pulling a tool into your repo — pick this lens only on repos you trust.
Read-only by design
Every lens gets a narrow allowlist of measurement commands — audits, outdated checks, counts — and cannot touch your working tree. A review cannot change your code, so running one is never a decision you have to weigh against risk of damage.
Measured, not vibes
This is the part that makes the report worth reading. Every metric cites the exact command or file it came from, and anything the agent could not verify is visibly marked as an estimate rather than quietly rounded into a number.
Findings are ranked by consequence and quote their evidence — the file, the lines, and why it matters in your repo specifically rather than in general.
Acting on a finding
Two routes from any finding:
- Start session to fix — spawns an agent already briefed with the finding and its evidence.
- Copy as prompt — takes the same brief to any session you already have open.
You can re-run a review as the code moves, and export the whole report as one self-contained HTML file if you need to hand it to someone who doesn't have Foreman.
While it runs
Each lens reports its own state — queued, running, done, failed or cancelled. A lens that fails doesn't take the review with it; you get the other four and an honest gap where the fifth would have been.
Language support
Lenses detect the ecosystem and use its own tooling: pnpm audit in a Node repo, pip-audit in Python, govulncheck in Go. There is no separate configuration for this — if the ecosystem has the tool, the lens uses it.