Security Audit

Review code and config for common security issues so risks are identified, evidenced, and handed over with the fix each one needs.

Read-only on the codebase: it reports findings and the remediation each calls for, and never applies an edit. The active phase (scanners, npm audit, registry lookups) is gated separately in step 2 and reads — it does not write either. A security fix belongs to whoever owns the code path, reviewed against the finding that motivated it; an audit that silently patches what it found leaves nobody able to check whether the patch closed the hole or moved it.

When to Activate

• User asks for "security review", "security audit", or "check for vulnerabilities"
• Before a release or after adding auth, payments, or sensitive data handling
• Reviewing new or changed endpoints, file handling, or configuration
• After adding a new dependency or external integration

Work Process

Split the work into a passive phase (reading source, config, and dependency manifests — no gate) and an active phase (running scanners, npm audit/pip audit, dependency resolution that reaches a registry, or any dynamic/network probe — behind the approval gate in step 2). Default to passive.