Rethink pi agent support: revert agent definition, use symlinks + docs instead

[bruno-garcia]

Context

PR #20 added pi as a full agent definition with MCP config writing. PR #21 followed up by making the mcp field optional on AgentDefinition since pi does not have built-in MCP support.

After discussion, we think the current approach is wrong for pi and should be replaced with the simpler symlinks-only path.

Why the current agent definition is problematic

Pi's MCP is extension-based, not core. Pi only reads mcp.json if the user has installed an MCP extension. The extension is optional, and users who have it typically manage their own config (e.g. symlinked to a personal dotfiles repo). Writing .pi/mcp.json during dotagents install either produces a dead file or conflicts with existing user config.

Pi is genuinely different from Claude/Cursor/Codex. Those agents have well-known, fixed MCP config paths that are always read. Pi does not. Listing it as an agent with mcp: undefined creates a false equivalence and produces a misleading "Pi doesn't support MCP" warning for users who DO have the MCP extension.

The only thing dotagents needs to do for pi is create a symlink. Pi reads skills from .pi/skills/ (project) and ~/.pi/agent/skills/ (user). A symlink to .agents/skills/ gives it all dotagents-managed skills. That's the entire value proposition — and it already works today via [symlinks].

Plan

1. Revert PR feat: add Pi coding agent support #20 — remove pi from the agent registry, agent definition, and paths
2. Close PR refactor: make MCP support optional per agent #21 — the optional MCP infrastructure change may still be useful for future agents, but it's not needed to solve the pi problem. Can be revisited independently.
3. Add pi setup instructions — document in the README that pi users add this to their agents.toml:

[symlinks]
targets = [".pi"]

This creates .pi/skills/ -> .agents/skills/, which is all pi needs to discover dotagents-managed skills.

Why this is better

• No code to maintain for pi — no serializer, no paths entry, no agent definition
• No dead config files written for users without MCP extensions
• No conflicts with users who manage their own mcp.json
• Documentation is official support — a clear one-liner in the README is genuinely useful
• Forward-compatible — if pi ever adds native MCP config, a proper agent definition can be added then