Skip to content

Team Workflow

Jump to bottom
Chris Sweet edited this page Jul 14, 2026 · 4 revisions

type: reference up: "What-is-the-llm-wiki-Template" related:

Team Workflow

How groups collaborate on a shared wiki. Grounded in the multi-agent write protocol (wiki/agents/wiki-write-protocol.md, scripts/wiki-write-protocol/), the discipline gates, the log-attribution convention, and the agent-comms federation feature. Where a capability is a reference implementation not yet wired into the default path, or is undocumented, it is marked.

Can multiple people edit the same wiki concurrently?

Yes. The wiki is a shared git repo, so multiple people (and their agents) pull, edit, commit, and push it like any repo. The template adds a coordination layer for the case that makes wikis painful: two writers pushing near-simultaneously. The vision materials note production wikis routinely have three or four writers, and the write protocol exists specifically to make that collision-free.

How do we handle merge conflicts on the wiki?

Two classes, handled differently:

  • Index and log files (index_*.md, log_*.md) union-merge mechanically via .gitattributes merge=union. Both writers' appended entries survive, in commit order, with no human involvement. The one-commit-per-log-entry discipline ensures entries do not interleave within a commit.
  • Content pages conflict only when two writers edit the same lines of the same section. Then a conflicted file is left on disk with markers, and the resolving agent reads both sides on its next turn and decides drop / adapt / supersede. Different pages, or different sections of one page, three-way-merge cleanly with no intervention.

What is the wiki-write-protocol (wiki_push), and why not just git push?

wiki_push (in scripts/wiki-write-protocol/protocol.sh) is an optimistic-push-with-retry wrapper. The reason not to use plain git push: a plain push is rejected when someone else pushed first, and the agent has to back out and reconcile manually. wiki_push instead tries the push, and on rejection fetches, merges (union-merge handles index/log automatically), resolves any genuine content conflict, and retries, up to a retry cap. The result: only one ref-update to main ever lands at a time, main is never half-merged, and readers always see a consistent wiki. From the outside it is still a normal git repo with periodic merge commits. Invoke it via the procedure in wiki/agents/wiki-write-protocol.md when pushing a shared wiki.

Status note: the protocol is specified and its reference implementation passes nine CI scenarios, but it is not yet wired into the agent overlay's default write path as of 2026-07-14. Today you invoke it deliberately when pushing; single-writer projects can push normally.

What is the discipline-gates document and how does it protect us?

wiki/agents/discipline-gates.md is the agent-agnostic enforcement layer shared across overlays. It names the "Universal Rationalizations (Always Wrong)" (e.g. "I'll add the cross-reference later", "the projection is fine to file", "good enough to commit") and the counter to each, plus three gate types (Design, Verification, Sequential) and a skill-dependency chain. It protects a team by converting honesty rules into checks the agent runs before a bad write lands, so one contributor's shortcut does not silently pollute everyone's shared memory. The Verification Gate is its canonical pre-commit instance; see Everyday-Operations.

Can students see the faculty's wiki?

Yes, if the faculty publish it. A wiki is a git repo; sharing it is a matter of the remote's visibility (public GitHub wiki, or granting access on a private one). The intended student flow is exactly this: faculty publish a topical bundle, students clone or ask against it through their own LLM. The template does not implement per-page access control; visibility is whatever the git remote grants. Fine-grained "students see X but not Y" is not documented in the template as of 2026-07-14; the unit of sharing is the repo.

How do we share wikis across labs or institutions?

Publish the wiki sub-repo to a remote the other group can clone. Two composition patterns from Knowledge-Bundles-Overview apply: read-only (their wiki sits alongside yours as a separate graph) or merged (folded in with namespace prefixes and provenance). The agent-comms feature adds a federation index (hosted at la3d-llm-agents.github.io) and an ask primitive so agents can discover and query peer bundles cross-org via a trusted-owner allowlist. That discovery/allowlist mechanism is part of the agent-comms feature, not the base template.

Can I clone another group's wiki as a reference?

Yes. git clone the wiki repo and either read it directly, point an LLM session at it, or use the agent-comms ask primitive, which clones a peer bundle into ~/.llm-agents/wikis-cache/, runs an LLM query against it, and returns the answer without the peer being involved. Reference-only consumption does not require merging anything into your own wiki.

What happens if two LLM agents write to the wiki at the same time?

The write protocol serializes them at the push level. Whichever pushes first wins; the second's push is rejected, so it fetches, merges (index/log union-merge automatically), resolves any true content overlap semantically, and retries. If both created the same new page, one becomes the base and the other's version is folded in. If the retry cap is hit, the protocol halts and surfaces the situation, leaving the agent's un-pushed commits for inspection. This is Optimistic Concurrency Control with the LLM as the semantic resolver.

How do we assign attribution when the LLM authors most of the content?

Through the log-attribution convention. Every log_<repo>.md entry's first bullet is - by: <human> via <agent>, where <human> is git config user.name in the wiki repo (read, not invented) and <agent> is the assistant (e.g. claude-code). Combined with one-commit-per-log-entry, git blame on the log stays a faithful per-entry, per-author record. So attribution is to the directing human via the agent that did the work; git history is the verifiable copy and the by: line is the human-readable one, and they must agree.

How does licensing work if we share the wiki publicly?

Not specified by the template as of 2026-07-14. The wiki is a git repo of Markdown; licensing is whatever LICENSE file you place in it, same as any repo. The template ships no default wiki license and no guidance on one. If you publish a bundle, add a license explicitly. (The KG extractor code under scripts/kg/ is derived from MIT-licensed prior work at LA3D/llm-wiki-colab, per its file headers; that concerns the tooling, not your wiki content.)

See also

Clone this wiki locally