lint-and-validate
sickn33/agentic-awesome-skills
Run lint and type checks, distinguish failures from unrun checks, and report concrete validation results.
What is lint-and-validate?
Executes configured lint and type-checking commands in a repository, carefully distinguishing between actual failures and checks that could not run. Use this after making code or configuration changes to validate against the project's own linting and type standards.
- Identifies changed languages and configured lint/type-check commands before execution
- Runs project-declared scripts (npm run lint, npm run typecheck, ruff check, mypy) without silent package fetching
- Distinguishes between check failures, missing tools, and successful validation
- Reports exact commands, exit codes, scope, and remaining limitations
- Includes bundled helpers: lint_runner.py for conservative check discovery and type_coverage.py for annotation inventory
How to install lint-and-validate
npx skills add https://github.com/sickn33/agentic-awesome-skills --skill lint-and-validate- Repository with configured lint or type-check scripts (package.json scripts, pyproject.toml, or similar)
- Relevant tools already installed locally (TypeScript, ruff, mypy, etc.)
- Read access to project configuration and scripts
How to use lint-and-validate
- 1.Inspect the repository's package.json or build configuration to identify available lint/type-check commands
- 2.Run the project's declared scripts (e.g., npm run lint, npm run typecheck) to execute configured checks
- 3.For Python projects, use installed tools like ruff check . or mypy . based on project configuration
- 4.Review the reported results, exit codes, and any limitations noted by the skill
- 5.Fix relevant failures without modifying rules, deleting work, or weakening validation standards
Use cases
- Validate TypeScript changes by running npm lint and typecheck scripts after behavior modifications
- Check Python code quality using configured ruff or mypy tools before committing
- Verify that required linting tools are installed locally rather than silently downloading them
- Generate a type-coverage inventory across a codebase to identify untyped regions
- Confirm lint passes before completing a task while reporting which checks actually ran
- Backend and frontend developers validating code changes
- Teams enforcing lint and type standards in CI/CD workflows
- Developers working in monorepos or complex project structures
- Anyone needing to distinguish between "check failed" and "check did not run"
lint-and-validate FAQ
No. It runs read-only lint and type checks by default. It will not add --fix flags or modify files without explicit authorization and inspection of proposed changes.
The skill reports the exact check that did not run rather than silently downloading a package. You must install the tool locally first or update the project configuration.
No. Passing lint and type checks does not guarantee the absence of runtime errors, security defects, or logic bugs. It validates against the project's configured standards only.
It can run checks in a given project directory, but it does not automatically detect every monorepo configuration. Inspect the project structure and scripts first.
lint_runner.py discovers and runs candidate checks (exit 0 for pass, 1 for failure, 2 for no checks found). type_coverage.py is a read-only annotation inventory that samples files and reports untyped regions without a pass/fail verdict.
Full instructions (SKILL.md)
Source of truth, from sickn33/agentic-awesome-skills.
name: lint-and-validate description: "Run configured lint and type checks, distinguish failures from checks that did not run, and report concrete validation results." risk: critical source: community date_added: "2026-02-27"
Lint and Validate
When to Use
Use after behavior or configuration changes when a repository has relevant lint or type checks. Read the repository's instructions and package scripts first. Run focused checks during development and the required checks before completion.
Procedure
- Identify the changed languages, configured commands, and installed tools. Inspect package scripts before executing them: a script named
lintcan modify files or run arbitrary project code. - Run the project's read-only lint/type-check commands. For Node projects, prefer declared scripts such as
npm run lintandnpm run typecheck. Do not usenpxto silently fetch an absent checker. - For Python, use configured, already installed tools such as
ruff check .ormypy .. Do not assume everypyproject.tomlconfigures both. Never add--fixwithout inspecting the proposed changes and the task's authorization. - Fix relevant failures without deleting user work, weakening rules, or raising timeouts just to pass. If a required tool is unavailable, report the exact check that did not run.
- Report commands, exit results, scope and remaining limitations. Passing lint does not prove the absence of runtime or security defects.
Example
After correcting a TypeScript behavior, inspect package.json, run the configured focused regression test, then npm run lint and npm run typecheck if those scripts exist. If TypeScript is declared but not installed, report the missing local checker; do not substitute a downloaded package or call the result a pass.
Bundled helpers
python scripts/lint_runner.py /absolute/project: runs a conservative set of candidate checks. Node fallback checkers must exist in localnode_modules/.bin; Python candidates must be installed. Inspect the project scripts first. A missing command or failing check exits 1; no configured checks or invalid project metadata exits 2. Exit 0 means the invoked checks passed, not that every needed check was discovered. Python detection is heuristic and may suggest unconfigured Ruff/MyPy commands.python scripts/type_coverage.py /absolute/project: read-only annotation inventory, despite its retained compatibility filename. Samples at most 30 files per language, skips links and build/dependency directories, and bounds file reads. Python uses AST nodes to avoid double-counting functions. TypeScript reports lexical: anyoccurrences, including possible comments and strings. No quality percentage or pass/fail threshold is inferred. Exit 2 means no applicable files; parse/read errors exit 1.
Limitations
The runner executes trusted project commands, which may mutate files or access the network. It does not install dependencies, detect every monorepo configuration, or replace the project's CI contract. The inventory is a bounded source sample, not semantic type coverage; inferred types, generics, decorator behavior and correctness require the actual type checker. Do not label unrun checks as successful.
Related skills
More from sickn33/agentic-awesome-skills and the wider catalog.

micro-saas-launcher
Launch profitable micro-SaaS products in weeks using indie hacker strategies and proven frameworks.

mobile-design
Mobile-first design system preventing desktop-thinking and unsafe assumptions in app development.

multi-agent-brainstorming
Structured peer-review process using multiple specialized agents to validate designs and surface hidden assumptions before implementation.

nestjs-expert
Expert Nest.js architecture guidance for enterprise Node.js applications with DI, testing, and auth patterns.

nextjs-best-practices
Next.js App Router principles: Server Components, data fetching, routing patterns.

nextjs-supabase-auth
Expert integration of Supabase Auth with Next.js App Router