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. 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. 2

    Add your license key as a repository secret

    In your repo: Settings → Secrets and variables → Actions → New repository secret. Name it ES_LICENSE_KEY with 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. 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. 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. 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.

Need a license? See plans. Questions? Help hub.

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.

  1. 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

  2. 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

  3. 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

  4. 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

  5. 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.

  6. 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.