Runs a Trailmark structural review gate over a branch, pull request, fix commit, release diff, or git ref range to detect new entrypoints, new tainted paths, removed validation or authorization calls, privilege-boundary drift, blast-radius growth, complexity growth, and newly reachable sensitive sinks. Use when reviewing a PR, branch, remediation commit, or release diff where graph-level security regressions should be checked before merge.
Scanned 9/8/2026
Install to Claude Code
npx -y skills add bg-szy/TOP-SKILLS --skill trailmark-review-gate --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Trailmark Review Gate?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/bg-szy-trailmark-review-gate)More formats (shields.io, HTML) on the badges page.
---
name: trailmark-review-gate
description: "Runs a Trailmark structural review gate over a branch, pull request, fix commit, release diff, or git ref range to detect new entrypoints, new tainted paths, removed validation or authorization calls, privilege-boundary drift, blast-radius growth, complexity growth, and newly reachable sensitive sinks. Use when reviewing a PR, branch, remediation commit, or release diff where graph-level security regressions should be checked before merge."
allowed-tools:
- Bash
- Read
- Grep
- Glob
- Write
---
# Trailmark Review Gate
Apply deterministic security gate rules to Trailmark structural diff evidence.
This skill does not replace line-level review. It produces a compact structural
packet reviewers can cite while they inspect the code.
## When to Use
- Reviewing a branch, pull request, release diff, or fix commit
- Checking whether a change expands attack surface
- Looking for removed validation or authorization on reachable paths
- Comparing before/after taint, privilege-boundary, blast-radius, or
complexity signals
- Producing graph evidence for a differential review
## When NOT to Use
- Single-snapshot analysis. Use `trailmark` or `trailmark-structural`.
- Text-diff review only. Use `differential-review`.
- Full vulnerability discovery. Use an audit or bug-finding workflow.
- One static finding. Use `trailmark-finding-triage`.
- Tooling is unavailable and the user wants manual review only.
## Rationalizations to Reject
| Rationalization | Why It Is Wrong | Required Action |
|---|---|---|
| "The line diff is small, so no graph gate is needed" | Small changes can create new call paths | Compare before/after graphs |
| "Graph gate passed, so the PR is secure" | The gate only checks structural regressions | Still perform line-level review |
| "Trailmark failed, so pass the gate" | Tool failure is unknown risk, not success | Emit `UNKNOWN` |
| "Tests pass, so removed validation is fine" | Tests may miss affected entrypoint paths | Review the removed path manually |
| "Only new code matters" | Removed auth, validation, and callers can be higher risk than additions | Review removals and path changes |
## Workflow
```
Review Gate Progress:
- [ ] Step 1: Resolve before/after inputs
- [ ] Step 2: Build graph-evolution evidence
- [ ] Step 3: Normalize structural changes
- [ ] Step 4: Apply gate rules
- [ ] Step 5: Emit review packet and actions
```
### Step 1: Resolve Inputs
Accept two refs, a branch name, a commit range, or before/after directories.
Do not check out branches unnecessarily. Prefer `git diff`, `git show`, and
git worktrees, following the `graph-evolution` snapshot workflow.
### Step 2: Build Graph Evidence
Run `graph-evolution` or equivalent Trailmark before/after graph analysis.
Both snapshots must run `engine.preanalysis()` so taint, privilege-boundary,
blast-radius, complexity, and entrypoint signals are available.
Record Trailmark version and any feature probes. If graph construction fails,
emit `UNKNOWN`.
### Step 3: Normalize Changes
Normalize evidence into:
- added, removed, and modified nodes
- added and removed edges
- entrypoint set changes
- taint membership changes
- privilege-boundary membership changes
- blast-radius changes
- complexity changes
- newly reachable sensitive sinks
- unresolved, proxy, or dynamic edge changes
### Step 4: Apply Gate Rules
Apply the rules in [references/gate-rules.md](references/gate-rules.md).
Gate verdicts are:
| Verdict | Meaning |
|---|---|
| `FAIL` | A high-risk structural regression needs review before acceptance |
| `WARN` | A meaningful graph change needs reviewer attention |
| `PASS` | No configured structural gate fired |
| `UNKNOWN` | Trailmark failed or evidence is too incomplete |
### Step 5: Emit Packet
Write the packet using
[references/output-format.md](references/output-format.md), then hand it to
the branch reviewer. Use
[references/review-integration.md](references/review-integration.md) when
combining this packet with `differential-review` or another PR review process.
## Requirements
- Never mutate the user's working branch while comparing refs.
- Never report `PASS` when Trailmark failed.
- Separate graph evidence from manual security judgment.
- Include exact changed nodes or paths for every `FAIL` and `WARN`.
- Include limitations when parser, proxy, unresolved-call, or dynamic-dispatch
uncertainty affects the verdict.
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!