himmel · for Claude Code

Ship more with Claude Code, and keep every change reviewable.

himmel puts Claude Code's work on a delivery graph. Each change is built in its own worktree, checked three ways at once, reviewed (by a second model too, once you add one) and merged through one gate. The guardrails apply to every session, including the ones you are not watching. For developers on Linux or macOS who use git.

One road for every changeEach change gets its own worktree, then passes the tests, a review and one merge gate. No step can be skipped. When a check fails, the change goes back with the reason, so main only gets work that passed.How a change ships
Guardrails that holdEdits and commits on main, pushes to main, reads of secret files, rm -rf, hard resets and force pushes are refused before they run.Level 1 · in your project
Cost you can seeHeavy work checks your remaining Claude usage first, and the fleet records the cost of what it merges.Level 5

himmel is built this way. Over 2,000 pull requests merged on its own main in 30 days (October 2026). See the graph they went through

A new project, shipping fast. The rules that keep it fast.

Guards aimed at real damage. Each guard targets a move that can hurt a project, and is replayed against real commands before it ships, so it stops what matters and lets the rest through.
Long tracks keep their pace. Each session keeps its context small, so its answers stay sharp. When it fills, a worker hands off at a set point and the chief passes the shift to a successor, with everything written down, so a long track never starts over.
Every merge is earned. A change merges through one gate only: CI green at its exact commit, every review point decided, and an approval signed for that commit.
Cleanup keeps every session fast. Stale worktrees and open tickets slow down each session that has to step around them, so finished worktrees are cleared and tickets close when their change merges.

Take a practice climb See the whole trail

What it is, and how you stay in control

himmel adds a delivery process to Claude Code. You decide how much of it runs, and where.

Question 1What is it?A delivery process for Claude Code: worktrees, git gates, a review (by a second model too, once you add one) and one merge gate, with guardrails that hold.

Small scripts fire automatically and refuse risky actions (edits and commits on your main branch, reads of your secret files, pushes to main), so the rules hold even when nobody remembers them.

Five words you will see

Hook: a script Claude Code runs before or after a tool; it can refuse the action.
Gate: a check that must pass before a commit, push or merge.
Worktree: a second working folder on its own branch, sharing the repo's history.
Handover: a written note a later session resumes from.
Sector: one region of your project's sky: a stable area of the work, the "where" of a ticket, so each area's progress shows on its own.

Every other term is in the glossary.

Who it is for

Developers who use git and a terminal. Linux and macOS are supported.

Question 2Who is in control?You are. You choose what runs, you see the plan before anything is written, and you can switch any part off.

You choose the starting point. A starter install for one project, or more: a second brain, a second reviewer, a fleet. Install profiles
You see the plan first. The installer lists everything it would add or change, and asks before it writes a thing.
Nothing runs on a schedule until you arm it, one job at a time.
Every guardrail has an off switch for one session, when you mean it.
One command takes it all back out. How

Question 3What changes on my machine, and how do I undo it?Files and settings in the project you install into, a few in your home folder, all recorded; one command takes them back out.

Read these four first

Helper scripts are copied into scripts/. A file with the same name is replaced only after himmel has backed it up, and uninstall restores it. If the backup cannot be made, the file is left alone and the install says not replaced … (cannot back up the existing file; left untouched). The preview lists every file it would replace.
Your statusLine is replaced in .claude/settings.json, and ~/.claude/plugins/claude-hud/config.json is rewritten. Both old values are backed up and uninstall restores them.
Commits and pushes to main are refused at once. If your project has no .pre-commit-config.yaml, the install places himmel's own git gates. They refuse a commit on main, a direct push to main, and a commit message without a conventional type and a ticket reference such as #1. No tracker? Answer none to the installer's tracker question, or put TICKET_ID_REQUIRED=0 in ~/.himmel/himmel.conf; that file applies to every project on this machine.
The install itself starts uncommitted. Main now refuses commits, so the installer offers to make the one allowed commit there (chore: add himmel), or prints the command that does. Until the install is committed, a new worktree has none of himmel's files, so Claude runs there without its hooks.

In the project folder

Three hook entries, a status line and HIMMEL_REPO in .claude/settings.json.
Three git hooks in .git/hooks. Existing ones are saved as <hook>.himmel-backup and still run after himmel's.
Claude Code plugins, recorded in .claude/settings.json; the preview names each one.

