Lint and Validate
Purpose
Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.
This skill provides operational guidance for Lint and Validate, including tool usage patterns, workflows, and quality expectations aligned with Syncolab skill standards.
When to Use
- Use when the user needs help with Lint and Validate.
- When integrations for this domain are available and the task matches the workflows below.
When NOT to Use
- When the task is unrelated to Lint and Validate or covered by a more specific skill.
- When required integrations or credentials are unavailable.
Expected Outcome
- Correct use of domain tools with verified results (not fabricated).
- Clear summary of actions taken, data returned, and recommended next steps.
- Errors and missing permissions reported explicitly.
Inputs to Gather
- User goal, constraints, and any identifiers (URLs, IDs, project keys).
- Available tool sets and connection status.
- Relevant context from related systems before destructive writes.
Workflow
- Confirm the request maps to Lint and Validate and required tools are available.
- Gather identifiers and scope (project, channel, repo, date range, etc.).
- Follow the domain guidance below; prefer list/search before get/update when applicable.
- Execute tool calls using schemas from the integration; never invent tool output.
- Summarize results and offer logical follow-ups.
Lint and Validate Skill
MANDATORY: Run appropriate validation tools after EVERY code change. Do not finish a task until the code is error-free.
Procedures by Ecosystem
Node.js / TypeScript
- Lint/Fix:
npm run lint or npx eslint "path" --fix
- Types:
npx tsc --noEmit
- Security:
npm audit --audit-level=high
Python
- Linter (Ruff):
ruff check "path" --fix (Fast & Modern)
- Security (Bandit):
bandit -r "path" -ll
- Types (MyPy):
mypy "path"
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
| Script |
Purpose |
Command |
scripts/lint_runner.py |
Unified lint check |
python scripts/lint_runner.py <project_path> |
scripts/type_coverage.py |
Type coverage analysis |
python scripts/type_coverage.py <project_path> |
Tool Availability Rules
| Access |
Behavior |
| Full tool access |
Execute workflows, verify outputs, report errors. |
| Read-only |
Inspect and plan; provide exact commands or dispatch request for writes. |
| No integration |
State limitation; do not fabricate API results. |
Related tool sets
github
vscode
github-actions
Review / Decision / Execution Criteria
- Prefer smallest safe change; confirm destructive actions with the user.
- Use evidence from tool responses; cite IDs and links when present.
- Match integration-specific conventions (JQL, RFC3339, A1 notation, etc.).
Output Format
Report:
- What was requested and what was done.
- Key results (tables or bullets).
- Errors, blockers, or missing permissions.
- Suggested next steps.
Quality Bar
- Specific, actionable, and grounded in tool output.
- Concise unless the user asked for detail.
- Respect rate limits, pagination, and API semantics.
Safety and Boundaries
- Do not commit secrets, tokens, or PII into skills or user-visible logs.
- Do not fabricate validation, send, or write confirmations.
- Confirm destructive operations (delete, destroy, mass update) when appropriate.
Escalation / Dispatch Rules
- If the task spans multiple domains, use or suggest related skills via
relationships.skills.
- If write access is required but unavailable, dispatch or ask the user to enable tools.
References
- Legacy content migrated from
skills/old_skills.json (lint-and-validate).
skills/skill.instruction.md, skills/meta.instructions.md
1---2name: lint-and-validate3description: Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.4---56# Lint and Validate78## Purpose910Automatic quality control, linting, and static analysis procedures. Use after every code modification to ensure syntax correctness and project standards. Triggers onKeywords: lint, format, check, validate, types, static analysis.1112This skill provides operational guidance for Lint and Validate, including tool usage patterns, workflows, and quality expectations aligned with Syncolab skill standards.1314## When to Use1516- Use when the user needs help with Lint and Validate.17- When integrations for this domain are available and the task matches the workflows below.1819## When NOT to Use2021- When the task is unrelated to Lint and Validate or covered by a more specific skill.22- When required integrations or credentials are unavailable.2324## Expected Outcome2526- Correct use of domain tools with verified results (not fabricated).27- Clear summary of actions taken, data returned, and recommended next steps.28- Errors and missing permissions reported explicitly.2930## Inputs to Gather3132- User goal, constraints, and any identifiers (URLs, IDs, project keys).33- Available tool sets and connection status.34- Relevant context from related systems before destructive writes.3536## Workflow37381. Confirm the request maps to Lint and Validate and required tools are available.392. Gather identifiers and scope (project, channel, repo, date range, etc.).403. Follow the domain guidance below; prefer list/search before get/update when applicable.414. Execute tool calls using schemas from the integration; never invent tool output.425. Summarize results and offer logical follow-ups.4344# Lint and Validate Skill4546> **MANDATORY:** Run appropriate validation tools after EVERY code change. Do not finish a task until the code is error-free.4748### Procedures by Ecosystem4950#### Node.js / TypeScript511. **Lint/Fix:** `npm run lint` or `npx eslint "path" --fix`522. **Types:** `npx tsc --noEmit`533. **Security:** `npm audit --audit-level=high`5455#### Python561. **Linter (Ruff):** `ruff check "path" --fix` (Fast & Modern)572. **Security (Bandit):** `bandit -r "path" -ll`583. **Types (MyPy):** `mypy "path"`5960## The Quality Loop611. **Write/Edit Code**622. **Run Audit:** `npm run lint && npx tsc --noEmit`633. **Analyze Report:** Check the "FINAL AUDIT REPORT" section.644. **Fix & Repeat:** Submitting code with "FINAL AUDIT" failures is NOT allowed.6566## Error Handling67- If `lint` fails: Fix the style or syntax issues immediately.68- If `tsc` fails: Correct type mismatches before proceeding.69- If no tool is configured: Check the project root for `.eslintrc`, `tsconfig.json`, `pyproject.toml` and suggest creating one.7071---72**Strict Rule:** No code should be committed or reported as "done" without passing these checks.7374---7576## Scripts7778| Script | Purpose | Command |79|--------|---------|---------|80| `scripts/lint_runner.py` | Unified lint check | `python scripts/lint_runner.py <project_path>` |81| `scripts/type_coverage.py` | Type coverage analysis | `python scripts/type_coverage.py <project_path>` |8283## Tool Availability Rules8485| Access | Behavior |86|--------|----------|87| Full tool access | Execute workflows, verify outputs, report errors. |88| Read-only | Inspect and plan; provide exact commands or dispatch request for writes. |89| No integration | State limitation; do not fabricate API results. |9091### Related tool sets9293- `github`94- `vscode`95- `github-actions`96979899## Review / Decision / Execution Criteria100101- Prefer smallest safe change; confirm destructive actions with the user.102- Use evidence from tool responses; cite IDs and links when present.103- Match integration-specific conventions (JQL, RFC3339, A1 notation, etc.).104105## Output Format106107Report:1081091. What was requested and what was done.1102. Key results (tables or bullets).1113. Errors, blockers, or missing permissions.1124. Suggested next steps.113114## Quality Bar115116- Specific, actionable, and grounded in tool output.117- Concise unless the user asked for detail.118- Respect rate limits, pagination, and API semantics.119120## Safety and Boundaries121122- Do not commit secrets, tokens, or PII into skills or user-visible logs.123- Do not fabricate validation, send, or write confirmations.124- Confirm destructive operations (delete, destroy, mass update) when appropriate.125126## Escalation / Dispatch Rules127128- If the task spans multiple domains, use or suggest related skills via `relationships.skills`.129- If write access is required but unavailable, dispatch or ask the user to enable tools.130131## References132133- Legacy content migrated from `skills/old_skills.json` (`lint-and-validate`).134- `skills/skill.instruction.md`, `skills/meta.instructions.md`