GitHub Release Gates
Evidence-backed release governance for AI-generated software
Enterprise Skills classifies each change's risk, requires the right evidence, and posts one explainable, commit-bound release decision as a required check, then proves exactly why every commit was allowed into production. Setup is four required steps, about ten minutes, plus one optional step for agent-produced evidence.
- 1
Install the GitHub App
Install Enterprise Skills Release Governor on the repositories you want governed. Permissions are minimal: checks (write), pull requests, contents, and metadata (read).
- 2
Add your license key as a repository secret
In your repo: Settings → Secrets and variables → Actions → New repository secret. Name it
ES_LICENSE_KEYwith the license key from your purchase email. The key never appears in workflow files. Active-repository limits follow your plan (Pro 3 · Team 10 · Enterprise contract-defined). - 3
Add the Release Governor workflow
Create
.github/workflows/release-governor.yml:name: Release Governor on: pull_request: types: [opened, synchronize, reopened] permissions: contents: read id-token: write jobs: govern: runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 with: ref: ${{ github.event.pull_request.head.sha }} fetch-depth: 0 - uses: actions/setup-node@v4 with: node-version: 20 - name: Activate license run: | mkdir -p ~/.enterprise-skills node -e "require('fs').writeFileSync(require('os').homedir()+'/.enterprise-skills/license.json', JSON.stringify({ key: process.env.ES_LICENSE_KEY }))" env: ES_LICENSE_KEY: ${{ secrets.ES_LICENSE_KEY }} - name: Govern and post the decision run: npx --yes enterprise-skills@^4.3.0 govern --post --pr "$PR_NUMBER" --base "origin/$BASE_REF" env: PR_NUMBER: ${{ github.event.number }} BASE_REF: ${{ github.base_ref }}The Governor reads commit-bound evidence from
.project-ai/skill-outputs/: produced by your reviewing agent for each change. Every file declares the commit it was produced against with a top-level commit: <sha> field; run enterprise-skills evidence bind after committing the change to stamp it. Missing evidence for a required domain fails closed, and so does evidence that carries no binding or belongs to an earlier commit. - 4
Optional: produce semantic evidence automatically
When a change requires evidence no CI tool produces mechanically (API compatibility, migration safety, observability/rollback readiness), you can let your own coding agent produce it in CI instead of relying on a reviewer to commit it. Add this step before the govern step, with your model credentials as a secret:
# Optional: auto-produce semantic evidence before governing. # Runs ONLY the agents this diff's risk classification requires. - name: Semantic domain agents run: npx --yes enterprise-skills@^4.3.0 agents run --yes --base "origin/$BASE_REF" --agent-cmd "claude -p \"{prompt}\" --permission-mode acceptEdits" env: BASE_REF: ${{ github.base_ref }} ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}The same risk classification the Governor uses selects which agents run: a docs change runs none, a migration runs migration-safety, and each agent must write schema-valid evidence while touching nothing else, or the step fails closed. Any agent CLI works via
--agent-cmd; we never pick a vendor for you. Agent output is evidence, never policy: the deterministic Governor still makes the only decision. - 5
Make the check required
Repo Settings → Rules → Rulesets → New branch ruleset: target your default branch and require the status check
enterprise-skills/release-governor. From that moment, merges block until a fresh, passing decision exists for the exact head commit.
What you get on every PR
- Deterministic risk classification of the actual diff (database migration, auth, API contract, infrastructure, dependencies, UI) selecting only the required evidence domains, never every check on every change.
- One explainable PASS/FAIL bound to the exact commit, with per-domain evidence states and the policy version that decided it.
- An Ed25519-countersigned, append-only record: browse it in your Release Records and verify offline against the published public key.
Trust architecture
Why you can trust the record
Evidence is bound, attested, countersigned, and chained: so an auditor can verify what shipped without trusting us, or you, at read time.
- 01
Evidence is produced
Your CI and your agents emit evidence (skill outputs, test results) bound to the exact commit and tree. Evidence from an earlier commit is rejected as stale, never silently reused.
commit-bound · stale = rejected
- 02
The producer is attested
Decisions posted from GitHub Actions carry an OIDC token the server verifies against the repository: proof of which workflow produced them, with no long-lived secret to steal.
GitHub OIDC · repository-bound
- 03
The server countersigns
Every accepted decision and deployment event is countersigned with the server's Ed25519 key. A local actor can rewrite their own files; they cannot rewrite the server's signature history.
Ed25519 · key 9a05918b3742d1b3
- 04
Entries chain into a ledger
Countersignatures land in a per-tenant, append-only transparency log whose running root hash is included in every subsequent entry: deletion and reordering are detectable, not deniable.
append-only · chained roots
- 05
One canonical Release Record
Per pull request and commit: the risk classification, every evidence item with its state, the decision and its explanation, overrides, and the deploy-to-promotion timeline.
- 06
Anyone can verify offline
Signed exports verify against the published public key: an auditor checks what shipped and why without an account, an API call, or trust in this site being honest today.
/api/evidence/public-key
This is the same chain that protects the live records counted on the homepage: the signing key shown is the production key serving right now.