A coding agent that loads only the skills and tools you name.

It begins with one useful MCP server. Then another. Soon the agent fixing a heading wakes up with database tools, browser controls, and their small novel of schemas. This is our config.

DoomPi is an opinionated, composable distribution of Pi. It is closer in spirit to Spacemacs, Doom Emacs, or a curated Neovim setup than to a single plugin. It is tailored for people whose agents have too many skills and tools. It turns extensions, skills, MCP servers, and system prompts into config instead of background noise.

Plugin systems often rely on model-driven discovery to decide what context to load. Codex, for example, selects plugins from their descriptions and then loads their skills, but relevant skills do not always load reliably. DoomPi makes the session composition explicit. Pick a major mode and some domains; add a profile if you want one. Four YAML files decide what loads; doompi --explain tells you what got in, why, and what it costs before launch.

It borrows its shape from Doom Emacs Core: quick to start, close to Pi, opinionated where defaults help, and easy to pull apart when they do not. Use it as-is, build your own config on top, or raid it for parts.

npm install -g @agimon-ai/doompi

The package pins and installs the upstream Pi version used by dpi. The root package contains the fixed host foundation only. Feature packages are selected by .doom/modes.yaml and installed into the consumer repository when they are first needed.

See Getting started for the full setup and sync behavior.

DoomPi is alpha software. Configuration and package boundaries may still change between alpha releases.

• Node.js 22.19.0 or newer for the published package
• Node.js 22.22.1 or newer when contributing from this workspace
• macOS or Linux on arm64 or x64 for the bundled Runner backend
• Pi 0.85.0 and Pi TUI 0.85.0 for packages that declare them as peer requirements

dpi is the comparison runner. Use it to try DoomPi beside your current pi customization before registering anything in Pi's settings:

dpi init
dpi sync
dpi

dpi init creates this repository's .doom configuration. dpi sync installs required configured packages and writes synchronized state without persisting a Pi settings overlay. dpi runs the pinned Pi version with that in-memory overlay. Your existing pi setup remains available for comparison.

See Getting started for worktree storage, permanent registration, and per-run matrix flags.

An agent does not need every tool for every job. DoomPi separates the base session from the things you switch on for a while: modes choose behavior, domains choose subject matter, and profiles choose a point of view.

A major mode is the base config. It names the extension layers that should run together. Minor modes are batteries-included switches inside that base. They stack freely and keep their tools and skills out of context until turned on.

A domain is a named group of agent plugins. It carries the skills and MCP servers for one kind of work, and /domains switches it while the session is running.

A profile can supply a narrative, brand rules, or a different voice. It is optional; no profile is a perfectly good profile.

See Concepts for discovery, caching, merge behavior, and examples.

Every tool schema and skill name consumes context and gives the model another possible choice. A smaller composition uses fewer tokens before work starts and reduces the number of irrelevant tools the model can select. Workflow jobs can choose their own composition instead of inheriting the previous job's toolbox.

Press SPC on an empty draft to open a map of the commands available in the current composition. When the keyboard is the wrong tool, autonomous Voice mode can keep the conversation going.

Loop and Workflow keep work moving when you are not present. Together they can dispatch structured jobs from one live session. See Automation for workflow syntax, tracked examples, and loop behavior.

DoomPi is a distribution, not one giant extension. Each package owns one job; shared TUI, Cordis services, and session contracts make them behave like one.

• Foundation and interface: configuration, domains, hashline tools, the Leader key, logs, and telemetry.
• Coordinated work: agent teams, persistent tasks, supervised commands, and staged compaction.
• Context and access: Help mode, scoped MCP access, structured questions, and operational metrics.
• Modes and automation: Plan, Loop, Goal, Workflow, and Voice modes.

See Features for the complete package catalog and behavior of each feature.

DoomPi reads four configuration files:

• config.yaml defines runtime settings such as trust, editor, planning, and voice behavior.
• modes.yaml defines default packages, extension layers, and major modes.
• domains.yaml catalogs plugins and sets session access.
• profiles.yaml supplies persona files and environment defaults.

Personal defaults live in ~/.pi/.doom/; repository overrides live in <repository>/.doom/. See Configuration for resolution rules, complete examples, and matrix checks.

DoomPi executes the extensions, remote Git/npm plugins, hooks, MCP stdio commands, workflows, and shell commands you configure. Treat them as trusted executable code.

See the Security model for the threat model, what guards the cockpit once it is reachable from a phone, and what is deliberately left open. See Trust and data boundaries for process privileges, credentials, model calls, voice, and telemetry behavior.

See the CLI reference for more commands, options, and direct-use guidance.

See Troubleshooting and direct use for sync drift, Runner fallbacks, headless sessions, and direct package installation.

See Architecture for standard Pi package composition, canonical fingerprints, transition classification, synchronized bundles, shared-host Cordis lifecycle ownership, and parent/child isolation.

See Contributing for local setup, repository boundaries, verification, commits, and pull requests. See Development for the maintainer release order.

DoomPi is maintained by Agimon.

MIT