Audit Codebase Before Push

Acts as a senior engineer doing a final pre-push review: reads the entire codebase file by file and fixes problems immediately rather than just listing them. The audit runs through ten checks in order - junk-file cleanup (OS/log/temp/build/dependency/IDE/backup/test-artifact files, plus a hard stop for secrets: .env files, hardcoded password/api_key/token/secret/private_key strings, *.pem/*.key/*.cert/credentials.json), .gitignore completeness (with .env.example holding keys but no values), dead code and code-quality fixes (unused imports/vars/functions, vague names, magic numbers, debug statements, TypeScript any, === over ==, functions over 50 lines, nesting over 3 levels), a zero-tolerance security pass (parameterized queries, no exec() on user input, path-traversal validation, no unescaped innerHTML, bcrypt/argon2 password hashing, server-side authorization, IDOR checks, npm audit), scalability checks (N+1 queries, missing indexes, unbounded queries, background queues for heavy operations, rate limiting, caching), architecture and separation-of-concerns review (no "god files," reusable utilities over duplication), performance (backend batching and cache headers, frontend code splitting and lazy loading), documentation (a complete README, WHY-focused comments), and test-suite hygiene (no test.only/fdescribe, tests on critical paths). It finishes by running the app to confirm nothing broke, then produces a structured report covering files removed, per-file code changes, flagged security issues, scalability fixes, and scores for security, code quality, and scalability.

Use it when a user asks to "audit the codebase" or "review before push," before the first push to GitHub, before making a repository public, for a pre-production deployment review, or when asked to "clean up the code" or "optimize everything." It is scoped to this exact pre-push audit job: use it only when the task clearly matches this scope, stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing, and don't treat its output as a substitute for environment-specific validation, testing, or expert review. Security issues found during the audit are hard blockers - nothing should ship with a critical vulnerability still open - and the skill defaults to asking the user first before deleting IDE config directories or anything else it's uncertain about removing.

Input is the target codebase; output is a structured audit report with five parts: a list of files removed (e.g. node_modules/, .env, backup duplicates), a per-file list of code changes made (removed unused imports, deleted dead functions, renamed vague variables, added missing try/catch), a security-issues section that labels each finding CRITICAL or HIGH alongside its fix (e.g. a hardcoded API key moved to .env, a SQL injection risk fixed with a parameterized query), a scalability section (e.g. pagination added to an endpoint, a missing index added), and a final status line plus 1-10 scores for security, code quality, and scalability.

No external tool integrations beyond the codebase and its own dependency audit (npm audit or equivalent); it's designed to be used alongside three related skills - @security-auditor for a deeper security review, @systematic-debugging for investigating specific issues, and @git-pushing to push the code once the audit is clean.

Developers preparing a first push to GitHub, making a repository public, or doing a pre-production deployment review, who want a senior-engineer-style pass that both flags and fixes dead code, security holes, scalability issues, and documentation gaps rather than just producing a list of complaints.