Hey everyone,
I’ve been working on Hammer CLI, a command-line interface that brings Hammer’s build engine to the terminal.
This is still early – I’m sharing the thinking and direction here before it ships officially. Would love your input.
The Short Version
You’ll be able to cd into any Hammer project and run:
hammer build
Same build engine. Same output. No GUI required.
Why Build This?
Hammer has always been a desktop-first tool. You open the app, select your site, hit build, see the results. That workflow is great for hands-on development, fantastic for hoomanz - and it’s not going anywhere.
But as I’ve been scaling content across multiple sites, some patterns keep coming up where the GUI becomes a bottleneck:
Automation. When AI tools generate content for a site, there’s no way to validate or build that content without opening Hammer and clicking through the UI. Every step requires a human at the keyboard.
CI/CD. If you want to check content quality in a pull request pipeline, you need a tool that can run headlessly and return a pass/fail exit code. A GUI app can’t do that.
Headless machines. A Mac mini sitting in a closet processing builds for a portfolio of sites doesn’t need (or have) a display. It needs a command it can run. Yes I’ve been playing with OpenClaw.
Scripting. Sometimes you just want to build 10 sites in a row from a shell script without switching between projects in the GUI.
The GUI is the right tool for development. But there’s a whole class of workflows where you need Hammer’s build engine without Hammer’s window.
What It Does
Four commands, covering the core workflow:
hammer build
Runs the full Hammer build pipeline – HTML tag processing, CSS compilation, content generation, asset copying – and writes the output to a Build/ directory.
hammer build
hammer build --verbose
hammer build --mode export
hammer build --format json
Works with any Hammer project. Content mode sites, simple HTML/CSS sites, everything.
hammer check
Validates content structure and governance rules for sites using content mode. Checks that required fields are present, templates exist, content files parse correctly.
hammer check
hammer check --strict
hammer check --format json
This is the command you’d wire into a CI pipeline to catch problems before they hit production.
hammer info
Shows what the CLI sees when it looks at your project – collections, paths, content mode status.
hammer info
Project: my-blog
Path: /Users/me/sites/my-blog
Build: /Users/me/sites/my-blog/Build
Content: enabled
Collections:
posts (24 files) -> content/posts
authors (3 files) -> content/authors
hammer doctor
Environment diagnostics – confirms the project is set up correctly before you run a build.
hammer doctor
Hammer Doctor
─────────────
✔ Project found: /Users/me/sites/my-blog
✔ Source directory readable: OK
✔ Build directory writable: OK
✔ Content config valid: 2 collections defined
✔ Collection 'posts' directory: OK
✔ Collection 'posts' template: OK
6/6 checks passed
How It Works
The CLI uses the exact same build engine as the Hammer app. Not a reimplementation, not a port – the same Swift code that runs when you click “Build” in the GUI. This means:
-
Build output is identical between GUI and CLI
-
Any fix or improvement to the build engine benefits both
-
No risk of the two diverging over time
You just run it from the terminal instead of the app.
Project Detection
One thing I wanted to get right: you shouldn’t need a special config file just to use the CLI. If you cd into a Hammer project directory and run hammer build, it should just work.
The CLI looks for content.config.json or .hammer-ignore as hints, but any directory is a valid project. If you’ve been building a site with Hammer, the CLI will build it too. No migration, no setup.
JSON Output
Every command supports --format json for machine-readable output. This is designed for piping results into other tools, parsing in scripts, or feeding into automation systems.
hammer check --strict --format json
{
"status": "pass",
"errors": [],
"warnings": [],
"stats": {
"filesChecked": 24,
"durationMs": 45
}
}
Exit codes are deterministic: 0 for success, 1 for failures, 2 for config errors. Standard stuff that plays well with set -e and CI runners.
What’s Next
This is actively in development. The core is working – build, check, info, and doctor all run against real projects. What I’m looking at next:
-
Bundling the CLI inside Hammer.app with an “Install CLI” option
-
Official documentation on the Hammer site
-
CI integration examples for common setups
Interested?
I’d love to hear what workflows you’d use this for. A few questions:
-
Would you use this in CI? If so, what does your pipeline look like?
-
Multi-site management – are you building more than one site with Hammer?
-
Content automation – are you using AI tools to generate content for Hammer sites?
-
What else should the CLI do? Watch mode? Incremental builds? Something else?
This is being built to solve real problems I’m hitting at scale, but I want to make sure it’s useful for the broader Hammer community too.
Looking forward to your thoughts.