PI PACKAGE EXTENSION

Oh My Pi

Pi-native cmux integration: notifications, split panes, and workspace tabs via native cmux CLI. No tmux-compat shims.

Overview

Pi-native cmux integration: notifications, split panes, and workspace tabs via native cmux CLI. No tmux-compat shims.

Package docs also remain available on the package summary page at /docs/oh-my-pi, but this page focuses on the Pi-native extension surface: commands, tools, environment variables, packaged skills, and extension files.

Environment

  • PI_CLI_PATH (default: auto-detect) - Optional absolute path override for the Pi launcher used in spawned cmux panes. Usually unnecessary because oh-my-pi reuses the current session's Node/Pi install automatically.
  • PI_CMUX_NOTIFY_LEVEL (default: all) - all, medium (skip "Waiting"), low (errors only), disabled
  • PI_CMUX_NOTIFY_THRESHOLD_MS (default: 15000) - Duration in ms above which a success run becomes "Task Complete"
  • PI_CMUX_NOTIFY_DEBOUNCE_MS (default: 3000) - Minimum ms between duplicate notifications
  • PI_CMUX_NOTIFY_TITLE (default: Pi) - Notification title shown in the cmux notification panel

Extension Files

Primary extension path: pi-packages/oh-my-pi/extensions/oh-my-pi

  • cmux-notify.ts
  • cmux-split.ts
  • cmux-workspace.ts
  • index.ts

Installation

bash 
pi install git:github.com/DiversioTeam/agent-skills-marketplace
/reload

Why this package exists

Diversio uses Pi inside cmux all day.

That means we already have two strong systems:

and show native notifications.

So the simplest good solution is:

We intentionally do not emulate tmux, fake notifications with OSC escape sequences, or add runtime-heavy dependencies. We use the cmux features that already exist.

  • Pi knows when the agent starts, reads files, changes code, fails, and waits.
  • cmux knows how to open panes, create workspace tabs, track unread state, and show native notifications.
text 
Pi lifecycle events  ──► summarize what happened ──► cmux native UX

Mental model

text 
@diversioteam/pi-cmux
  ├─ knows how to talk to cmux safely
  ├─ builds shell / Pi launch commands
  ├─ opens splits and workspace tabs
  └─ provides the low-level notify primitive

cmux-notify.ts
  ├─ listens to Pi events
  ├─ collects simple facts during a run
  └─ sends one useful notification at the end

cmux-split.ts
  └─ exposes readable /omp-split-* commands (+ short aliases)

cmux-workspace.ts
  └─ exposes readable /omp-workspace* commands (+ short aliases)

How this relates to dev-workflow

oh-my-pi is the explicit cmux command surface.

This package used to carry all of the low-level cmux mechanics itself.

That worked until the same mechanics also existed somewhere else.

From first principles, split launching is exactly the kind of code that should have one shared implementation:

If two packages each implement that flow, they will eventually diverge. When they diverge, one package gets the hardening and the other keeps the old failure mode.

So the new architecture is:

That separation keeps oh-my-pi easier to reason about: command UX lives here, terminal mechanics live in the shared library.

That means if you want to manually say:

then oh-my-pi is the package that gives you those commands.

dev-workflow now also uses cmux automatically for some workflow commands like /workflow:reviewer when Pi is inside cmux and the parent session is idle.

Why not make dev-workflow call /omp-split-right directly?

Because the packages should stay independently installable.

So the mental model is:

  • "open a split to the right"
  • "run this shell command in a split"
  • "open a named workspace tab"
text 
open pane
  -> build command string
  -> preserve PATH
  -> start Pi or a shell command
  -> keep the pane readable if startup fails
text 
oh-my-pi
  ├─ owns the user-facing slash commands
  └─ delegates the brittle cmux mechanics to @diversioteam/pi-cmux

@diversioteam/pi-cmux
  ├─ owns split/workspace/notify primitives
  ├─ owns hardened shell and Pi command building
  └─ is shared by oh-my-pi and dev-workflow