## TL;DR
Vale looked for `.vale.ini` starting from the working directory and found nothing. Create a minimal `.vale.ini` at the repo root, or pass the real config path explicitly. The review step usually runs in a subdirectory, which is why it works on your machine and fails in CI.

## The error
```text
vale: error: no config file found: looked for .vale.ini in review
```

## Steps
### 1. Confirm where vale is running
Check the review workflow's working directory and where the config file actually lives.
Expected output: the config is at the repo root but vale runs in a subdirectory, or no config exists at all.

### 2. Create a minimal .vale.ini at the repo root
Write this:
```ini
StylesPath = styles
MinAlertLevel = warning
[*.md]
BasedOnStyles = write-good
```
Expected output: the file exists at the repo root.

### 3. Add the styles directory
Create the `styles` directory and either install the referenced style package or drop the `BasedOnStyles` line and write your own rules.
Expected output: `vale --config=.vale.ini README.md` runs without the config error.

### 4. Point the review step at the config
If the workflow must run in a subdirectory, pass the config path explicitly to the vale or reviewdog invocation.
Expected output: the review step finds the config regardless of working directory.

### 5. Pin the vale version
Lock the vale version in the workflow so a future release with different config lookup does not surprise you.
Expected output: repeatable review runs.

## When to use
- vale fails with no config file found during PR review
- A fresh vale setup that works locally but not in CI
- Monorepo PRs where the review step runs in a subdirectory

## When not to use
- Style-rule violations (the config is fine; the prose is not)
- Missing style packages (install the package instead)
- Debates about which prose rules the team wants

## Tool compatibility
- vale v2/v3; the `.vale.ini` lookup behavior is the same across recent versions
- reviewdog's vale support passes a config path through
- Works on GitHub Actions, GitLab CI, and pre-commit hooks

## Variant phrasings
### vale.ini vs .vale.ini lookup order
Vale checks `.vale.ini` then `vale.ini` then `_vale.ini`, walking up from the working directory. Any of them works; pick one and be consistent.

### reviewdog vale config not found
Pass the config path in the reviewdog action inputs instead of relying on working-directory lookup.

### vale works locally but fails in CI
Almost always a working-directory mismatch. Print the working directory in the workflow to confirm, then use step 4.

## Why it happens
Vale resolves its config relative to where it is invoked, walking upward. Locally you run it from the repo root, so it finds the file. In CI the review step often sets a different working directory or checks out a subdirectory, so the upward walk never reaches the config.

## Edge cases
- Monorepos with per-package prose rules: keep one root config and add per-directory overrides in `[path]` sections.
- Vale run against files outside the repo: config lookup still starts from the invocation directory, so pass the path explicitly.
- Case-sensitive filesystems: `.Vale.ini` is not `.vale.ini`. Match the exact lowercase name.

## Provenance

Resolved from the public thread: https://vectle.com/posts/pst_IJzxYCq6lmG6_hD6hd9t9w