In your home folder

A himmelctl launcher in ~/.local/bin, a cache in ~/.claude/himmel.
A trust entry for the project in ~/.claude.json.

Only if bun is installed

The qmd search tool, about 2.1 GB of search models, and an index of your himmel clone.

Left alone

Your notes vault, scheduled jobs, the Telegram bridge and the second-model reviewers.

Every part the installer can add is one item of the install manifest, 55 items in all, 41 of them in the starter install, and himmelctl status checks each one. The full reference: Install on your project.

Undo

From the project you installed into, node ~/himmel/scripts/himmelctl/bin.js uninstall --yes removes what the install added and restores what it replaced. Add --dry-run first to see the list; anything it cannot undo by itself is listed under NEEDS YOU.

Take a practice climb

Ten steps on a spare project you can delete afterwards. You install himmel, watch a guardrail stop a risky move, keep the install, make one change in its own worktree, and then remove everything again. Each output below comes from one real run on a clean machine; paths and commit hashes that differ on yours are shortened to "…".

$ you type it in your terminal› you type it to Claudedashed box: what you see✓ what success looks like

Install the tools

git, node with npm, jq, python3 and Claude Code. The installer stops and tells you if git, bash, jq, python3 or npm/bun is missing.
LinuxmacOS
Run · Debian or Ubuntu, needs sudo
$ sudo apt-get update $ sudo apt-get install -y nodejs npm git jq python3 $ curl -fsSL https://claude.ai/install.sh | bash
Ubuntu's nodejs package ships without npm, hence the separate name.
Run · with Homebrew
$ brew install node git jq python bash uv $ curl -fsSL https://claude.ai/install.sh | bash $ uv tool install pre-commit
The bash and python3 that macOS ships are too old for some himmel scripts.
Success: if claude is not found, open a new terminal and it will be.
Sign in to Claude Code

Run claude, finish the sign-in in the browser it opens, leave with /exit. An account problem then shows up before himmel is involved.
Run
```
$ claude --version
```
Real output
```
2.1.305 (Claude Code)
```
Success: a version number followed by (Claude Code).
Make a spare project

One empty commit on main. No remote is needed: without one, himmel cuts worktrees from your local main.
Run
```
$ mkdir ~/himmel-trial
$ cd ~/himmel-trial
$ git init -b main
$ git commit --allow-empty -m "chore: initial commit"
```
Real output, at the end
```
[main (root-commit) 02c1d2c] chore: initial commit
```
Success: one empty commit on main, made before any himmel hook exists.

Download himmel next to your projects

Run

$ git clone https://github.com/yotamleo-org/Himmel ~/himmel

Expected

Cloning into '/home/you/himmel'...

Success: git ends without an error.

Preview the install

This writes nothing. It lists every file, setting and plugin the install would touch, then a summary. With --scope project the installer asks no questions; it uses the starter answers (install profiles lists the questions a bare install asks). Inside the script the starter set is called "core".
Run from the project
```
$ cd ~/himmel-trial
$ node ~/himmel/scripts/himmelctl/bin.js install --scope project --dry-run
```
Real output, abridged
```
==> himmel adopter preflight (check-only)
WARN: scripts/jira/node_modules and scripts/jira/dist/index.js not built …
preflight OK
…
would install (--dry-run — NOTHING below was executed):
  + himmel (profile=starter, scope=project) — would run bash …/adopt.sh --profile core --scope project
  + workspace trust — would run ensure-workspace-trust.sh for the install target
…
next: commit these files on a branch
```
The Jira warning is harmless on a starter install: the Jira command line is only needed if you track work in Jira.

Success: the summary says NOTHING below was executed, and git status still shows a clean tree. In a real project, a would replace … line names each of your files the install would back up and replace.
Install
Before you press Enter
- git status is clean. A same-named file in scripts/ is backed up before it is replaced, and left alone if the backup fails; a clean tree also shows you exactly what changed.
- You accept that your project statusLine is replaced; the old one is backed up.
- You know that from now on commits and pushes to main are refused, and a commit message needs a type such as feat: and a ticket reference such as #1.
Run
```
$ node ~/himmel/scripts/himmelctl/bin.js install --scope project
```
Real output, the lines that matter
```
  .gitignore: added .claude/worktrees/
  The install is uncommitted on main, which the git gates now refuse commits on.
  Commit it once with: bash …/adopt.sh --scope project --target …/himmel-trial --commit-install
…
installed:
  + himmel (profile=starter, scope=project) via bash …/adopt.sh --profile core --scope project
  + workspace trusted: …/himmel-trial (hasTrustDialogAccepted written to ~/.claude.json)
```
If your terminal asks Commit the install on main now (the one allowed commit there)? [y/N], answer y and step 8 is already done. Otherwise the installer prints the command for step 8, as above, with the full path to your himmel clone, so it runs from your project as printed.

