References

The standards eyeful reviews against, and the three projects it builds on.

Software quality

• ISO/IEC 25010:2023, Product quality model. The experts are divided along its characteristics (roster).

Code review

• Google Engineering Practices: The Standard of Code Review (when a comment blocks, review standard), What to look for (the experts' questions; every line is read) and How to write comments.
• Conventional Comments. The format of every comment and the names of its labels and decorations (comment format). A community convention, so it names the labels and does not justify them.
• M. V. Mäntylä and C. Lassenius, "What Types of Defects Are Really Discovered in Code Reviews?", IEEE TSE, 35(3), 2009. Review findings are functional or evolvability defects: the line between a note and the other severities (comment format).
• OASIS, SARIF 2.1.0. How findings are stored, and the two scales they are graded on: kind (§3.27.9) and level (§3.27.10) (Kind and severity).
• Tenny, Trust Doesn't Live in the Code Review, Raft, 2026. A review is an event and trust is a state; a check counts only once it has been seen to fail (limits, rounds, tests).

Design and maintainability

• T. J. McCabe, "A Complexity Measure", IEEE TSE, 1976. Cyclomatic complexity.
• W. Stevens, G. Myers and L. Constantine, "Structured Design", IBM Systems Journal, 1974. Coupling and cohesion.
• R. C. Martin, Design Principles and Design Patterns, 2000. SOLID.
• M. Nygard, Documenting Architecture Decisions, 2011.

Correctness and security

• SEI CERT Coding Standards.
• CWE and the CWE Top 25. The weakness class of each correctness and security finding.
• OWASP Top 10 and OWASP ASVS.
• OSV and CVE. Known vulnerabilities in dependencies.

Testing

• E. T. Barr, M. Harman, P. McMinn, M. Shahbaz and S. Yoo, "The Oracle Problem in Software Testing: A Survey", IEEE TSE, 41(5), 2015. Specified, derived, implicit and human oracles (the oracle).
• ISO/IEC/IEEE 29148:2018, Requirements engineering. Inspection, analysis, demonstration and test (evidence).
• C. E. Jimenez et al., "SWE-bench: Can Language Models Resolve Real-World GitHub Issues?", ICLR 2024. Fail-to-pass, pass-to-pass, and the statuses PASSED, FAILED and ERROR (the verifier).
• R. Just, D. Jalali and M. D. Ernst, "Defects4J", ISSTA 2014. A fault is tied to the change that introduced it: the introduced gate.
• C. Zhang et al., "SoK: DARPA's AI Cyber Challenge (AIxCC): Competition Design, Architectures, and Lessons Learned", arXiv:2602.07666, 2026. A proof of vulnerability, then a patch validated by reproducing it and running the functional tests: the two claims the gates support. A precedent, not where the gates come from.
• N. Alshahwan et al., "Automated Unit Test Improvement using Large Language Models at Meta", FSE Companion 2024. A generated test is kept only if it builds and gives the same result over five runs: the runs and not_flaky gates.
• ISO/IEC/IEEE 29119, Software testing. Test design techniques.
• A. van Deursen, L. Moonen, A. van den Bergh and G. Kok, "Refactoring Test Code", XP 2001. Test smells.
• Y. Jia and M. Harman, "An Analysis and Survey of the Development of Mutation Testing", IEEE TSE, 2011.
• Martian, "Code Review Bench", 2026, https://github.com/withmartian/code-review-benchmark. The offline set and the judge match.py runs.

Usability and accessibility

• W3C, WCAG 2.2 and the WAI-ARIA Authoring Practices Guide.
• J. Nielsen, 10 Usability Heuristics for User Interface Design.
• ISO 9241-110:2020, Interaction principles.
• RFC 9457, Problem Details for HTTP APIs, and Semantic Versioning 2.0.0.

Readability and documentation

• Effective Go, PEP 8 and the Google style guides, used when the project has no guide of its own.
• Diátaxis. The four kinds of documentation.

Projects

From antfu/pulls.review (MIT). eyeful runs @pulls.review/core to group the change (The plan) and shows its summary first in the terminal. It also takes three ideas:

Idea	Where
Sort files with rules before any model runs	Triage
Read a working tree through a copy of the index	The snapshot
Review a large change one scope at a time	Large changes

From umputun/revmux:

Idea	Where
A fixed sequence of stages	Stages
Merge findings within two lines and count their sources	The ranked report
Carry on with less when a step fails	Stages
Pass the previous round's findings to the next	Rounds
Keep a round's input beside its output	snapshot.json and change.diff
One process per reviewer	Each expert runs on its own
A cap on concurrent reviewers and time limits per call	Agents

From alibaba/open-code-review (Apache-2.0), compared on 2026-10-28 after a 58-minute cloud review:

Idea	Where
Eight experts or judges at once, and a 15-minute cap on each call	Agents
A time limit on each model request	Agents and models

Compared with similar tools

	Claude Code ultrareview	revmux	Open Code Review	eyeful
Who picks reviewers	Not published	The caller picks a profile	Rules match files; one agent per file bundle	A planner groups the change; Go picks by rule
What is reviewed	Bugs	What the profile's lenses cover	Defects, guided by review rules per file	Design, functionality, security, tests, usability, readability
How findings are verified	Reproduced in a cloud sandbox	Another agent reads the code	A reflection pass re-reads each comment; nothing runs	The verifier runs a test; the rest is marked review
Feedback	Findings, without fixes	JSON or Markdown with a fix text	Line comments and a summary	Conventional Comments in a ranked report
Where it runs	Anthropic's cloud	Inside the reviewed repository	The user's machine, CI jobs and IDE plugins	The user's machine, or a sandbox per pull request