Code Health Auditor

Systematic audit process that scans directories to identify security issues, bugs, and code health problems. Findings are tracked as work items for remediation.

Quick Start

Example: For @native-yield-operations/automation-service/ do /audit-code-health

1. Scan the target directory for issues
2. Document findings in a table (Security → Bugs → Code Health)
3. File work items or create a findings summary

For deeper audits, follow the Workflow below.

When to Apply

Use this skill when:

• Auditing a codebase for security vulnerabilities
• Identifying bugs and edge cases
• Assessing technical debt and code health
• Creating structured work items for remediation
• Running systematic code reviews

When NOT to Apply

Do not use this skill when:

• Developing a new feature
• Writing a new test

Core Principles

1. Audit only, no fixes: Discover and document—never modify code
2. Track everything: All findings become work items
3. Scoped analysis: Stay within the target directory unless context requires external references
4. Prioritize by impact: Security → Bugs → Code Health

Audit Categories by Priority

Quick Reference

Security Issues (CRITICAL)

• Auth/authz errors
• Injection risks (SQL, command, XSS)
• SSRF, path traversal
• Secrets or insecure defaults
• Broken crypto usage
• Missing input validation
• Dependency vulnerabilities

Bugs (HIGH)

• Edge cases and boundary conditions
• Concurrency / race conditions
• Error handling gaps
• Resource leaks
• Numeric overflow/underflow
• Retry / timeout bugs

Code Health (MEDIUM)

• Oversized or high-complexity modules
• Low test coverage near critical logic
• Duplicated abstractions
• Dead code or unused exports
• Poor documentation
• Misleading names

Related Skills

• Smart Contracts: If you detect *.sol files, use the developing-smart-contracts skill for Solidity-specific security patterns
• Unit Testing: Use the unit-testing-guidelines skill to assess test quality and coverage gaps

Workflow Overview

Audits run in cycles. Choose depth based on scope:

Each cycle follows: SCAN → FINDINGS → VERIFY → FILE → TRIAGE

Cycle Process

For each cycle, execute these steps:

Cycle Progress:
- [ ] Step 1: SCAN - Inspect target directory
- [ ] Step 2: FINDINGS - Document issues by category
- [ ] Step 3: VERIFY - Validate findings before filing
- [ ] Step 4: FILE - Create work items
- [ ] Step 5: TRIAGE - Assign priorities

Step 1: SCAN

Analyze the target directory:

• Review code for security issues, bugs, and health problems
• Run read-only tooling: build, tests, lint, typecheck
• Use code-simplifier on hotspots (if available)

Step 2: FINDINGS

Produce a findings table grouped by Security, Bugs, Code Health:

Step 3: VERIFY

Before filing, validate each finding:

• Confirmed the issue exists (not a false positive)
• Identified the correct file and line number
• Assessed severity accurately
• Checked if issue is already tracked

Step 4: FILE

Create work items for verified findings.

If using Beads (bd):

• See beads-format.md for epic/issue structure
• Use bd commands to create and link items

If bd is not available:

• Use Markdown task lists for tracking findings
• Format: - [ ] [P0/Security] auth/jwt.ts: Token not verified

Step 5: TRIAGE

• Assign P0/P1/P2 priorities
• Identify quick wins vs deep refactors
• Group related issues under epics (if using bd)

Output Format

Each cycle produces:

## Cycle N Summary

### Findings Table
| Severity | Type | File(s) | Description | Confidence | Status |

### Work Items Created
- [P0] ...
- [P1] ...

### Triage Notes
...

### Backlog Overview
Open items grouped by priority

Constraints

• DO NOT implement code changes
• STAY WITHIN target directory unless minimal external context needed
• PREFER many small issues over large vague ones
• VERIFY findings before filing to avoid false positives

Reference Files

• Security Issues Checklist
• Bugs Checklist
• Code Health Checklist
• Beads Format Guide
• Audit Examples