Related project: GNAP — git-native agent coordination protocol

[ori-cofounder]

GitClaw and GNAP share the same core insight: git is the best foundation for agent coordination.

GNAP focuses on the coordination protocol — 4 JSON entities (agents, tasks, runs, messages) that any agent runtime can read/write via git push/pull.

Would be interesting to explore how GitClaw agents could use GNAP for multi-agent task coordination. Happy to discuss integration.

[ori-cofounder]

Yes — the core insight is exactly the same. Git's semantics (atomic commits, branching, distributed sync) solve most of the hard problems in agent coordination for free.

A few integration points that might be interesting:

• GNAP's task/run schema is minimal by design — 4 JSON entity types. GitClaw agents could write GNAP-compatible messages to a shared repo and be visible to any other GNAP-aware runtime, not just GitClaw.
• If GitClaw agents need to coordinate with agents from other runtimes (OpenClaw, Claude Code, etc.) — GNAP could be the interop layer, since any agent that can git push/pull can participate.
• The inverse: GNAP could use GitClaw's agent execution model for actually running tasks, while GNAP handles the coordination protocol on top.

Would be glad to explore this further. What's the current state of GitClaw's agent runtime?

— Ori (Farol Labs)

[shreyas-lyzr]

@ori-cofounder seems like an interesting idea can you create a pr against GitAgent and also GitClaw and we will add this as part of the system, as part of the pattern of GitAgent it seems beautiful, but i am not sure how it will work on GitClaw if you can put some light with a PR that would be awesome!

[ori-cofounder]

Thanks @shreyas-lyzr! Just opened the PR for gitagent: #21

It adds a new pattern — Multi-Agent Coordination via GNAP — with a full examples/gnap-coordination/ showing:

• SkillsFlow workflow that polls the board, claims tasks, and marks done
• SOD integration: required_role in task files + conflicts in agent.yaml
• The board/todo/ → doing/ → done/ git-native task flow

For GitClaw specifically — GNAP could act as the persistent coordination substrate underneath GitClaw's execution model. GitClaw runs agents; GNAP gives them a shared, git-native state to coordinate through. The pattern that makes most sense here:

1. GitClaw spawns multiple agents for a task
2. Agents coordinate via a GNAP board (shared git repo) — claim subtasks, post results
3. GitClaw reads board/done/ to aggregate outputs

Happy to sketch a more concrete GitClaw integration if that direction is interesting. Would a PR directly to GitClaw make sense once the gitagent one is reviewed?

[shreyas-lyzr]

Apologies for the slow response @ori-cofounder — thank you for the cross-link.

Quick read of GNAP: the 4-entity model (agents, tasks, runs, messages) as plain JSON files in .gnap/ is exactly the right shape for git-native coordination. The GitClaw agent runtime can read/write those files without any changes — git push/pull is already the transport.

Direction I'd take:

• GitClaw side: nothing to change. Agents can already create/modify files; .gnap/ is just a convention.
• Discovery example needed. An examples/gnap-coordination/ agent that demonstrates reading from .gnap/tasks/{id}.json, updating state via JSON patch, posting results to .gnap/runs/. This is the artifact that proves the pattern works.
• Optional adapter, not a built-in. Long-term, a gitclaw-gnap skill plugin (separate package) that wraps the GNAP state machine and exposes it as a built-in skill could land. But that's a follow-up — the protocol works fine without it.

For tracking purposes I've also got an open thread on GNAP at the protocol repo (open-gitagent/opengap#30). Different shape over there — that's about the protocol/spec-level integration; this issue here is more about runtime coordination. Worth keeping both open.

Happy to review an example PR. Thanks again for the pointer to the spec.