Success: both + lines are present. A note that ~/.local/bin is not on your PATH is normal; add the line it prints.
Watch a guardrail refuse

Start claude in the project and ask it to create hello.txt. The edit is refused because you are on the main branch.
Type to Claude
```
› Create hello.txt with the word hi in it.
```
Real output, first lines
```
⛔ block-edit-on-main: refusing to edit `~/himmel-trial/hello.txt` — its repo is on main/master.
…
    bash scripts/worktree.sh feat/<scope>   # create the worktree
```
The refusal names the command that fixes it, and that command is in your project now. Leave Claude with /exit. git refuses a commit on main the same way:
Run
```
$ git commit --allow-empty -m "chore: try main #1"
```
Real output
```
ERROR: Committing directly on 'main' is not allowed.
```
Success: the refusal appears and hello.txt does not exist.
Keep the install

The install's files are still uncommitted, and main now refuses commits. The installer may make one commit there, and only for its own files:
Run from ~/himmel-trial
```
$ bash ~/himmel/scripts/adopt.sh --scope project --target ~/himmel-trial --commit-install
```
Real output, at the end
```
  committed the install on main (chore: add himmel)
──── Done ────
```
The install also added .claude/worktrees/ to .gitignore, so a later git add -A never stages a worktree. On a real project with a shared main, you can instead commit the install on a branch and merge it by pull request.

Success: git log --oneline -1 shows chore: add himmel, and git status is clean.
Work in a worktree

A worktree is a second folder on its own branch. It is cut from main, which now carries himmel's files, so the guardrails come with you.
Run from ~/himmel-trial
```
$ bash scripts/worktree.sh feat/try-himmel
```
Real output
```
WARN new-worktree: uniqueness-vs-merged-PR check skipped (forge unreachable)
WARN new-worktree: no 'origin' remote - branching from local 'main'
OK new-worktree: feat/try-himmel → …/himmel-trial/.claude/worktrees/feat+try-himmel (log: …)
```
Both warnings are normal for a project with no remote. Start claude inside the printed path and ask for hello.txt again; Claude Code asks your permission, as it always does for an edit. Then commit it. The commit rule wants a ticket reference:
Run inside the worktree
```
$ git add hello.txt
$ git commit -m "feat: add hello"
$ git commit -m "feat: add hello #1"
$ git log --oneline -1
```
Real output
```
COMMIT REJECTED: no ticket reference matched: (^|[^0-9A-Za-z_])(#|LOCAL-)[0-9]+([^0-9A-Za-z_]|$)
…
66493de feat: add hello #1
```
Success: the second commit goes through, and ls scripts/hooks in the worktree lists himmel's hooks, so the guardrails came with you.

Check, then undo whenever you like

Run from ~/himmel-trial

$ node ~/himmel/scripts/himmelctl/bin.js status
$ node ~/himmel/scripts/himmelctl/bin.js uninstall --dry-run

Real output, abridged

green  pre-commit-hooks  installed hook type(s): pre-commit, commit-msg, pre-push (…/.git/hooks)
green  wiring-pretooluse  …/himmel-trial/.claude/settings.json; …
…
0 red, 0 degraded, 7 green, 42 n/a (4 of them desired but not set up: see the n/a rows above)
…
DRY: Reconcile report - ledger …, 96 units
  reverted   82  (removed 82, restored 0, already-base 0, surgical 0)
  NEEDS YOU   0

To remove it for real, run the same command with --yes instead of --dry-run, then delete ~/himmel-trial.

Success: 0 red in the status count, and the undo preview has nothing that needs you. A green row means "found", not "working"; the n/a rows are features a starter install does not turn on.

"…" marks a path or text that depends on your machine. Full reference: Install on your project and Getting started.

The trail

Eight levels, each optional. Base camp is a complete result on its own; climb only as far as it pays. Each level says what you get, what it costs, and how you turn it off.

