c-review

An orchestrated security review workflow for native C and C++ code, targeting memory corruption, integer overflows, race conditions, type confusion, and platform-specific vulnerabilities in userspace daemons, services, and applications on Linux, macOS, and Windows. It runs in the main conversation as an orchestrator that fans work out to named plugin subagents: c-review-worker agents run assigned clusters and write findings, a c-review-dedup-judge merges duplicate findings first, and a c-review-fp-judge then filters false positives, assigns severity, and produces the final reports. Findings are exchanged as markdown-with-YAML files in a shared output directory, and the orchestrator keeps a Task ledger for retry bookkeeping. It is explicitly scoped: appropriate for native C/C++ memory-safety auditing, but not for kernel drivers or modules, managed languages such as Java, C#, Python, Go, or Rust, or embedded/bare-metal code without libc. The workflow resolves a plugin root (across native Claude Code, Codex, or a fallback filesystem search) so later phases can call its bundled Python scripts, and it separates two scopes — a finding_scope_root, the audit subtree where findings may be filed, and read-only context_roots that agents may inspect to verify reachability, callers, build flags, and mitigations. Phase 0 collects parameters, inferring them from free-text arguments where possible: a threat model (REMOTE, LOCAL_UNPRIVILEGED, or BOTH), a worker model (haiku, sonnet, or opus), a severity filter (all, medium, or high), and an optional scope subpath. Later phases build a run plan, spawn a primer plus parallel workers, classify outcomes, run the two judges, and emit a stable artifact set including REPORT.md and REPORT.sarif. The skill documents concrete operational pitfalls to avoid, such as not spawning workers in the background (which defeats the primer cache), always running both judges even on zero findings, and never hiding a partial run behind a clean report.