---
name: audit
description: Thoroughly audit any system, project, or directory for security risks, misconfigurations, exposed secrets, dependency vulnerabilities, and architectural issues. Works broadly (full system) or granularly (specific focus area). Use to sanity-check anything you're building.
model: opus
user-invocable: true
allowed-tools: Read, Bash, Grep, Glob, Agent, WebSearch, WebFetch, TaskCreate, TaskUpdate, AskUserQuestion
---

# System Audit

Perform a thorough audit of a system or project directory. This skill is designed for builders who want a fast, actionable sanity check on anything they're building, without needing a security background.

---

## Input Parsing

The user invokes this as `/audit [target] [focus]` where:

- **target** (optional) — a directory path or system name. Defaults to the current working directory.
- **focus** (optional) — a specific audit area. If omitted, run ALL areas. Valid focus keywords:
  - `secrets` — credentials, API keys, tokens, .env files, hardcoded passwords
  - `deps` — dependency vulnerabilities, outdated packages, lockfile integrity
  - `config` — insecure configurations, overly permissive settings, debug modes in prod
  - `architecture` — structural risks, single points of failure, coupling issues
  - `infra` — deployment configs, Docker, CI/CD, server configs, SSH, cloud permissions
  - `data` — database security, backup practices, data exposure risks
  - `logic` — workflow logic, silent failure points, cascading errors, missing validation between steps
  - `context` — context file conflicts, contradictory instructions, prompt/config coherence across the system
  - `guardrails` — self-modifying systems, agent autonomy boundaries, override protections, drift prevention
  - `all` — full audit (default)

Examples:
- `/audit` — audit current directory, all areas
- `/audit /path/to/project` — audit specific directory, all areas
- `/audit /path/to/project secrets` — audit specific directory, secrets only
- `/audit . deps` — audit current directory, dependencies only

---

## Phase 1: System Discovery

Before auditing anything, you must understand what you're looking at. Use the Explore agent extensively here.

### 1a. Map the target directory

Launch an Explore agent (set to "very thorough") to map the full system:

- Directory structure (all levels)
- Languages and frameworks in use
- Package managers and dependency files (package.json, requirements.txt, Gemfile, go.mod, Cargo.toml, etc.)
- Configuration files (.env, .env.*, config/, *.config.js, *.yaml, *.toml, docker-compose.*, Dockerfile, etc.)
- Deployment and CI/CD files (.github/workflows, Procfile, vercel.json, fly.toml, render.yaml, etc.)
- Infrastructure files (Terraform, Pulumi, Ansible, SSH configs, etc.)
- README, CLAUDE.md, and any documentation that explains the system
- Git history — check for sensitive files that may have been committed and removed
- `.gitignore` — verify it covers secrets and build artifacts

### 1b. Identify connected systems

Look for evidence of:
- Remote servers (SSH configs, deploy scripts, server addresses in configs)
- Cloud services (AWS, GCP, Vercel, Supabase, Firebase configs)
- External APIs (API keys, webhook URLs, third-party service configs)
- Databases (connection strings, ORM configs, migration files)
- Other local directories the system references

If remote systems are discoverable and the user has SSH access, ask the user if they want you to audit those too. If they say yes, SSH in and run the same discovery process there.

### 1c. Check for parent context

Walk up the directory tree from the target all the way to the git repo root (or filesystem root if not in a repo). At every level, read any CLAUDE.md files found. Do not stop at the first parent — traverse the full chain. These files contain venture hierarchy, project relationships, deployment context, and architectural decisions that inform the audit.

For example, if the target is `/a/b/c/d/`, check for CLAUDE.md in `d/`, `c/`, `b/`, and `a/`. Each level may add context the others don't.

---

## Phase 2: Audit Execution

Run the relevant audit areas based on the user's focus parameter. For each area, use parallel Agent calls where possible to speed things up.

### Secrets & Credentials

- Search for hardcoded API keys, tokens, passwords, and secrets in all source files
  - Common patterns: `API_KEY`, `SECRET`, `TOKEN`, `PASSWORD`, `PRIVATE_KEY`, base64-encoded strings, AWS key patterns (`AKIA...`), long hex strings
- Check `.env` files — do they contain real values? Are they gitignored?
- Check git history for accidentally committed secrets: `git log --all --diff-filter=D -- "*.env" ".env*"` and `git log -p --all -S "API_KEY"` (search for common secret patterns)
- Check if `.gitignore` properly excludes secret files
- Look for secrets in Docker files, CI configs, and deployment scripts
- Check for private keys (*.pem, *.key) in the repo
- Severity: any exposed real credential is **CRITICAL**

### Dependencies

- Identify all dependency manifests
- Check for known vulnerabilities:
  - Node.js: run `npm audit` or `yarn audit` if applicable
  - Python: check against known CVE databases via web search for any pinned versions that look old
  - Other ecosystems: check for obviously outdated major versions
- Check for lockfile presence and integrity (package-lock.json, yarn.lock, etc.)
- Look for unpinned or wildcard version ranges that could introduce breaking changes
- Check for unused dependencies (if tooling is available)
- Severity: known CVEs are **HIGH**; missing lockfiles are **MEDIUM**

### Configuration

- Check for debug modes or development settings that shouldn't be in production
  - `DEBUG=true`, `NODE_ENV=development` in prod configs, verbose logging enabled
- Check CORS settings — are they overly permissive (`*`)?
- Check authentication configs — are there default passwords, disabled auth checks?
- Check rate limiting — is it configured?
- Check HTTPS/TLS settings
- Check file permissions on sensitive configs
- Severity varies by finding

### Architecture

