Files
kz-tob 4b1b74b181 Give differential-review a trigger, and name every component in its README (#278)
* Give differential-review a trigger, and name every component in its README

differential-review's description listed what it does and never named a
situation, so it competed on capability wording alone. It now closes with
the triggers its own README already documents — reviewing a PR, commit,
or diff; checking whether a change re-introduces a fixed bug; asking what
else a change could break; finding modified code with no test.

The same plugin's README never mentioned adversarial-modeler, which is
what Phase 5 dispatches for HIGH RISK changes. Checking whether that was
isolated turned up more of it, and the sweep found three kinds of gap:

zeroize-audit's agent table was missing three of its eleven agents —
0-preflight, which gates the entire run, plus 5b-poc-validator and
5c-poc-verifier. All three appear in the phase diagram directly above the
table, which is why they read as present.

constant-time-analysis documents the ct-analyzer CLI end to end and never
says the plugin also ships a skill and a command. entry-point-analyzer
lists phrases that trigger its skill but never names the skill or its
command.

Three more READMEs describe their skill without naming it. That matters
most where the skill name is not the plugin name and a user cannot guess
it: chrome-mcp-troubleshooting and interpreting-culture-index.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Fix review findings and make the README sweep a gate

The two PoC rows I added to zeroize-audit said Phase 4. The diagram three
lines above them, SKILL.md, and workflows/phase-5-poc-validation.md all
say Phase 5, steps 5a and 5b. "Wave 5a" is a label that exists nowhere.
A debugger consulting the table — the artifact this branch designates as
what runs when — would have opened phase-4-poc-generation.md and found no
validation in it. Also corrected the sentence introducing that table,
which still said 10 agents across 8 phases against 11 across 9, and the
Phase 0 diagram line, which still credited the orchestrator for a gate
the new row credits to 0-preflight.

differential-review's README claimed the agent is "dispatched", and named
it bare in a column whose other rows are namespaced. Nothing dispatches
it: the only instruction is prose in SKILL.md, and a bare subagent_type
fails at runtime. Namespaced both, and corrected the five stale line
counts in the same file — reporting.md is 369 lines, not the ~120 the
token-efficiency section budgets for.

Drop the dead `name: trailofbits:<cmd>` key from five command files.
The three newest command files carry no name: at all, #275 namespaced 22
bare invocations, and this branch documents the `/<plugin>:<cmd>` form —
so the key contradicts the docs it sits next to.

Then make the sweep repeatable. Doing this by hand three times found
eight gaps and missed two more, both of the same shape: a workflow ships
under meta.name, not its filename, so a README citing the filename never
writes the name a reader types. The validator now checks that a README
names every skill, agent, command, and workflow its plugin ships, reading
meta.name for workflows. It refuses a run that inspected zero components,
and six self-test assertions hold it to known-bad fixtures.

It found git-cleanup on its first run: ships as /git-cleanup:git-cleanup-analysis,
README cites workflows/analyze-branches.js four times and that name never.
static-analysis had the same gap for codeql-build.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

* Fix both P2s: the gate was a substring test, and the dispatch was still bare

The README gate ran `name not in text`. That reads as thorough and could
not fail for a large share of what it counted: `draw` was satisfied by
"(draw cards instead)", `semgrep-rule` by the plugin's own name in the
install line, `burp-search` by a `scripts/burp-search.sh` path that is a
different thing, and `audit` by the prose "shared-state struct audit".

Match by kind instead. Commands and workflows are reachable only as
`/<plugin>:<name>`, so require that literal — it is the only string a
user can type. Agents are dispatched by identifier and never typed as
prose, so require an identifier-shaped mention. Skills are genuinely
referred to by bare name, so require only a delimited occurrence, which
is what stops "draws" counting as `draw`.

That surfaced seven real gaps, the four above plus insecure-defaults'
audit-pipeline workflow, mutation-testing's skill, and trailmark's
code-slice-worker. All seven fixed.

adversarial-modeler was still bare at SKILL.md:96. Line 77 was the
decision-tree mention; line 96 is the "Delegate to this agent"
instruction a model actually acts on, so the runtime failure the last
commit claimed to fix survived it. Namespaced, and it now says why.

Also from the review: a per-kind floor, since a single total stays
healthy while skill_files() — 63% of coverage — silently stops matching;
workflow_names anchored to the meta block, because a bare search takes
any earlier `name:` in a comment, and .mjs was invisible; and AGENTS.md
documents the new hard failure. Self-test 88 -> 96, each new rule with a
negative control.

Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
2026-08-26 08:54:12 -04:00
..

Burp Suite Project Parser

Search and extract data from Burp Suite project files (.burp) for use in Claude

Author: Will Vandevanter

Prerequisites

When to Use

Use this skill when you need to get the following from a Burp project:

  • Search response headers or bodies using regex patterns
  • Extract security audit findings and vulnerabilities
  • Dump proxy history or site map data for analysis
  • Programmatically analyze HTTP traffic captured by Burp Suite

Trigger phrases: "search the burp project", "find in burp file", "what vulnerabilities in the burp", "get audit items from burp"

What It Does

This skill provides CLI access to Burp Suite project files through the burpsuite-project-file-parser extension:

  1. Search headers/bodies - Find specific patterns in captured HTTP traffic using regex
  2. Extract audit items - Get all security findings with severity, confidence, and URLs
  3. Dump traffic data - Export proxy history and site map entries as JSON
  4. Filter output - Use sub-component filters to optimize performance on large projects

Installation

/plugin install trailofbits/skills/plugins/burpsuite-project-parser

Usage

Inside Claude Code, run /burpsuite-project-parser:burp-search — it takes the same project path and flags as the script below.

Base command:

scripts/burp-search.sh /path/to/project.burp [FLAGS]

Available Commands

Command Description Output
auditItems Extract all security findings JSON: name, severity, confidence, host, port, protocol, url
proxyHistory Dump all captured HTTP traffic Complete request/response data
siteMap Dump all site map entries Site structure
responseHeader='.*regex.*' Search response headers JSON: url, header
responseBody='.*regex.*' Search response bodies Matching content

Sub-Component Filters

For large projects, filter to specific data to improve performance:

proxyHistory.request.headers    # Only request headers
proxyHistory.request.body       # Only request body
proxyHistory.response.headers   # Only response headers
proxyHistory.response.body      # Only response body

Same patterns work with siteMap.*

Examples

Search for CORS headers:

scripts/burp-search.sh project.burp "responseHeader='.*Access-Control.*'"

Get all high-severity findings:

scripts/burp-search.sh project.burp auditItems | jq 'select(.severity == "High")'

Find server signatures:

scripts/burp-search.sh project.burp "responseHeader='.*(nginx|Apache|Servlet).*'"

Extract request URLs from proxy history:

scripts/burp-search.sh project.burp proxyHistory.request.headers | jq -r '.request.url'

Search for HTML forms:

scripts/burp-search.sh project.burp "responseBody='.*<form.*action.*'"

Output Format

All output is JSON, one object per line. Pipe to jq for formatting or use grep for filtering:

scripts/burp-search.sh project.burp auditItems | jq .
scripts/burp-search.sh project.burp auditItems | grep -i "sql injection"