GNAP: git-native task board for Roo Code's multi-agent team coordination

[ori-cofounder]

Feature request: GNAP integration for Roo Code's boomerang tasks and multi-agent workflows

Roo Code v3.51 introduces slash commands for reusable workflows — and with Roo's multiple modes (Code, Architect, Ask, Debug, Custom), you already have the building blocks for a multi-agent team. Boomerang tasks let agents spin up sub-agents for parallel work. The missing piece: a shared coordination protocol.

GNAP (Git-Native Agent Protocol) fills this gap. A git repo serves as the task board: board/todo/ → board/doing/ → board/done/. Multiple Roo Code instances can coordinate on large projects without stepping on each other.

Applied to Roo Code's boomerang architecture:

A Roo Code Orchestrator mode decomposes a large feature into parallel subtasks:

board/todo/implement-backend-api.md        ← Architect mode writes spec
board/todo/implement-frontend-ui.md
board/todo/write-integration-tests.md

board/doing/implement-backend-api.md       ← Code mode instance 1 claims
board/doing/implement-frontend-ui.md       ← Code mode instance 2 claims

board/done/implement-backend-api.md        ← PR #142 committed
board/done/implement-frontend-ui.md        ← PR #143 committed

board/doing/write-integration-tests.md     ← Test instance reads both done files

Since Roo Code runs terminal commands and manages files, GNAP participation is native — no new capabilities needed. A custom Roo Code mode (Coordinator mode) could automatically manage GNAP task boards, using Roo's existing skills system.

This could make Roo Code the first coding agent with built-in multi-agent coordination via GNAP.

Spec: https://github.com/farol-team/gnap

[roomote-v0]

I have looked into this issue and wanted to share some observations and questions before proposing a plan.

Roo Code already has a solid delegation/subtask architecture: the new_task tool lets an Orchestrator mode spin up child tasks (Code, Architect, Debug, etc.), and the ClineProvider.delegateParentAndOpenChild() / reopenParentFromDelegation() flow handles parent-child lifecycle, metadata persistence, and result injection. However, this is all in-process -- a single VS Code instance managing a stack of tasks.

GNAP proposes a fundamentally different coordination model: multiple independent Roo Code instances (possibly on different machines) coordinating via a shared git repo acting as a task board (board/todo/, board/doing/, board/done/). This raises several design questions:

1. Scope of integration -- Are you envisioning GNAP as a new coordination layer that sits alongside the existing boomerang/delegation system, or as a replacement? The existing system handles single-instance subtask chains well; GNAP would add multi-instance coordination on top.

2. Claiming mechanism -- In GNAP, an agent "claims" a task by moving it from todo/ to doing/. With multiple Roo Code instances, how should conflicts be handled? Git-level locking, optimistic concurrency with retry, or something else?

3. Task file format -- The GNAP spec at https://github.com/farol-team/gnap describes task files in markdown. Should these map 1:1 to Roo Code modes (e.g., a task file specifies mode: code), or should the claiming instance decide what mode to use?

4. Integration surface -- Should this be:

   • A new built-in tool (e.g., gnap_claim, gnap_complete) available to modes?
   • A new custom mode ("Coordinator") that wraps GNAP operations?
   • An MCP server that provides GNAP operations as tools?
   • Some combination of the above?

5. Polling vs. watching -- How should a Roo Code instance discover new tasks? File watching on the board directory, periodic polling via git pull, or manual trigger?

6. MVP scope -- Given the breadth of this feature, what would a minimal first version look like? For example: read-only board awareness (showing tasks in the UI) vs. full claim/execute/complete lifecycle?

These answers would help shape a concrete implementation plan. Please tag @roomote in your response and I will move forward from there.