trailmark-review-gate

AI Community

Repo stars 0
Author updated Aug 25, 2026, 07:09 AM
Author repo skills

Interpretation is structured for decision-making; original keeps the upstream SKILL.md unchanged.

Decide Fit First

Core job: Runs a Trailmark structural review gate over a branch, pull request, fix commit, release diff, or git ref range to detect new en…
Best fit: Use it when the task has reusable inputs, steps, and validation criteria rather than a one-off answer.
Avoid forcing it: If the source lacks commands, platform support, or external-service evidence, keep those fields unknown instead of guessing.

Design Intent

Structure: The skill is organized around “When to Use”, “When NOT to Use”, “Rationalizations to Reject”, “Workflow”, showing how the author expects the agent to judge fit, collect context, and produce verifiable output.
Trigger evidence: Prioritize the author’s wording around when to use it, what context to collect, and what output shape to produce.
Evidence boundary: Author text states facts, repository files prove commands and paths, and Fluxly only adds fit, limits, and usage judgment.

How To Use It

Inputs: Provide target material, scope, expected result, forbidden changes, and validation method.
Invocation: Name trailmark-review-gate directly; if the source includes slash commands, start with the command and then add task context.
Validation: Start small and check whether the result follows “When to Use / When NOT to Use / Rationalizations to Reject” before expanding.

Boundaries And Review

Dependencies: It usually needs no extra API key, so start with a small validation task.
Permissions: Declared permissions include read / write; ask the agent to state file, command, and rollback boundaries before acting.
Quality bar: A useful result names the deliverable, evidence, and next action. Generic prose means the task needs tighter context.

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. 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, then hand it to the branch reviewer. Use 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.

Fluxly profile Author and license come from source; runtime, permissions, and network are Fluxly detections or estimates

Fluxly category: AI
Author-declared agents: No explicit declaration found; this is not inferred or tested compatibility
Static check: 88 / 100 · heuristic scan, not runtime safety proof
Author / version / license: @trailofbits · no license declared
Fluxly token estimate: Lean
Fluxly setup estimate: Plug-and-play
External API key: No requirement detected
Detected OS requirements: Unspecified
Runtime requirements: Unspecified
Detected file/system behavior: Read-only
Write / modify
Detected network behavior: Local-only
Install commands: None (reference only)

Profile is derived at build time from SKILL.md and install vectors. Subject to drift from author intent.

Heads up: 未限定 allowed-tools，默认拥有全部工具权限。

Output preview trailmark-review-gate.preview

The current SKILL.md does not define a fixed output example.

SKILL.md SKILL.md

# 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

…

Evidence boundary and execution chain

Author text anchors workflow facts; Fluxly only indexes current sections, terms, files, and commands.

sections -> When to Use → When NOT to Use → Rationalizations to Reject → Workflow → Step 1: Resolve Inputs → Step 2: Build Graph Evidence
terms    -> Apply deterministic security gate rules to Trailmark structural diff evidence. · - Single-snapshot analysis. · Accept two refs, a branch name, a commit range, or before/after directories. · Run graph-evolution or equivalent Trailmark before/after graph analysis. · Record Trailmark version and any feature probes. · Apply the rules in [references/gate-rules.md](references/gate-rules.md). · Write the packet using [references/output-format.md](references/output-format.md), then hand it to the branch reviewer. · - Never mutate the user's working branch while comparing refs.
files/cmd -> trailmark · trailmark-structural · differential-review · trailmark-finding-triage · UNKNOWN · git diff · git show · graph-evolution
body sha256 -> 9de62276a97c