/wtf

name: wtf
description: "Pre-launch and pre-commit audit for vibe coding projects. Use when asked to check whether a project is ready to ship, deploy, merge, or commit, especially for common AI-built app mistakes: broken project structure, committed secrets or cache files, environment variable hygiene, database migrations, ORM/schema drift, unsafe raw SQL, unused legacy code, dead routes/components, weak auth, missing tests, build failures, and deployment footguns."

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.

6. **Check dead and legacy code**

• Search for unused routes, duplicate pages/components, abandoned API handlers, old feature flags, large commented blocks, stale TODO/FIXME/HACK notes, generated placeholders, console debugging, unused dependencies, and test/demo data paths.
• Prefer repository-aware tools when available: TypeScript compiler, ESLint, depcheck, framework route manifests, import graph tools, or existing CI checks.
• Treat dead code as lower severity unless it affects security, deploy size, routing, migrations, or user-visible behavior.

7. **Check deployment shape**

• Inspect Dockerfiles, wrangler/vercel/netlify/cloudflare config, GitHub Actions, release scripts, cron configuration, and required runtime versions.
• Flag missing production build commands, wrong package manager commands, missing migration steps, secrets expected at build time vs runtime, cache directories mounted incorrectly, and local-only assumptions.

Useful Commands

Adapt commands to the repository; do not run broad destructive commands.

git status --short
git ls-files
rg -n --hidden --glob '!node_modules' --glob '!.git' 'AKIA|BEGIN (RSA |OPENSSH |EC )?PRIVATE KEY|DATABASE_URL|JWT_SECRET|SECRET_KEY|API_KEY|ACCESS_TOKEN|REFRESH_TOKEN|WEBHOOK_SECRET|STRIPE_SECRET|OPENAI_API_KEY|ANTHROPIC_API_KEY|PASSWORD=' .
rg -n --hidden --glob '!node_modules' --glob '!.git' 'TODO|FIXME|HACK|console\\.log|debugger|ts-ignore|eslint-disable' .

For JavaScript/TypeScript projects, inspect `package.json` scripts first, then run only relevant existing scripts such as `npm run lint`, `npm run typecheck`, `npm test`, or `npm run build`.

Severity

• **P0 Blocker**: likely secret exposure, data loss, auth bypass, production deploy failure, broken migration, or user-data corruption.
• **P1 High**: strong launch risk such as missing env documentation, unsafe database access, unprotected sensitive route, failing build/test, or tracked cache/build artifacts.
• **P2 Medium**: m