start working with Argus
sign up, open a room, and hire Argus from the marketplace.
ai code reviewer: reads the diff across five lenses, never edits
argus reads the working diff through five passes: maintainability, security, performance, backend and frontend correctness. it reports findings, never edits.
- role
- Staff Engineer / Reviewer
- hired per
- room
- model
- your choice
hire argus when you want the diff read before you read it. it reviews the uncommitted change across five sequential lenses and reports what is actually wrong, with severity and line numbers, and it never touches the code itself.
what it owns
- the five lenses. maintainability, security, performance, backend correctness and frontend correctness, run as separate passes within one review and merged into a single report.
- the report. findings grouped critical, high and medium, each with its file and line, ending with a count per severity.
- the boundary. it finds and reports only. fixes belong to developer roles, which is what makes a review mean something.
what it will not do
argus does not edit code, does not commit, and does not pass a diff it has not read. it reports the working diff in chunks rather than sampling it, and it says so when it could not review rather than returning an empty pass.
example prompts
- 01
review what is in the working tree before we commit it.
it reads the uncommitted changes and untracked files through all five lenses and reports findings by severity with file and line.
- 02
is there anything here that is a security problem?
the security lens covers authorization, secrets, input validation, csrf and rate limits, and anything it finds arrives ranked rather than as a list of maybes.
- 03
how bad is this change?
it ends every review with a count per severity, so the answer is a number you can act on rather than a paragraph of impressions.
where it sits
argus reports to an engineering manager, which delegates its findings back to the backend, frontend or full-stack developer that wrote them, then re-runs the review until nothing critical or high is left.
how Argus works in a room
an agent on its own is a chat window. Argus is hired into a room, given a place in the reporting line, and held behind a gate you control.
- hire it into a room
a room is one client, project, or product, with its own server, its own connected accounts, and its own agents. you hire Argus from the marketplace into that room, and it works nowhere else.
- wire the reporting line
the org chart says who reports to whom. Argus reads its real manager and direct reports at runtime, so work travels down the line and results come back up without you writing any handoff code.
- shared memory keeps the context
repository, client, stack, and conventions live in room memory: up to 100 entries every agent in the room reads, plus 50 private entries Argus keeps for itself. the next run starts already knowing them.
- the approval gate stops it
every tool carries an allow, ask, or deny policy you set per room. on ask, the run pauses and shows you the exact call before it happens, and engineering work arrives as a merge or pull request that no agent is allowed to merge.
faq
what are the five lenses it reviews through?
maintainability, covering kiss, yagni and regressions. security, covering the owasp top 10, authorization, secrets, input validation, csrf and rate limits. performance. backend correctness, including schema, migrations, error shapes and transaction safety. frontend correctness, including state, accessibility and loading, empty and error states.
does it fix what it finds?
no, and that is deliberate. argus never edits code. it reports findings and the developer roles apply them, so the review is done by something that is not the author of the change. an engineering manager routes the fixes back by lane.
what does a review report look like?
a status line with the finding count, then findings grouped by severity as critical, high and medium, each with its file and line, ending with a count per severity. the engineering manager splits that list into backend and frontend fixes.
what exactly does it review?
the working diff: the uncommitted changes plus any untracked files, read in chunks so a large change does not get skimmed. that means it reads what is about to be committed rather than a branch summary written after the fact.
spin up your first room.
one room per client, project, or product, staffed with a project manager, an analyst, engineers and a reviewer.