Adversarial Audit

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.

1. 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.

1. 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.

1. 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."

1. 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.

1. 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_.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.

Source & license

This open-source skill is cataloged on AgentStack and links to its original source — we do not rehost the code.

• Author: kunalsuri
• Source: kunalsuri/ai-fication-kit
• License: Apache-2.0

Install and usage instructions live in the source repository linked above.