opencues validate is the linter for your config tree. It walks every search-path layer, parses every .md, and reports what's malformed, unreachable, or a security footgun, before you find out at runtime.
What it catches
- Schema problems: malformed frontmatter, a cue with neither
match:norkeywords:, a blank with noblankKeywords, animpl:orblankScript:pointing at a file that doesn't exist. - Unreachable entries: host-compat declarations that resolve to zero hosts, meaning the entry can never run anywhere.
- Blank-specific footguns: no binding profile declared (unreachable at runtime), a
blankScriptthat isn't executable,sandbox:left unset, animpl:declaring no capabilities, orphaned secret bindings. - Empty bodies: a cue with no tip JSON and no prompt text, so the source has nothing to do.
- Endpoint problems: invalid or non-default
-endpoint:overrides.
Built for CI
Every finding is tagged with its lint-rule code from the open standard's linting rules. --json gives machine-readable output, --strict treats warnings as errors, and the exit code is 0 on success and 1 on errors (or warnings under --strict), so wiring it into a pipeline is one line. A team shipping project-level cues in a repo can gate merges on it. And because it walks every layer, it also catches problems in a project's .cues/ that you'd otherwise only hit when next working inside that project.
When to reach for it
After editing any CUE.md or BLANK.md (the project's FAQ recommends opencues validate --project right after scaffolding), and before publishing a config pack for others. Its static analysis is also the first pass of opencues review, the security review that runs before a third-party pack is installed.
Related: Write your own cue · Write your own blank · The open standard · opencues list · GitHub repo