ln-22-codebase-auditor
starsforks
How to install ln-22-codebase-auditor?
levnikolaevich/claude-code-skills/ln-22-codebase-auditor
$npx -y skills add levnikolaevich/claude-code-skills --skill ln-22-codebase-auditorAudits cross-cutting code health across security, delivery, maintainability, dependencies, diagnosability, concurrency, and lifecycle. Use when no specialist audit is primary.
SKILL.md
| 1 | # Codebase Auditor |
| 2 | |
| 3 | **Goal:** Perform a broad, read-only production-code health audit. Find concrete cross-cutting failure, security, delivery, and maintenance risks without turning detector matches or personal style preferences into findings. Do not substitute for documentation trust, test-portfolio, whole-architecture, or persistence-specific review. |
| 4 | |
| 5 | **Execution contract:** Treat the ordered checkbox workflow below as this skill's Definition of Done. Work through every item in order, and mark it complete only when its action and required evidence are complete. `N/A`, skipped, unavailable, or delegated items remain incomplete. |
| 6 | Before returning, apply this skill's verdict, decision, and approval rules to every incomplete item and prepend **Checklist: X/Y complete**<br>**Incomplete: None | section/item — reason; outcome impact; exact next action**; list every incomplete item. |
| 7 | |
| 8 | ## Tool Routing |
| 9 | |
| 10 | | Need | Preferred tool | Use it when | Fallback | |
| 11 | |---|---|---|---| |
| 12 | | Repository map and stack detection | Native file listing, manifests, build files, and repository instructions | Establishing scope, generated areas, entrypoints, supported runtimes, and commands | Targeted tree inspection and known entrypoints | |
| 13 | | Symbols, callers, ownership, and data flow | Language server or host-native code intelligence | A finding depends on symbol identity, references, overrides, route wiring, or cross-file behavior | Narrow text search plus direct inspection of every relevant match | |
| 14 | | Current changes and historical context | Git status, diff, log, and blame | Separating current work, regressions, intentional constraints, and dead compatibility paths | Current implementation and explicit decision records | |
| 15 | | Delivery health | Repository-defined build, lint, type, test, and smoke commands | Establishing whether the project can ship in its documented environment | Inspect CI and scripts; mark execution unavailable | |
| 16 | | Dependency and security state | Native package-manager audit, manifests, lockfiles, and official advisories | Checking known vulnerabilities, unsupported versions, and dependency health | Official registry and vendor sources; never guess severity | |
| 17 | | Runtime evidence | Existing logs, metrics, traces, profiles, and diagnostics | Static analysis cannot establish frequency, reachability, or operational impact | Call-path analysis with an explicit static-only limitation | |
| 18 | | Current external behavior | Official specifications, vendor documentation, and release notes | A finding depends on current API, runtime, or standard behavior | Primary-source web research; otherwise mark `UNVERIFIED` | |
| 19 | |
| 20 | Start with summary-level discovery and narrow before reading deeply. Run only repository-defined or clearly safe diagnostic commands; never publish, deploy, migrate production data, rotate secrets, or rewrite files during the audit. |
| 21 | |
| 22 | ## Evidence Rules |
| 23 | |
| 24 | - A pattern match is a candidate, not a finding. Confirm reachability, context, and consequence. |
| 25 | - Runtime failure or deterministic command output outweighs static suspicion; static evidence remains valid when execution is unavailable and the limitation is explicit. |
| 26 | - Generated, vendored, fixture, migration-history, and intentionally compatible code require context-specific treatment. |
| 27 | - External best practice is actionable only when it addresses a concrete repository defect or risk. |
| 28 | - Score or count only findings with distinct root causes; deduplicate symptoms that share one correction. |
| 29 | |
| 30 | ## Checklist |
| 31 | |
| 32 | ### 1. Establish Scope and Baseline |
| 33 | |
| 34 | - [ ] Detect languages, frameworks, package managers, entrypoints, deployment model, generated areas, and the repository's supported verification commands. |
| 35 | - [ ] Classify each runtime surface as long-running service, CLI, library, job, serverless function, or platform-managed component before requiring probes, telemetry, signal handling, or shutdown behavior. |
| 36 | - [ ] Read applicable instructions and identify security boundaries, critical business paths, public interfaces, and irreversible operations. |
| 37 | - [ ] Inspect Git state so the audit does not overwrite, misattribute, or ignore unrelated user changes. |
| 38 | - [ ] Establish build, lint, type, test, and smoke baseline where feasible; record commands, environment, exit status, and relevant output. |
| 39 | - [ ] Define exclusions and depth based on risk rather than scanning every file with equal effort. |
| 40 | - [ ] Keep the audit read-only. Allow only permitted caches and build artifacts and disclose them when created. |
| 41 | |
| 42 | ### 2. Audit Security and Delivery Boundaries |
| 43 | |
| 44 | - [ ] Search for committed secrets, unsafe credential patterns, sensitive defaults, debug bypasses, and accidental exposure through logs or errors. |
| 45 | - [ ] For credential findings, never expose the raw value: distinguish live material from |
People who liked this also viewed
6 picksType
- requesting-code-reviewUse when completing tasks, implementing major features, or before merging to verify work meets requirementsSkillsJul 2026
- code-reviewSkills for Real Engineers. Straight from my .agents directory.SkillsJul 2026
- receiving-code-reviewUse when receiving code review feedback, before implementing suggestions, especially if feedback seems unclear or technically questionable - requires technical rigor and verification, not performativeSkillsJul 2026
- baoyu-format-markdownFormats plain text or markdown files with frontmatter, titles, summaries, headings, bold, lists, and code blocks. Use when user asks to "format markdown", "beautify article", "add formatting", or imprSkillsJul 2026
- code-review-excellenceMaster effective code review practices to provide constructive feedback, catch bugs early, and foster knowledge sharing while maintaining team morale. Use when reviewing pull requests, establishing reSkillsJul 2026
- code-review-and-qualityConducts multi-axis code review. Use before merging any change. Use when reviewing code written by yourself, another agent, or a human. Use when you need to assess code quality across multiple dimensiSkillsJul 2026
