The Spell editor is where you shape a spell by hand: its steps, the tools each step uses, the reference files it reads, and the history of runs. Whether the Familiar built the spell or you started it yourself, it opens here on the same plan.
The Spell editor is where a Spell (a saved, runnable response automation) is built and edited by hand. Whether the Familiar assembled it from a sentence or you started it yourself, the editor opens on the same structured plan and lets you shape every part of it: the trigger, the steps, the tool bindings, the knowledge it reads, and the runs it has produced.
The step editor and the lifecycle bands
Steps are grouped into five bands that read top to bottom: the trigger that starts the Spell, then investigate, decide, act, and verify. Each step names what it does and which tool it uses. A tool that is wired shows as Connected in teal; one that is not yet connected shows in orange as needing attention. A step that cannot run at all is the only thing shown in red. You add, reorder, and retag steps directly, so the plan you see is exactly what will run.
Draft, save, and resume
A Spell can be saved while it is still incomplete. A draft with a missing trigger or an unconnected tool saves without complaint and simply shows what still needs attention, so you never lose work to a validation wall. Full checks apply only when you promote the Spell out of draft or run it. You can leave the editor and come back, or hand off to the Familiar to keep building in conversation and return to the editor afterwards.
Versions
Every save that changes the plan snapshots a new version, so the editor keeps a history of how the Spell evolved. The Versions tab lists those snapshots with who saved each one and when, giving you a paper trail for a Spell that a whole team touches over time.
Knowledge base
Attach files that teach the Spell the context it needs: a runbook, a policy, a list of known good senders. Uploaded files are extracted and made available to the agent steps as reference, so the Spell reasons with your own context instead of generic assumptions.
Runs and the Seal
Running a Spell sends it through the safety gate and records a receipt for every step. Read steps are observed, agent steps run on their own, and any privileged write pauses at a Seal (the human approval checkpoint) rather than firing, where every proposal joins the Seals queue for a human decision. The Runs tab shows each run truthfully: where it paused, what is awaiting approval, and the outcome of every step. See Spells for how a Cast reads once the Spell is live.