← ClaudeAtlas

repo-health-auditlisted

Read-only repository health and organization audit for finding naming drift, unclear file or folder placement, weak module boundaries, dead code, duplicate code, repeated patterns that should become shared helpers, duplicate concepts, inconsistent conventions, oversized files, circular dependencies, and structural issues that make a codebase harder to navigate or more likely to become spaghetti over time. Use when the user asks to review repo organization, folder structure, naming, architecture hygiene, codebase structure, module layout, dead code, duplicate code, reuse opportunities, or whether a repository is getting messy.
specialone0007/review-skills · ★ 1 · AI & Automation · score 77
Install: claude install-skill specialone0007/review-skills
# Repo Health Audit Run a read-only audit of repository structure, naming hygiene, reuse health, and long-term maintainability. Produce a prioritized report of organization problems with evidence and practical fix direction. Default posture: do not edit, move, rename, reformat, stage, or delete files unless the user explicitly asks for cleanup after the audit. ## Core Rules - Stay read-only during the audit. If the user asks for fixes too, audit first, then switch to normal implementation only after the target changes are clear. - Default to a full-repository audit when the user does not provide a specific scope. Inventory the repo's top-level structure, modules, and packages, then inspect the areas with the most naming drift, duplication, dead code, or boundary confusion. - Full-repo audits are breadth-first, then depth-limited. Inventory the repo, rank surfaces by risk, deep-inspect as many high-risk surfaces as the turn allows, and list the rest under **Surveyed But Not Deeply Inspected** with a pointer to run another pass on them. State the surface counts in the report header. Never present a shallow sweep as complete coverage. - Focus on organization, discoverability, naming, boundaries, dead code, duplication, reuse opportunities, and long-term maintainability. Do not report ordinary implementation bugs unless they are caused by structural confusion or repeated code. - Infer conventions from the repo before judging. Existing patterns, framework defaults, monorepo lay