WTF

Use this skill as a hard-nosed pre-launch or pre-commit audit for fast-moving "vibe coded" projects. The goal is to find concrete blockers before code is shipped, not to produce a generic best-practices essay.

Operating Mode

• Inspect the actual repository before judging it. Start with git status --short, project docs, file tree, package manifests, framework config, CI config, and deployment config.
• Keep the audit scoped to the user's target: current branch, staged changes, a PR diff, or the whole project. If unclear, default to the current worktree plus files likely to affect deploy/runtime.
• Prefer evidence over guesses. Tie every finding to a file, command output, or missing expected artifact.
• Do not print secret values. If a secret is committed or exposed, name the file and variable/key shape, but redact the value.
• If the user asks to fix issues, implement the fixes after the audit and verify them. Otherwise, remain in review/audit mode.

Audit Workflow

1. Map the project

   • Identify app type, framework, package manager, runtime, deployment target, database, ORM, auth provider, and build/test commands.
   • Check whether the root is clean or dirty. Preserve unrelated user changes.
   • Find likely entrypoints: app routes, API routes, workers, server actions, CLI commands, cron jobs, migrations, schemas, and config files.

2. Check repository hygiene

   • Look for committed .env* files other than safe examples, local database files, logs, cache directories, build outputs, generated artifacts, coverage, temporary uploads, screenshots, and tool caches.
   • Verify .gitignore covers framework/runtime artifacts such as .next, dist, build, .turbo, .vercel, .wrangler, .parcel-cache, coverage, node_modules, local SQLite files, logs, and upload/cache folders.
   • Use git ls-files to distinguish ignored local junk from files already tracked by Git.