| name | ak:vibe-audit |
| description | Audit AI-generated apps for security, performance, and maintainability issues. Use when user says /vibe-audit or "I generated this with AI and want to know how bad it is". |
| disable-model-invocation | true |
| argument-hint | [@folder or leave empty for current project] |
| context | fork |
| agent | Explore |
Skill: /vibe-audit
Audit of apps built with vibe coding. Detects the typical problems AI generated without anyone reviewing them: security, performance, maintainability, and accumulated technical debt.
Target
$ARGUMENTS
If Target is empty, audit the current project root. If a folder path is provided, scope the audit to that folder only.
When to use it
When the user writes /vibe-audit or /vibe-audit @folder.
Also useful when someone says "I generated this with AI and want to know how bad it is".
What this skill does first
- Scans the complete project structure (folders, main files) starting from Target
- Reads the most critical files: entry point, routes/endpoints, main components, config
- Checks each of the 20 risk patterns documented in patterns.md
- Generates a report with severity, concrete evidence, and suggested fix
See patterns.md for the complete list of patterns — what to look for, the risk, and the fix for each one. Load it before starting the audit.
Report format
# Vibe Audit — [project name]
Audited: [date]
## Summary
- 🔴 Critical: N (block production or are security risks)
- 🟡 Important: N (affect stability or maintainability)
- 🔵 Improvements: N (technical debt, quality)
---
## 🔴 Critical
### [Problem name]
**Where:** `path/file.ts` line X
**Evidence:**
[problematic code]
**Risk:** [what can happen if not fixed]
**Suggested fix:**
[corrected code or concrete steps]
---
## 🟡 Important
[same format]
---
## 🔵 Improvements
[same format]
---
## What's good
[1-3 things vibe coding did well — balanced feedback is more actionable]
## Suggested action plan
1. [This first — the most urgent critical]
2. [Then this]
3. [...]
Rules
- Be specific: cite the file and line, don't say "there's a security problem" without showing where.
- One problem at a time if the user wants to fix them: don't generate 50 fixes at once. Offer to fix them in priority order.
- Don't rewrite the app: the goal is to identify and fix existing problems, not redo everything with "best practices".
- If the project is large: audit by module (auth, API, frontend) instead of everything at once.
