Add pi agent to devshell and wire up local MCP setup

[ncrmro]

Problem

The dev shell currently exposes a claude wrapper that auto-loads the local plugins and uses the project-level .mcp.json (the deepwork-dev server running uv run deepwork serve --platform claude). There is no equivalent for pi — the numtide/llm-agents.nix packaging of the earendil-works/pi coding agent — so contributors who want to dogfood DeepWork against pi have to hand-roll an MCP config and install pi out-of-band.

Proposal

1. Add the numtide/llm-agents.nix flake as an input and expose its pi package in devShells.default.packages (alongside python311, uv, git, jq, gh).
2. Make the in-shell pi see the local deepwork-dev MCP server by default — equivalent to what the claude wrapper already does for Claude Code.

Implementation sketch

flake.nix:

inputs.llm-agents.url = "github:numtide/llm-agents.nix";
inputs.llm-agents.inputs.nixpkgs.follows = "nixpkgs";

# in devShells.default
packages = [
  pkgs.python311 pkgs.uv pkgs.git pkgs.jq pkgs.gh
  inputs.llm-agents.packages.${system}.pi
];

pi reads MCP servers from ~/.pi/agent/mcp.json, not the project-level .mcp.json. Two viable approaches:

• A. Per-shell config dir. Set PI_CONFIG_HOME=\"\$REPO_ROOT/.pi\" (or whatever env var pi honors — verify) in the shellHook and materialize \$REPO_ROOT/.pi/agent/mcp.json pointing at uv run deepwork serve --platform claude. Mirrors the claude wrapper pattern: zero global side-effects, lives and dies with the shell.
• B. Import from existing claude-code config. pi reportedly supports importing MCP configs from other agents (cursor, claude-code, claude-desktop, vscode, windsurf, codex). If it can read from the project's .mcp.json directly, prefer that — one source of truth.

A should be safe to do unconditionally. B needs verification against the current pi release.

Acceptance criteria

• nix develop (or direnv-activated shell) yields pi on PATH.
• Running pi inside the shell can call DeepWork MCP tools (get_workflows, start_workflow, finished_step, …) without any manual setup.
• No state leaks out of the worktree — no writes to ~/.pi/ unless the user is using approach B and already has that directory.

Out of scope

• Shipping pi to end users (the plugin install flow is unchanged).
• Onboarding docs / README updates — separate PR once the wiring works.