feat(lint): add vale-run skill

Covers invoking the vale CLI and interpreting its output — output
formats, severity filtering, exit-code handling, and false-positive
triage — for an already-configured project.
This commit is contained in:
2026-07-23 19:12:25 +00:00
parent e4abe23560
commit cb2257d5d4
4 changed files with 171 additions and 0 deletions

View File

@@ -0,0 +1,23 @@
# vale-run
Run Vale (a prose/style linter) against an already-configured project and interpret its results.
## What it does
This skill covers invoking the `vale` CLI against files or directories, choosing an output format (human-readable CLI, `line`, or machine-parseable `JSON`), filtering by severity via `--minAlertLevel`, and handling exit codes in scripts and CI. It also covers resolving common runtime issues: false positives, format-specific inline suppression, and CI failures caused solely by Vale's non-zero exit code. It assumes the project already has a working `.vale.ini` and installed styles — setting those up is the sibling `vale-config` skill's job.
## Usage
```
/vale-run
```
Describe what you want to lint and how (human-readable output, CI/JSON output, filtered by severity). The skill will pick the right flags and, if results include false positives, walk through the narrowest applicable fix.
## Files
| File | Purpose |
|------|---------|
| `SKILL.md` | Core invocation, key flags, output format guidance, false-positive triage order |
| `references/troubleshooting.md` | Inline suppression syntax, rule-specific disabling, spelling ignore lists, pre-commit integration, CI edge cases |
| `references/sources.md` | Research provenance |

View File

@@ -0,0 +1,61 @@
---
name: vale-run
description: >
Use when running Vale (a prose/style linter) against files or directories in an
already-configured project — one that already has a .vale.ini — and interpreting
or reporting its results: choosing an output format for humans vs. CI, filtering
by severity, handling Vale's exit codes in scripts, or resolving common runtime
issues like false positives and unexpected CI failures. Use even if the user
doesn't say "vale" explicitly, e.g. "lint the docs", "check prose style", "run
the style linter", "why is CI failing on the docs check". Do not use when the
project has no .vale.ini yet, or needs styles installed/configured — that's the
vale-config skill.
metadata:
version: "0.1.0"
category: linting
source_keys:
- context7-websites-vale-sh
---
## Gotchas
- Vale exits non-zero whenever it finds an alert at or above `MinAlertLevel` — that's what makes it usable as a CI gate, not a sign the invocation failed. Read the output before concluding the command errored.
- `vale ls-config` prints the fully-resolved, currently active configuration as JSON — the fastest way to check why a rule "isn't applying" is what's actually active, not what's written in `.vale.ini`.
- Inline suppression syntax is format-specific: Markdown/MDX uses `{/* vale off */}` / `{/* vale on */}`, Org mode uses `# vale off` / `# vale on`. Don't assume one syntax works across formats.
## Running vale
Default invocation:
```bash
vale <path-or-glob>
```
Key flags:
| Flag | Purpose |
|---|---|
| `--output=<style>` | Output format/template: `CLI` (default, human-readable), `line` (compact, one alert per line, good for grep/piping), `JSON` (for programmatic parsing), or a custom template. |
| `--minAlertLevel=<suggestion\|warning\|error>` | Overrides `MinAlertLevel` from `.vale.ini` for this run only, without editing config. |
| `--no-exit` | Forces exit code `0` regardless of findings. Use in CI stages that should surface lint output without hard-failing the build. |
| `--ignore-syntax` | Treats input as plain text, skipping format-aware parsing — use when a file's syntax-aware parser produces noisy or wrong results. |
`vale sync` downloads the packages/styles declared in `.vale.ini` — that's a one-time-per-change setup step (vale-config's territory), not part of a normal lint run. If a run behaves as though no styles are active, that's a sign `vale sync` hasn't been run yet, not a `vale-run` problem.
Prefer `--output=JSON` whenever the caller (a script, a CI step, another agent) needs to act on individual alerts rather than just get a pass/fail signal — `CLI` and `line` are for humans reading the terminal.
## Fixing false positives
Scope the fix as narrowly as possible, in this order:
1. **One-off**: inline-suppress the specific text run with the format's `vale off`/`vale on` markup.
2. **Recurring known-exception string, one rule**: disable that specific rule for that specific match inline (e.g. `{/* vale Style.Redundancy["ACT test","OTHER"] = NO */}` ... `= YES`), rather than the whole rule.
3. **Known project term failing spell check**: add it to the style's `ignore` list, not an inline suppression.
Never disable a rule project-wide to fix one false positive — editing `.vale.ini`/`BasedOnStyles` is vale-config's job, and it silences the rule everywhere, not just the false-positive case.
If output looks wrong because Vale mis-parsed a file's format, rerun with `--ignore-syntax` before assuming the rule itself is broken.
For CI that fails solely because Vale returned non-zero on found alerts — not because the content is wrong for that pipeline stage — add `--no-exit` rather than disabling the rule.
If setting up Vale as a pre-commit hook or need the full inline-suppression/spelling-ignore syntax reference, read `references/troubleshooting.md`.

