agentsclimarketplace

Adversarial audit

Skill kunalsuri/ai-fication-kit/templates/claude/skills/adversarial-audit

AI-Fication Kit: A Simple & Elegant Way for Making any Codebase AI-native through Scaffolded, Human-verified Context and Development Loop.

Install
npx -y skills add kunalsuri/ai-fication-kit --skill adversarial-audit

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Deep, judgement-based adversarial code audit — hunts for stale cross-references, unescaped interpolation, platform gaps, generated-file ownership conflicts, and cross-module consistency rot that no mechanical check can catch. Read-only; writes a dated findings report.

SKILL.md

4.8 KB, as published. Nobody here has run it

<!-- Copyright (c) 2026 Kunal Suri (CEA LIST). All rights reserved. -->

Run a deep, adversarial audit of the current codebase. This is not the mechanical verify/drift check — those confirm paths exist. This hunts for defects those checks categorically cannot catch: places where the code's actual behavior no longer matches what the code, comments, or docs say it does, or where a change elsewhere in the repo silently broke an assumption made here.

Read-only. Do not edit any file other than the report this command writes. Full-repo scope every run — do not sample or skip areas because they seem stable; staleness hides exactly where nobody looked recently.

What to hunt for

  1. Stale cross-references — comments, docstrings, or user-facing strings describing behavior a later change invalidated. Search for "never", "always", "not yet available", "no writes unless X", "once available", TODO, and version/feature gates — then verify the referenced behavior against the current code, not what was true when the comment was written.
  2. Unquoted/unescaped interpolation — any generated shell command, CLI suggestion, file path, or subprocess argument built by string concatenation or a template literal without quoting/escaping. Check every subprocess spawn/exec call and every "here's the command to run" string for inputs that could contain spaces or shell metacharacters.
  3. Platform-specific gaps — subprocess calls or path handling that assume POSIX (missing a shell flag for .cmd-shimmed binaries on Windows, hardcoded path separators, case-sensitivity assumptions). Flag anything that has never actually been exercised cross-platform.
  4. Ownership conflicts on generated files — any file written by more than one code path (scaffolded once, then continuously regenerated by a live process). Check whether "protect user edits" / backup / diffing logic correctly distinguishes "changed because it's supposed to" from "changed because a human edited it."
  5. Mechanical vs. semantic validation gaps — places where an automated check only confirms a path or reference exists, not that the prose describing it is still accurate. List every place documentation makes a factual claim about code behavior and check it against the current implementation.
  6. Cross-module consistency after incremental changes — for every function or module that references another component's state, existence, or capabilities, confirm that reference is re-validated, not assumed from when it was first written.

Method

  • Locate code via ai/guide/MODULE_MAP.md first; don't crawl the whole tree blind.
  • For any suspicious claim, reproduce it — run the command, exercise the code path, or trace the call — rather than reasoning from the source alone. Findings that were actually reproduced should say so explicitly.
  • Prefer depth over coverage: a handful of concrete, reproducible defects beats a long list of speculative ones.
  • Before opening a finding, check ai/analysis/audit-reports/DEFECT_TRACEABILITY.md for a prior audit row at the same location — don't re-report something already FIXED or tracked OPEN.

Output

Append a new dated audit section to ai/analysis/audit-reports/DEFECT_TRACEABILITY.md (create it, following its existing row format, if this is the first audit) with one row per finding — ID, severity, status (OPEN until fixed), location, defect, root cause, trace — and write the full evidence/repro for each finding to ai/analysis/audit-reports/ADVERSARIAL_AUDIT_<YYYY-MM-DD>.md, tagged [inferred] until a human reviews them. One line per finding in the summary:

path:line — issue — concrete failure scenario — suggested fix

Order most-severe first. No architecture summary, no restating what the code does — only defects and risks with evidence.

Then report the finding count and the top 3 by severity directly to the user.

What this does NOT do

  • Does not fix anything — that is a separate, explicit follow-up task the user asks for after reviewing the report (typically via /fix-bug).
  • Does not replace verify/drift (mechanical path checks) or review-agent-config (CLAUDE.md/AGENTS.md structure) — this is deliberately the one check in the kit that requires judgement instead of a deterministic script.
  • Not a CI gate: it is non-deterministic and costly. Run it periodically (before a release, after a large refactor), not on every push.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.