Pull request reviews
Review triggers, policy limits, finding publication, and reconciliation.
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, checks out the primary repository at the exact pull request head SHA, and mounts any approved secondary repositories read-only at exact commits.
The sandbox runs Codex or Claude 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 worker failures are retried with backoff. Active tasks heartbeat their lease; another worker can reclaim an expired lease after a crash. A retry creates observable attempt history rather than hiding the earlier failure.
Use Workflow diagnostics to distinguish admission, clone, sandbox, provider, validation, and GitHub publication failures.