# Codebase Audit Pre Push

> Deep audit before GitHub push: removes junk files, dead code, security holes, and optimization issues. Checks every file line-by-line for production readiness.

- Skill: `newmindsgroup/codebase-audit-pre-push` (Agent Skill)
- Install (CLI): `npx skillmds@latest add newmindsgroup/codebase-audit-pre-push`
- Raw SKILL.md: https://api.skillmd.com/api/skills/newmindsgroup/codebase-audit-pre-push/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Security
- License: MIT
- Author: newmindsgroup (https://skillmd.com/u/newmindsgroup)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/newmindsgroup/codebase-audit-pre-push

---


# Pre-Push Codebase Audit

As a senior engineer, you're doing the final review before pushing this code to GitHub. Check everything carefully and fix problems as you find them.

## When to Use This Skill

- User requests "audit the codebase" or "review before push"
- Before making the first push to GitHub
- Before making a repository public
- Pre-production deployment review
- User asks to "clean up the code" or "optimize everything"

## Your Job

Review the entire codebase file by file. Read the code carefully. Fix issues right away. Don't just note problems—make the necessary changes.

## Audit Process

### 1. Clean Up Junk Files

Start by looking for files that shouldn't be on GitHub:

**Delete these immediately:**
- OS files: `.DS_Store`, `Thumbs.db`, `desktop.ini`
- Logs: `*.log`, `npm-debug.log*`, `yarn-error.log*`
- Temp files: `*.tmp`, `*.temp`, `*.cache`, `*.swp`
- Build output: `dist/`, `build/`, `.next/`, `out/`, `.cache/`
- Dependencies: `node_modules/`, `vendor/`, `__pycache__/`, `*.pyc`
- IDE files: `.idea/`, `.vscode/` (ask user first), `*.iml`, `.project`
- Backup files: `*.bak`, `*_old.*`, `*_backup.*`, `*_copy.*`
- Test artifacts: `coverage/`, `.nyc_output/`, `test-results/`
- Personal junk: `TODO.txt`, `NOTES.txt`, `scratch.*`, `test123.*`

**Critical - Check for secrets:**
- `.env` files (should never be committed)
- Files containing: `password`, `api_key`, `token`, `secret`, `private_key`
- `*.pem`, `*.key`, `*.cert`, `credentials.json`, `serviceAccountKey.json`

If you find secrets in the code, mark it as a CRITICAL BLOCKER.

### 2. Fix .gitignore

Check if the `.gitignore` file exists and is thorough. If it’s missing or not complete, update it to include all junk file patterns above. Ensure that `.env.example` exists with keys but no values.

### 3. Audit Every Source File

Look through each code file and check:

**Dead Code (remove immediately):**
- Commented-out code blocks
- Unused imports/requires
- Unused variables (declared but never used)
- Unused functions (defined but never called)
- Unreachable code (after `return`, inside `if (false)`)
- Duplicate logic (same code in multiple places—combine)

**Code Quality (fix issues as you go):**
- Vague names: `data`, `info`, `temp`, `thing` → rename to be descriptive
- Magic numbers: `if (status === 3)` → extract to named constant
- Debug statements: remove `console.log`, `print()`, `debugger`
- TODO/FIXME comments: either resolve them or delete them
- TypeScript `any`: add proper types or explain why `any` is used
- Use `===` instead of `==` in JavaScript
- Functions longer than 50 lines: consider splitting
- Nested code greater than 3 levels: refactor with early returns

**Logic Issues (critical):**
- Missing null/undefined checks
- Array operations on potentially empty arrays
- Async functions that are not awaited
- Promises without `.catch()` or try/catch
- Possibilities for infinite loops
- Missing `default` in switch statements

### 4. Security Check (Zero Tolerance)

**Secrets:** Search for hardcoded passwords, API keys, and tokens. They must be in environment variables.

**Injection vulnerabilities:**
- SQL: No string concatenation in queries—use parameterized queries only
- Command injection: No `exec()` with user-provided input
- Path traversal: No file paths from user input without validation
- XSS: No `innerHTML` or `dangerouslySetInnerHTML` with user data

**Auth/Authorization:**
- Passwords hashed with bcrypt/argon2 (never MD5 or plain text)
- Protected routes check for authentication
- Authorization checks on the server side, not just in the UI
- No IDOR: verify users own the resources they are accessing

**Data exposure:**
- API responses do not leak unnecessary information
- Error messages do not expose stack traces or database details
- Pagination is present on list endpoints

**Dependencies:**
- Run `npm audit` or an equivalent tool
- Flag critically outdated or vulnerable packages

### 5. Scalability Check

**Database:**
- N+1 queries: loops with database calls inside → use JOINs or batch queries
- Missing indexes on WHERE/ORDER BY columns
- Unbounded queries: add LIMIT or pagination
- Avoid `SELECT *`: specify columns

**API Design:**
- Heavy operations (like email, reports, file processing) → move to a background queue
- Rate limiting on public endpoints
- Caching for data that is read frequently
- Timeouts on external calls

**Code:**
- No global mutable state
- Clean up event listeners (to avoid memory leaks)
- Stream large files instead of loading them into memory

### 6. Architecture Check

**Organization:**
- Clear folder structure
- Files are in logical locations
- No "misc" or "stuff" folders

**Separation of concerns:**
- UI layer: only responsible for rendering
- Business logic: pure functions
- Data layer: isolated database queries
- No 500+ line "god files"

**Reusability:**
- Duplicate code → extract to shared utilities
- Constants defined once and imported
- Types/interfaces reused, not redefined

### 7. Performance

**Backend:**
- Expensive operations do not block requests
- Batch database calls when possible
- Set cache headers correctly

**Frontend (if applicable):**
- Implement code splitting
- Optimize images
- Avoid massive dependencies for small utilities
- Use lazy loading for heavy components

### 8. Documentation

**README.md must include:**
- Description of what the project does
- Instructions for installation and execution
- Required environment variables
- Guidance on running tests

**Code comments:**
- Explain WHY, not WHAT
- Provide explanations for complex logic
- Avoid comments that merely repeat the code

### 9. Testing

- Critical paths should have tests (auth, payments, core features)
- No `test.only` or `fdescribe` should remain in the code
- Avoid `test.skip` without an explanation
- Tests should verify behavior, not implementation details

### 10. Final Verification

After making all changes, run the app. Ensure nothing is broken. Check that:
- The app starts without errors
- Main features work
- Tests pass (if they exist)
- No regressions have been introduced

## Output Format

After auditing, provide a report:

```
CODEBASE AUDIT COMPLETE

FILES REMOVED:
- node_modules/ (build artifact)
- .env (contained secrets)
- old_backup.js (unused duplicate)

CODE CHANGES:
[src/api/users.js]
  ✂ Removed unused import: lodash
  ✂ Removed dead function: formatOldWay()
  🔧 Renamed 'data' → 'userData' for clarity
  🛡 Added try/catch around API call (line 47)

[src/db/queries.js]
  ⚡ Fixed N+1 query: now uses JOIN instead of loop

SECURITY ISSUES:
🚨 CRITICAL: Hardcoded API key in config.js (line 12) → moved to .env
⚠️ HIGH: SQL injection risk in search.js (line 34) → fixed with parameterized query

SCALABILITY:
⚡ Added pagination to /api/users endpoint
⚡ Added index on users.email column

FINAL STATUS:
✅ CLEAN - Ready to push to GitHub

Scores:
Security: 9/10 (one minor header missing)
Code Quality: 10/10
Scalability: 9/10
Overall: 9/10
```

## Key Principles

- Read the code thoroughly, don't skim
- Fix issues immediately, don’t just document them
- If uncertain about removing something, ask the user
- Test after making changes
- Be thorough but practical—focus on real problems
- Security issues are blockers—nothing should ship with critical vulnerabilities

## Related Skills

- `@security-auditor` - Deeper security review
- `@systematic-debugging` - Investigate specific issues
- `@git-pushing` - Push code after audit

## Limitations
- Use this skill only when the task clearly matches the scope described above.
- Do not treat the output as a substitute for environment-specific validation, testing, or expert review.
- Stop and ask for clarification if required inputs, permissions, safety boundaries, or success criteria are missing.