hofstadter-io/hof: a CUE-centered code generator, data model tool and task engine
A developer experience centered on CUE. Unifies schemas, data models, deterministic and agentic code generation, workflow and task engine, dagger powered environments, coding assistant, and vscode extension; woven together on the CUE lattice. Squint harder if you can't see the cube :]
At a glance
- What is it?
- hof is a Go CLI that unifies CUE-based schemas, data models, deterministic and agentic code generation, and a workflow engine. The README pitches it as something you add to an existing workflow, and the release history shows why you should read that as alpha software.
- Who is it for?
- hof is worth adopting if your team already thinks in CUE and wants generation, data modeling and a task engine under one CLI, and if you can pin to a release and tolerate the v0.7.0 alpha line. It is the wrong tool if you need a stable generator with a semantic-versioned API, or if your team has no CUE experience and no appetite to learn it.
- Can I use it commercially?
- Yes. Apache-2.0 is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 134 days ago.
- What is it written in?
- Mainly Go, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.
DEEP OPEN-SOURCE ANALYSIS
The problem hof targets: one CLI for schemas, data and generation
Most teams doing code generation end up with three disconnected tools: a schema language for validation, a template runner for output, and a workflow runner for orchestration. hof's claim is that these can share one substrate. The README states the project is "a tool that unifies data models, schemas, code generation, and a task engine", and that it is "a CLI tool you *add* to your workflow".
The audience is narrower than that sentence suggests. hof is built on CUE, and the README is explicit: "`hof` uses CUE to power the DX and implementation." The subcommands listed in the CLI help are CUE subcommands plus extras: def, eval, export, vet, fmt and mod sit alongside gen, datamodel, flow, create, chat and tui. If you do not already write CUE, the first thing hof asks you to do is learn a language whose own documentation lives at cuelang.org and cuetorials.com, both linked from the README.
The payoff, if you accept that premise, is that a data model and the code generated from it are the same artifact viewed two ways. The README describes "data models that can evolve and be input to code generation", and the datamodel subcommand is documented as managing, diffing and migrating them. That is a real difference from a template-only generator, where the schema lives somewhere else and drifts.
How hof works: CUE values in, generated artifacts out
The mechanism visible in the repository is a pipeline. CUE files hold schemas and data. hof unifies, evaluates and exports them, then feeds the result into generators. The CLI flags describe the data flow precisely: `-d, --schema` takes an expression selecting a schema to apply to data files, `-I, --input` adds extra data to unify into the root value, `-D, --include-data` auto-includes data files found alongside CUE files, and `-l, --path` is a CUE expression for placing data files. Output goes through `hof export`, which the README describes as outputting data in a standard format.
The task engine is separate but same-shaped. The repository has a `flow/` directory described as "the source for `hof flow` and the task engine", and `flow.cue` at the top level. The README calls it an "Extensible task and DAG workflow engine" based on cue/flow, so tasks and their dependencies are themselves CUE values rather than YAML.
Two other pieces matter for how you would actually run this. The Go module file pins `cuelang.org/go v0.15.4` and pulls in `dagger.io/dagger v0.20.0`, which matches the README's mention of "dagger powered environments" and the repository's `examples/env/` directory. The repository also carries `extensions/` and a pnpm workspace, which corresponds to the VS Code extension and the `chat` interface for combining an LLM with hof code generation. The Makefile shows the project using itself: GitHub Actions workflows are generated by running `hof export --out yaml` over `ci/gha/*.cue`, and the devcontainer config is exported from `ci/devc/devcontainer.cue`.
Installing hof and running a first export
The README says the preferred installation method is the downloads on the GitHub releases page. Homebrew is offered as an alternative, and the README also gives a self-update path if you already have the binary.
brew install hofstadter-io/tap/hofAfter installing, the README suggests enabling shell completions and then verifying the binary. The completion line is written for bash; the README notes bash, zsh, fish and power-shell are supported, so substitute your shell's name.
echo ". <(hof completion bash)" >> $HOME/.profile
source $HOME/.profile
hof --help
hof version`hof version` prints detailed version information, which is the check that matters given the alpha releases. If you already have hof and want to move to a specific tag, the README gives `hof update --version vX.Y.Z`.
For a first real use, the smallest thing the CLI exposes is evaluation and export of CUE. With a CUE file in the current directory, `hof eval` evaluates and prints configuration, and `hof export` writes data in a standard format. The README does not print a worked example of either, so the honest next step is the getting-started and walkthrough sections at docs.hofstadter.io, which the README points to for a tour and for building a generator. There is also a terminal interface: `hof tui` is described as a terminal-based interface with a built-in help system and documentation, and the README links a YouTube tour for it. If you prefer exploring to reading flags, start there.
Where hof is the wrong tool, and what the release line tells you
The most concrete limitation is versioning. The recent releases list shows v0.7.0-alpha.1 on 2026-01-02, v0.7.0-alpha.2 on 2026-01-17, and before that v0.6.10 on 2024-12-31. That is a gap of more than a year between the last stable release and the alpha line, and the alpha notes themselves say "stabilizing new features" and "new features and future conversion". If you need a generator whose interface you can hold fixed across a two-year project, the stable line is v0.6.10 and the interesting work is in alphas. The last push to the repository was on 2026-05-05, so the project is being worked on, but the release cadence is not a stability guarantee.
The second limitation is CUE itself. Everything in hof is expressed in CUE, including workflows. That is coherent, and it is also a hard dependency on a language with a smaller hiring pool and a different mental model from YAML or JSON Schema. A team that wants a generator with a Jinja-style template language and a JSON Schema input will find hof's model heavier than the problem.
Third, the README's own framing is a warning about scope. "A tool that unifies data models, schemas, code generation, and a task engine" plus agent servers, a coding assistant, a VS Code extension and dagger environments is a lot of surface for one binary. The docs site, not the README, is where the detail lives, and the README defers to it repeatedly. Treat any feature you have not seen documented at docs.hofstadter.io as unverified, including rollback behaviour for `hof datamodel` migrations, which the README does not document.
hof against a plain template generator
The nearest alternative in practice is a template-first generator that takes a schema or a data file and renders files, with no schema language of its own and no task engine. The difference is where the source of truth sits. In a template-first tool the schema is an input, often JSON Schema or a language's own type definitions, and the generator is the only thing that understands it. In hof the schema is CUE, and CUE is also the language of the data, the tasks and the module dependencies. `hof vet` validates data with CUE, `hof def` prints consolidated CUE definitions, and `hof mod` manages CUE module dependencies. Generation is one consumer of that value, not the centre of the system.
That reordering has a cost and a benefit. The cost is that you cannot adopt hof incrementally without adopting CUE; there is no mode where you point it at a JSON Schema and get files out. The benefit is that validation, generation and workflow share one evaluation model, so a change to a schema propagates to everything that reads it rather than to the one template that happened to reference it.
A second comparison is a general workflow engine. hof's flow is a DAG engine, and the README calls it extensible, but the tasks are CUE. A team already running a general-purpose orchestrator has little reason to move task definitions into a CUE file unless they want generation and orchestration to share inputs, which is exactly the case hof is built for.
Maintenance, licence and the upgrade path
The repository is not archived, and the last push was on 2026-05-05. Releases are tagged on GitHub and the README points to the releases page as the preferred download source, so the upgrade path is explicit: download a tag, or run `hof update --version vX.Y.Z` from an existing install. That self-update command is the one piece of maintenance tooling the README documents by name.
Upgrade cost is dominated by the CUE dependency. The Go module pins `cuelang.org/go v0.15.4` and `dagger.io/dagger v0.20.0`, so a hof upgrade can move both the CUE language version and the dagger engine underneath you. Because generators, data models and workflows are all CUE, a CUE language change is not confined to one part of your setup. The Makefile's `cuefmt` target shows the project running `cue fmt` over its own CUE files, which is a reasonable habit to copy: formatting your CUE before an upgrade makes the diff readable.
On licensing, the README states the project is licensed under the Apache 2.0 License and points to the LICENSE file, and the repository metadata agrees. Apache 2.0 is permissive and includes an explicit patent grant. One detail worth noticing rather than acting on: the `package.json` at the repository root declares `"license": "ISC"` for the JavaScript workspace that builds the VS Code extension. That is a difference between the Go project and its JS tooling, and if the extension matters to you, read both files rather than assuming one licence covers the repository. Nothing here is legal advice.
Editorial conclusion
hof is worth adopting if your team already thinks in CUE and wants generation, data modeling and a task engine under one CLI, and if you can pin to a release and tolerate the v0.7.0 alpha line. It is the wrong tool if you need a stable generator with a semantic-versioned API, or if your team has no CUE experience and no appetite to learn it. Before committing, verify three things: that the release you install matches the docs at docs.hofstadter.io, that `hof gen` handles your target language, and that `hof mod` resolves your CUE dependencies against cuelang.org/go v0.15.4.
Frequently asked questions
What is hofstadter-io/hof?
It is a Go CLI that the README describes as a tool unifying data models, schemas, code generation and a task engine, built on CUE. It ships as a single binary with subcommands for CUE definition, evaluation, export, validation and formatting, plus generation, data model management, workflows, starter kits and a terminal interface.
How do I install hof?
The README says the preferred method is the downloads on the GitHub releases page, with Homebrew as an alternative via `brew install hofstadter-io/tap/hof`. If you already have hof, the README gives `hof update --version vX.Y.Z` to install a specific version.
Does hof require CUE?
Yes. The README states that hof uses CUE to power the developer experience and implementation, and the CLI's core commands are CUE definition, evaluation, export and vet alongside generation and workflows. There is no documented mode that takes a non-CUE schema as input.
Community notes