All wizards have a book of spells. What are yours?

An update on what’s new in MoFlo — the open-source npm package that upgrades Claude Code with full project knowledge, persistent memory, sandboxed automation, and a swarm of agents that actually stay wired together.

GitHub: github.com/eric-cielo/moflo
npm: npmjs.com/package/moflo — npm install --save-dev moflo

Every wizard worth their staff carries a grimoire — a personal library of spells, tested and refined, ready to cast on demand. The spells aren’t the wizard’s power; they’re how that power gets aimed. Without them, every incantation is improvised, every result a coin flip.

MoFlo gives Claude that grimoire. A spell in MoFlo is a YAML or JSON file that composes typed steps — shell commands, browser automation, agent spawns, conditions, loops, parallel branches, IMAP, Slack, MCP calls, GitHub operations — into a single runnable workflow. It runs the same way every time. It can be triggered by /flo, scheduled by cron, or invoked from any other spell as a sub-step. And every step in it is sandboxed.

“Wait, can it…?”

Probably, yes. Consider a real one: “Listen to my Gmail inbox, and when an attachment lands from our supplier, save it to the filesystem and post a message in Slack with a link.”

That’s a four-line spell:

steps:
  - id: watch
    type: imap
    config: { mailbox: INBOX, from: "supplier@vendor.com", hasAttachment: true }

  - id: save
    type: bash
    config: { command: "node -e 'fs.writeFileSync(\"./inbox/{watch.attachmentName}\", Buffer.from(\"{watch.attachmentBase64}\",\"base64\"))'" }

  - id: announce
    type: slack
    config: { channel: "#ops", text: "New supplier doc saved: {watch.attachmentName}" }

That’s it. Schedule it once, and your inbox-to-filesystem-to-Slack pipeline runs forever, the same way, every time, with audit logs you can read.

The same primitives compose into anything else you’d otherwise hand-script:

Pull the latest GitHub PRs, summarize them with an agent, and post the digest to a Notion page each morning.
Watch an Outlook calendar for new client meetings, drop a research brief into ./prep/, and ping the account exec.
Hit a web app with Playwright, fill a form, capture the confirmation screenshot, and file it under ./evidence/{date}/.
Walk a directory, run a code generator with a subagent, validate the output, and open a PR if the diff is non-trivial.
Scrape an HTTP endpoint on a schedule, branch on the response, and cancel itself cleanly when the underlying ticket closes.

If you can describe the workflow in steps, you can write a spell for it. The engine handles the boring parts — sequencing, variable interpolation between steps, retries, rollback on failure, structured per-step results — so the spell file stays focused on intent.

The /flo command is itself a spell

This is the part developers usually don’t realize: MoFlo’s flagship /flo <issue> command — the one that picks up a GitHub issue, plans it, spawns specialist agents, writes code, runs tests, opens a PR — is just a spell. It lives as a YAML definition, composed from the same step commands available to you. No special path, no hidden engine.

The same applies to /flo epic, the multi-issue orchestrator. It’s a spell that loops over child stories, dispatches sub-spells in parallel, gathers their results, and consolidates them into one merged epic PR. We dogfood the spell engine for our own flagship workflow precisely because if it isn’t good enough for us, it isn’t good enough to ship.

Practically, that means anything /flo can do, your own spells can do too. The IMAP-to-Slack pipeline above runs through the exact same runner, sandbox tiers, capability gates, and credential store as the command that wrote this paragraph’s tests.

Safety, with the sandbox tier picked for your OS

An automation layer is only useful if you can trust it to run unattended. MoFlo treats safety as a layered contract, not a single switch.

Permission disclosure before you cast. Before any spell runs for the first time, MoFlo analyzes its steps and shows you exactly what permissions it needs — filesystem read/write, network access, shell execution, credentials, browser, agent spawning — with a per-step risk grade (low / medium / elevated / dangerous). You accept once; the acceptance is recorded so the next cast doesn’t re-prompt unless the spell changes. No surprises, no opaque “trust me” buttons.

OS-level process isolation, picked for your platform. Bash steps don’t just run; they’re wrapped in the most efficient sandbox each operating system actually supports:

