lint-rule-pattern-verification

Validates regex and AST-based lint gates against missed spellings and false-positive matches.

1|Updated Jun 9, 2026
One-click install
npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill lint-rule-pattern-verification-vilnacrm-org
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: lint-rule-pattern-verification
Source: https://github.com/VilnaCRM-Org/claude-plugins/tree/main/plugins/react-frontend-sdlc/skills/lint-rule-pattern-verification
Command: npx skills add https://github.com/VilnaCRM-Org/claude-plugins --skill lint-rule-pattern-verification-vilnacrm-org

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Pattern-based CI gates fail silently in two directions: they miss alternate spellings of the construct they police (bracket access, quoted keys, namespace imports), or they count commented-out and quoted code as real coverage, letting a gate pass while enforcing nothing. ## Core Features & Use Cases - AST-first matching guidance: Shows how to walk the TypeScript AST with a pure (fileName, sourceText) parser so comments and string literals never count as executable calls. - Mandatory fail-closed fixtures: Defines the three test cases every guard needs — a real call, a commented-out call, and a quoted call — plus a fourth assertion that the walk found enough calls to avoid vacuous passes. - Spelling enumeration for regex gates: Checklists recurring miss patterns across member access, object keys, imports, and function declarations, with must-fail fixtures per form. - Use Case: A drift guard greps source for a helper call and has never failed since it was added; use this Skill to prove it can fail, add fixtures for commented-out and quoted variants, and widen the pattern to cover bracket-access spellings. ## Quick Start Ask the AI to verify whether the gate script under scripts/ci/ can actually fail by adding must-fail fixtures for commented-out, quoted, and bracket-access spellings of the call it polices.

Frequently Asked Questions about lint-rule-pattern-verification

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I test that an ESLint no-restricted-syntax rule actually works?▼

Add must-fail fixtures that violate the rule and assert the gate fails on them. Cover every spelling of the construct — bracket access, quoted keys, namespace imports — so the rule cannot be bypassed by reformatting the code.

Why does my regex-based CI gate pass on commented-out code?▼

Regex over raw source cannot distinguish executable code from comments or string literals, so a commented-out call still matches. Parse the TypeScript AST instead, where comments never become nodes and quoted calls remain strings.

When should I use an AST selector instead of a regex for lint rules?▼

Use an AST selector whenever the rule polices a call or statement rather than a token, because commenting out code is the cheapest way to disable a regex gate. Reserve regex for cases where you enumerate and fixture-test every spelling.

What spellings does a lint pattern commonly miss?▼

Common misses include obj.key versus obj['key'] versus obj[variable], bare versus quoted versus shorthand object keys, default versus namespace versus dynamic imports, and function declarations versus arrow functions versus method shorthand.

Why has my custom lint gate never failed since it was added?▼

A gate that never fails likely cannot fail — it may match only one spelling or count non-executable text as coverage. Add a failing fixture to prove it fires, and assert the search found enough matches to avoid vacuous passes.