Pull request reviews

Tasuku turns eligible pull request webhooks into durable review workflows. A webhook request verifies and records work; an independent worker performs the review later.

Eligible triggers

Repository policy independently controls review on:

pull request opened
pull request reopened
draft converted to ready for review
pull request synchronized by a new push

Draft reviews are a separate policy choice. If drafts are disabled, a draft open or push is not reviewed until a later eligible ready event.

Admission checks

Before work is queued, Tasuku checks that:

The delivery signature is valid and its delivery ID is new.
The GitHub installation can still access the repository.
The repository is enabled in Tasuku.
The event and draft state match repository policy.
The author is not excluded.
The changed-file count is within the configured limit.

Excluded path patterns keep matching files out of agent review. Configure broad generated, vendor, or lock-file exclusions deliberately; the agent cannot report on content it never receives.

Strictness and limits

Strictness is LOW, MEDIUM, or HIGH. It changes the review posture supplied to the agent; it does not bypass publication validation.

max_changed_files accepts 1 through 5000. comment_limit accepts 1 through 100. Tasuku stores the complete validated finding set; the comment limit only bounds the deterministic subset published to GitHub.

Execution

The trusted worker resolves effective repository configuration, obtains short-lived read-only repository access, and checks out the primary repository at the exact pull request head SHA. The agent can load an approved supporting repository at its exact pinned commit when the review needs it; supporting checkouts remain read-only.

The first eligible review inspects the pull request's merge-base diff. Each later push is reviewed incrementally, from the head of the last review that completed successfully to the new head, while the reconciliation step updates findings carried forward from earlier commits. Basing the range on the last reviewed head rather than the webhook's previous head means commits pushed while reviews were disabled, excluded by policy, or failing are still reviewed on the next eligible push instead of being skipped. A force push restarts the range at the pull request's merge base, because it rewrites the commits the earlier review read.

The sandbox runs Codex, Claude, or OpenCode without GitHub credentials. It returns structured review output, which Tasuku validates, stores, and publishes through the GitHub App.

Findings

A finding records its file, narrowest changed-line location, severity, message, evidence, validation state, and stable fingerprint. A range is used only when every selected changed line is necessary to demonstrate the problem. Review summaries include the inspected areas, important files, validation, context sources, confidence, and limitations; a clean review is therefore more than a bare approval. The dashboard keeps the full finding set even when the publication limit prevents every candidate from becoming a GitHub comment.

On later pushes, Tasuku compares stable fingerprints with the previous review:

findings that remain current are reconciled with their existing thread;
new findings can create new comments;
resolved findings receive a commit-specific verification reply before their thread is resolved;
findings whose referenced code no longer exists receive an explicit outdated reply before resolution.

This avoids starting an unrelated thread for the same unchanged problem on every push.

Automatic approval

Repositories can opt into automatic approval from their Automation settings. After findings are saved and any previous findings are reconciled, Tasuku checks the pull request again on GitHub. Approval is submitted only when the reviewed head is still current, the pull request is open and no longer a draft, the author is not Tasuku, and no open Tasuku findings remain.

If a current-head review has open findings, Tasuku publishes a comment review and dismisses its own earlier active approvals. Human approvals are never changed. If the head changed while Tasuku was reviewing, Tasuku publishes a comment without approving or dismissing anything; the newer webhook run evaluates the new head.

Tasuku approval is a code-review result only. CI, branch protection, required checks, and merge eligibility remain separate repository gates, and Tasuku never merges the pull request.

Failures and retries

Transient failures are retried with backoff inside the run's workflow. If the sandbox is lost mid-run, the Scheduler Durable Object reclaims its lease and starts a new attempt. A retry creates observable attempt history rather than hiding the earlier failure.

Use the workflow-run events on the work item detail and pull request detail views to distinguish admission, clone, sandbox, provider, validation, and GitHub publication failures.