Quick start

About ten minutes from nothing to your first proof record. You need admin rights on the GitHub organisation or account, and a repository with GitHub Actions turned on.

1. Install the Slipmark GitHub App

   Install it here and pick the repositories you want covered. The app posts the Slipmark and Slipmark policy checks on pull requests. It can read repository contents and metadata but never writes code. The full list is on Security and data.

2. Add Slipmark to the repository

   From the repository root:

   npx slipmark init

   This writes three things, and shows you each change before it makes it:

   • .slipmark/attestations/, where your agents' attestations live. Commit this folder.
   • .github/workflows/slipmark.yml, a report-only gate that runs on pull requests and pushes to main.
   • A short instruction block in AGENTS.md (and CLAUDE.md, Copilot and Cursor rules where you have them) telling your coding agents how to attest.

3. Turn on Slipmark Cloud

   Add two things to the workflow: permission for the job to request a GitHub OIDC token, and cloud: "true" on the Slipmark step.

   jobs:
     verify:
       runs-on: ubuntu-latest
       permissions:
         contents: read
         id-token: write
       steps:
         - uses: actions/checkout@v4
         - uses: founder-ship-it/Slipmark@v0.4.0
           with:
             fail-on-refusal: "false"
             cloud: "true"

   There is no API key to manage. GitHub signs a short-lived token that says which repository, commit and workflow run the record came from, and Slipmark Cloud only accepts tokens issued for it (audience slipmark). A run can only ever write to its own repository's ledger.

4. Open a pull request

   Push the change on a branch and open a pull request. When the workflow finishes you will see:

   • A Slipmark check on the pull request saying how many verdicts matched their files, with a link to the proof page. Slipmark Cloud works this out itself from GitHub's copy of the commit rather than taking CI's word for it.
   • A link to the proof page in the job summary (public repositories).
   • The run under the repository on your dashboard. Its proof page shows the ledger entry number, the chain status and “Re-verified against GitHub”.

   No attestations yet? That is fine. The gate reports that nothing has been attested, and the run is still recorded. Ask your agent to review a file and attest it, then push again.

5. Make it block merges

   Once your agents attest reliably, two switches turn reporting into enforcement:

   • In the workflow, set fail-on-refusal: "true" so a stale or failing verdict fails the build.
   • On Team and Business, add a rule, then make Slipmark policy a required status check. In GitHub go to Settings, then Branches (or Rules, then Rulesets), edit the rule for your default branch, turn on Require status checks to pass, and add Slipmark policy.

   Making it required is safe even if your plan lapses or every rule is turned off. Slipmark still posts Slipmark policy on each pull request, as neutral (“Rules not enforced: no active plan” or “No rules turned on”). GitHub treats a neutral check as passing, so pull requests never wait on it.

   Also protect the workflow itself: add .github/workflows/ to CODEOWNERS so changes to it need an owner's review. Slipmark Cloud re-checks every verdict against GitHub's copy of the commit, so a workflow edited to report a fake pass is caught, but reviewing workflow changes is still good practice.

Pin a version

Use a release tag such as @v0.4.0 rather than @main so a new release never changes your gate without you choosing it. Releases are listed on GitHub.