Audit projects for linting configuration, create strict configs, generate lint rule tests, and enforce code quality on every file write via PostToolUse hooks.
From project-lintingnpx claudepluginhub nbkm8y5/claude-plugins --plugin project-lintingThis skill uses the workspace's default tool permissions.
references/eslint_configs.mdreferences/ruff_configs.mdreferences/shell_configs.mdreferences/swiftlint_configs.mdImplements Clean Architecture, Hexagonal Architecture (ports/adapters), and Domain-Driven Design for backend services. For microservice design, monolith refactoring to bounded contexts, and dependency debugging.
Implements CQRS patterns with Python templates for command/query separation, event-sourcing, and scalable read/write models. Use for optimizing queries or independent scaling.
Provides REST and GraphQL API design principles including resource hierarchies, HTTP methods, versioning strategies, pagination, and filtering patterns for new APIs, reviews, or standards.
Adopt a strict-by-default "straightjacket" approach to linting. Every rule starts enabled at its strictest setting. Teams adapt by selectively relaxing rules with documented rationale — never by starting permissive and hoping to tighten later.
The reasoning is simple: it is far easier to disable a rule that does not apply to your codebase than to retroactively enforce a rule across thousands of existing violations. Strict defaults create a culture of intentional exceptions rather than accidental omissions.
| Language | Linter | Config File | Key Focus Areas |
|---|---|---|---|
| TypeScript | ESLint | .eslintrc.json | Type safety, no-any, explicit returns, strict bools |
| Python | ruff | ruff.toml | PEP 8, import sorting, security, complexity |
| Swift | SwiftLint | .swiftlint.yml | Force unwrap prevention, naming, complexity |
| Bash | shellcheck | .shellcheckrc | Quoting, globbing, POSIX compliance |
Use detect_stack.sh (located at ${CLAUDE_PLUGIN_ROOT}/lib/detect_stack.sh) to automatically identify which languages are present in a project. The script scans for:
tsconfig.json or .ts files (maxdepth 3, excludes node_modules)package.json + .js files without tsconfig.jsonpyproject.toml, setup.py, requirements.txt, or .py filesPackage.swift, .xcodeproj, or .swift files.sh files (excludes node_modules, .git)Output is one language per line, enabling pipeline composition.
When auditing a project, check three layers per detected language:
package.json (or Makefile, pyproject.toml) define a lint script/target?.github/workflows/, .circleci/, or similar contain a lint step?Each layer is scored independently, producing a per-language audit report.
| Severity | Color | Meaning | Example |
|---|---|---|---|
| GREEN | Green | All three layers present and correctly configured | ESLint config + npm lint + CI step |
| YELLOW | Yellow | Config exists but missing lint script or CI integration | ruff.toml present, no Makefile target |
| RED | Red | No linter configuration found for a detected language | Python project with zero ruff config |
Reference configs in references/ follow these principles:
For each lint rule in a config, generate two test fixtures:
A test runner script executes the linter against both fixtures and asserts expected outcomes. This validates that:
The post_write_lint.sh hook (at ${CLAUDE_PLUGIN_ROOT}/hooks/scripts/post_write_lint.sh) runs automatically on every Write or Edit tool use:
file_path from TOOL_INPUT JSONGraceful degradation ensures the hook never breaks workflows: