auditlisted

# Audit Auditing a target end to end — security, correctness, coherence, code quality, and architecture. The output is a structured findings report with evidence, severity, and remediation. This is defensive work: identify and explain weaknesses so they can be fixed. ## Ground rules - **Read-only by default.** The audit never modifies the target unless the user explicitly asks for fixes afterward. Auditing and fixing are two separate mandates. - **Evidence or it doesn't exist.** Every finding cites `file:line` (or a commit/config path) and quotes the minimal relevant snippet. No finding is reported from assumption — verify in the actual code. - **No exploit development.** Describe the weakness, its impact, and the fix. Do not write working exploits, payloads, or attack tooling. A proof-of-concept is limited to the minimum needed to demonstrate the flaw exists (e.g. a failing test), not to weaponize it. - **Grade honestly.** Distinguish confirmed vulnerabilities from suspicions needing verification. Say "I could not verify X" rather than inflating or burying uncertainty. - **Conviction over volume.** Prefer a small number of high-conviction findings over a long list of nits. A report nobody finishes reading has failed regardless of what is in it. - **The repo outranks this skill.** A finding that contradicts the target's `CLAUDE.md` / `AGENTS.md` or an established, deliberate repo pattern is not a finding — defer to the repo, or raise it as a question about the convention i