schema

npx @elizon/cli schema [--json]

Prints the schema of elizon.yaml for the exact CLI version you ran. It needs no project, no manifest, no account and no network, so it works in an empty folder as a quick lookup.

• Without --json: a readable outline. Required fields are marked *, every field shows its type and allowed values, and rules that span fields are spelled out under the field they apply to.
• With --json: the schema as JSON Schema (draft-07) in the document's data. Editors and coding agents can read it directly.

ELIZON Package manifest (elizon.yaml)
manifest apiVersion elizon.ai/v1 · @elizon/cli 0.5.0

apiVersion*: string = "elizon.ai/v1"
kind*: string = "Package"
metadata*: object
  name*: string (matching /^[a-z0-9]+(?:-[a-z0-9]+)*$/)
  namespace*: string
  version*: string (matching /…semver…/)
  …
A field marked * is required. Anything not listed is rejected.

Always take field shapes from here

The schema is generated from the same definition validate checks against, so it's never out of date for the version you're running. That's why neither the starters nor the coding-agent files init writes list manifest fields. They point here instead, because a copied field list is correct the day it's written and silently wrong after the next release.

What JSON Schema can't express

A few rules can't be written in JSON Schema: a value that's only whitespace, IANA time-zone names, the retention vocabulary, case-insensitive uniqueness, and every rule that spans two fields (for example, a Slot's regions must appear in compliance.regions). None of these is dropped silently:

• each one is stated in the description of the field it applies to, and
• all of them are listed at the root under x-elizon.constraintsNotExpressibleInJsonSchema.

A manifest can therefore pass JSON Schema validation in your editor and still fail validate. validate is the authority.

schema takes no arguments; the output always covers the whole manifest. For a field-by-field explanation, see The manifest.