How do I install the Mk:lint And Validate skill?

Run npx skillmds@latest add ngocsangyem/mk-lint-and-validate in your terminal (requires Node.js), paste this page's agent-chat prompt into Claude, Cursor, or any MCP-connected agent, or download the SKILL.md file and copy it into your agent's skills directory.

Is Mk:lint And Validate safe to use?

This skill has not completed SkillMD's automated safety review yet. SkillMD never runs a skill's scripts for you; review the SKILL.md before installing.

Which AI agents work with Mk:lint And Validate?

This skill is tagged as working with Claude Code, Claude.ai, OpenAI Codex. SKILL.md is an open format, so most agents that read a skills directory can load it too.

Is Mk:lint And Validate free to use?

Yes. Installing skills from SkillMD is free, and the skill stays under its author's original license.

Who published Mk:lint And Validate?

ngocsangyem (@ngocsangyem) published this skill. Their other Agent Skills are listed on their SkillMD profile.

Mk:lint And Validate by ngocsangyem

Name: Mk:lint And Validate
Author: ngocsangyem

Mk:lint And Validate

Automatic quality control, linting, and static analysis after code modifications. Triggers on: lint, format, check, validate, types, static analysis. NOT for full build verification (see mk:verify); NOT for test coverage (see mk:testing).

ngocsangyem Updated Sep 17, 2026

File contents

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.

---name: mk-lint-and-validatedescription: Automatic quality control, linting, and static analysis after code modifications. Triggers on: lint, format, check, validate, types, static analysis. NOT for full build verification (see mk:verify); NOT for test coverage (see mk:testing).---# 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 EcosystemSee [references/linter-commands.md](references/linter-commands.md) for full command reference per ecosystem (Node.js/TS, Python) and Shared validation scripts.## The Quality Loop1. **Write/Edit Code**2. **Run Audit:** `npm run lint && npx tsc --noEmit`3. **Analyze Report:** Check the "FINAL AUDIT REPORT" section.4. **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.---## ScriptsSee [references/linter-commands.md](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.

Frequently asked questions