lint-and-validate

name	lint-and-validate
description	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.

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

1. Confirm the request maps to Lint and Validate and required tools are available.
2. Gather identifiers and scope (project, channel, repo, date range, etc.).
3. Follow the domain guidance below; prefer list/search before get/update when applicable.
4. Execute tool calls using schemas from the integration; never invent tool output.
5. 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

1. Lint/Fix: npm run lint or npx eslint "path" --fix
2. Types: npx tsc --noEmit
3. Security: npm audit --audit-level=high

Python

1. Linter (Ruff): ruff check "path" --fix (Fast & Modern)
2. Security (Bandit): bandit -r "path" -ll
3. Types (MyPy): mypy "path"

The Quality Loop

1. 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.

---

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:

1. What was requested and what was done.
2. Key results (tables or bullets).
3. Errors, blockers, or missing permissions.
4. 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