Give Copilot a security review contract instead of a prompt.

git clone https://github.com/omarmohelal/SecHelix.git
mkdir -p .github/skills
cp -R SecHelix/skills/sechelix .github/skills/sechelix
git add .github/skills/sechelix && git commit -m "chore: add the SecHelix review contract"

Committing it is the point. A prompt in someone's editor settings reviews one person's work. A directory in the repository reviews everyone's, survives onboarding, and shows up in the diff when someone changes the rules.

Both a prompt and a skill are text the model reads. The difference is that the skill brings a vocabulary with defined edges, and refuses to let a claim skip a state.

Applicability states

APPLICABLE, NOT_APPLICABLE, UNKNOWN, BLOCKED. Missing evidence is UNKNOWN and is never quietly rewritten as NOT_APPLICABLE.

Finding states

HYPOTHESIS, VERIFIED, LIKELY_BUT_UNPROVEN, FALSE_POSITIVE, DUPLICATE_ROOT_CAUSE, BLOCKED_BY_ENVIRONMENT.

Evidence chain

Seven links per finding: attacker control, reachability, boundary failure, safe reproduction, impact, preconditions, root cause. The schema requires all seven.

Refutation attempt

A required non-empty string. A finding cannot validate against the contract without a written attempt to disprove it.

Release decision

PASS, PASS_WITH_KNOWN_RISK, BLOCKED, INCOMPLETE. Missing evidence fails closed rather than passing quietly.

Re-reviewing a whole repository on every pull request is slow and returns the same findings each time. The narrower question is what the diff did. A deterministic classifier answers it without a model, and it ships in the repository.

git diff main...HEAD | python scripts/diff_review.py -
python scripts/diff_review.py change.patch --json-output
gh pr diff 42 | python scripts/diff_review.py - --fail-on-new-risk

Eighteen rules map a changed line to a direction. The directions are deliberately conservative: removing a control is new risk, adding a control is reduced risk, and adding a new surface is new risk.

Then hand the same diff to the model with the review framing.

Use SecHelix to security-review the current pull request/diff.
Map changed trust boundaries and dataflows, identify new or weakened controls, verify important
candidates, and state whether the PR introduces a verified blocker, known risk, or no
evidence-backed security regression.

- name: Classify the security delta
  run: git diff origin/main...HEAD | python scripts/diff_review.py - --fail-on-new-risk

- name: Gate the release on the canonical report
  run: python scripts/security_gate.py report.json --policy policies/default.json

Keep report generation and gating in separate steps. The gate reads a canonical report and returns an exit code: 0 for PASS and PASS_WITH_KNOWN_RISK, 1 for BLOCKED, and 2 for INCOMPLETE or malformed input. Treat both 1 and 2 as non-green, because a run that could not produce evidence is not a run that found nothing.

• A forked pull request cannot hold the gateWorkflows on forks run without repository secrets. Classify the diff there and run the full gated job on a trusted trigger instead.
• A green typecheck is not a green buildA recorded audit nearly accepted a fix that a stale prerender cache had reverted. The types compiled; the served application still had the defect. Assert against the built artifact.
• A blanket denial passes as a fixA regression test that only proves the hostile input is rejected also passes when the feature is broken for everyone. Assert the legitimate path still works in the same test.

• No claim is made that SecHelix finds more issues than any other approach. That comparison has not been measured.
• The value being claimed is narrower and checkable: the vocabulary is fixed, the evidence requirement is enforced by a schema, and the gate fails closed.