FAQ

Home > FAQs > opencues validate

What is opencues validate?

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: nor keywords:, a blank with no blankKeywords, an impl: or blankScript: 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 blankScript that isn't executable, sandbox: left unset, an impl: 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