Skip to main content

Start Here: Six Lessons

Everything in this documentation set is real and verified — and there is a lot of it. You do not need most of it on day one. Take these six lessons in order and you are good to go. Each one builds on the last, states how long it takes, and ends with something working.

Two notes before Lesson 1: do it in a throwaway directory — the real profile decision is Lesson 2, and a scratch run is what makes deferring it legitimate. And if you are here to review rather than adopt, Lesson 6 alone is your path — it needs only an evidence file, not the toolchain.

The path

Lesson 1 — Install it and reach a green gate

Getting started: zero to first passing gate · ~30 minutes

Install the CLI, initialize a project, stage a real failure on purpose, read the finding, fix it, finish green. When you are done you have a working governed repository and you have seen the gate catch something.

Lesson 2 — Choose the right profile for your repository

Choosing profiles, presets, and frameworks · ~20 minutes

Lesson 1 used the appsec profile on faith. This lesson is the decision you actually own: which profile fits your repository, what each one installs and enforces, and which compliance frameworks it selects. Do this before initializing anything real.

Lesson 3 — Write your first spec

Your first spec · ~30 minutes

The gate exists to judge specs. Copy the template, fill it section by section, stage a defect so you see a finding fire, reach green. After this you have done the core loop the whole product is about. Lesson 5 returns here to teach what the gate cannot check about what you wrote.

Lesson 4 — Put the gate in CI

Wire the gate into CI · ~30 minutes

Extra starting state for this lesson: a git repository hosted on GitHub with push and pull-request rights — Lesson 1 deliberately did not create one. Governance that depends on people remembering to run a command is not governance. Wire the shipped workflow, watch a pull request go red on a staged failure and green on the fix — with screenshots of exactly what you should see.

Lesson 5 — Write a spec worth reviewing

Spec authoring: every governance section · ~60 minutes

The gate now has teeth, so this is the moment to learn what those teeth cannot bite. Section by section: what each governance section is for, what the rule literally checks, and the difference between analysis and gate-passing filler — including the demonstration that a spec saying "we did not do the work" passes every rule. The gate catches vocabulary; you supply substance. This lesson is where that stops being a slogan.

Lesson 6 — Review a gate you did not run

Read evidence as a reviewer · ~20 minutes

Someone must be the reader the visibility controls were built for. Handed only a stranger's gate-summary.json: which rules ran, what was disabled or narrowed and by whom, where the rules were loaded from, what was never scanned — and the six documented grounds to refuse an approval.

That's it. Six lessons, about three hours (a natural split: 1–3, then 4–6), and you can take a repository you own from nothing to a merge-blocking gate, write a spec a reviewer would accept as analysis rather than vocabulary, and read a green run's own evidence to say what it actually checked — and whether anything was weakened.

When you need it

The remaining playbooks are task-shaped: go to them when their situation is in front of you, not before. In particular, the first time the gate goes red for a reason you did not stage, open Investigate a failing gate.

When this happensGo here
Adopting in a repo that already has a constitution or templatesBrownfield adoption
The gate is red and you do not know whyInvestigate a failing gate
You need a project-specific check the shipped rules do not coverAdd a custom rule
A shipped rule is too broad (or too noisy) for your repositoryOverride a shipped rule
Choosing or changing compliance frameworks after setupSelect frameworks

Reference documentation (every finding code, every rule parameter, every evidence field) lives in USAGE.md and the rule engine guide — for looking things up, not for reading through.