.projectstore

.projectstore / method / 3

Many sessions. Many people. One vault.

The context belongs to the team, not to one developer's chat. ADRs and specs go through pull requests, like code. What gets reviewed is the reasoning.

Four ways to work

Several sessions, one vault

Two agents or two people in one vault at the same time is normal. Each session knows about the others, and a few simple rules keep them out of each other's way.

  • No silent overwrites. Before saving a new file, ProjectStore checks that it does not exist yet. Two sessions on the same topic get a clash, not two copies.
  • Each status line shows its own work. 2–6 sessions side by side each see exactly their own epic and story.
  • Session names are offered, not imposed. Once a session settles on one piece of work, it suggests a name for it. Rarely: at most twice a session, 12 offers across nine recorded sessions.
a second session on your-project-vaultClaude Code
developer A has worked on CHECKOUT since 13:35. you open a second session:

⚠ Multi-session warning — 1 other projectstore session active.
  Run /projectstore:search <topic> before creating new artifacts.

later, once your work settles on “Saved cards are listed at checkout”:
projectstore: this session looks like "checkout-saved-cards-are-listed-at-checkout"
  → /rename checkout-saved-cards-are-listed-at-checkout

Everyone sees more than their own part.

The developer, the tech lead and QA work from the same decisions and criteria. A person without an agent needs only GitHub or a Markdown editor: it is just files.

The context is available to the whole team, not only to the owner of the chat.

Shared contracts. Separate areas of work.

In one project, the API, Web and Platform teams run their own epics on top of shared ADRs and specs. A change to a shared contract is discussed in review with the teams that use it. ProjectStore shows which stories depend on it.

Who owns which artifacts and who signs off on contracts is the team's call.

Different executors. Shared grounds.

The planner reads the decisions and the code map. The implementer reads the story and the spec. The reviewer reads the diff and the criteria. Each gets the context it needs, not the whole history of someone else's session. Sessions on the same vault warn each other.

Launching agents and handing work between them is the job of your harness or orchestrator.

An example of organizing the work, not live orchestration

the vault in its own repository

What it looks like in git

Developers with their own agents bind to one vault in its own git repository. ADRs and specs are reviewed as pull requests. A teammate without an agent reviews on GitHub or in Obsidian. setup push / pull review & pull Developer AClaude Code + projectstoreagent Developer BCodex + projectstoreagent Developer Cno agentreviews on GitHub/Obsidian your-project-vault its own git repo · plain markdown adr/ decisions, with dates specs/ how it must work epics/ · stories/ the backlog kanban.md the board graph.md all the links code-map.md epic ↔ code every write shown, then approved git remote GitHub · GitLab · anything ADRs and specs reviewed as pull requests: the why gets reviewed, not just the code
Put the vault in its own repository. Everyone installs ProjectStore, binds to the same vault and saves changes only after approval. A teammate without an agent reviews on GitHub or in Obsidian.
Setup

A team setup, step by step

  1. 01

    A separate vault repo

    One repository of project documents per project, not per person. It sits next to the code repository.

  2. 02

    Own checkouts, one vault

    Each person clones the vault repository, then runs npx projectstore setup in their own copy of the code and names that clone as the vault. The binding stays on that machine and is not committed.

  3. 03

    A branch and a pull request

    A person reviews each decision before it is accepted. The critic checks it before the pull request; your team reviews it inside.

  4. 04

    Doctor in CI

    npx projectstore doctor --json runs in CI with no agent and no tokens. It fails the step when it finds problems. reconcile --write can rebuild the board there too.

Claude Code and Codex can work one project side by side: they share the binding, and each keeps its own agent models and session state.

How it works →Why it works →Install →