- Identify single points of failure
- Check for proper error handling at system boundaries
- Look for hardcoded values that should be configurable
- Check separation of concerns — is business logic mixed with infrastructure?
- Review the data flow — are there obvious bottlenecks or trust boundary violations?
- Check for proper input validation at external interfaces
- Severity: usually **MEDIUM** unless it's a data exposure risk

### Infrastructure & Deployment

- Audit Dockerfiles: running as root? Multi-stage builds? Secrets in build args?
- Audit CI/CD pipelines: secrets management, branch protection, deployment gates
- Check server configs if accessible (Nginx, Apache, etc.)
- Check cloud permissions if config files are present (overly broad IAM roles, public S3 buckets)
- Check SSH configurations (key-based auth? Password auth disabled?)
- Check firewall rules if accessible
- Severity: running as root or public cloud resources are **HIGH**

### Data

- Check database connection strings — are they encrypted? Using SSL?
- Look for raw SQL that could be vulnerable to injection
- Check backup configurations if present
- Look for PII handling — is sensitive data logged, stored in plaintext?
- Check for proper data validation and sanitization
- Severity: SQL injection or exposed PII is **CRITICAL**

### Workflow Logic & Reliability

This section is especially important for AI agent systems, automation pipelines, and multi-step workflows.

- **Silent failure points:** Steps that can fail without the system noticing or reporting. Look for missing error handling between pipeline stages, API calls without retry/fallback, and fire-and-forget patterns with no confirmation.
- **Cascading errors:** If step 2 gets bad input from step 1, does it pass garbage downstream or catch it? Trace the data flow through the full pipeline and identify where one bad output poisons everything after it.
- **Missing validation between steps:** Are there sanity checks between stages? For example, does an LLM output get validated before being fed into the next prompt or written to a database?
- **Race conditions and ordering:** In async or parallel workflows, can steps execute out of order? Are there timing assumptions that could break?
- **Idempotency:** If a step runs twice (retry, duplicate trigger), does it produce correct results or corrupt state?
- Severity: silent failures are **HIGH**; cascading errors are **HIGH**; missing inter-step validation is **MEDIUM**

### Context & Prompt Coherence

Critical for any system that uses AI agents, CLAUDE.md files, system prompts, or multi-file context.

- **Contradictory instructions:** Read ALL context files, system prompts, CLAUDE.md files, and configuration that gets pulled into agent workflows. Flag any contradictions between them. Example: one file says "always use formal tone" while another says "be casual and conversational."
- **Stale or orphaned context:** Context files that reference things that no longer exist (deleted files, renamed functions, old API endpoints, discontinued features).
- **Prompt injection surface:** Are there places where user input or external data gets interpolated into prompts without sanitization?
- **Context window overflow:** Systems that stuff too many files/contexts into a single prompt, risking truncation of critical instructions.
- **Priority ambiguity:** When multiple context sources apply, is it clear which takes precedence? Are there explicit override rules?
- Severity: contradictions are **HIGH** (they cause unpredictable behavior); stale context is **MEDIUM**; prompt injection is **CRITICAL**

### Guardrails & Self-Modification

Critical for any system where AI agents can modify their own behavior, prompts, configs, or rules.

- **Unprotected self-modification:** Can the system rewrite its own core rules, system prompts, or configuration files? If so, are there boundaries on what it can change?
- **Drift prevention:** Over time, does the system have a mechanism to detect when it has drifted from its original intent? Example: an agent that rewrites its own prompts could gradually optimize for the wrong thing.
- **Core rule immutability:** Identify the "constitution" of the system — the rules that should NEVER be overridden. Are they actually protected, or could a sufficiently creative prompt or edge case bypass them?
- **Rollback capability:** If the system modifies itself into a bad state, can it be rolled back? Is there version history or snapshotting?
- **Autonomy boundaries:** What actions can the system take without human approval? Are those boundaries explicit and enforced, or just implied by the current prompt?
- **Feedback loop runaway:** Systems that improve themselves based on their own output can enter positive feedback loops that amplify errors. Is there a human-in-the-loop checkpoint?
- Severity: unprotected self-modification of core rules is **CRITICAL**; missing rollback is **HIGH**; unclear autonomy boundaries are **HIGH**

---

## Phase 3: Report

Present findings as a clean, prioritized report. Use this exact structure:

```
## Audit Report: [System Name]

**Scope:** [what was audited — directory, focus areas]
**Date:** [today's date]
**System:** [brief description of what this system does, based on discovery]

---

### Critical Findings
[Items that need immediate action — exposed secrets, known vulnerabilities being actively exploited, etc.]

### High Priority
[Items that should be fixed soon — dependency CVEs, running as root, overly permissive cloud configs]

### Medium Priority
[Items worth addressing — missing lockfiles, no rate limiting, architectural concerns]

### Low Priority / Recommendations
[Nice-to-haves — code quality, testing gaps, documentation]

### Clean Areas
[What looks good — acknowledge what's done right so the user knows those areas are solid]

---

### Recommended Next Steps
[Numbered list of concrete actions, ordered by priority. Each step should be specific enough to act on immediately.]
```

---

## Important Notes

- **Be honest about limitations.** This is a static analysis and config review, not a penetration test. Say what it can and can't catch.
- **Don't alarm unnecessarily.** A development .env file with test credentials is not the same as a production secret leak. Context matters.
- **Be specific.** "You have a security issue" is useless. "Your Supabase service role key is hardcoded in `src/lib/supabase.js:14` and committed to git" is actionable.
- **Offer to fix.** After the report, ask if the user wants you to fix any of the findings right now.
- **Respect scope.** If the user asked for `secrets` only, don't audit architecture. Mention that other areas exist but weren't checked.