Method

Where the material comes from

The input is code review discussion on public pull requests: the diff under review, the reviewer's comment, and the replies that resolved it. Review comments are where standards are stated explicitly — a maintainer explaining why a change is unsafe is more specific than the same project's documentation usually is.

Threads that repeat the same point across a repository are grouped, and the recurring requirement is written up as one instruction: a rule, the reasoning, and usually an example of the shape being asked for. Everything is stored as plain markdown in _reviewers/, with the source threads kept in a sibling JSON file so any instruction can be traced back to the comments it came from. The Source discussions section on each instruction page is that file, rendered.

How entries are dated

Dates are derived, not declared. For each instruction, the timestamps of every comment in its source threads are collected: the newest is its last update, the oldest its first seen. A domain's date is the newest date among its instructions, and the corpus date is the newest of all.

So a date means the review conversation behind an instruction was still active then. It does not mean the text was rewritten that day. An instruction from 2023 whose repository has moved on will look old, which is the useful signal.

How domains are assigned

Domain comes from the source repository, because that is what determines the kind of system the expertise applies to — an error-handling rule from an inference server is about inference servers. The mapping is explicit, one entry per repository, in build_data.py; repositories added later fall back to a keyword rule and get reported in the build log so the mapping can be made explicit. Topic and language come from the entry itself and cut across domains.

Regenerating everything

Nothing outside _reviewers/ is a source of truth. Domain stats, dates, indexes, raw endpoints, bundles and llms.txt are all derived:

git clone https://github.com/baz-scm/awesome-reviewers
cd awesome-reviewers
python build_data.py      # regenerate every derived artifact
bundle install && bundle exec jekyll serve

Limits

• Coverage follows whichever repositories have been processed, not the importance of a topic. Gaps are gaps in the input, not judgments.
• Instructions reflect one project's standards at one point in time. Two repositories in the same domain can disagree, and both are in the corpus.
• Some source comments are written by review bots. They are counted and attributed like any other reviewer on the sources page.
• This is community-contributed material distilled from public discussion. It is not official guidance from the projects it was derived from, and it is not guaranteed to be correct for your codebase. Report anything harmful or wrong as an issue.

Contributing

Submit a public repository from the sources page and it is queued for extraction. Corrections to an existing instruction are pull requests against its file in _reviewers/.