Frontend linter manager

Skill ytvee-dev/webdev-agent-kit/skills/frontend-linter-manager

A cross-platform frontend kit for Codex, Claude Code, Cursor, OpenCode, etc. It helps AI coding agents work predictably and safely with existing frontend projects.

Install

npx -y skills add ytvee-dev/webdev-agent-kit --skill frontend-linter-manager

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

5 stars5 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

Run scoped frontend lint verification, repair related lint failures, or plan explicitly requested lint setup. Prefer existing commands; dependencies, scripts, and config changes require approval.

SKILL.md

6.3 KB, as published. Nobody here has run it

Frontend Linter Manager

Purpose

Run or plan lint verification for frontend code changes, repair related lint failures within a bounded loop, and manage user-requested lint setup safely.

When To Use

Use this skill after any code-changing fix, feature, refactor, implementation slice, or approved greenfield code creation.

Use it before code changes only when the user explicitly asks to add or repair lint setup.

When Not To Use

Do not use this skill for planning-only, design-only, documentation-only, README-only, or analysis-only tasks. Do not treat lint setup as a testing workflow.

Required Context

Read AGENTS.md.
Read package scripts or project/verification-profile.md to find existing lint commands.
Read common/lint-verification-rules.md and common/windows-shell-sandbox-rules.md before rerunning a command that failed because of Windows shell policy or sandbox access.
Read common/verification-loop-rules.md and common/bounded-retry-rules.md when lint repair is in scope.
Read only files needed to understand the package manager or workspace boundary.

Tool Contract

May run an existing lint command after code changes.
May inspect package scripts and workspace files.
May use one equivalent .cmd package-manager fallback on Windows after a PowerShell .ps1 execution-policy block.
May update project/verification-profile.md when durable lint command facts are useful.
May fix lint failures related to the current change when safe and in scope.
Must not add packages, scripts, or config files without explicit user approval.
Must not change PowerShell execution policy.
Must not repeat the same shell-blocked command after an equivalent fallback exists.
Must not create tests or testing workflows.
Must not introduce UI component libraries.

Workflow

Detect the smallest relevant existing lint command.
Run that command after the code change.
If the command is blocked by Windows PowerShell .ps1 policy, retry once with the equivalent .cmd package-manager command when available.
If lint passes, record command and result.
If lint fails, classify failures as related, likely pre-existing, unrelated environment issue, shell-blocked, sandbox-blocked, or unknown.
If lint fails because of the current change, fix it when safe and in scope.
Rerun the same lint command after related fixes.
Use bounded retry rules when multiple related lint repair attempts are needed.
Do not switch to an easier command just to claim success.
Do not keep rerunning lint after the same shell or sandbox blocker repeats; report the blocker and verification impact.
Report lint command, fallback command when used, result, attempt count, and unresolved lint issues.
If no lint command exists, report that lint was not run.
If the user asks for lint setup, propose a setup plan first and wait for approval.

User-Provided ESLint Model

When the user asks to add the provided lint rules, use the uploaded flat ESLint model as the preferred source pattern.

The model includes TypeScript type-checked rules, React rules, React Hooks rules, JSX accessibility rules, SonarJS rules, Prettier compatibility, ignore rules, optional strict presets, and a format-lint-fix helper.

Adapt the model to the host project after inspecting the existing package manager, framework, TypeScript usage, React usage, formatter or linter config, workspace layout, and scripts.

Output Contract

Final response: return only facts that affect the user's understanding, confidence, or next action. Omit empty fields and workflow narration.

Lint command run:
Lint result:
Fallback command:
Attempts:
Related failures fixed:
Unresolved lint issues:
Blocked checks:

If lint was not run, include the reason and impact.

Validation Gates

Lint was run for code-changing work when a command exists.
Lint status is reported honestly.
Windows shell-policy failures use at most one equivalent .cmd fallback.
Shell and sandbox blockers are not reported as project code failures.
Related lint repairs use bounded retry rules.
Unrelated or pre-existing failures are not silently claimed as fixed.
No dependency, script, execution-policy, or config change happened without approval.
No testing workflow was introduced.
No UI component library was introduced.

Trigger Evals

Should trigger:

"Run the existing lint command after this frontend change."
"Repair only lint failures caused by the current patch."
"On Windows, npm run lint failed because npm.ps1 is blocked. Verify with the correct fallback and report honestly."

Should not trigger:

"Add a new testing framework."
"Explain this lint rule without running verification."

Reference Map

AGENTS.md - canonical policy and routing.
common/lint-verification-rules.md - lint command and reporting rules.
common/windows-shell-sandbox-rules.md - Windows PowerShell and sandbox blocker handling.
common/verification-loop-rules.md - verification classification and rerun rules.
common/bounded-retry-rules.md - bounded repair loop rules.
project/verification-profile.md - local-only verification commands.
user-provided ESLint model - preferred setup pattern when setup is explicitly requested.