Skip to content
pi-code

Roadmap

Where pi-code is headed. These are concrete features in design, not vague aspirations. Each one has a detailed design document in the repository.

Teams Live Dashboard Widget

Medium complexityPlanned

The teams extension spawns persistent teammate sessions with a shared task board and inter-agent messaging — but has no live widget. You see tool output scroll by without an at-a-glance view of which teammates are working, which tasks are claimed or blocked, or what messages are flowing between agents.

The fix: a persistent setWidget dashboard that auto-updates as team state changes. Task board with status icons, teammate list with colored names and working/idle indicators, and a live message feed — all in one responsive panel using the same visual language as the tasks and subagent extensions.

Wide terminals show tasks and teammates side-by-side. Narrow terminals stack vertically. The widget appears on team_create and disappears on team_shutdown.

Extension: teamsAPI: ctx.ui.setWidget()Depends on: pi-tui, Theme API

Parallel Plan Execution via Git Worktrees

High complexityDraft

One plan, N worktrees, N models. Give pi-code a task, pick three models, and it spins up isolated git worktrees — one per model — all running the same plan in parallel. When they finish, compare approaches side-by-side: diffs, test results, token costs, wall-clock time.

This is real model evaluation on your actual codebase. Not synthetic benchmarks — your code, your constraints, your judgment on what “better” means.

The system uses two extensions: worktree-arena for orchestration (worktree lifecycle, agent spawning, cleanup) and an optional terminal pane provider (WezTerm, tmux, Zellij) for visual multi-pane display. Without a display extension, agents run in the background with log files.

Invocation: pi-code plan exec —models claude,gpt-4o,geminiConfig: .pi/plans/*.yamlSetup: .pi/worktree.yaml

Unified Plugin System (Claude Code + pi compatible)

High complexityNearly complete

One plugin system that understands both ecosystems. pi-code reads from .claude/ (Claude Code convention) and .pi/ (pi convention) at every level: project-local, user-global, and system. Both directory trees are scanned, merged at runtime, and project-local always wins.

Claude Code users bring their existing setup. pi users get the additional structure pi expects: extensions, prompts, skills, agents. No migration, no duplication. Drop a command in .claude/commands/ or .pi/commands/ and it works.

Claude Code compatibility maps CC config locations (~/.claude/.claude.json, .claude/commands/, CLAUDE.md) into pi-code’s runtime. CC lifecycle hooks (PreToolUse, PostToolUse, Stop) map to pi-code events. MCP servers declared in CC config register through the mcp-adapter. Slash commands merge into pi-code’s command system.

pi-native paths add what CC doesn’t have: extensions, typed prompts with subcommands, skills, and agents at the project level.

Scopes:

  • Commands. .pi/commands/ project-local and ~/.pi/agent/commands/ global, via commands-folder extension. CC-format commands/ from plugin sources via plugins extension.
  • Prompts. .pi/prompts/ and ~/.pi/agent/prompts/ natively discovered by pi. Registered as /name slash commands.
  • CC Hooks. PreToolUse, PostToolUse, Stop mapped to pi events via plugins → hooks:merge event bus. Extension-level hooks.json scanning in both ~/.pi/agent/extensions//hooks.json and .pi/extensions//hooks.json.
  • CC Context. CLAUDE.md and AGENTS.md loaded natively by pi from cwd, ancestor directories, and ~/.pi/agent/. Injected into system prompt automatically.
  • Settings. .pi/settings.json deep-merges with ~/.pi/agent/settings.json via SettingsManager. Project overrides user defaults.
  • Hooks. .pi/hooks.json and .pi/settings.json (hooks key) merge with global hooks. Supports standalone files, settings-embedded hooks, and extension-level hooks.json scanning.
  • Skills. .pi/skills/ discovered natively by pi at project level, layered on top of ~/.pi/agent/skills/.
  • Agents. .pi/agents/ discovered at project level by agent-commands and subagent extensions, layered on top of ~/.pi/agent/agents/.
  • Extensions. .pi/extensions/ discovered natively by pi at project level, alongside ~/.pi/agent/extensions/.

Remaining: .claude/commands/ directory scanning (currently only .pi/commands/), .claude.json settings passthrough, MCP server registration from CC config.

CC paths: .claude/*, CLAUDE.md, .claude.jsonpi paths: .pi/*, AGENTS.mdDone: commands, prompts, CC hooks, context files, settings, hooks, skills, agents, extensions

Prompt Stash (Ctrl+S)

Low complexityPlanned

You’re composing a long prompt and need to do something else — run a quick command, ask a different question. Today you lose what you’ve typed or paste it somewhere manually.

Ctrl+S stashes the current input and clears the field. Ctrl+S again pops it back. Simple stack semantics: multiple stashes supported, last-in-first-out. When the input is non-empty and the stack has a previous stash, it swaps — current input goes onto the stack, previous one comes back. A brief notification shows the stash count.

In-memory only — cleared on session end. No files, no settings.

Keybinding: Ctrl+SStorage: In-memory stackExtensible to: /stash list, /stash pop N

Plugin Git Sources and Caching

Medium complexityPlanned

The plugins extension can parse and classify git sources (git:github.com/user/plugin@v1.0.0) but rejects them at runtime — only local paths work today. The cache infrastructure (content hashing, TTL logic, mtime comparison) is fully implemented in utils.ts but not wired into the session lifecycle.

The fix: connect the existing plumbing. Git-pinned sources (@version) clone once and cache immutably — never re-fetched. Git-unpinned sources clone and cache with a 1-hour TTL, then git fetch when stale. Local sources cache scan results and invalidate on mtime change, with a content hash as secondary check.

/plugins refresh will force-invalidate all cache entries and re-scan within the running session, replacing the current “restart pi” message.

Extension: pluginsCache dir: ~/.pi/cache/plugins/Existing code: CacheEntry, computeContentHash, shouldRefreshCache

Plugin Source Caching and Git Support

Medium complexityPlanned

The plugins extension re-scans all local sources from disk on every session start, and git sources (git:github.com/user/plugin@v1.0.0) don’t work at all. The caching infrastructure already exists in the code — content hashing, mtime comparison, TTL checks — but none of it is wired up.

The plan: local sources skip re-scanning when mtime is unchanged. Git pinned sources (@version) clone once and cache immutably. Git unpinned sources re-clone on a 1-hour TTL. A cache index at ~/.pi/agent/plugins-cache/index.json tracks everything. /plugins refresh force-refreshes all sources regardless of TTL.

Extension: pluginsCache: ~/.pi/agent/plugins-cache/Exists: CacheEntry, computeContentHash(), shouldRefreshCache()