No badge: shipped and supportedpreview works, still changingplanned not built yet

Base camp

Guardrails for any project

Levels 0 and 1. You can stop here, and that is a complete result.

0Install & stay currenthimmelctl status reads what is installed, armed and working on your machine.

You know exactly what himmel put on your machine, and one command reports whether each part is still there.

Turn it on

node ~/himmel/scripts/himmelctl/bin.js install and press Enter for the starter answers. The practice climb walks it end to end; install profiles explains the other answers.

What you get

himmelctl install and status

The installer previews every file, setting and plugin it would touch, asks before it writes, and records what it changed. status prints one row per item, worst first, then a count.
One install manifest

Every part the installer can add is one item of scripts/install/manifest.json, with the profiles that include it; status and uninstall read the same list.
Staying current: /himmel-update

Pulls your himmel clone, refreshes the plugin marketplace and the tools the install built, and lists anything that needs you. /himmel-update --check only reports.

Try it

See what is installed

Run from your project

$ node ~/himmel/scripts/himmelctl/bin.js status

You see, in this shape

<red|degraded|green>  <item>  <what was found>
…
<N> red, <N> degraded, <N> green

One row per item, worst first, then a count. Green means found, not proven working. On the practice project the count read 0 red, 0 degraded, 7 green, 42 n/a: the n/a rows are features a starter install does not turn on.

You need

Linux or macOS, git, bash, jq, python3, and node with npm (or bun).
Claude Code, signed in.

Setup time

Not measured yet.

What it costs

No model usage.
Disk: the himmel clone and a cache in ~/.claude/himmel.

Turn it off

node ~/himmel/scripts/himmelctl/bin.js uninstall --yes removes what the install added and restores what it replaced; add --dry-run first to see the list.

Who it is for

Anyone who installs himmel.

1Ship with guardrailsEdits and commits on your main branch, direct pushes to main and reads of secret files are refused. A guard against destructive shell commands is on by default.

Every change Claude makes lands on its own branch in its own worktree, and the moves that can hurt a project are refused before they run.

Turn it on

Included in the starter install, the destructive-command guard too.

What you get

Worktree isolation

Claude may not edit files while your checkout is on main. The refusal names the command that cuts a worktree: bash scripts/worktree.sh feat/<scope>.
Secret-file protection

Reads of .env files, keys and similar secret files are refused. To read one on purpose, start Claude Code with READ_SECRETS_OK=1 for that session.
Git gates: commit, message, push to main

If your project has no .pre-commit-config.yaml, the install places himmel's own git hooks. They refuse a commit on main, a direct push to main, and a commit message without a conventional type and a ticket reference such as #1. No tracker? Put TICKET_ID_REQUIRED=0 in ~/.himmel/himmel.conf.
Destructive-command guard

On by default. It refuses rm -rf, git reset --hard, git clean -f, force pushes and similar before the command runs. To run one on purpose, start Claude Code with DESTRUCTIVE_OK=1 for that session.
/pr-check review panel

Reviews a branch before its pull request opens: Claude reads the diff (and a second model family too, once you add one at Level 4), you rule on each finding, and a round repeats until nothing blocking is left.

Try it

Three refusals you will meet

› Ask Claude to read .env

You see

⛔ block-read-secrets: refusing Read of secret file: ~/your-project/.env

Run

$ git push origin main

You see

ERROR: Direct push to 'main' is not allowed.
Open a PR from a worktree branch instead.

› Ask Claude to run rm -rf build

You see

block-destructive-commands: destructive command refused (recursive rm); bypass: DESTRUCTIVE_OK=1 in the launching shell (per run)

Each of Claude's refusals names a one-session bypass, which you set when you start Claude (for example READ_SECRETS_OK=1 claude), never per command. The push-to-main gate has no bypass: changes reach main through a pull request.

You need

Level 0.
A git repository with a main branch.

Setup time

Not measured yet.

What it costs

No model usage for the guards and gates.
/pr-check uses your Claude usage for each review round.

Turn it off

For one session: start Claude Code with EDIT_ON_MAIN_OK=1, READ_SECRETS_OK=1 or DESTRUCTIVE_OK=1. For good: node ~/himmel/scripts/himmelctl/bin.js uninstall --yes.

Who it is for

Anyone who installs himmel.

