WTF

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.

3. Check secrets and environment variables

   • Search for tokens, private keys, API keys, JWT secrets, database URLs, webhook secrets, cloud credentials, and hardcoded production URLs.
   • Verify required env vars are documented in .env.example, deployment docs, or typed config. Flag required envs that are used in code but undocumented.
   • Check for accidental logging of secrets, auth headers, cookies, session payloads, or provider responses.

4. Check database readiness

   • Identify whether the app uses Prisma, Drizzle, TypeORM, Sequelize, Rails migrations, Django migrations, Alembic, Knex, raw SQL, or another migration system.
   • Confirm schema changes have matching migrations and that migrations are committed.
   • Flag schema drift, missing deploy migration commands, destructive migrations without a backfill/rollback plan, seed data required in production, and raw SQL that is not parameterized.
   • If a database-backed app has no ORM or migration tool, call that out as a launch risk unless the repository has a clear alternative migration process.

5. Check app correctness and security basics

   • Run or inspect available lint, typecheck, test, and build scripts when practical.
   • Review auth boundaries, protected routes, admin-only actions, server/client separation, CORS, CSRF where relevant, rate limits, file upload validation, SSRF surfaces, open redirects, and unsafe eval/shell execution.
   • Check error handling and observability: production errors should not leak stack traces, secrets, or internal IDs unnecessarily.