Your repo sets the rules. Charlie runs the review. | Charlie Labs

Daemon-powered PR reviews are now generally available. They replace Charlie’s previous automatic PR reviews with a review system your repository can define and evolve.

You control judgment; Charlie handles the moving system.

That is the central idea behind the launch. Your repository defines what useful review means: when Charlie should review, which perspectives matter for a change, what evidence earns an author’s attention, how follow-up reviews should behave, and what Charlie may publish. Charlie handles the live system around that judgment: gathering the current pull request, selecting relevant perspectives, running focused investigation, reconciling the results, and delivering one coherent review.

This is a meaningful upgrade over Charlie’s previous automatic PR reviews and the common pattern of applying one broad review pass to every change. A single general reviewer has to carry every concern at once. It can apply the same depth where it is not useful, miss repository-specific standards, or mix unrelated feedback into a noisy result.

Daemon-powered reviews work differently. Teams define a review system from focused parts. Charlie decides which parts apply to the current change, runs those perspectives independently against shared evidence, then verifies and synthesizes their output before anything appears on GitHub.

The result is not simply more configuration or more agents. It is a reviewer your team can shape as its codebase and standards evolve.

From one broad review to a repository-defined system

The review system begins with ordinary Markdown in your repository. The current reference looks like this:

.agents/daemons/pr-review/<br>├── DAEMON.md<br>└── references/lanes/<br>├── correctness.md<br>└── repository-guidance.md<br>DAEMON.md is the review-wide policy. In plain language, it defines when the role wakes, the evidence and feedback rules that apply across the review, how re-reviews treat prior work, how feedback should be presented, and which outcomes Charlie is allowed to use.

The checked-in reference runs when an eligible pull request opens, a draft becomes ready, CharlieHelps is requested as a reviewer, or a pull request comment explicitly requests review. It does not review every new commit by default, though teams can add push-based re-review cadence when that additional coverage is worth the work. It excludes feedback that would waste an author’s attention: personal style preferences without a governing repository rule or concrete behavior risk, problems the pull request did not introduce or make materially riskier, expected generated artifacts without a real consequence, and issues already covered adequately by checks or another reviewer.

It also establishes a practical evidence bar. A finding needs a concrete issue, a plausible trigger or supporting evidence, and a material consequence. The goal is not to list everything that might be wrong. The goal is to report what is useful enough to change a decision or materially improve the pull request.

Because the policy lives in the repository, changing review behavior is a normal engineering change. A team can inspect the current rules, propose an edit in a pull request, discuss the tradeoffs, see the history, and roll back a change. Review policy can evolve with the system it governs instead of living as an opaque universal default.

The policy used for a review comes from the repository’s accepted version, so a pull request cannot rewrite the rules used to judge itself.

Focused lanes, selected for the change

Review lanes define focused perspectives. Each lane can say when it applies, what it should investigate, what evidence a finding needs, which cases to exclude, and how deeply to follow a concern.

The current reference starts with two lanes.

The correctness lane applies when a change can affect runtime behavior, externally visible results, stored state, data transformations, error handling, concurrency, retries, ordering, or lifecycle behavior. It looks for concrete problems such as an incorrect result on a reachable path, a broken state invariant, or an unhandled boundary or failure. Its evidence rules ask Charlie to connect the trigger, expected behavior, changed behavior, and consequence rather than presenting a hypothetical edge case as a finding.

The repository-guidance lane applies only when current repository instructions, documentation, schemas, or contracts govern the changed paths or behavior. It can identify a conflict with an explicit path-specific requirement, a regression against a documented interface or lifecycle contract, or a missing safeguard that repository policy actually requires. It does not turn nearby patterns or generic best practices into invented rules.

Those are reference choices, not a fixed Charlie taxonomy. A payments team might add a lane for authorization boundaries. A platform team might add migration safety, API compatibility,...