The climb

The full stack

Levels 2 to 7. Each card says what you can turn on, what it costs you, and how you turn it off.

2Second brainYour notes vault fills and links itself on a schedule, and Claude's lessons land in it.

A link you drop into your vault at midnight is a connected, summarized note by morning, and search over it stays fresh.

Turn it on

Run the installer again and pick the luna profile; it scaffolds a vault (or uses yours) and offers the scheduled jobs below.

What you get

Your vault, from the template

Start from the bundled templates/luna-second-brain/ or a vault already made from it. Any folder of notes is not enough.

Scheduled jobs

Recurring jobs on your system's scheduler (cron). You see a row only when its condition holds, and anything you decline is recorded as declined.

Scheduled jobs: pick from 5
Job	What it does	Offered when
`pipeline`	Daily: pulls in what you clipped and writes summaries into the vault. Uses your Claude usage.	a vault exists
`qmd`	Daily: re-indexes the vault for search. No model usage.	a vault exists
`graphmap`	Hourly: refreshes the map of links between notes, no model usage; a weekly deeper pass uses Claude.	a vault exists
`vault-stall`	Every 15 minutes: notices when the vault stops saving itself to git, clears a few known harmless causes, and alerts you.	a vault exists
`doctor`	Daily health check of your install; reports, fixes nothing.	always

Not offered on the trail (3):

drift-fix: A maintainer job that bumps himmel's own pinned upstreams; the installer hides it on a starter install.
upstream-watch: A maintainer job that watches himmel's own upstream pull requests and issues; the installer hides it on a starter install.
pull-cadence: A personal health-data connector, offered only when its own token is set; not part of the trail.

Vault search (qmd)

Local search over your vault. Re-indexing is its own job: arm only the pipeline and your search goes stale.
Clip triage (obsidian-triage)

/triage-clips summarizes and tags Web Clipper output in Clippings/ and moves action items to today's daily note. /synthesize-clips finds patterns across clips.
Obsidian skills (claude-obsidian)

Comes from upstream, pinned to a release tag; not a himmel fork.
Note graph (graphify)

A map of how your notes link to each other, kept current by the graphmap job.
Memory compounding: /memory-compound

Claude Code keeps a memory index for each project and loads it into every session, within a fixed budget. When the index nears that budget, run /memory-compound in a session of its own. It moves the lasting lessons into vault notes, checks that qmd search finds them, and only then trims the index. The vault notes land on a branch for you to review and merge. It runs when you ask; there is no schedule.

Try it

Check a scheduled job

Run

$ bash ~/himmel/scripts/luna/qmd-cadence.sh status

You see whether the job is armed, its schedule and its last run. arm refuses to arm it twice, and disarm removes exactly what arm added.

You need

Levels 0 and 1.
A vault made from templates/luna-second-brain/.
bun, for qmd search (about 2.1 GB of models).
cron on Linux or macOS.

Setup time

Not measured yet.

What it costs

Disk: about 2.1 GB for search models.
Search re-indexing and the hourly graph refresh: no model usage.
The pipeline's summaries and the weekly graph pass: your Claude usage, per run.

Turn it off

One command per job; every job script takes arm, status and disarm, for example bash ~/himmel/scripts/luna/pipeline-cadence.sh disarm.

Who it is for

Anyone with an Obsidian vault, or ready to start one.

3ReachYour phone joins: capture to the vault from chat, and alerts reach you.1 preview

You send your bot a message or a link, and Claude answers in the chat or files it into the vault.

Turn it on

With a vault, the installer asks whether to configure the Telegram bridge; you create a bot token and the two files below.

What you get

Telegram bridge

A small supervisor on your machine relays your messages to Claude Code and the replies back. Only the Telegram user ids in access.json are answered.
Bridge health checks

The supervisor restarts the bridge when it stops answering, and himmelctl status reports whether it runs.
Capture from chat

Send a link or a note; it lands in the vault for the pipeline to summarize and link.
Alerts

Scheduled jobs and health checks send their alerts to the same chat.
Voice notespreview

Speak a message instead of typing it; the reply can be read aloud. Works, still changing.

Try it

Talk to Claude from your phone

Two files you create once

~/.claude/channels/telegram/.env          TELEGRAM_BOT_TOKEN=<your bot token>
~/.claude/channels/telegram/access.json   {"allowFrom":["<your Telegram user id>"]}

