Your repo sets the rules. Charlie runs the review.

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/
├── DAEMON.md
└── references/lanes/
    ├── correctness.md
    └── repository-guidance.md

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, architecture, or release readiness. Another repository might need a focused perspective for data retention, accessibility, infrastructure policy, or a domain-specific invariant.

The important part is that each lane represents a distinct question. Teams define its applicability, evidence bar, exclusions, and depth. They can narrow a noisy lane, split a perspective whose concerns require different evidence, combine overlapping lanes, or remove one that no longer earns its review cost.

Installed does not mean always run. Charlie evaluates which lanes are relevant to the current pull request and skips perspectives that cannot add useful judgment. A documentation-only edit should not automatically trigger every runtime-oriented investigation. A change to authentication behavior can justify a focused authorization lane without forcing that same work onto an unrelated build-script update.

Selection keeps the system responsive to the change instead of treating the number of lanes as a target.

Charlie selects relevant perspectives, runs them independently against the same current pull request, and synthesizes their evidence into one reviewer experience.

Parallel investigation, one synthesized review

Once Charlie selects the applicable lanes, focused subagents can investigate them independently and in parallel. Each starts from the same current evidence: the diff, changed files, checks, pull request discussion, prior feedback, and relevant repository context.

Shared evidence matters because the perspectives should disagree only in judgment, not because they reviewed different versions of the change. The correctness lane can trace runtime behavior while repository guidance checks the same files against an explicit contract. A migration lane can inspect data transitions while an API compatibility lane considers consumers. Each perspective stays narrow enough to specialize, and independent checks do not become a needlessly serial queue.

Lane outputs are candidate evidence, not separate public bot comments. Charlie centrally verifies the candidates against the root policy and the current pull request. He combines duplicates that describe the same underlying problem, avoids repeating feedback already covered adequately by checks or people on the PR, and preserves materially distinct risks even when they touch the same code.

That synthesis is what turns multiple perspectives into one reviewer. Authors should not have to reconcile a collection of lane reports, repeated warnings, or conflicting bot voices. When useful feedback exists, Charlie produces one coherent review with the strongest evidence and the repository’s presentation rules applied consistently.

The same principle applies on re-review. The reference considers the full current pull request while focusing on new changes and the behavior they affect. It avoids repeating findings that were resolved, dismissed with supporting evidence, or explicitly accepted by an authorized maintainer unless materially new evidence changes the risk. A re-review is not a blind replay of the first pass.

You control judgment; Charlie handles the moving system

Repository policy should describe the decisions that genuinely vary by team. It should not require customers to build an orchestration engine in Markdown.

Your repository controls:

• which events should start review;
• which lanes exist and when each applies;
• what evidence feedback requires;
• which categories should never become feedback;
• how re-reviews handle new changes and prior findings;
• presentation, placement, ordering, and consolidation;
• which review outcomes are allowed; and
• how broad and deep the work should be.

Charlie handles:

• collecting the current pull request and relevant repository context;
• selecting applicable lanes;
• giving focused subagents shared evidence and running independent work in parallel;
• verifying lane evidence and applying review-wide rules;
• reconciling overlap and feedback already on the pull request;
• synthesizing one customer-visible result; and
• reliably delivering the configured outcome to the current GitHub pull request.

Pull requests can change while review is in progress, so Charlie also handles compact but important delivery mechanics such as checking the current state and comment locations, respecting authorization, and retrying without turning those concerns into customer-authored workflow code.

Teams define review meaning and authority. Charlie runs the changing system required to apply that policy as one coherent reviewer.

Customize the work, depth, cost, and outcome

The same policy that shapes review quality also shapes the amount of work. Teams choose how frequently the daemon runs in DAEMON.md, how many lanes exist and which ones are applicable, and how broadly or deeply each lane investigates through its guidance.

The reference reviews when an eligible pull request opens or becomes ready, when CharlieHelps is requested as a reviewer, or when a pull request comment explicitly requests review. A repository can instead require explicit requests, add push-based re-review for substantial updates or every commit, or choose another supported combination. A lane can apply to most runtime changes or only to a narrow class of paths and behavior. Its instructions can ask for local context, callers, schemas, tests, history, or dependency documentation when those sources are needed to establish a material consequence.

This is cost control through control of the work. The goal is not to invent a hard budget slider or make every review equally shallow. Teams can spend deeper investigation where it is valuable and avoid running broad perspectives where they are irrelevant. The canonical cost-controls guide provides more specific recommendations.

Outcomes are customizable too, but they are one part of the larger system. The current reference publishes formal findings as COMMENT. A customer can define thresholds for APPROVE or REQUEST_CHANGES if those outcomes fit its workflow and GitHub permissions. Those choices do not replace branch protection or required human approval.

The reference also defines a quiet clean result. When every applicable lane completes with no useful finding and no coverage limitation, Charlie leaves one +1 reaction on the pull request body instead of manufacturing an empty review or “LGTM” comment. Teams can edit that behavior. The reaction indicates the configured review completed cleanly; it is not a merge control or a substitute for human judgment.

Start from the reference, then evolve it through pull requests

You do not need to design the system from a blank page. Start from the public reference PR-review daemon: its DAEMON.md, correctness lane, and repository-guidance lane. Review when it wakes, what it excludes, what evidence it requires, how it handles re-reviews, and what it may publish. Then adapt those choices to the repository in front of you.

Add a lane when a distinct perspective deserves focused attention. Narrow one when it runs too often. Strengthen an evidence rule when plausible concerns are not yet useful. Change cadence when the work should happen more or less frequently. Evolve those decisions through the same pull-request process your team already uses for code and other repository policy.

Dashboard Activity shows the review run and its status. What appears on GitHub follows the daemon policy in your repository. Daemon-powered review runs through Charlie; it is not a GitHub Action that your team has to assemble and maintain.

The launch changes the relationship between your team and automatic review. You no longer have to accept one broad, fixed pass as the definition of useful feedback. You can define a system of relevant perspectives, give each one a clear job, and change that system as your codebase changes.

Charlie handles the live pull request, the parallel work, and the synthesis into one result.

You control judgment. Charlie handles the moving system.