Installing mochi-framework puts a mochi-framework binary on your PATH. Inside a project it is available to package.json scripts directly. Anywhere else, run it with bunx:

bunx mochi-framework <command> [options]

bunx mochi-framework --help # list every command

bunx mochi-framework --version # print the installed version

-h/--help and -v/--version work as shorthands.

build

Produces a production bundle by reading config straight from your entry’s Mochi.serve() call, so the prebuilt manifest stays single-sourced with the runtime. This is the command behind your build script:

{
  "scripts": {
    "build": "mochi-framework build"
  }
}

The build lists every SSR entrypoint it compiled as one tree. Your routes come first, then three groups no route reaches: the error page (renders on a throw), email templates (render on a send), and server islands (render on a fetch of their own endpoint).

      Route                                   islands   bundle
  ┌ ● /                                             1  2.45 kB
  ├ λ /health                                       -        -
  ├ ● /orders/:id                                   1  2.45 kB
  │
  │   Error page
  ├ ⚠ $mochi/templates/DefaultError.svelte          1  3.17 kB
  │
  │   Email template
  ├ ✉ src/emails/Receipt.svelte                     -    316 B
  │
  │   Server island
  ├ ◐ /_mochi/island/Cart_3iqkh56ovhduk             1  89.6 kB
  └ ○ /_mochi/island/Stamp_dnp0teboqefy             0    235 B

  ● page with islands  ·  λ api  ·  ⚠ error page  ·  ✉ email template  ·  ◐ server island with islands  ·  ○ server island

After the tree, the build lists the resources it emitted — one row per local image import, largest first:

      Resource                        dimensions     size
  ┌ ▣ error-page-3jm1noc19vxtj.png       1400×807   330 kB
  └ ▣ debug-bar-ycfe5vg1pwxv.png          1036×72  22.5 kB

  2 assets · 353 kB

Silence the list with Mochi.serve({ build: { resources: false } }). The build: done summary still reports the asset count.

The manifest stores all artifact paths relative to the out-dir, so the output is relocatable. Move or copy it and boot with outDir (or manifest) pointing at the new location. See Production builds.

Static files are the exception: the build reads --public-dir only to reject a file that shadows a route, and copies nothing. The runtime serves that directory from disk, so it travels with your source. A 0 public file(s) summary for an app with static assets means --public-dir points somewhere unexpected.

generate-key

Generates a MOCHI_KEY (a base64url-encoded 32-byte secret) and writes it to .env in the current directory:

bunx mochi-framework generate-key

It creates .env if missing, appends MOCHI_KEY if absent, and prompts before overwriting an existing key.

update-skill

Fetches the latest SKILL.md — agent guidance for coding assistants — and writes it into your project for the given agent (default: claude-code):

bunx mochi-framework update-skill [agent]

Run it again whenever you upgrade the framework to keep the guidance in sync. See Docs for LLMs for the full list of supported agents.

Confirming an update

Since: 0.10.0 (not released yet): The confirmation prompt and --force flag were added in 0.10.0. Earlier versions overwrite an existing SKILL.md without asking.

The hosted SKILL.md is instructions your coding agent will follow. When the file already exists and the fetched copy differs, the CLI prints a unified diff and asks before writing:

bunx mochi-framework update-skill

[mochi] Skill update fetched from https://mochi.fast/SKILL.md:

--- .claude/skills/mochi/SKILL.md
+++ https://mochi.fast/SKILL.md
@@ -12,3 +12,3 @@
 Routes live in src/routes.ts.
-Use Mochi.page() for SSR pages.
+Use Mochi.page() for SSR pages and Mochi.api() for JSON.

[mochi] Apply this update?

A first write is not prompted — there is no prior content to review — and an unchanged file exits early with is already up to date.