Quickstart
Install Dicast on one repository, open a pull request, and read your first verdict. About two minutes of work, most of it on GitHub’s side.
1. Install the app
Sign in with GitHub and authorise the Dicast app. On the repository selection screen, pick a single repository to start with — you can add the rest later, and nothing is reviewed until you do.
Dicast requests read access to the repositories you select, plus permission to post review comments and publish a status check. It never pushes commits, never merges, and never requests changes on behalf of a human reviewer.
Leave your current review tool running for the first two weeks. Dicast posts alongside it, and the comparison — how many comments each posted, how many you acted on — is the only benchmark that reflects your codebase.
2. Open a pull request
No further setup is needed. The next pull request opened against your default branch is heard automatically. You’ll see two status checks appear:
# Checks on pull request #482
✓ dicast / review 3 posted, 9 struck Details
✕ dicast / merge-gate 1 unanimous finding Details
dicast / review always passes — it reports what the panel decided to post. dicast / merge-gate fails only when a finding was affirmed unanimously. Neither blocks anything until you mark the gate as required in branch protection.
3. Read the verdict
Each posted comment carries the vote it received. Three filled discs mean all three jurors affirmed the finding; two mean one juror refuted it and was outvoted. Findings that reached fewer than two votes are struck — they never appear as comments, but they are kept.
Open the Details link on the review check to see the struck record: every rejected finding, the vote it got, and the reason each juror gave for refuting it. This is the fastest way to tell whether the panel is calibrated for your codebase.
4. Tune the panel
Commit a .dicast.yml to your repository root. Every setting is optional; the defaults below are what runs if the file is absent. The full list is in the configuration reference.
panel:
jurors: [anthropic, openai, google]
threshold: 2 # votes required to post a comment
block_at: 3 # votes required to fail the merge gate
scan:
paths: ["src/**", "!**/*.generated.ts"]
max_diff: 3000 # lines; larger PRs are split and heard in parts
rules:
- "Money paths must be idempotent."
- "No network calls inside a request handler."
suppress:
- style
- test_coverage
Where to go next
How the panel works
Why jurors are asked to refute rather than confirm, and what vendor independence buys you.
Writing house rules
Turning the invariants your team already argues about into evidence the panel weighs.
The merge gate
Making the check required, scoping it to paths, and handling an override.
Security and data handling
What is sent to model vendors, what is retained, and how to run on your own keys.