Start the bridge

$ cd ~/himmel/scripts/telegram
$ bun supervisor.ts

Then message your bot. Each message starts one short Claude run, and the reply comes back to the chat.

You need

Level 2 for capture to the vault.
bun.
A Telegram bot token from BotFather, and your own Telegram user id.

Setup time

Not measured yet.

What it costs

Each message is one short Claude run on your usage.

Turn it off

bun supervisor.ts --kill from ~/himmel/scripts/telegram stops the bridge.

Who it is for

Anyone who wants Claude and the vault from a phone.

Read more

Telegram bridge

4Review depthA second model family (OpenAI GPT, on your ChatGPT/Codex subscription) reviews every diff alongside Claude, and its track record tunes the review.1 preview1 planned

Every /pr-check round is read by two model families, and you can see which reviewer's findings hold up.

Turn it on

Answer codex to the installer's lanes question (after codex login), or run the install again with --with-codex.

What you get

OpenAI GPT critic, via hermes

A critic is one reviewer model; hermes is the open-source agent runtime himmel uses to call it. With hermes installed and your ChatGPT/Codex login in place, /pr-check calls the GPT critic beside Claude.
/cr-scores critic scorecard

Every /pr-check round records its findings and verdicts in a review ledger on your machine. /cr-scores shows, for each critic, how many of its findings held up and how often it was available, and says when a critic is worth dropping.
/cr-tune tuning proposals

Drafts tuning proposals from the findings that were disproved, each citing its ledger rows, and never applies them itself.
/cr-learnings-refresh known findings

Updates the list of known findings from the ledger, and from a CodeRabbit learnings export if you use CodeRabbit.
Free hermes criticspreview

Critics on free model tiers, called the same way. Early: works, still changing.
Multi-model front endplanned

One place to drive Claude and the other model families side by side. Not built yet.

Try it

Read the reviewers' scorecard

After a few reviews, in a Claude session

› /cr-scores

You see, before any review has run

no critic scores recorded yet (ledger: …)

Once reviews have run, it shows one row per critic: how many of its findings held up, and how often it was available.

You need

Level 1 (/pr-check).
hermes installed.
A signed-in ChatGPT/Codex subscription (codex login).

Setup time

Not measured yet.

What it costs

The GPT critic draws on your ChatGPT/Codex subscription, one call per review round.
The scorecard and tuning commands use your Claude usage when you run them.

Turn it off

Run the installer again and leave codex out of the lanes answer; /pr-check then reviews with Claude alone.

Who it is for

Anyone with a ChatGPT or Codex subscription.

Read more

Codex lane · hermes runbook

5Spend & contextHeavy work checks your remaining usage first, and each session can read its own context fill.1 planned

You see how full each session's context is, and scheduled work waits instead of eating the usage you need for your own sessions.

Turn it on

The status line comes with the starter install; the usage check runs by itself before scheduled work.

What you get

claude-hud status line

Shows the model, the context fill and your usage under every prompt. The install backs up your old statusLine and uninstall restores it.
Usage preflight

One word before a heavy run: go, or wait and why. Scheduled runs check it before they start, because they spend the same usage as your own sessions.
Self-read context fill

bash ~/himmel/scripts/context-fill.sh prints how full the current session's context window is, read from the status line's own snapshot, so a session can hand off before it fills.
rtk output trimming

rtk filters long command output before Claude reads it, so a noisy build log does not fill the context.
Headless runs with a budget guardplanned

Unattended runs that stop at a spend limit you set. Not built yet.

Try it

Ask before a heavy run

Run

$ bash ~/himmel/scripts/lib/bank-preflight.sh

You see one word

PROCEED

Or SKIPPED-BANK when your 5-hour or weekly Claude usage is too high, SKIPPED-FLEET when too many sessions already run, and BANK-STALE or BANK-UNKNOWN when the usage reading is old or missing.

You need

Level 0.

Setup time

Not measured yet.

What it costs

No model usage: these read numbers Claude Code already reports.

Turn it off

node ~/himmel/scripts/himmelctl/bin.js uninstall --yes restores your old status line; the preflight only ever answers, it never runs anything.

Who it is for

Anyone who runs Claude Code for long or unattended.

Read more

Token economy · Configuration

6Always-onWork continues while you are away, and you read one morning report.2 planned

