Code Security Review

Use this product-side skill for repository and diff analysis. The goal is to turn source files into durable candidate signals, then investigate only the most useful files with clear evidence and revalidation. This is a passive workflow; any build, test, shell, network, browser, or mutation action requires target authorization plus a matching durable approval per docs/durable-approvals.md — chat consent alone is insufficient.

For services accepting document, image, audio/video or archive uploads, apply the upload processing audit baseline. Trace intake through delayed or optional processing and actual native dependencies; include its chain inventory, control assessment and unresolved edges in the review output. This applies even when the upload handler only stores bytes.

Ground Rules

• Treat a repository, local checkout, source archive, or diff as authorized only for passive reading unless a durable approval grants a broader action.
• Do not run install, build, test, scripts, hooks, or package-manager commands without a durable approval.
• Never load secret or config files (.env, key material, credentials) into prompts, model context, or evidence while reading the target; record their existence by path only and keep their values out of prompts, commands, telemetry, and evidence.
• Division of labor: deterministic repo/diff candidate scans live here; spec/protocol invariant tracing belongs to spec-implementation-review.
• Prefer deterministic candidate discovery before model-heavy investigation.
• Keep project context short. Include target shape, key auth primitives, entry points, false-positive patterns, and priority paths; do not dump the full repo.
• Keep scan state append-only: rescans add history, investigations add analysis entries, revalidation annotates findings.
• Separate candidate signals from findings. A route handler, sink, or tool definition is a reason to review, not a vulnerability by itself.
• Revalidate candidate findings independently before marking them validated, remediated, or false positive.

Workflow

1. Scope. Identify repo/path/diff, target id, commit or artifact version, allowed actions, and whether this is a full pass or changed-file review.
2. Compact context. Summarize architecture, auth/session controls, data stores, agent/tool boundaries, priority paths, and known false positives in a short project context.
3. Candidate scan. Prefer passive matchers for entry points, auth boundaries, raw SQL, SSRF-like fetches, file writes, process execution, dangerous HTML, secret handling, and agent tool definitions.
4. Prioritize. Investigate precise candidates before normal and noisy candidates. In diff mode, still inspect changed files even when no matcher fires.
5. Investigate. For each file or small batch, produce evidence-backed draft findings, no-finding coverage notes, and missing-evidence questions.
6. Revalidate. Try to disprove each draft finding by rereading the code, checking guards/reachability, and looking for fixes. Mark true-positive, false-positive, fixed, uncertain, or duplicate.
7. Persist evidence. Save scan summaries, candidate manifests, analysis notes, and validated finding artifacts through the Evidence Interface (src/server/evidence/artifact-service.ts) and the normal finding path; cite returned artifact IDs.

Output

Return:

• Scope: repository/path/diff, target id, commit or artifact version, and passive/approved actions.
• Scan Summary: files considered, candidates by matcher/category/noise tier, clean changed files, and priority paths.
• Candidate Queue: ranked files with candidate reasons and exact paths/lines.
• Findings: draft or validated findings with evidence, confidence, severity, and revalidation state.
• No-Finding Coverage: files or entry points reviewed with no issue found.
• Next Steps: approval needs, follow-up matchers, validation plans, patch candidates, or report-ready artifacts.