Prerequisites

Before valinor init lands a working consumer repo, a few things need to exist at the org level. init scaffolds files; it cannot provision org-side infrastructure. This page is what each item is and why the gates need it.

What the org needs

The Valinor GitHub App

The Valinor GitHub App must be installed on the org, with packages: read. The scaffolded CI workflow mints a short-lived installation token from the App (scoped owner: cmbrcreative) and uses it to authenticate the @cmbrcreative/valinor install from GitHub Packages. Without it, the install gets a 401 and the gates can't run.

A Greptile account, App, and a connected repo

The LLM-review layer (the .greptile/ rubric suite) runs through Greptile on your pull requests — and that requires a Greptile account, the Greptile GitHub App installed, and the specific repo activated for review in Greptile's dashboard at app.greptile.com/review/github (one-time per repo — reviews aren't enabled on App-install alone). Until the repo is activated, the deterministic CI gates still run; only the per-PR review rubrics go un-evaluated. Greptile review is not free or automatic — it's gated on this activation.

Once activated, the merge gate relies on three review behaviors: auto-review of every non-draft PR and no review of draft PRs are Greptile defaults (the draft skip is the lever the gate uses — hold a PR in draft until the gates pass, then mark it ready), and re-review on every commit is the one opt-in (triggerOnUpdates: true), which valinor init weaves into your .greptile/config.json automatically. The exhaustive in-repo contract lives in docs/guide/prerequisites.md §2.

App credentials at the org level

The token mint needs two inputs at the org's Actions secrets/variables:

• VALINOR_APP_ID — the App's numeric App ID, provisioned as an Actions variable.
• VALINOR_APP_PRIVATE_KEY — the App's PEM private key, provisioned as an Actions secret.

Provision both once at the organization level (an org admin, at Settings → Secrets and variables → Actions) — every repo in the org inherits them. They're the same credentials the App's other workflows already use; the App itself is typically already installed. Until they're provisioned, the scaffolded gates job skips its gate steps and runs a loud "VALINOR GATES NOT ENFORCED" step — warning annotations plus a run-summary banner — so its green check is never mistaken for enforcement. (A zero-secret OIDC token-broker path is planned.)

Node 24+, Actions, and registry access

• Node 24 or newer — Valinor is ESM TypeScript and the scaffolded workflow pins Node 24.
• GitHub Actions enabled with adequate minutes (one job per PR + push to your default branch — init detects it from origin/HEAD and templates it into the scaffolded workflows).
• Registry access — @cmbrcreative/valinor lives in Camber's GitHub Packages; the workflow's App-minted token authenticates the pull.

What init does not do

valinor init scaffolds files into the target repo — it does not install the App, connect Greptile, provision the secrets, or configure the consumer's branch protection. The required status checks (gates, Greptile Review, greptile-score-verify) are wired per consumer, not by init. If a freshly-init'd repo's CI looks green but no governance seems to run, the cause is almost always one of the prerequisites above.

The full setup contract

This page is the help-center summary. The authoritative, exhaustive setup contract — including the CI-workflow mechanics (the two npx auth paths, gh on the runner, fetch-depth: 0, per-workflow permission scopes, and the required checks to wire per consumer) — lives in the Valinor repository's docs/guide/prerequisites.md.

Next steps

• Ready to adopt? Walk through Installation.
• Want the layer-by-layer model? See the Governance overview.
• Hit a snag? Check FAQ & troubleshooting.