trailmark-finding-triage — Claude Code skill: triage one finding

What trailmark-finding-triage does

The skill takes one candidate issue — a file and line, a function name, a SARIF result, a weAudit annotation or a report excerpt — and normalises it into a title, path, suspected source or sink, and claimed impact. With no concrete code anchor it stops and asks for one.

Then it builds a Trailmark graph, or reuses a fresh one from .trailmark/, binds the finding to a node and runs a query recipe: entrypoint paths with their trust levels, membership in the tainted, privilege_boundary and high_blast_radius subgraphs, direct callers and callees, downstream sinks. For file and line anchors there is a bundled script, scripts/evidence_packet.py, that builds the graph once and handles several findings in one pass, writing the packet as JSON. It runs through uv run --no-project, so uv has to be on the machine.

Reachability in the graph is not proof of exploitability. An empty path list can also mean the analysis is limited — dynamic dispatch, proxies, an incomplete entrypoint model. An auth check sitting on the path is a review target, not a clean bill of health. The output is one verdict: Promote, Needs manual review or Deprioritize.