OriginAIProduct specs for Claude Code, Cursor, and Codex

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.

TriggerBehaviour
PR opened, reopened, or a new commit pushedReviews only when the PR's release_hash differs from the base branch's. A plain code PR is skipped.
@originai-review in a PR commentAlways 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

  1. Install the App on the repositories you want reviewed. GitHub sends you to the App's setup page afterwards.
  2. 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.
  3. Make sure each repository is linked:
npx originai login
npx originai link

The 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-trigger

Re-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 with npx originai sync.

The App never pushes to your branch; advancing release_hash stays your commit.

Limits

  • One .origin.json at 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.

On this page