Feature request: GNAP coordination for Plandex multi-instance workflows
Plandex is designed for large projects — multi-step planning, persistent context, and handling complex codebases. For truly large projects (microservices, monorepos), running multiple Plandex instances in parallel would be powerful. GNAP provides the coordination layer.
GNAP (Git-Native Agent Protocol) is a natural fit for Plandex: a git repo as the coordination board with board/todo/ → board/doing/ → board/done/. Plandex already works with git — GNAP adds zero friction.
Applied to Plandex's multi-plan workflow:
A large codebase migration split across multiple Plandex instances:
board/todo/migrate-service-auth.md ← Orchestrator creates breakdown
board/todo/migrate-service-billing.md
board/todo/migrate-service-notifications.md
board/doing/migrate-service-auth.md ← Plandex instance 1 claims
board/doing/migrate-service-billing.md ← Plandex instance 2 claims
board/done/migrate-service-auth.md ← Migration committed, tests passing
board/done/migrate-service-billing.md
Each Plandex instance handles one service's migration plan in isolation — no conflicts. GNAP's atomic task claiming (git mv) ensures two instances can't start the same service migration.
Given Plandex's "designed for large projects" positioning, GNAP-enabled multi-instance support would be a significant differentiator — enabling teams where each developer's Plandex instance handles a different module.
Spec: https://github.com/farol-team/gnap
Feature request: GNAP coordination for Plandex multi-instance workflows
Plandex is designed for large projects — multi-step planning, persistent context, and handling complex codebases. For truly large projects (microservices, monorepos), running multiple Plandex instances in parallel would be powerful. GNAP provides the coordination layer.
GNAP (Git-Native Agent Protocol) is a natural fit for Plandex: a git repo as the coordination board with
board/todo/→board/doing/→board/done/. Plandex already works with git — GNAP adds zero friction.Applied to Plandex's multi-plan workflow:
A large codebase migration split across multiple Plandex instances:
Each Plandex instance handles one service's migration plan in isolation — no conflicts. GNAP's atomic task claiming (git mv) ensures two instances can't start the same service migration.
Given Plandex's "designed for large projects" positioning, GNAP-enabled multi-instance support would be a significant differentiator — enabling teams where each developer's Plandex instance handles a different module.
Spec: https://github.com/farol-team/gnap