Hammer

Hammer is our native macOS static site generator. It compiles HTML, CSS, and assets into a deployable site without imposing a heavyweight JavaScript framework or a rigid content model.

Where Forge is where sites live, Hammer is how we build them. Every content site at Beach runs through Hammer and deploys to Forge: product marketing, blogs, microsites, and this handbook.

Static site generators already existed when we started Hammer. So did headless CMS platforms, React frameworks, and all-in-one site builders. None of them matched how we actually worked.

We wanted something lightweight: a tag system that lets authors work with everything the modern web already offers, without dragging in bloated, opinionated JS frameworks. HTML stays HTML. CSS stays CSS. Includes, variables, and path resolution handle the repetition. The output is fast, portable, and deployable anywhere.

As AI-assisted development became central to how we build, Hammer evolved again. Content creation moved out of separate CMS workflows and into the build tool itself. Agents needed CLI access. Hammer became both the generator and the surface that agents operate on.

Hammer is not just a compiler. It is a small platform of capabilities that work together:

• Hammer: the macOS static site generator at the core. A tag system for includes, variables, stylesheets, scripts, and asset paths. Smart path resolution across the project. Live reload for development. Minimal ceremony, maximum clarity.
• Hammer CLI: command-line access to Hammer's capabilities, designed for agentic workflows. Combined with Skills, agents can scaffold pages, run builds, resolve paths, and manage site structure on behalf of authors.
• Hammer Content: content workflows built into Hammer, replacing our earlier Chisel CMS headless CMS. Chisel turned Parse Server into a hosted editorial platform; Hammer Content moves that work into the filesystem, Git, and agentic workflows with Claude and Cursor. Content is generated at build time, not synced from a dashboard.

The philosophy is consistent: stay close to the web platform, stay close to the filesystem, and let AI meet you where the work already happens.

Hammer and Forge are designed as a pair. Hammer builds. Forge hosts.

A typical flow: author or agent edits source files locally, Hammer compiles to a Build directory, Forge deploys the output. Product pages, campaign microsites, documentation, and thought leadership all follow the same pattern. One toolchain, one deployment target, no framework lock-in.

For service companies using Forge, Hammer is the reference implementation of how to build content sites well: fast, maintainable, and ready for AI-assisted iteration from day one.

Hammer supports several Beach Way ideas directly:

• Trails: source files in a repo are trails. Every edit, include, and annotation is evidence of the journey. Hammer compiles them into something others can follow.
• Activities: a page edit, a new include, a build run. Small, meaningful units of progress that compound into a shipped site.
• Apprenticeship: Hammer's simplicity lowers the barrier to participation. New contributors can read HTML and understand the project structure without learning a framework first.
• Guides: Skills and CLI conventions act as guides for agents, giving them enough context to operate Hammer correctly without micromanagement.

The Beach Way values shared understanding over deliverables. Hammer keeps the source of truth in plain files that humans and agents can both read. The compiled site is the deliverable. The repo is where understanding lives.