wtf

Name: wtf
Author: noobnooc

1.4kstars129forks

How to install wtf?

noobnooc/agent/wtf

$npx -y skills add noobnooc/agent --skill wtf

Installs into the current project.

Summary

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, d

Files · 1

View on GitHub

SKILL.md

1	# WTF
2
3	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.
4
5	## Operating Mode
6
7	- 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.
8	- 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.
9	- Prefer evidence over guesses. Tie every finding to a file, command output, or missing expected artifact.
10	- Do not print secret values. If a secret is committed or exposed, name the file and variable/key shape, but redact the value.
11	- If the user asks to fix issues, implement the fixes after the audit and verify them. Otherwise, remain in review/audit mode.
12
13	## Audit Workflow
14
15	1. Map the project
16	- Identify app type, framework, package manager, runtime, deployment target, database, ORM, auth provider, and build/test commands.
17	- Check whether the root is clean or dirty. Preserve unrelated user changes.
18	- Find likely entrypoints: app routes, API routes, workers, server actions, CLI commands, cron jobs, migrations, schemas, and config files.
19
20	2. Check repository hygiene
21	- 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.
22	- 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.
23	- Use `git ls-files` to distinguish ignored local junk from files already tracked by Git.
24
25	3. Check secrets and environment variables
26	- Search for tokens, private keys, API keys, JWT secrets, database URLs, webhook secrets, cloud credentials, and hardcoded production URLs.
27	- Verify required env vars are documented in `.env.example`, deployment docs, or typed config. Flag required envs that are used in code but undocumented.
28	- Check for accidental logging of secrets, auth headers, cookies, session payloads, or provider responses.
29
30	4. Check database readiness
31	- Identify whether the app uses Prisma, Drizzle, TypeORM, Sequelize, Rails migrations, Django migrations, Alembic, Knex, raw SQL, or another migration system.
32	- Confirm schema changes have matching migrations and that migrations are committed.
33	- 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.
34	- 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.
35
36	5. Check app correctness and security basics
37	- Run or inspect available `lint`, `typecheck`, `test`, and `build` scripts when practical.
38	- 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.
39	- Check error handling and observability: production errors should not leak stack traces, secrets, or internal IDs unnecessarily.
40
41	6. Check dead and legacy code
42	- 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.
43	- Prefer repository-aware tools when available: TypeScript compiler, ESLint, depcheck, framework route manifests, import graph tools, or existing CI checks.
44	- Treat dead code as lower severity unless it affects security, deploy size, routing, migrations, or user-visible behavior.
45
46	7. Check deployment shape
47	- Inspect Dockerfiles, wrangler/vercel/netlify/cloudflare config, GitHub Actions, release scripts, cron configuration, and required runtime versions.
48	- 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.
49
50	## Useful Commands
51
52	Adapt commands to

People who liked this also viewed

6 picks

Type

wtf

1.4kstars129forks

View on GitHub

How to install wtf?

noobnooc/agent/wtf

$npx -y skills add noobnooc/agent --skill wtf

Installs into the current project.

Summary

Files · 1

View on GitHub

SKILL.md

1	# WTF
2
3	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.
4
5	## Operating Mode
6
7	- 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.
8	- 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.
9	- Prefer evidence over guesses. Tie every finding to a file, command output, or missing expected artifact.
10	- Do not print secret values. If a secret is committed or exposed, name the file and variable/key shape, but redact the value.
11	- If the user asks to fix issues, implement the fixes after the audit and verify them. Otherwise, remain in review/audit mode.
12
13	## Audit Workflow
14
15	1. Map the project
16	- Identify app type, framework, package manager, runtime, deployment target, database, ORM, auth provider, and build/test commands.
17	- Check whether the root is clean or dirty. Preserve unrelated user changes.
18	- Find likely entrypoints: app routes, API routes, workers, server actions, CLI commands, cron jobs, migrations, schemas, and config files.
19
20	2. Check repository hygiene
21	- 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.
22	- 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.
23	- Use `git ls-files` to distinguish ignored local junk from files already tracked by Git.
24
25	3. Check secrets and environment variables
26	- Search for tokens, private keys, API keys, JWT secrets, database URLs, webhook secrets, cloud credentials, and hardcoded production URLs.
27	- Verify required env vars are documented in `.env.example`, deployment docs, or typed config. Flag required envs that are used in code but undocumented.
28	- Check for accidental logging of secrets, auth headers, cookies, session payloads, or provider responses.
29
30	4. Check database readiness
31	- Identify whether the app uses Prisma, Drizzle, TypeORM, Sequelize, Rails migrations, Django migrations, Alembic, Knex, raw SQL, or another migration system.
32	- Confirm schema changes have matching migrations and that migrations are committed.
33	- 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.
34	- 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.
35
36	5. Check app correctness and security basics
37	- Run or inspect available `lint`, `typecheck`, `test`, and `build` scripts when practical.
38	- 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.
39	- Check error handling and observability: production errors should not leak stack traces, secrets, or internal IDs unnecessarily.
40
41	6. Check dead and legacy code
42	- 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.
43	- Prefer repository-aware tools when available: TypeScript compiler, ESLint, depcheck, framework route manifests, import graph tools, or existing CI checks.
44	- Treat dead code as lower severity unless it affects security, deploy size, routing, migrations, or user-visible behavior.
45
46	7. Check deployment shape
47	- Inspect Dockerfiles, wrangler/vercel/netlify/cloudflare config, GitHub Actions, release scripts, cron configuration, and required runtime versions.
48	- 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.
49
50	## Useful Commands
51
52	Adapt commands to

People who liked this also viewed

6 picks

Type