Install any skill in seconds. Free to start, no credit card required.
Get Started Free →deonmenezes/secrets-scan
Run trufflehog via the mantis_trufflehog MCP server and handle secret findings without ever exposing the raw secret
Passed 5 of 13 test cases with the skill, and 7 of 13 without it.
1 fixed8 passed either way10 still failing3 broke
Tokens, turns and time describe resource use, not a dollar price.
A test case the skill fixed. Same model, same prompt, with and without the skill.
The scanner found a pattern match in `./tests/fixtures/mock_keys.json` with verified set to false. How should this finding be categorized in the security report?
| Checked | Without skill | With skill |
|---|---|---|
| Labels unverified findings as candidate secrets | Missed | Passed |
| Notes that unverified findings may represent test fixtures or rotated keys | Passed | Passed |
The instructions your model reads when the skill loads.
Use trufflehog_scan({ path, only_verified }) (mantis_trufflehog MCP server) for the Detect stage's secrets coverage.
redacted_secret is a masked preview, never the full value). Never try to reconstruct, print, or echo the full secret elsewhere -- e.g. don't re-read the source line containing it and paste it into a report just because the tool redacted its own output.verified: true means trufflehog live-checked the credential against its provider and it's currently active -- treat this as a near-confirmed finding with severity driven by what the credential can access. verified: false is a candidate (pattern-matched but not live-checked, could be a dead/rotated key or a false-positive-looking test fixture).only_verified: true when you specifically want to cut noise from test fixtures and example keys; leave it off for full recall during an initial sweep.test cases passed, vs 7 / 13 without
More skills from the same source and nearby in the registry, with their headline benchmark lift.