Code & security review

Why

A security review starts with one question: where can the outside world get in, and what does each way in touch? Without a graph the agent answers it by grepping for route decorators and reading controller after controller. BoostGraph already knows the answer.

• One call for the attack surface — boostgraph_entrypoints lists every HTTP route with its handler (file:line), where it is registered, its middleware, and the effects the handler reaches.
• Effects, not just routes — database reads/writes (with the model), responses with status codes, outbound network, auth/token checks, queues, email, payments, cache, storage and processes.
• Read less — the agent drills into only the risky endpoints with boostgraph_explore, which returns the verbatim source of the handler and everything on its call path in one call.
• 100% local — the graph is built on your machine; no code leaves it.

Set up once

Install Boost (see the Quickstart), then register the graph MCP server. boost graph install writes the boost-graph MCP server into Claude Code and Cursor and allows its read-only tools. The review skills are opt-in: open boost report -w, click the /boost-security-review or /boost-code-review card under Boosters and choose Install — it writes the skill under ~/.claude/skills/, and Remove deletes it. Nothing installs them by default.

boost graph install      # MCP server "boost-graph" for Claude Code and Cursor
boost report -w          # Boosters → click a skill → Install
# restart Claude Code, then in any repository:
/boost-security-review
/boost-code-review

You do not need to index first: each skill runs boost graph status and then boost graph init (first time) or boost graph sync (after edits) before it touches the graph. Unregister the MCP server with boost graph install --remove.

Security review: /boost-security-review

Run it in Claude Code on a repository, or just ask for a security review — the skill loads automatically. It follows five steps:

1. Index — boost graph init or boost graph sync so the graph matches the tree.
2. Map — one boostgraph_entrypoints call. For a PR, it is scoped to the changed controllers/routers with filter.
3. Triage — from the map alone: state-changing routes that reach database writes, processes, payments or outbound network; routes with no auth middleware; handlers the graph could not fully see.
4. Drill in — boostgraph_explore on each high-risk handler, its middleware and effect calls, to check authz, validation, injection, CSRF and error leaks.
5. Report — findings per endpoint (METHOD path, file:line, exploit, fix) plus the list of endpoints reviewed vs. only triaged.

Code review: /boost-code-review

For a PR, branch or diff:

1. Index — boost graph sync so the graph reflects the branch under review.
2. Scope — git diff against the base to list changed symbols.
3. Blast radius — one boostgraph_explore call with the changed symbols: who depends on them, which tests cover them, and the source of the call path.
4. Affected endpoints — boostgraph_entrypoints filtered to the changed files, to catch changed status codes, dropped middleware or new database writes on a route.
5. Affected tests — git diff --name-only <base>...HEAD | boost graph affected --stdin lists the test files that transitively depend on the change; the agent runs only those, and flags changed code no test reaches.
6. Review — correctness at every caller the blast radius names, behavior changes on affected endpoints, missing tests.

With the built-in /code-review and /security-review

Claude Code's built-in /code-review and /security-review commands have fixed prompts that do not know about BoostGraph, so on their own they fall back to grep and file reads. The skills are how the agent is told to index first and use the graph: run /boost-security-review or /boost-code-review instead, or ask in plain words ("security review this PR") and the matching skill loads. With the boost-graph MCP server connected, an agent running the built-in commands can still call boostgraph_entrypoints — mention it in the prompt ("start with boostgraph_entrypoints").

The boostgraph_entrypoints tool

Listed by default on the boost-graph MCP server, next to boostgraph_explore. Arguments (all optional):

• filter — only routes whose URL, handler or file contains this text ("/admin", "payments", "UserController")
• category — only effects of one kind: database, response, network, auth, queue, email, payments, cache, storage, process
• maxRoutes — cap the list (default 200); effects: false skips the per-handler walk
• includeTests — also routes declared in test files; projectPath — query another indexed repo

Example output

Express and Spring PetClinic, abbreviated:

## HTTP routes (5 of 278 indexed)

### examples/auth/index.js

- **GET /restricted** at examples/auth/index.js:88 · inline handler · middleware: `restrict`
  - response: `res.send` → 200 in `(inline handler)` examples/auth/index.js:89
- **POST /login** at examples/auth/index.js:104 · inline handler
  - response: `res.sendStatus` → 400 in `(inline handler)` examples/auth/index.js:105
  - response: `res.redirect` → 302 in `(inline handler)` examples/auth/index.js:119

### src/main/java/.../owner/OwnerController.java

- **POST /owners/new** — `processCreationForm` (method) at OwnerController.java:77
  - database: `owners.save` (write Owner) in `processCreationForm` OwnerController.java:84

From the terminal

The same map is available without an agent — handy in CI or for a quick look:

boost graph init                       # index (first time)
boost graph sync                       # re-index changed files
boost graph entrypoints                # every route → handler → middleware → effects
boost graph entrypoints -f /admin      # one area
boost graph entrypoints -c database    # one effect category
boost graph entrypoints --json         # for scripts and CI

# which tests does this change affect?
git diff --name-only origin/main... | boost graph affected --stdin
git diff --name-only origin/main... | boost graph affected --stdin -q | xargs npx vitest run
boost graph affected src/auth/session.ts --filter "e2e/*.spec.ts" --json

Limits

• Routes and effects come from static analysis. Routing built at runtime (string-assembled paths, reflection, plugin registries) can hide an entry point — the skills tell the agent to say so.
• Framework coverage follows BoostGraph's resolvers: Express, NestJS, Next.js, React Router, Vue/Nuxt, SvelteKit, Django, Flask, FastAPI, Rails, Laravel, Spring, ASP.NET, Gin/chi/gorilla, Axum/actix/Rocket, Vapor and more.
• The graph engine needs a build with cgo (tree-sitter parsers). If boost graph reports it is unavailable, the skills fall back to a normal review.