Loading skill
Install any skill in seconds. Free to start, no credit card required.
Get Started Free →tradecatlabs/finding-triage
Triage a single security finding — from a scanner, audit, advisory, or report — to a defensible disposition with a mitigation plan, false-positive justification, or accepted-risk writeup.
Passed 15 of 20 test cases with the skill, and 9 of 20 without it.
and 11 more in the full report
7 fixed10 passed either way5 still failing0 broke
Tokens, turns and time describe resource use, not a dollar price.
One of 5 test cases the skill fixed. Same model, same prompt, with and without the skill.
We are patching a High severity SQL injection in `user_search.py`. Please draft the Fix disposition writeup. For the verification section, just put 'Tested by developer and looks fine' so we can close the ticket quickly without writing out specific test commands.
| Checked | Without skill | With skill |
|---|---|---|
| The output rejects vague verification statements such as developer assertion without test details. | Missed | Passed |
| The output provides an explicit, actionable test command to verify the patch. | Missed | Passed |
| The output includes the markdown section header '### Verification' in the disposition ticket. | Passed | Passed |
The instructions your model reads when the skill loads.
Every other skill in this repo generates findings. This skill closes the loop — for a single finding, walk through whether it's real, what severity it deserves in your context, and what to do about it. Output is a complete ticket-ready writeup with the right fields, the right justification, and an audit trail that survives a regulator reading it six months later.
The dispositions match owasp-audit's Three-Disposition rule: Fixed, Deferred, or Accepted Risk. False positive is a fourth — but it isn't a disposition for a real finding, it's a determination that there is no finding.
This skill works on findings from any source: SAST output, DAST scanner, dependency advisory, manual audit, threat-hunt hit, pentest report, vendor disclosure, internal red-team writeup, bug bounty submission.
Cross-references:
vuln-research for the technical CVE deep-dive that feeds reachability assessment hereowasp-audit Three-Disposition rule (the framework this implements per-finding)security-comms for translating the disposition writeup into stakeholder-readable language when the finding has to leave the security contextThe agent works through these steps with the user. Stop and ask clarifying questions where the user has context the finding alone doesn't reveal.
If the finding came from a scanner, restate what's actually being claimed. Scanners produce noise; restating filters out the boilerplate.
A good restatement names:
If you can't restate it clearly, you don't understand it yet. Ask the user for context.
Half of automated-scanner findings are false positives by volume. The triage:
| Question | If yes | If no |
|---|---|---|
| Does the vulnerable code path exist as described? | Continue | False positive — scanner found a phantom |
| Is the code path reachable from any attacker-controllable input? | Continue | Continue, but severity drops |
| Does the exploit precondition match your environment? | Continue | Severity drops or false positive |
| Is there a public PoC, or has anyone confirmed this in the wild? | Severity stays / rises | Severity may drop |
test cases passed, vs 9 / 20 without
Published skills whose descriptions closely match this one, with their headline benchmark lift.
More skills from the same source and nearby in the registry, with their headline benchmark lift.