The CLI

One command line, graview, and every subcommand lives in the package whose concern it is: the generator and the checker in @graview/core, serve in @graview/ship, skills in @graview/skills. None of them needs a browser.

graview check <entry> [--views <module>] [--json]

Loads <entry> (a module whose default export, or app export, is a GraviewApp) and reports schema problems. Exits 1 on any error.

graview create <dir> [--name "Field Notes"] [--kind note] [--plural notes]

      --name <text>      the product's name (default: from <dir>)
      --kind <slug>      the first node kind (default: item)
      --plural <slug>    its plural (default: <kind>s)
      --link <path>      consume the framework from a sibling checkout by
                         path rather than from a registry
      --pm pnpm|npm      the package manager (default: whichever ran this)
      --port <n>         the dev server port (default: 5170)
      --accent <#hex>    the brand accent (default: a worked green)
      --no-install       write the files and stop
      --no-skills        do not install the authoring skills
      --no-git           do not initialise a git repository
      --workspace        the layout every real product ends up with: a
                         workspace root with the app under app/ and the
                         harness scripts at the root
      --merge            write only the files that do not exist yet, and
                         name every collision without touching it
      --force            write into a directory that is not empty

Starts a product on Graview in <dir>: the declaration split into domain and UI, an eighty-line shell, a headless test, a CI workflow.

graview describe <entry> [--as <role>] [--views <module>]

Reads the app out: what a blank installation meets and in what order, what is drawn and what falls back, the hues, what a seat may do, how a model is reached, what is judged. The rung between check and a browser — "run it and look" for something that cannot see.

graview docs <entry> [--out <dir>] [--views <module>]

Writes llms.txt and agents.md next to the entry, or into <dir>.

graview figure <entry> --kind <kind> [--name <shipped>]

[--from "<what the thing is>"] [--judge <file|->] Prints the figure line to paste into defineNode. With --name it is one of the shipped drawings; with neither, it suggests the nearest one by name and says so. --from prints the brief to hand a model — the rules, the angle and a shipped figure as the style — and --judge reads the answer back, holds it to the rules graview check holds a figure to, and prints the line. Nine shipped figures is a vocabulary to start from, not a vocabulary to finish in.

graview lens <name> --roles a,b,c [--binds fields|entities] [--dir <dir>]

Writes a lens that compiles: the role check that fails loudly, the createXLens factory, three fidelities, pick targets — and beside it a REUSE TEST in a domain the app is not about, red until you make the claim true. If you cannot make it pass, you wrote a view, and a view is a legitimate thing to have written.

graview serve <entry> [--data <dir>] [--port <n>] [--seed <file>] [--sqlite <file>]

Serves the app's store over HTTP. The op log is the wire: a client sends calls, the store judges them under the caller's own seat, and the ops come back. Data lives in <dir> (default ./data) as readable JSON, or in a SQLite file with --sqlite.

graview skills install [dir]   copy the skills into ${SKILL_DESTINATIONS.join(" and ")}
graview skills list            what is in this package
graview skills path            where the skill files live

Copies the authoring skills into .claude/skills and .agents/skills, where Claude Code and Codex look for them; list says what ships and path says where the files live. graview create runs the install for you.

graview sync-seed <entry> --seed <file> [--data <dir> | --sqlite <file>]

[--apply] [--prune] [--json] Diffs the bootstrap seed against the live store and says, as content steps, what would bring the store in step with it: records put, fields patched, ties made. Prints and exits by default; --apply lands the steps as one logged, undoable operation; --prune also drops what the seed no longer has. The seed itself is only ever read at first install — this is how default content moves afterwards, in place of deleting the store.