Observed Behavior
Each project's .teamwork/memory/ directory is entirely self-contained. Patterns, decisions, and anti-patterns accumulated in one repository are invisible to agents working in another repository in the same organization.
teamwork memory sync supports the hub-spoke multi-repo model but requires explicit invocation and only syncs specified domains between pre-configured repos. It is not a shared knowledge base — it is a manual copy operation between known repos.
Why It Matters
Organizations using Teamwork across multiple repositories (e.g., a Go API, a React frontend, a shared database layer, a CLI tool) repeatedly discover the same patterns and anti-patterns in isolation. An architectural decision recorded in the API repo ("we use JWT with 15-minute expiry") is invisible to the frontend repo's Architect agent. A security anti-pattern caught in one repo ("never log request bodies — they contain PII") is caught again from scratch in every other repo.
The memory system's value should compound across an organization's projects, not be reset for each new repository. This is particularly acute for startups where the same small team works across all repos and institutional knowledge transfers poorly between repo contexts.
v2 Target
A shared team knowledge base — a designated repository (e.g., org/teamwork-knowledge) or a shared directory readable by all projects in the organization:
- Agents automatically load shared patterns when they match the current workflow type and tech stack (via domain tags)
teamwork memory add --scope shared promotes a local memory entry to the shared knowledge baseteamwork memory sync --pull fetches shared entries relevant to the current project's tech stack and workflow type- The shared knowledge base is versioned (git-tracked) and auditable like all other Teamwork state
No central server required — the shared knowledge base is just another git repository that Teamwork knows how to read from.
Observed Behavior
Each project's
.teamwork/memory/directory is entirely self-contained. Patterns, decisions, and anti-patterns accumulated in one repository are invisible to agents working in another repository in the same organization.teamwork memory syncsupports the hub-spoke multi-repo model but requires explicit invocation and only syncs specified domains between pre-configured repos. It is not a shared knowledge base — it is a manual copy operation between known repos.Why It Matters
Organizations using Teamwork across multiple repositories (e.g., a Go API, a React frontend, a shared database layer, a CLI tool) repeatedly discover the same patterns and anti-patterns in isolation. An architectural decision recorded in the API repo ("we use JWT with 15-minute expiry") is invisible to the frontend repo's Architect agent. A security anti-pattern caught in one repo ("never log request bodies — they contain PII") is caught again from scratch in every other repo.
The memory system's value should compound across an organization's projects, not be reset for each new repository. This is particularly acute for startups where the same small team works across all repos and institutional knowledge transfers poorly between repo contexts.
v2 Target
A shared team knowledge base — a designated repository (e.g.,
org/teamwork-knowledge) or a shared directory readable by all projects in the organization:teamwork memory add --scope sharedpromotes a local memory entry to the shared knowledge baseteamwork memory sync --pullfetches shared entries relevant to the current project's tech stack and workflow typeNo central server required — the shared knowledge base is just another git repository that Teamwork knows how to read from.