A session that ends leaves a note the next one resumes from, and a shift while you sleep ends in one report you read over coffee.

Turn it on

/handover-setup once in your project. Shifts while you are away: /afk-shift.

What you get

Session handover

/handover at the end of a session saves what you did and where you left off; a fresh session resumes from it.
Shifts while you are away: /afk-shift

Starts a shift that keeps working through the queue you leave it, within the usage the preflight allows, and stops when the queue is empty or the usage runs low.
Morning report

/morning-report sums up what merged, what failed and what waits on you since you left.
Monitoring set up for youplanned

Dashboards for the fleet's health, installed and wired by the installer. Not built yet.
A morning report you can shapeplanned

Choose what the report covers and where it goes. Not built yet.

Try it

End a session so the next one can pick up

Once, in a Claude session in your project

› /handover-setup

Choose where notes live: a handovers/ folder in the repo, or a separate git repo.

At the end of each session

› /handover

It saves what you did and where you left off, and confirms the saved note. A fresh session resumes from it.

You need

Levels 1 and 5.
A place for the notes: a folder in the repo or a separate git repo.

Setup time

Not measured yet.

What it costs

A shift uses your Claude usage while you are away; the preflight stops it before your own budget runs out.

Turn it off

Nothing runs until you start a shift; /stop ends one.

Who it is for

Anyone who leaves work running overnight.

7Command a fleetMany workers ship tickets in parallel under one chief, and you watch them live.2 preview2 planned

You hand the chief a list of tickets, and workers ship them in parallel, each through the same review and merge gate as your own changes.

Turn it on

/chief new starts a chief; himmelctl ui opens the fleet view.

What you get

Written briefs for each worker

A worker is one Claude session that owns one ticket, one worktree and one pull request. The chief writes each worker a brief with its scope and the files it may touch.
Parallel workers, started in waves

The chief is the session you talk to: it hands out the tickets, starts workers in parallel waves, and keeps them off each other's files.
Coordination in writing, not memory

Every worker reports in its handover note and by message, so a chief that hands over its shift loses nothing.
Merge only on the chief's approval

A worker merges only when CI is green at its exact commit, every review point is decided, and the chief has approved that commit.
Session run view

himmelctl ui serves a local page on 127.0.0.1 behind a per-launch key. Its Fleet page lists every live Claude session; click one to follow it as it runs.
Fleet boardpreview

With a chief running, the same page groups the workers under it and shows each one's stage and whether it waits on you. Works, still changing.
Release managerpreview

A session that rules which tickets go into each version and reports the burn-down. Works, still changing.
Trends over days and weeksplanned

Throughput and cost per merged change, over time, from real runs. Not built yet.
Installable chief moduleplanned

The chief and its scripts as one installable part for your own project. Not built yet.

Try it

Open the fleet view

Run from your own terminal, not inside Claude

$ node ~/himmel/scripts/himmelctl/bin.js ui

You see one link

http://127.0.0.1:37931/agui/#t=…

Open it in your browser. The port and the key after #t= change each launch, and the page only answers on your own machine. It stops after 30 idle minutes or on Ctrl-C.

You need

Levels 1, 5 and 6.
bun, and a one-time build of the fleet page.
A ticket tracker the chief can read.

Setup time

Not measured yet.

What it costs

Each worker is a full Claude session: a fleet spends your usage several times faster, and the preflight holds new workers back when it runs low.

Turn it off

Close the chief and its workers; Ctrl-C stops the fleet view. Nothing keeps running on its own.

Who it is for

Anyone running many tickets at once; most adopters stop below this level.

Being tried out

Skill eval and optimization loops
Self-evolving workflows

Experiments, not on the trail yet. They join a level once they work for someone other than us.

Placeholder: a short recording of a fleet at work goes here. Not recorded yet.

Getting started Install profiles Scheduled jobs Orchestration patterns

Ship more with Claude Code, and keep every change reviewable.

What it is, and how you stay in control

Five words you will see

Who it is for

Read these four first

In the project folder

In your home folder

Only if bun is installed

Left alone

Undo

Take a practice climb

Install the tools

Sign in to Claude Code

Make a spare project

Download himmel next to your projects

Preview the install

Install

Before you press Enter

Watch a guardrail refuse

Keep the install

Work in a worktree

Check, then undo whenever you like

The trail

Guardrails for any project

The full stack

Being tried out