I am an external contributor and had a few PRs merged there and I'm using a heavily customized fork.
Two core ideas I think are right:
- Worktrees as the essential unit of the project interface, not a secondary feature. It kinda makes it a default thought for every coding session: maybe I create worktree instead of sending multiple agents in one workdir.
- A hierarchical spec view
The interesting tension is that it's built around pi, which has a tiny share, while the potential users of agentic IDEs are already on Claude Code or Codex. That's why my fork is about hosting Claude Code compatibility and adding to GUI what's my missing for CC.
CommanderTvis•1h ago
Two core ideas I think are right: - Worktrees as the essential unit of the project interface, not a secondary feature. It kinda makes it a default thought for every coding session: maybe I create worktree instead of sending multiple agents in one workdir. - A hierarchical spec view
The interesting tension is that it's built around pi, which has a tiny share, while the potential users of agentic IDEs are already on Claude Code or Codex. That's why my fork is about hosting Claude Code compatibility and adding to GUI what's my missing for CC.