A repository can teach the reviewer its own questions
A .reviewer/ folder holds what only your repository knows to ask. Published to npm, but not to the MCP registry or the releases page; 1.0.4 fixed that.
The reviewer asks the same baseline questions everywhere. What it cannot know cold is what one repository always wants asked: an invariant a past incident bought, a change that must ship with its migration, a directory whose churn is never incidental. That belongs in the repository beside the code, not in a prompt the server ships.
A .reviewer/ folder at the repository root now holds it, served by a new get_reviewer_instructions. The server reads the folder rather than the agent, because the reviewer has no file access by design: reaching the transcript is exactly what the role split forbids.
House rules add questions and replace none. A repository writes its rules without the baseline in view, so a short folder read as the whole set would quietly shorten the interview. The folder is bounded (50 files, depth 3, 64 KB each) with anything cut named, and because a fork’s pull request can edit it, it is framed as reference material that cannot override the protocol or the schema.
Found by its own interview
Distilling this change found four defects in it, all fixed before release. The telling one: present meant “the folder exists” in one function and “there is something readable in it” in another, so a folder holding no markdown was reported absent and present in the same run.
Also
- •The site is cached at the edge for a day and purged on deploy, instead of revalidating on every request. The purge did not actually run until 1.0.4.
- •The landing page was rebuilt around the live demo, with an install tab per agent, an FAQ, social metadata,
robots.txt,sitemap.xmlandllms.txt.
Commits for this release: v1.0.2…v1.0.3