OpenSkillIndex← back to search
claude-codeautomation

Claude-skill-registry auditing-libraries

This skill should be used when the user asks to "audit libraries", "check library conventions", "validate lib structure", "find convention violations", "review library organization", or wants to verify that existing libraries follow the _.ts/__.ts namespace pattern correctly. Identifies and reports violations.

install
source · Clone the upstream repo
git clone https://github.com/majiayu000/claude-skill-registry
Claude Code · Install into ~/.claude/skills/
T=$(mktemp -d) && git clone --depth=1 https://github.com/majiayu000/claude-skill-registry "$T" && mkdir -p ~/.claude/skills && cp -r "$T/skills/data/auditing-libraries" ~/.claude/skills/majiayu000-claude-skill-registry-auditing-libraries && rm -rf "$T"
manifest: skills/data/auditing-libraries/SKILL.md
tags
#code-analysis#linting#conventions#typescript#automation#code-quality
source content

Auditing Libraries

Analyze existing libraries for convention violations and report issues.

CRITICAL

Read Conventions Before Auditing

The authoritative convention documents are:

  • ~/.claude/docs/conventions/namespace-module.md
    — Core 
    _.ts
    /
    __.ts
    pattern
  • ~/.claude/docs/conventions/library-local.md
    — Local library context (
    src/lib/
    )
  • ~/.claude/docs/conventions/library-package.md
    — Package-level context

Read these before auditing to understand the full rules.

Operations

Audit Single Library

Check a specific library for violations.

Steps:

  1. Identify library type (local lib, package lib)
  2. Check file structure matches expected pattern
  3. Validate 
    _.ts
    content
  4. Validate 
    __.ts
    content (if exists)
  5. Check import patterns in code modules
  6. Verify test file imports
  7. Report all violations found

Audit All Libraries

Scan project for all libraries and check each.

Steps:

  1. Find all directories containing 
    _.ts
    files
  2. Categorize each (local lib at 
    src/lib/*
    , package lib at 
    src/*
    )
  3. Audit each library individually
  4. Summarize violations by category

Fix Violations

After auditing, fix identified issues.

Steps:

  1. Present violations to user
  2. Propose fixes for each
  3. Apply fixes with user approval
  4. Re-audit to confirm resolution

Violation Categories

Structure Violations

ViolationDescriptionFix
Missing 
_.ts
Library has no namespace moduleCreate 
_.ts
with correct export
Missing 
__.ts
Multiple impl files but no barrelCreate 
__.ts
with re-exports
Extra 
__.ts
Single impl file with barrelRemove 
__.ts
, update 
_.ts
Wrong locationLibrary not in 
src/lib/
Move to correct location

Namespace Module (
_.ts
) Violations

ViolationDescriptionFix
Wrong export targetPoints to wrong fileFix export path
Has importsContains import statementsRemove imports
Wrong namespace nameDoesn't match directoryFix namespace name
Missing barrel referenceHas 
__.ts
but exports from impl		Change to 
from './__.js'

Barrel Module (
__.ts
) Violations

ViolationDescriptionFix
Imports from 
_.ts
Circular dependencyRemove import
Value importsHas 
import { x }
not re-export		Convert to 
export { x } from
External importsImports from outside libraryMove to code module
Parent importsImports from 
../
Remove or restructure

Import Pattern Violations

ViolationDescriptionFix
Destructured namespace
import { Foo } from '#lib'
Use 
import { Lib } from '#lib'
then 
Lib.Foo
Self namespace importCode imports own 
_.ts
Use relative imports
Self barrel importCode imports own 
__.ts
Use relative imports
Relative cross-lib
import from '../other-lib'
Use 
#other-lib

Test Violations

ViolationDescriptionFix
Wrong importTest imports from impl fileImport from 
./_.js
DestructuredTest destructures namespaceUse namespace directly
Missing fixture namespaceFixture doesn't export 
Fx
Add 
export namespace Fx

Audit Checklist

## Library: <name>

### Structure

* [ ] Located at correct path (src/lib/<name>/ or src/<name>/)
* [ ] Has _.ts namespace module
* [ ] Has __.ts barrel (if multiple impl files)
* [ ] No __.ts (if single impl file)

### Namespace Module (_.ts)

* [ ] Correct export pattern
* [ ] Namespace name matches directory (PascalCase)
* [ ] No import statements
* [ ] Points to __.ts (if exists) or impl file

### Barrel Module (__.ts) - if exists

* [ ] Only contains re-exports
* [ ] No imports from _.ts
* [ ] No external package imports
* [ ] All exports from local files

### Code Modules

* [ ] No imports from own _.ts
* [ ] No imports from own __.ts
* [ ] Cross-lib imports use #<name>
* [ ] Sibling imports use relative paths

### Tests (_.test.ts)

* [ ] Imports from ./_.js only
* [ ] Uses namespace, no destructuring
* [ ] No top-level describe wrapping all tests

### Config

* [ ] package.json has imports entry
* [ ] tsconfig.json has paths entry

Examples

Violation Report Format

Library: src/lib/parser/

VIOLATIONS FOUND: 3

1. [NAMESPACE] _.ts has wrong export
   Current:  export * from './parser.js'
   Expected: export * as Parser from './__.js'
   Reason:   __.ts exists, so _.ts must export namespace from barrel

2. [IMPORT] tokenizer.ts imports from own namespace
   Line 3: import { Parser } from './_.js'
   Fix:     Use relative import: import { helper } from './helper.js'

3. [TEST] _.test.ts destructures namespace
   Line 1: import { tokenize, lex } from './_.js'
   Fix:     import { Parser } from './_.js' then use Parser.tokenize

Notes

  • Run 
    /fix-conventions
    command for automated fixing
  • Some violations require architectural decisions (restructuring)
  • Package-level libraries have different path expectations