devenjarvis/lathe: generate hands-on tutorials, then work through them yourself

The problem Lathe targets: tutorials you read instead of type

Most LLM output arrives as an answer. You paste a question, you get prose, you nod, and nothing sticks. Lathe inverts that arrangement. The README describes the project as "an experiment in using LLMs to teach you, rather than think for you," and the workflow reflects it: the model writes a tutorial, and you do the work by hand in a local reader built for that purpose. The intended user is an engineer who learns by building things, the same instinct that produced the build-your-own-x repository and Crafting Interpreters, both of which the README names as formative influences.

The output is not a single wall of text. Lathe generates either a single-part tutorial or a multi-part series from any prompt, and each tutorial records its sources, the model that produced it, and the prompt that drove the tutorial's voice. That last detail matters more than it looks. Because the voice prompt is stored alongside the content, a tutorial is reproducible in tone even after the underlying model changes.

How Lathe splits work between the CLI and your coding agent

The architecture is deliberately thin on the model side. Lathe is a Go binary that stores, manages and serves tutorials, plus a collection of skills that live inside whatever coding agent you already use. The README states the boundary plainly: "the binary never drives a model itself." That single constraint explains most of the design.

Generation happens when you invoke a skill such as /lathe inside Claude Code, Cursor, Codex, Gemini CLI, opencode, Cline or Windsurf. The agent does the research and writing; the CLI receives and persists the result. Reading happens through lathe serve, which starts a web server and opens a browser. The dependencies in go.mod confirm the rendering path is local: goldmark for Markdown, goldmark-highlighting and chroma for syntax highlighting, and cobra for the command tree. There is no database driver and no HTTP client to a model provider, which is consistent with the claim that the binary stays out of the model loop.

Interaction after generation has two modes. In live mode you run /lathe-work once inside a coding agent while lathe serve is running, which starts a small worker loop. The Ask drawer then shows a connected indicator, and the Ask, Verify this tutorial and Add a part buttons drive work directly in that session, with answers rendering in the reader and edits applying in place. Without a worker, each button hands you the exact /lathe-* command to paste into your LLM instead. That fallback is the honest part of the design: the feature degrades to copy and paste rather than failing.

Installing lathe and generating your first tutorial

Lathe ships as a single self-contained binary. On macOS the README recommends Homebrew, and notes the formula is distributed as a cask, meaning a pre-built binary, so it is macOS-only:

brew install devenjarvis/tap/lathe

On Linux, or anywhere you prefer not to use Homebrew, the install script is the documented path:

curl -sSf https://raw.githubusercontent.com/devenjarvis/lathe/main/install.sh | sh

If you have Go 1.25 or newer, go install works too. The go.mod file pins go 1.25.5, so the version floor is real rather than aspirational:

go install github.com/devenjarvis/lathe@latest

The binary alone does nothing useful until the skills are discoverable by your agent. Install them into the current project, or into your home directory for every project:

lathe skills install
lathe skills install --user

Each agent has its own target directory. Cursor is the exception worth knowing about: its commands are slash-invoked, so the install translates the skill rather than copying it verbatim:

lathe skills install --agent cursor
lathe skills install --agent codex
lathe skills install --agent all

With skills in place, generate a tutorial by prompting your agent. The README gives this example:

/lathe build a 3D Slicer in Erlang

Then start the reader from any terminal. The server opens the browser for you:

lathe serve

You should see a tutorial selection screen listing what you have generated, with light and dark modes. Click a tutorial and work through it by hand.

Where Lathe breaks down or is the wrong choice

The dependency on an interactive agent session is the sharpest constraint. Live mode requires /lathe-work to be running in a supported agent, and the README states the interactive handoff model is documented against Claude Code, so a few runtime details differ on the other agents. If you use an agent outside the supported list, you are in copy-paste mode permanently. That is usable, but the reader's buttons become command generators rather than controls.

Platform coverage is uneven. The Homebrew path is macOS-only by the README's own admission, so Linux users depend on the install script or a Go toolchain. And the Go route demands 1.25 or newer, which is a recent floor; a machine pinned to an older toolchain cannot build from source without an upgrade first.

Quality scales with the model you point at it, and the README says so directly: the bigger the local thinking model you can run, the better the tutorials, because these are research- and explanation-heavy tasks rather than mechanical edits. A small local model will produce thin tutorials, and nothing in the CLI compensates for that. Lathe is also not a documentation generator for a codebase, not a hosted service, and not something you drive from a script: the CLI's other commands exist, per the README, mainly to give the LLM a deterministic way to manage tutorials.

Lathe compared with asking an agent to write a tutorial directly

The obvious alternative is to skip Lathe and prompt your coding agent for a tutorial in the chat window. The difference is persistence and structure. A chat answer scrolls away and carries no record of which sources or model produced it. Lathe stores the tutorial as a library item with its sources, model and voice prompt attached, renders it with syntax highlighting in a dedicated reader, and supports search and filtering across everything you have generated.

The second difference is the multi-part series. A chat prompt tends to produce one long document. Lathe generates either a single part or a series, and the Add a part affordance extends an existing tutorial with a new part rather than starting over. If your learning goal is a sequence (build the parser, then the evaluator, then the REPL), that structure is the reason to use the tool. If you just want an explanation of a concept right now, the chat window is faster and Lathe adds a binary, a skill install and a running server for no benefit.

Maintenance, licence and upgrade cost

The repository is not archived, and the last push was on 2026-08-03. Releases have moved steadily: v0.3.0 on 2026-06-07, v0.4.0 on 2026-06-12, and v0.5.0 on 2026-07-20. The version numbers signal pre-1.0 software, so command names and skill formats can change between releases, and the README's own framing of the project as an experiment supports that expectation.

Upgrading is cheap in the common case. The binary is self-contained, and the skills are bundled inside it, so a new release arrives with its skills attached. Re-running lathe skills install after an upgrade refreshes the files in your agent's skill directory, which matters because the skill content is versioned with the binary rather than fetched separately. Tutorials you have already generated live in your library and are not tied to the skill version.

Lathe is MIT licensed, and the LICENSE file sits at the repository root. That permits commercial and private use, modification and redistribution provided the copyright notice and permission notice are included. Nothing here is legal advice; if you plan to redistribute a modified binary or bundle it into a product, read the licence text yourself.

Editorial conclusion

Lathe suits engineers who already work inside a coding agent and want generated tutorials they actually type through by hand, not summaries they skim. It is the wrong tool if you want a hosted service, a REST API for automation, or a reader that runs without an agent session. Before adopting it, verify that your agent is one of the eight supported targets and check which install path your platform allows: the Homebrew cask is macOS-only, so Linux users need the install script or go install with Go 1.25 or newer.

Frequently asked questions

Official sources

1. devenjarvis/lathe on GitHub
2. Issues
3. License: MIT
4. README
5. Releases