From lint-and-fix
Detect available linters and formatters in the project, run them with auto-fix flags, report results, manually resolve remaining issues, then commit and push the fixes. Use when the user says "lint and fix", "run the linter", "run linters", "fix lint errors", "format the code", "lint this project", "check and fix", "run eslint", "run prettier", or any variant involving running project linters or formatters.
How this skill is triggered — by the user, by Claude, or both
Slash command
/lint-and-fix:lint-and-fixThe summary Claude sees in its skill listing — used to decide when to auto-load this skill
Detect project linters and formatters, run them with auto-fix, and resolve remaining issues.
Detect project linters and formatters, run them with auto-fix, and resolve remaining issues.
The user may provide these options inline:
--tool eslint, --tool prettier)When another skill invokes lint-and-fix, that parent skill may provide an explicit continuation block immediately after the command:
Parent continuation:
- Caller: <parent skill name>
- Resume target: <parent workflow step to resume>
- On lint success: <what the parent must do next>
- On lint failure or skipped required lint work: <what the parent must do next>
Honor this block as part of the lint-and-fix invocation.
--no-push means "commit fixes, but leave push to the caller or user." It is not a terminal stop when a parent continuation block is supplied.On lint success.On lint failure or skipped required lint work.Final output for a parent invocation must include:
Lint status: <success|no-tools|failure>
Commit: <none|commit SHA>
Unresolved or skipped: <none|summary>
Caller resume target: <target from continuation block>
Check for linter and formatter configuration in the project. Use Glob and Read to find config files and check for installed tools. Run detection checks in parallel where possible.
| Config file(s) | Tool | Fix command | Check command |
|---|---|---|---|
eslint.config.*, .eslintrc.* | eslint | npx eslint --fix . | npx eslint . |
.prettierrc*, prettier.config.* | prettier | npx prettier --write . | npx prettier --check . |
.markdownlint.json, .markdownlint.jsonc, .markdownlint.yaml | markdownlint | npx markdownlint-cli2 --fix "**/*.md" | npx markdownlint-cli2 "**/*.md" |
.markdownlint-cli2.* | markdownlint-cli2 | npx markdownlint-cli2 --fix "**/*.md" | npx markdownlint-cli2 "**/*.md" |
| Shell scripts in project | shellcheck | (no auto-fix) | shellcheck <files> |
| Shell scripts in project | shfmt | shfmt -w <files> | shfmt -d <files> |
knip.json, knip.config.*, knip.ts | knip | (no auto-fix) | npx knip |
cspell.json, cspell.jsonc, .cspell.json, .cspell.jsonc, cspell.config.* | cspell | (no auto-fix) | npx cspell --dot . |
package.json has lint script | npm lint | Try npm run lint -- --fix, fall back to npm run lint | npm run lint |
package.json has format script | npm format | npm run format | Try npm run format -- --check, fall back to npm run format |
bin/lint, scripts/lint, script/lint | Project script | Try <script> --fix first | <script> |
.github/workflows/*.yml, .github/workflows/*.yaml run: steps | CI workflow script | Run detected command | Run detected command |
package.json and check for lint, format, or check scripts.**/*.sh, bin/*, scripts/*, script/*. If shell scripts are present, shellcheck and shfmt apply.bin/lint, scripts/lint, script/lint.npx, which, or package.json devDependencies).Scan .github/workflows/*.yml and .github/workflows/*.yaml files to discover repo-specific linting and validation steps that go beyond standard tooling.
.github/workflows/*.yml and .github/workflows/*.yaml.name suggests linting, validation, or code quality (keywords: "lint", "check", "validate", "format", "style", "quality", "verify").run: commands: From matching jobs and steps, collect all run: values.uses: org/repo/.github/workflows/workflow.yml@ref (a reusable workflow call, e.g., cboone/gh-actions/.github/workflows/[email protected], cboone/gh-actions/.github/workflows/[email protected], cboone/gh-actions/.github/workflows/[email protected]), skip it entirely. Reusable workflows run in CI only and cannot be executed locally. They are not a source of locally-runnable lint commands.bin/, scripts/, script/, ./bin/, ./scripts/, or ./script/). These are repo-specific validation tools. Also keep commands that invoke standalone tools not already covered by the detection table (e.g., actionlint, taplo check).shellcheck was already detected from shell scripts in the project, do not add a duplicate entry from the CI workflow. Similarly, if bin/lint was already detected as a project lint script, skip it.bin/check and scripts/check), use the relative path as the identifier to avoid collisions. These scripts typically have no auto-fix mode, so use the same command for both fix and check.Example: A CI workflow containing these steps:
- name: Validate JSON syntax
run: bin/validate-json
- name: Validate plugin structure
run: bin/validate-plugins
Would produce two additional detected tools:
| Tool | Config | Command |
|---|---|---|
| validate-json | CI workflow (ci.yml, step 6) | bin/validate-json |
| validate-plugins | CI workflow (ci.yml, step 7) | bin/validate-plugins |
If --tool was specified, filter the detected list to only that tool. If the specified tool was not detected, report that and stop.
If no tools are detected, report that no linters or formatters were found. If a parent continuation block was supplied, report Lint status: no-tools, include the caller resume target, and allow the parent workflow to continue according to its continuation block. Otherwise stop.
Before running, display the detected tools:
## Detected Linters and Formatters
| Tool | Config | Command |
|------|--------|---------|
| eslint | eslint.config.js | npx eslint --fix . |
| prettier | .prettierrc.json | npx prettier --write . |
| shellcheck | (shell scripts found) | shellcheck bin/* |
If running in --check mode, show check commands instead of fix commands.
Run each detected tool sequentially. For each tool:
Run the fix command (or check command if --check was specified). Capture stdout, stderr, and exit code.
Tool-specific notes:
--fix, some issues auto-fix and others remain.-w, formats in place silently. With -d, shows diffs.--dot so dotfiles and dot-directories match CI spell-check behavior. Users fix typos in the source or add words to cspell.json (words array) or a project word list file. In git worktrees, --dot can expose the .git file; if that happens, add .git as well as .git/ to the project's cspell ignore paths.--fix first. If the script does not recognize --fix, run without it.For each tool, record:
After all tools run, display a summary:
## Lint and Fix Results
| Tool | Status | Fixed | Remaining |
|------|--------|-------|-----------|
| eslint | Ran with fixes | 3 files | 2 errors |
| prettier | All formatted | 5 files | 0 |
| shellcheck | Check only | — | 4 warnings |
If --check was specified, show results and stop here.
If all tools passed with zero remaining issues (auto-fix resolved everything), skip step 5 and go directly to step 6. Auto-fix commands modify files on disk even when they resolve all issues. You must still verify in step 6 and commit in step 7.
For each remaining issue that auto-fix could not resolve:
no-unused-vars), edit the code to comply.If a remaining issue is ambiguous or risky to fix automatically (e.g., removing a dependency that might be used dynamically, or a lint rule that conflicts with project intent), skip it and report:
Skipped: <file>:<line> — <rule> — <reason>
Re-run all detected tools one final time in check mode to confirm a clean state:
## Final Verification
| Tool | Status |
|------|--------|
| eslint | Pass |
| prettier | Pass |
| shellcheck | Pass (1 advisory skipped) |
After verification, always proceed to step 7. Tools that auto-fixed files will have modified files on disk that need to be committed.
This step is required unless --no-commit or --check was specified. Linters and formatters modify files on disk when they auto-fix. Those changes must be committed even if every tool now reports a clean state.
Skip this step only if:
Check for file changes and commit:
git status --porcelain and check whether its output is empty.git status --porcelain produced no output): Report "No changes needed, all files were already clean." If a parent continuation block was supplied, include the final output required by Parent Continuation Contract and allow the parent workflow to continue according to its continuation block. Otherwise stop.git status --porcelain produced any output): Stage all modified files and commit them.style: for pure formatting and linting fixes.fix: if linting changes corrected actual bugs (e.g., unused variables removed, error handling added).After committing, push to the remote:
-u to set it.npm install -D eslint).chmod +x <script>.package.json lint script and a standalone config (e.g., eslint) are detected, prefer the package.json script (it may have project-specific flags). Note the overlap to the user.mfinelli/setup-shfmt). If the tool is not locally available, report the missing tool and suggest installation. Reusable workflow calls (e.g., cboone/gh-actions/.github/workflows/[email protected], cboone/gh-actions/.github/workflows/[email protected], cboone/gh-actions/.github/workflows/[email protected]) are CI-only and should be skipped entirely.run: commands use GitHub Actions expressions (${{ }}) or environment variables only available in CI. Skip these commands and note them as CI-only.Creates, edits, and optimizes skills for Claude Code, including drafting, evaluating with test prompts, iterating on performance, and improving skill descriptions for better triggering accuracy.
npx claudepluginhub cboone/agent-harness-plugins --plugin lint-and-fix