code-auditing
Skill1 starsChanged 2 months agoMITView on GitHub
Use when auditing code quality or security - a systematic pass over a module, package or whole codebase following OWASP Top 10 and NIST, including dead-code detection. Use for security reviews, pre-release audits and 'is this code safe/healthy' questions, not for reviewing a single change (use adversarial-review for that).
In this repository13 other files it gives its agents.
- AGENTS.mdAGENTS.md
- adversarial-reviewSkill
- architecture-guidelinesSkill
- auto-run-taskSkill
- commitSkill
- enrich-taskSkill
- harness-setupSkill
- run-taskSkill
- runtime-verificationSkill
- start-projectSkill
- update-docsSkill
- using-git-worktreesSkill
- writing-skillsSkill
The file
We split this skill into the rules it gives an agent
11 rules. About 0 are common, 9 are distinctive, and 2 are very specific to this project.
≈0
Common · estimate
Many files like this have a rule of this kind.
≈9
Distinctive · estimate
This author's own choices. Worth a look.
2
Very specific
Tied to their project's names, files or tools. Probably skip.
- Common
- Distinctive
- Very specific
- Very specific: line 23
Check for project configuration files (package.json, tsconfig.json, etc.)
- Distinctive: line 25
Check for linting/formatting configs
- Distinctive: line 26
Run existing linting/testing commands as baseline
- Distinctive: line 31
Create tracking list for each file
- Distinctive: line 55
Look for recurring issues:
- Distinctive: line 63
Check if current libraries provide the functionality
- Distinctive: line 64
Search for mature ecosystem packages
- Distinctive: line 65
Verify library health (commits, issues, activity)
- Distinctive: line 66
Check compatibility with project setup
- Very specific: line 103
Use of any type
- Distinctive: line 124
Important: Always verify tool findings before reporting.
≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.
Files
Code Auditing Skill
Comprehensive methodology for systematic code quality audits.
When to Use
- Comprehensive code quality audits
- Security vulnerability assessments
- Technical debt identification
- Pre-release code reviews
- Best practices verification
- Library and dependency audits
Audit Phases
Phase 0: Pre-Analysis Setup
- Check for project configuration files (package.json, tsconfig.json, etc.)
- Identify tech stack and main libraries
- Check for linting/formatting configs
- Run existing linting/testing commands as baseline
- Load documentation for identified core libraries
Phase 1: Discovery
- Find all code files by type
- Create tracking list for each file
- Group files by module/feature for contextual analysis
Phase 2: File-by-File Analysis
For each file, analyze for:
- Dead code (unused functions, variables, imports)
- Code smells and anti-patterns
- Custom implementations that could use established libraries
- Security vulnerabilities
- Performance issues
- Outdated patterns or deprecated APIs
- Missing error handling
- Overly complex functions
- Duplicate code
Phase 3: Best Practices Verification
For every library and framework:
- Retrieve official documentation
- Compare implementation against official patterns
- Identify deviations from recommendations
- Note outdated usage patterns
- Flag discouraged anti-patterns
Phase 4: Pattern Detection
Look for recurring issues:
- Common anti-patterns across files
- Duplicated logic that could be abstracted
- Inconsistent coding styles
- Missing error handling patterns
Phase 5: Library Recommendations
For custom implementations:
- Check if current libraries provide the functionality
- Search for mature ecosystem packages
- Verify library health (commits, issues, activity)
- Check compatibility with project setup
Phase 6: Comprehensive Report
Generate detailed report with:
- Executive summary
- Critical issues requiring immediate attention
- File-by-file findings
- Prioritized action plan
- Effort estimates
- Library recommendations
Issue Priority Levels
- Critical - Security vulnerabilities, broken functionality
- High Priority - Performance bottlenecks, unmaintainable code
- Medium Priority - Code quality, best practices deviations
- Low Priority - Style, minor improvements
- Quick Wins - Less than 30 minutes to fix
Analysis Categories
Security
- Hardcoded secrets
- SQL injection risks
- XSS vulnerabilities
- Missing input validation
- Exposed sensitive data
Performance
- Inefficient algorithms
- Blocking operations
- Memory leaks
- Missing caching opportunities
- N+1 query patterns
TypeScript/Type Safety
- Missing type annotations
- Use of
anytype - Custom types duplicating official types
- Missing @types packages
Async/Promise Issues
- Missing await keywords
- Unhandled promise rejections
- Callback hell
Dead Code
- Unused imports and exports
- Unused functions, classes, and methods
- Unused variables and types
- Unreachable code blocks
- Unused files (not imported anywhere)
- Unused dependencies
Tools:
- JavaScript/TypeScript:
npx knip --reporter json - Python:
deadcode . --dry
Important: Always verify tool findings before reporting. Check for:
- Dynamic imports (
import(variable)) - Framework patterns (React components, decorators)
- Re-exports for public API
- Entry points (CLI scripts, serverless handlers)
Resources
See the reference documents for complete methodologies:
references/audit-methodology.md- Full 6-phase audit process with detailed checklistsreferences/dead-code-methodology.md- Dead code detection tools, verification, and cleanup workflows
Quick Reference
Before Starting
- Read project configuration files
- Identify tech stack and libraries
- Run existing linters as baseline
- Create file tracking list
During Audit
- Mark files as in-progress
- Analyze each category systematically
- Note specific line numbers
- Document before/after examples
- Mark files as completed
After Audit
- Categorize all findings by priority
- Generate comprehensive report
- Save report to project root
- Provide brief console summary
Does it work?
Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.
No reviews yet
People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.
- It worked
- Partly
- It didn't
Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.
Your trail
Files you open will collect here, so you can find them again.
Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.
Now do this for your own.
Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.