Linux — bwrap (Bubblewrap). Read-only root, network namespaced off unless declared, PID isolation, writable mounts only on paths the step asked for. Native, fast, no daemon.
macOS — sandbox-exec with a generated .sb profile. Same posture: deny-by-default filesystem, network gated by capability, kernel-enforced.
Windows — Docker with a hardened minimal image. Same posture, same capability checks, with a bind-mount only for the writable paths the step requested.

Same spell file, same capability declarations, same observable behavior — the runner picks the right primitive for the host. You don’t write OS-specific spells.

Capability gateway in front of every step. Every step command declares the capabilities it needs (fs:read, fs:write, net, shell, memory, credentials, browser, agent). The runner blocks any I/O the step didn’t declare. Spell authors can narrow a default — fs:read restricted to ./config/, shell restricted to ["cat", "jq"] — but never expand it. A CAPABILITY_DENIED error is intentional, not a problem to engineer around.

Catastrophic-pattern denylist. Before any sandbox decision happens, an unconditional denylist blocks the things nobody ever wants: rm -rf /, git push --force main, chmod -R 777, fork bombs, curl | sh. Cross-platform, non-overridable, runs first.

Encrypted credential store. Spells that need an API token, an OAuth refresh token, or a database password reference them as {credentials.SLACK_TOKEN}. The values live in an encrypted store — never in the spell file, never in environment variables checked into git, never echoed in logs. The credentials capability has to be explicitly granted, and steps that use it are flagged in the permission disclosure.

The contract for an agent running inside a spell is brutally simple: do what the step says, nothing more. That’s what makes a scheduled spell safe to deploy at 3 a.m.

Connectors and steps: components, not copy-paste

Spells aren’t monolithic scripts. They’re compositions of two reusable primitive types:

Step commands — the verbs. bash, github, browser, memory, agent, condition, loop, parallel, prompt, wait, imap, outlook, slack, mcp, graph. Each one is a typed module with declared capabilities, a config schema, and validate / execute / rollback hooks.
Connectors — the transports. http-tool, github-cli, playwright, imap, local-outlook, slack, graph (Microsoft), mcp-client. A connector handles one I/O surface — auth, retries, rate-limit, response parsing — so step commands don’t reinvent it.

The win is composition. The Slack connector handles auth and rate-limit; the Slack step command exposes slack.post and slack.thread.reply; ten different spells share the same connector instance and the same credential. When the Slack API changes, you fix one file. When you want a new behavior — say, posting to a thread instead of a channel — you extend one step command, and every spell in your library inherits it.

That’s the difference between scripting and engineering: a script is a one-off, a spell is a piece of a system. Your /flo spell, your IMAP-to-Slack spell, your nightly deploy spell — they all draw from the same shelf.

Spell-creation skills: walked through, not stared at

You don’t have to learn the spell schema to write spells. MoFlo ships three Claude Code skills that handle the structural parts so you can focus on intent:

/spell-builder — the primary author. Walks you through creating a new spell from scratch or editing an existing one: arguments, step composition, capability declarations, variable wiring between steps, validation, and a dry-run before first cast. It knows what step commands and connectors exist and proposes the right composition based on what you’re trying to do.
/connector-builder — the components author. When you need a brand-new step command or connector — a new I/O transport, a new platform integration — this skill scaffolds it: capability declarations, config schema, validate/execute/rollback skeleton, registry wiring, and a tests stub. New verbs that everything else can then compose with.
/spell-schedule — the operator. Schedules a spell on the local moflo daemon: cron, fixed interval, or one-off. Handles the daemon registration, next-run preview, and tear-down, so “run this every weekday at 9 a.m.” takes one prompt instead of a config-file expedition.

The skills are first-class moflo product, not prompt templates. They run the same engine, respect the same capability gates, and produce spells that drop straight into your library.

Start a library

npm install --save-dev moflo
flo init

Then, in any Claude Code session, type /spell-builder and describe the workflow you want. The skill will walk you through the steps, the capabilities, the schedule if you want one, and the safety review before first cast. Your first spell will be in your grimoire in under five minutes.

The biggest unlock isn’t any one spell — it’s having a library of them. Every workflow you used to half-remember, paste from a README, or hold together with shell aliases becomes a tested, sandboxed, version-controlled artifact your team can read, share, and trust.

All wizards have a library of spells. What are yours?

npm: npmjs.com/package/moflo — npm install --save-dev moflo

GitHub: github.com/eric-cielo/moflo