Installation
No separate download: the skill runs the in-repo tool
.claude/tools/cli/security-lint.cjs
.
Ensure
Node.js
(v18+) is installed:
nodejs.org
or
winget install OpenJS.NodeJS.LTS
(Windows),
brew install node
(macOS).
From the project root, the script is invoked automatically; no extra install steps.
Cheat Sheet & Best Practices
AST-based validation:
Use ESLint (or equivalent) with selectors/patterns; rules listen for specific node types. Prefer existing community rules before writing custom ones; custom rules need
meta
(type, fixable, schema) and
create
.
Process:
Check naming (camelCase/PascalCase/snake_case), indentation, import order, function/class structure, comment style. Run in pre-commit and CI; provide auto-fix where possible.
Hacks:
Use
--fix
for auto-fixable rules; combine with security-lint for policy. Define rule metadata clearly for docs and tooling. Use AST selectors for precise pattern matching (node type, attributes, child/sibling).
Certifications & Training
ESLint:
Use in project
,
custom rules
,
selectors
. No cert; skill data: AST-based validation, pre-commit/CI, auto-fix, naming/indent/imports.
Hooks & Workflows
Suggested hooks:
Pre-commit: run security-lint (skill script) or ESLint; block commit on failure. Use with
developer
(secondary),
code-reviewer
(secondary),
qa
(CI).
Workflows:
Use with
code-reviewer
(secondary),
developer
(secondary). Flow: before commit or in CI → run validator → fix or block. See
code-review-workflow.md
,
validation
hooks.
Step 1: Identify Code Style Patterns
Analyze the codebase to identify style patterns:
Naming conventions (camelCase, PascalCase, snake_case)
Indentation style (spaces vs tabs, width)
Import organization
Function/class structure
Comment style
Step 2: AST-Based Validation
Use language-specific AST parsers:
TypeScript/JavaScript
:
const
ts
=
require
(
'typescript'
)
;
const
fs
=
require
(
'fs'
)
;
function
validateTypeScriptFile
(
filePath
)
{
const
sourceCode
=
fs
.
readFileSync
(
filePath
,
'utf8'
)
;
const
sourceFile
=
ts
.
createSourceFile
(
filePath
,
sourceCode
,
ts
.
ScriptTarget
.
Latest
,
true
)
;
const
issues
=
[
]
;
// Validate naming conventions
ts
.
forEachChild
(
sourceFile
,
node
=>
{
if
(
ts
.
isFunctionDeclaration
(
node
)
&&
node
.
name
)
{
if
(
!
/
^
[
a
-
z
]
[
a
-
z
A
-
Z
0
-
9
]
*
$
/
.
test
(
node
.
name
.
text
)
)
{
issues
.
push
(
{
line
:
sourceFile
.
getLineAndCharacterOfPosition
(
node
.
name
.
getStart
(
)
)
.
line
+
1
,
message
:
Function name "
${
node
.
name
.
text
}
" should be camelCase
,
}
)
;
}
}
}
)
;
return
issues
;
}
After implementing your validator:
node validate-code-style.js src/components/Button.tsx Validate Directory :
After implementing your validator:
node
validate-code-style.js src/components/
Output Format
:
{
"file"
:
"src/components/Button.tsx"
,
"valid"
:
false
,
"issues"
:
[
{
"line"
:
15
,
"column"
:
10
,
"rule"
:
"naming-convention"
,
"message"
:
"Variable 'UserData' should be camelCase: 'userData'"
,
"severity"
:
"error"
}
,
{
"line"
:
23
,
"column"
:
5
,
"rule"
:
"indentation"
,
"message"
:
"Expected 2 spaces, found 4"
,
"severity"
:
"warning"
}
]
,
"summary"
:
{
"total"
:
2
,
"errors"
:
1
,
"warnings"
:
1
}
}
!/bin/bash
.git/hooks/pre-commit
changed_files
$( git diff --cached --name-only --diff-filter = ACM | grep -E '.(ts|tsx|js|jsx|py)$' ) for file in $changed_files ; do
Replace with your actual validator path
if
!
node
validate-code-style.js
"
$file
"
;
then
echo
"Code style validation failed for
$file
"
exit
1
fi
done
.github/workflows/code-style.yml
- name : Validate code style run : |
Replace with your actual validator path
node validate-code-style.js src/ if [ $? -ne 0 ]; then echo "Code style validation failed" exit 1 fi Iron Laws ALWAYS use AST-based validation over regex — regex-based style checking breaks on multi-line constructs, comments, and strings; AST-based tools (ESLint, Prettier) are format-independent and semantically accurate. ALWAYS check for existing ESLint/Prettier rules before writing custom ones — custom rules are expensive to maintain; 95% of style needs are covered by existing rules with configuration. NEVER block commits for style warnings, only errors — warnings are informational; blocking CI on warnings creates friction that leads teams to disable style checks entirely. ALWAYS provide auto-fix suggestions alongside findings — reports without auto-fix require manual intervention for each issue; auto-fixable violations have near-100% resolution rates vs 30% for manual. ALWAYS run style validation in both pre-commit hooks and CI — pre-commit catches issues locally before they reach the repository; CI catches cases where hooks were bypassed or aren't installed. Anti-Patterns Anti-Pattern Why It Fails Correct Approach Regex-based style checking Breaks on multi-line, strings, and comments Use AST-based tools (ESLint, Prettier) Custom rules for covered standards High maintenance; inconsistent with community Configure existing ESLint/Prettier rules first Blocking CI on warnings Excessive friction causes teams to disable style checks Block only on errors; log warnings Style validation without auto-fix Manual fixes have low resolution rate Always provide auto-fix commands alongside findings Running only locally, not in CI Developers bypass pre-commit hooks regularly Run in both pre-commit and CI pipeline Memory Protocol (MANDATORY) Before starting: Read .claude/context/memory/learnings.md After completing: New pattern -> .claude/context/memory/learnings.md Issue found -> .claude/context/memory/issues.md Decision made -> .claude/context/memory/decisions.md ASSUME INTERRUPTION: If it's not in memory, it didn't happen.