magus v0.4.3 is out. See what's new
¶ View generated markdown
2 min read

magus-init

Bootstrap a workspace (magus.yaml + magusfile.buzz + merge driver)

Synopsis

magus init [flags]

Description

Bootstrap a magus workspace in the current directory.

By default, magus.yaml is written to $XDG_CONFIG_HOME/magus/ (the global user config location). Use --local to write it into the repo instead (useful for checked-in, team-shared config). The magusfile stub and VCS merge driver are always wired in the repo.

With --global only the global config is written; the per-clone workspace bootstrap (magusfile stub + merge driver) is skipped.

The config holds no keys: every key keeps its built-in default until "magus config set" changes it, so no key a later magus removes is pinned there. An existing config is left as it is; --force replaces it with an empty one. Nothing a newer magus wrote (the config, the managed sections in .gitattributes and the hooks, the merge driver registration) is replaced: init stops and names the build to update to.

The VCS is taken from --vcs, or chosen interactively when stdin is a terminal.

The "spell" subcommand scaffolds a new spell instead of bootstrapping a workspace: "magus init spell <name>" writes spells/<name>/spell.buzz with the mgs_ contract stubbed, each function documented, and a runnable test block.

Options

--dry-run
Print the config, magusfile, and merge-driver destinations without writing any of them
--force
Replace an existing config file with one holding no keys
--global
Write only the global config; skip the workspace bootstrap
--local
Write config into the repo (CWD) instead of $XDG_CONFIG_HOME/magus/
--vcs string
VCS to wire the merge driver for (git|hg); prompts when omitted on a TTY

Examples

Bootstrap the current repo

magus init

Non-interactive (CI): pick the VCS explicitly

magus init --vcs git

Write only the global config

magus init --global

Scaffold a new spell

magus init spell mytool

See Also

magus(1), magus-ls(1), magus-describe(1), magus-where(1), magus-run(1), magus-affected(1), magus-x(1), magus-clean(1), magus-shell(1), magus-query(1), magus-refs(1), magus-explain(1), magus-path(1), magus-graph(1), magus-diff(1), magus-vcs(1), magus-session(1), magus-job(1), magus-notes(1), magus-queue(1), magus-watch(1), magus-events(1), magus-server(1), magus-broker(1), magus-mcp(1), magus-status(1), magus-buzz(1), magus-spell(1), magus-agent(1), magus-doctor(1), magus-config(1), magus-completion(1), magus-man(1), magus-self(1), magus-version(1)

ManpagePages in this section. magus describeDefine a magus concept (spell, charm, target, project, workspace, module, mcp-tool, tool, file, graph, harness) and list every entity of that kind, or detail one when a name is given. magus doctorRun diagnostic checks on the workspace covering project discovery, magusfile syntax, graph cycles, symlinks, env vars, and VCS reachability. SpellsA spell is a library of tool-native ops (go-build, cargo-clippy, eslint) plus cache metadata that your magusfile composes into runnable targets.
generatedinternal/commands/registry.goclimagus initbootstrapsetupmagus.yamlmagusfileworkspace
Last updated (29d8b3de)
Earlier changes on this page (7)

Full history ↗ · Blame source ↗

Glossary

Workspace

The magus root directory that owns a set of projects and shared config; the unit magus operates over. Workspace in full.

Magusfile

The magusfile.buzz that declares a project's targets (as export funs) and binds its spells. Magusfile in full.

Op

A single tool-native command a target composes (long form: operation); the middle of the work hierarchy (Spell to Op to Target). Op in full.

Spell

A language/runtime adapter (e.g. go, md) that maps generic targets onto a toolchain's real commands. Spell in full.

Buzz

The language magusfiles are written in (the .buzz engine). Buzz in full.

Affected

The set of projects touched by a change; magus affected <target> runs a target only over them. Affected in full.

Broker

The per-user background process that holds this host's capacity: the machine budget every run claims slots from, and the shared services runs keep warm. A run starts it on demand; broker: off in magus.yaml runs without one. Broker in full.

CI

An ordinary target you compose yourself with ctx.needs; magus does not hardcode its stages. It is the anchor magus affected ci keys off, and ci strips the rw charm. CI in full.

MAGUS.md

The committed routing index at a workspace root, regenerated from the knowledge graph: it lists every node and points at the exact query for a given question, so it is the entry point an agent reads first. MAGUS.md in full.

Agent

A model working through an agent host such as Claude Code, Codex, Cursor or OpenCode. magus treats an agent as one more caller of its CLI, MCP tools and console, held to the same checks as a person. Agent in full.

Tool

An action a model can call through its host: a name, a description, a typed input and a result. magus serves its tools over MCP, each a read of the workspace model or a run of the CLI it already has. Tool in full.

Session

An agent host's conversation, by the id the host delivers to its hooks. magus never mints one: a record with no session is unattributed, and the OS user it carries says whose account ran it. Session in full.

Job

The unit of delegated work, and one row of the job store: what an orchestrating agent handed out, with its goal, the checkpoint it was cut against, the paths it may write or must not touch, and the one check it runs. A job's holder is either a session, for work an orchestrator handed out, or the daemon, for its own maintenance. The store records; the agent guard is what reads those facts back when grading a write. Job in full.

Run

One target executing under one magus invocation, such as magus run test web or magus affected ci. A run keeps its captured output behind an output reference. Every magus run is a run whether or not any job asked for it; see Job for how the two relate. Run in full.

Conventions

This page uses none of the site's convention markers. The full set is on the conventions page.