Mk lint and validate

Skill ngocsangyem/MeowKit/packages/mewkit/src/migrate/modules/cursor/root/.cursor/skills/mk-lint-and-validate

Production ready. AI Agent Workflow System for Claude Code

Install

npx -y skills add ngocsangyem/MeowKit --skill mk-lint-and-validate

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

15 stars15 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Linting and static analysis after code edits. Triggers on lint, format, check, validate, types. NOT for full build verification (mk:verify) or test coverage (mk:testing).

SKILL.md

3.2 KB, 717 tokens by cl100k_base, as published. Nobody here has run it

Lint and Validate Skill

MANDATORY: Run appropriate validation tools after EVERY code change. Do not finish a task until the code is error-free.

For the full pipeline (build → lint → type-check → tests → coverage), use mk:verify. mk:lint-and-validate is a lint-only subset intended for post-edit quick checks.

Procedures by Ecosystem

See references/linter-commands.md for full command reference per ecosystem (Node.js/TS, Python) and Shared validation scripts.

The Quality Loop

Write/Edit Code
Run Audit: npm run lint && npx tsc --noEmit
Analyze Report: Check the "FINAL AUDIT REPORT" section.
Fix & Repeat: Submitting code with "FINAL AUDIT" failures is NOT allowed.

Error Handling

If lint fails: Fix the style or syntax issues immediately.
If tsc fails: Correct type mismatches before proceeding.
If no tool is configured: Check the project root for .eslintrc, tsconfig.json, pyproject.toml and suggest creating one.

Strict Rule: No code should be committed or reported as "done" without passing these checks.

Scripts

See references/linter-commands.md for full command tables and Shared validation scripts.

Gotchas

ESLint flat config (eslint.config.mjs) and legacy .eslintrc are mutually exclusive — ESLint 9 auto-detects the flat config format and ignores any .eslintrc.* files in the same directory; if the project has both, the flat config silently wins and all legacy extends rules are dropped without error, making it look like rules pass when they were never loaded.
eslint --fix run on unstaged files destroys uncommitted work — --fix writes changes directly to disk without prompting; if run on a file with uncommitted edits, ESLint's changes overwrite the working tree diff; always stage changes with git add -p before running --fix, or use --fix-dry-run to preview.
TypeScript ESLint parser version must match the installed typescript version — @typescript-eslint/parser pins against specific TypeScript minor versions; a TypeScript upgrade (e.g., 5.3 → 5.5) without bumping @typescript-eslint/parser causes Unexpected token parse errors on new syntax even though tsc accepts it fine.
extends order determines rule precedence and later entries win — in legacy .eslintrc, extends: ['plugin:vue/recommended', 'prettier'] works (prettier overrides vue formatting), but reversing to ['prettier', 'plugin:vue/recommended'] re-enables vue formatting rules that conflict with prettier, producing unfixable lint errors on every save.
Prettier and ESLint format rules conflict when both run on the same file — eslint --fix applying quotes: 'single' then prettier reformatting to double quotes creates an infinite fix loop in editor save hooks; disable all formatting rules in ESLint (eslint-config-prettier) and let Prettier own formatting exclusively.