View File

@@ -0,0 +1,9 @@
# Sources
## context7-websites-vale-sh
- **URL:** context7:/websites/vale_sh
- **Description:** Official Vale documentation site (vale.sh) indexed by Context7 — `.vale.ini` config reference, style/rule/check model, CLI commands and flags, installation across package managers and Docker, format-specific inline disable syntax, pre-commit integration, spelling ignore lists.
- **Research doc:** plugins/lint/docs/research/docs/vale/sources.md
- **Contributing files:** SKILL.md, references/troubleshooting.md
- **Status:** `extracted`

View File

@@ -0,0 +1,78 @@
---
source_keys:
- context7-websites-vale-sh
---
# Vale troubleshooting reference
## Inline suppression syntax by format
Markdown/MDX:
```mdx
{/* vale off */}
This text will be ignored.
{/* vale on */}
```
Org mode:
```org
# vale off
This text will be ignored.
# vale on
```
## Disabling a specific rule for specific matches
Targets one rule and specific known-exception strings, then re-enables — the preferred fix for a recurring false positive on a specific term, since it keeps the rule active everywhere else:
```mdx
{/* vale Style.Redundancy["ACT test","OTHER"] = NO */}
This is some text ACT test
{/* vale Style.Redundancy["ACT test","OTHER"] = YES */}
```
## Ignoring words in spell check
The `spelling` check accepts an `ignore` list of external plain-text files, so project-specific terms don't need touching the dictionary:
```yaml
extends: spelling
message: "Did you really mean '%s'?"
level: error
ignore:
- ignore1.txt
- ignore2.txt
```
## Plain-text fallback
If a file's syntax-aware parsing produces noisy or incorrect results (an unsupported or malformed format), rerun with `--ignore-syntax` to treat it as plain text instead of relying on the format-specific parser.
## CI failing unexpectedly
If a CI job fails solely because Vale returns a non-zero exit code on found alerts — not because the content is actually wrong for that pipeline stage — add `--no-exit` rather than suppressing the rule itself. This preserves the lint output while not gating the build on it.
## pre-commit integration
Vale ships a pre-commit hook definition. A typical setup runs `vale sync` once (with `pass_filenames: false`) plus the actual lint pass with CI-appropriate flags:
```yaml
repos:
- repo: https://github.com/errata-ai/vale
rev: 16d3a7f
hooks:
- id: vale
name: vale sync
pass_filenames: false
args: [sync]
- id: vale
args: [--output=line, --minAlertLevel=error]
```
## CI output for machine parsing
```bash
$ vale --output=JSON README.md
```
Use `--output=JSON` when a CI step needs to parse results programmatically rather than read the default CLI-formatted output.