---

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: maintainability or reliability issue likely to slow future work, such as stale duplicate code, missing focused tests, weak error handling, or unused dependencies.
• P3 Low: cleanup or polish that is useful but not launch-blocking.

Host-Specific Review Output

Detect host-specific review capabilities from active system/developer/app instructions, available tools, or local agent docs. Do not infer support from the model name alone, and do not invent pseudo-directives for a host.

• Codex App: for findings tied to a specific file and line, emit one inline review comment directive per issue:

  ::code-comment{title="[P1] Short issue title" body="Explain the concrete risk and the smallest practical fix. Redact any secret value." file="/absolute/path/to/file.ts" start=42 end=42 priority=1}
  

  Use absolute file paths, tight line ranges, and priority matching severity (P0/P1 = 1, P2 = 2, P3 = 3). Keep repo-level findings, missing-file findings, command failures, and residual risks in the normal findings list.

• Claude Code: do not assume an inline review comment output directive. Use normal review findings with file:line references unless the current Claude Code environment explicitly provides a comment protocol or tool.

• Antigravity: do not assume a portable text directive for artifact or inline comments. If the active environment exposes a native artifact/comment tool, use that tool; otherwise use normal review findings with file:line references.

• Zed: do not assume a response-level inline comment directive. Zed may show agent edit review UI, but audit findings should stay in normal review format unless the active Zed environment explicitly provides a comment protocol or tool.

Output Format

Lead with findings, ordered by severity. For each finding include:

• Severity and short title.
• Evidence: file path, line, command, or missing expected file.
• Impact: what can break or leak.
• Fix: the smallest practical next step.

Then add:

• Verified: commands actually run and their result.
• Not verified: checks skipped and why.
• Residual risk: anything the repository shape prevented you from proving.