collaborative-code

Collaborative Graph-Native Code

Use the code document graph as the shared source tree. Generated files are read-only projections for builds and tests. Contributors must never patch them.

Required server surface

This skill requires the server to run with TOOL_MODE=collaborative_coding and advertise the solver_* tools. If those tools are unavailable, do not imitate persistent tasks, ownership, or locks in chat. Work serially through code-work, or ask the user to restart the server in collaborative-coding mode before concurrent mutation.

Partition before concurrent mutation

The integration owner must:

1. Inspect the artifact roots or subtrees that bear on the requested change and check active locks. Read broader topology or history only when it affects partitioning; do not run a fixed orientation ritual.
2. If guided navigation would help at a consequential partition or design choice, ask for concrete graph-sensitive possibilities:

graph_suggest_next({
  task: "Build and integrate this graph-native software project",
  workflow: "collaborative_coding"
})

Consider the weights, then choose, combine, modify, or reject the routes for this task. In direct mode, partition and coordinate through the graph without this call. If a selected route needs re-entry, call graph_understand with its stance and focus. The roll is guidance, not a coordination state machine. 3. Assign one owner per document root or disjoint subtree. Avoid two active writers on the same node or sibling-order chain. 4. Give each solver a bounded outcome, owned node IDs, forbidden subtrees, dependencies, acceptance commands, and required handoff shape. 5. Name one integration owner before mutation begins.

Lock graph ownership

Locks protect graph resources, not generated files:

solver_lock({
  resource_ids: ["n_code_root"],
  holder_id: "parser-contributor",
  scope: "subtree",
  duration_minutes: 10,
  reason: "Own parser source nodes through handoff"
})