| name | muninn-boot |
| description | Boots Muninn — runs scripts/boot.sh, which fetches oaustegard/claude-skills and oaustegard/muninn-utilities from their main branches (dynamic sideload), loads the Turso and GitHub tokens, and runs the memory-system boot sequence. Trigger on the first message of any new conversation in the Muninn project, or when the user says "boot up" / "boot" — unless the message contains "skip boot". If the message contains "skinny boot", run with BOOT_MODE=perch. Safe to run on every message: a warm container fast-exits in ~0s via a sentinel, so re-running is cheap and idempotent. |
Muninn Boot
Oskar's own repos and credentials (oaustegard/, /mnt/project/.env). Standing
procedure — runs every session.
bash /mnt/skills/user/muninn-boot/scripts/boot.sh
Skinny boot ("skinny boot" in the message):
BOOT_MODE=perch bash /mnt/skills/user/muninn-boot/scripts/boot.sh
scripts/boot.sh (~35 lines, sibling of this file — readable before running)
does, in order:
- Fetches oaustegard/claude-skills → /mnt/skills/user and
oaustegard/muninn-utilities → /home/claude/muninn-utilities, each at
current main HEAD (dynamic — no pinned SHA).
- Sources the two env files
boot() reads: Turso.env (memory, config,
reminders) and GitHub.env (GH_TOKEN for the RECENT FLIGHTS block, which
degrades to empty without it).
- Writes the
.pth so from scripts import boot resolves, runs boot(),
prints its output, and writes the sentinel (last, only on success).
Credential scope
The remaining project .env files (bsky.env, muninn-bsky.env,
strava.env, proxy.env, claude.env) are used by later task-specific
steps, which source them inline immediately before the command that needs
them:
set -a; . /mnt/project/strava.env 2>/dev/null; set +a
(Env vars do not persist across separate bash_tool calls, so per-call
sourcing is how every consumer works regardless of what boot loads.)
Dynamic sideload (no pins)
CLAUDE_SKILLS_REF / MUNINN_UTILS_REF at the top of scripts/boot.sh are
main, not pinned SHAs — the point of sideloading is that skill/utility
updates land on the next cold boot with no version bump and no re-upload of
this skill. The cost is that main runs as-is, unreviewed, so keep both repos
deployable on main.
A warm container will not re-pull mid-session (the sentinel short-circuits it);
rm /home/claude/.muninn-booted forces a fresh pull of main. This skill file
itself is still the one exception that must be re-uploaded to the project when
it changes, since the running copy is the project upload, not the fetched one.