How Critique fits together

Critique is not an IDE plugin. It sits next to GitHub: the GitHub App holds installation identity and talks to the API, while this app holds users, entitlements, review runs, chat sessions, and the policies that decide which models run and whether sandbox or API-backed evidence is used.

You can require the check named Critique / Review so merges wait on the review outcome. The review itself is still advisory in spirit; the check encodes your team's bar for "ready to merge."

GitHub delivers signed webhooks to /api/github/webhooks. Each delivery is deduped and stored so support can trace what happened. Pull request events such as opened, synchronize, and ready for review enqueue work when your automation rules allow it.

After install, /github/setup walks account linking. Repository and installation records stay synced so the right token is used for checks and comments.

The server cannot do all review work inside the webhook request. Outbound calls go through Upstash QStash, which invokes routes under /api/qstash/… (for example process-delivery, review run, review analysis, remedy, builder, chat runs, and repo indexing). That gives retries, signing, and separation from the interactive request path.

A weekly Vercel cron under /api/cron/weekly-email-captures is for product email flows—not for PR review timing. Reviews are event-driven from GitHub and your reruns.

For a given pull request and head SHA, the system upserts a ReviewRun and moves it through queued, in progress, and terminal states. The pipeline opens or updates a check run, gathers evidence, runs specialist and lead model passes, normalizes findings, and publishes a summary on the PR. Reruns (from the button, API, or a rerequested check) reuse the same wiring.

From the app you get deep links and dashboards; from GitHub you see the check, the review body, and threadable discussion—including later assistance that ties back to the run when you use in-thread commands.

When policy allows, analysis can run in an E2B sandbox: clone, diff, search, and optional local checks, with artifacts written back for the model stages. If sandboxing is off, misconfigured, or errors, the pipeline falls back to a GitHub API scout path so a review still ships with coarser but reliable context.

Remedy is a separate track: it turns eligible findings into an OpenCode-style run in a managed environment, with validation and branch updates when your permissions and policy allow. Builder (below) is similar machinery aimed at ad hoc jobs rather than a specific review handoff.

Defaults live at the installation; a repository can override. That includes path rules, which models back the lead and specialists, Remedy settings, and whether sandbox review is in play. Entitlements gate which models you can select on your plan.

The public /models page describes the catalog; the actual resolution happens server-side with your policy snapshot at run time.

Mention the bot in a PR comment to trigger focused sub-runs: for example follow-up review, explain, security or test lens, and fix-oriented prompts where enabled. The exact command set is the same product surface the parser routes into chat-style responses tied to the thread.