GitHub App review
Have OriginAI review each pull request against the product spec it claims to implement — nothing missing, nothing extra, nothing wrong.
The OriginAI GitHub App reads the spec change a pull request claims to implement and checks the code against it. It answers one question: does this PR implement exactly the released spec delta?
- Missing — a requirement in the spec delta with no implementation in the diff.
- Extra — user-visible behaviour in the diff that the spec never asked for.
- Wrong — an implementation that contradicts the spec.
Findings live on the check run. When the review says the spec is wrong, the App stages a change request in OriginAI for you to apply — it never writes the live workspace.
What triggers a review
The App keys off release_hash in your repository's .origin.json — the pointer to the last published release this repository has implemented.
| Trigger | Behaviour |
|---|---|
| PR opened, reopened, or a new commit pushed | Reviews only when the PR's release_hash differs from the base branch's. A plain code PR is skipped. |
@originai-review in a PR comment | Always reviews (use GitHub's mention autocomplete). With no hash change there is nothing owed, so it only reports extra and wrong. Legacy @originai review still works. |
@originai-review <hash> | Reviews against that release hash even though .origin.json still points elsewhere. Useful when you just republished the spec. |
Draft pull requests are skipped until they are marked ready.
The verdict lands on a check run named originai / spec-review. The App does not leave a pull-request comment. A clean review is success; findings are informational (neutral) — the check does not fail, so it will not block merges via required status checks. Use the severity levels (blocker / major / minor) on the check to decide what to do.
If .origin.json carries a proposal_id (set with npx originai get-proposal-diff <id> --bind), the App reviews the code against that change request's proposed tree versus the published release. Otherwise it compares release_hash as in the table above. Spec-side findings from the same PR accumulate in one GitHub-sourced change request.
Setup
- Install the App on the repositories you want reviewed. GitHub sends you to the App's setup page afterwards.
- Paste an OriginAI access token on that page. A read-only token is enough — it can read published releases and stage change requests, but it cannot apply them. The token is stored encrypted and is bound to that installation.
- Make sure each repository is linked:
npx originai login
npx originai linkThe first Origin account to connect an installation owns it. Rebinding later requires a token from the same Origin workspace.
The loop
spec released → PR bumps release_hash → review
├─ pass → merge
└─ issues → fix, then re-triggerRe-trigger in whichever direction the finding points:
- The code is wrong — fix it in the repository and push. The new commit re-runs the review automatically.
- The spec is wrong — apply the staged change request in OriginAI, publish a new release, then comment
@originai-review <new hash>on the PR. Once it passes, commit the pointer bump withnpx originai sync.
The App never pushes to your branch; advancing release_hash stays your commit.
Limits
- One
.origin.jsonat the repository root. Monorepos with several linked projects are not supported yet. - Very large pull requests are truncated before the review, and the check summary says so.
- The review reads the diff, not the whole repository, so it errs toward flagging nothing when the code plausibly relies on existing behaviour it cannot see.