c-review
Performs comprehensive C/C++ security review for memory corruption, integer overflows, race conditions, and platform-specific vulnerabilities. Use when auditing native C/C++ applications, reviewing daemons or services for memory safety, or hunting integer overflow / use-after-free / race conditions in userspace code.
npx skills add trailofbits/skills --skill c-review --agent claude-code
Same command for any agent — swap --agent for codex, cursor, copilot.
Weekly change comes from our own snapshots, not the repository page — it measures attention, not adoption.
What it does
The skill defines a comprehensive C/C++ security review workflow. It runs in the main conversation and coordinates subagents (workers and judges) to perform memory-safety, integer-overflow, race-condition checks in native C/C/C++ code, especially daemons or services. Findings are exchanged via markdown-with-YAML files in a shared output directory. It specifies an orchestration architecture and a phased pipeline (prerequisites, output directory setup, codebase context, build/run plan, and subsequent phases) and delegates plan-building and worker prompt generation to an external script at ${C_REVIEW_PLUGIN_ROOT}/scripts/build_run_plan.py.
How it works
- Invoke via /c-review:c-review. The orchestrator owns the Task* ledger; workers and judges are subagents (c-review:c-review-worker, c-review:c-review-dedup-judge, c-review:c-review-fp-judge). Findings are exchanged in a shared output directory as markdown-with-YAML files.
- When to use: for native C/C++ security review focusing on memory safety, integer overflows, races, and platform-specific issues in user-space code.
- It defines subagents and their tool sets. It notes how search tooling should be performed under Bash (rg or find-based approaches) and explains constraints around Glob, Grop, and Bash tools during searches.
- The workflow comprises phases: parameter collection, prerequisites, output directory creation, codebase context, buildRunPlan, and subsequent build/run execution, with deterministic behavior and chunking rules for worker processes.
- Phase 4 delegates plan generation to a Python script and describes how outputs (plan.json, worker prompts) are produced and consumed.
When to use it
Use for native C/C++ security review of memory safety, integer overflow, races, type confusion, and related issues in Linux/macOS daemons or Windows userspace services.
# C/C++ Security Review Runs in the main conversation (invoke via `/c-review:c-review`). Orchestrator owns the `Task*` ledger as bookkeeping for retries; workers and judges have no Task tools. Workers and judges are named plugin subagents (`c-review:c-review-worker`, `c-review:c-review-dedup-judge`, `c-review:c-review-fp-judge`); tool sets are declared in `plugins/c-review/agents/*.md`. Findings are exchanged via markdown-with-YAML files in a shared output directory. ## When to Use Native C/C++ application security review: memory safety, integer overflow, races, type confusion, Linux/macOS daemons, Windows userspace services. ## When NOT to Use - Kernel drivers/modules (Linux, Windows, macOS). - Managed languages (Java, C#, Python, Go, Rust). - Embedded/bare-metal code without libc. ## Subagents | Subagent type | Purpose | Tool set | |---|---|---| | `c-review:c-review-worker` | Run assigned cluster, write findings | Read, Write, Edit, Bash | | `c-review:c-review-dedup-judge` | Merge duplicates (runs **first**) | Read, Write, Edit, Glob | | `c-review:c-review-fp-judge` | FP + severity + final reports (runs **second**) | Read, Write, Edit, Bash | Tools come from each agent's frontmat
- When to Use
- When NOT to Use
- Subagents
- Architecture
- Rationalizations to Reject
- Orchestration Workflow
- Phase 0: Parameter Collection
- Phase 1: Prerequisites
- Phase 2: Output Directory
- Phase 3: Codebase Context
- Phase 4: Build Run Plan (deterministic)
- Phase 5: Create Bookkeeping Tasks (orchestrator-internal)
- Phase 6: Spawn workers (optional cache-primer first, then M in parallel)
- Phase 7: Wait for Workers and Classify Outcomes
is_cpp
find "${finding_scope_root:-.}" -type f \( -name '*.cpp' -o -name '*.cxx' -o -name '*.cc' -o -name '*.hpp' -o -name '*.hh' \) -print -quit
is_posix
grep -rlE '#include[[:space:]]*<(pthread|signal|sys/(socket|stat|types|wait)|unistd|errno)\.h>' \
is_windows
grep -rlE '#include[[:space:]]*<(windows|winbase|winnt|winuser|winsock|ntdef|ntstatus)\.h>' \
printf '%s\n' "${context_roots:-.}" | tr ',' '\n' | while IFS= read -r root; do
done | head -1
mkdir -p "${output_dir}/findings" "${output_dir}/coverage"
python3 "${C_REVIEW_PLUGIN_ROOT}/scripts/build_run_plan.py" \What does the c-review skill do?
Performs comprehensive C/C++ security review for memory corruption, integer overflows, race conditions, and platform-specific vulnerabilities. Use when auditing native C/C++ applications, reviewing daemons or services for memory safety, or hunting integer overflow / use-after-free / race conditions in userspace code.
How do I install it?
Run `npx skills add trailofbits/skills --skill c-review --agent claude-code` — it drops the skill into your project so the agent can pick it up. Swap the --agent value for codex, cursor or copilot if you use one of those.
Where does this skill come from?
From trailofbits/skills, a repository with 6,426 stars. We read it straight from the repository tree rather than a submitted listing, so what you see here is what is actually published.
Is a popular skill a good skill?
Not necessarily. Stars measure attention, not adoption — a repository can trend for a week and be abandoned. That is why we show the weekly change from our own snapshots next to the total, instead of a single flattering number.