@agimon-ai/doompi-workflow
GitHub Actions-style workflow graphs, artifacts, recovery, and asynchronous runs for DoomPi.
Package details
Install @agimon-ai/doompi-workflow from npm and Pi will load the resources declared by the package manifest.
$ pi install npm:@agimon-ai/doompi-workflow- Package
@agimon-ai/doompi-workflow- Version
0.0.1-alpha.58- Published
- Sep 6, 2026
- Downloads
- 6,797/mo · 1,151/wk
- Author
- agiflow-ai
- License
- MIT
- Types
- extension
- Size
- 1.4 MB
- Dependencies
- 11 dependencies · 2 peers
Pi manifest JSON
{
"extensions": [
"./dist/extensions/pi.mjs"
]
}Security note
Pi packages can execute code and influence agent behavior. Review the source before installing third-party packages.
README
@agimon-ai/doompi-workflow
Discover, launch, monitor, control, and recover asynchronous DoomPi workflows.
Part of the DoomPi distribution.
The integration embeds @agimon-ai/workflow-mcp. Workflow files describe job dependencies and
host-executed steps, while DoomPi provides session-scoped tools and TUI surfaces.
Alpha: workflow and recovery contracts may change between releases.
Requirements
- Node.js 22.19.0 or newer
- Pi 0.85.0 and Pi TUI 0.85.0
Install
The seeded modes.yaml selects Workflow in default.packages. Keep it there or select it through
a layer; its tools remain inactive until Workflow mode is enabled. For standalone Pi:
pi install npm:@agimon-ai/doompi-workflow
Enable tools with SPC w e, or set WORKFLOW_MCP_MODE=on for a non-interactive harness that cannot
toggle the minor mode.
Define a workflow
Create a *.workflow.yml file:
name: verify
jobs:
test:
steps:
- name: Run tests
run: pnpm test
summarize:
needs: test
steps:
- name: Record result
run: node scripts/write-verification-summary.mjs
run commands execute on the host with the workflow process's environment and privileges. There is
no VM, container, or sandbox. Review workflow files as executable code. Runner-specific
interactiveRun mappings are available for commands that require a TTY.
Launch and monitor
Core tools are:
list_workflows: discover workflows.launch_workflow: register and start an asynchronous run.workflow_run: inspect or control a run through supported actions.
Launch returns after the run is registered, not after all jobs complete. Use status and follow controls for progress, and wait for a terminal notification.
In the TUI, SPC w l lists the repository's workflows and launches the one under the cursor with
r, SPC w r inspects this session's runs, SPC w c opens recovery, and SPC w e
toggles model-visible tools. The root session can launch; child sessions can inspect the catalog but
do not receive an unrestricted workflow factory.
Storage, concurrency, and lifecycle
Registry data defaults to $HOME/.workflow-mcp; set WORKFLOW_MCP_HOME to relocate it. Persisted
records contain workflow and run identity, job and step state, ownership, output locations, and
recovery evidence. The default concurrency ceiling is five runs.
Runs embedded directly in the Pi process end with that process. Runs launched through a terminal
host such as tmux or cmux can have a different lifetime and remain manageable from the CLI. When
Team is loaded, Workflow contributes active session runs through Team's doom/background-work
service. That contribution reconnects after Team is replaced and is removed when Workflow unloads.
Reconciliation distinguishes stale registry records from live processes; do not assume every run
outlives its parent session.
Each workflow or repair step can launch commands and model-backed agents, consuming provider quota and repeating external side effects.
Recovery
Recovery is available only for records in a terminal failure state. A recovery claim atomically adopts the eligible failure, validates the evidence, and transfers ownership to the replay session. Live controls remain scoped to the owning session. Recovery does not launch a second copy beside a still-running job and does not guarantee that parent-session work survives shutdown.
The package publishes workflow-recovery for active Workflow mode. While parent Help mode is
active, it also contributes doompi-author-workflow for writing workflow definitions and
doompi-use-workflow for launching, monitoring, and recovering runs. Deactivating Help hides both
descriptors; cached files may remain.
Each Pi extension instance uses the runner's shared Doom lifecycle. Reload or shutdown stops retained callbacks, interrupts bounded inline work, removes UI and service registrations, and releases package resources. Detached children load the same extension entry in their own process.
Pi extension
The Pi extension is published at @agimon-ai/doompi-workflow/extensions/pi and declared in
package.json.pi.extensions. Installing the package loads it automatically; there is no secondary
registration or dispatcher export.
Development
pnpm build
pnpm typecheck
pnpm test
pnpm lint
Maintained by Agimon.
Web cockpit plugin
The src/web directory is this package's DoomPi web cockpit plugin: the workflows panel the dock's
workflows group opens in a temporary tab, its store, and its workflow_runs session channel,
compiled into the cockpit bundle by doompi-web's build.
The hub-side data source ships behind the ./web-hub subpath and reads the workflow registry
(run.json plus progress.ndjson) exactly as the engine writes it. Both halves are declared by the
doompiWeb block in package.json.
License
MIT, except the src/web directory, which is source available under the DoomPi Web License (see
src/web/LICENSE): free to use, including commercially, but not to redistribute.