.projectstore

.projectstore / Methode / 3

Viele Sitzungen. Viele Menschen. Ein Vault.

Der Kontext gehört dem Team, nicht dem Chat eines einzelnen Entwicklers. ADRs und Specs laufen wie Code über Pull Requests. Reviewt wird die Begründung.

Vier Arten zu arbeiten

Mehrere Sitzungen, ein Vault

Dass zwei Agenten oder zwei Menschen gleichzeitig in einem Vault arbeiten, ist normal. Jede Sitzung weiß von den anderen, und ein paar einfache Regeln sorgen dafür, dass sie sich nicht in die Quere kommen.

  • Kein stilles Überschreiben. Bevor ProjectStore eine neue Datei speichert, prüft es, ob sie schon existiert. Zwei Sitzungen zum selben Thema bekommen einen Konflikt, keine zwei Kopien.
  • Jede Statuszeile zeigt die eigene Arbeit. 2–6 Sitzungen nebeneinander sehen jeweils genau ihr eigenes Epic und ihre eigene Story.
  • Sitzungsnamen werden angeboten, nicht aufgezwungen. Sobald sich eine Sitzung auf eine Aufgabe festlegt, schlägt sie einen Namen dafür vor. Selten: höchstens zweimal pro Sitzung, 12 Vorschläge in neun aufgezeichneten Sitzungen.
eine zweite Sitzung auf your-project-vaultClaude Code
Entwickler A arbeitet seit 13:35 an CHECKOUT. Du öffnest eine zweite Sitzung:

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

später, sobald sich deine Arbeit auf „Gespeicherte Karten werden im Checkout aufgelistet“ festlegt:
projectstore: this session looks like "checkout-gespeicherte-karten-werden-im-checkout"
  → /rename checkout-gespeicherte-karten-werden-im-checkout

Alle sehen mehr als ihren eigenen Teil.

Entwickler, Tech Lead und QA arbeiten mit denselben Entscheidungen und Kriterien. Wer keinen Agenten nutzt, braucht nur GitHub oder einen Markdown-Editor: Es sind einfach Dateien.

Der Kontext steht dem ganzen Team zur Verfügung, nicht nur dem Besitzer des Chats.

Gemeinsame Verträge. Getrennte Arbeitsbereiche.

In einem Projekt führen die Teams API, Web und Plattform ihre eigenen Epics auf Basis gemeinsamer ADRs und Specs. Eine Änderung an einem gemeinsamen Vertrag wird im Review mit den Teams besprochen, die ihn nutzen. ProjectStore zeigt, welche Stories davon abhängen.

Wem welche Artefakte gehören und wer Verträge abzeichnet, entscheidet das Team.

Verschiedene Ausführende. Gemeinsame Grundlage.

Der Planner liest die Entscheidungen und die Code-Map. Der Implementierer liest Story und Spec. Der Reviewer liest Diff und Kriterien. Jeder bekommt den Kontext, den er braucht, nicht den ganzen Verlauf einer fremden Sitzung. Sitzungen im selben Vault warnen einander.

Agenten zu starten und Arbeit zwischen ihnen zu übergeben, ist Aufgabe deines Harness oder Orchestrators.

Ein Beispiel für die Arbeitsorganisation, keine Live-Orchestrierung

der Vault im eigenen Repository

So sieht es in git aus

Entwickler mit eigenen Agenten binden denselben Vault, der in einem eigenen Git-Repository liegt. ADRs und Specs werden als Pull Requests reviewt. Ein Teammitglied ohne Agent reviewt auf GitHub oder in Obsidian. Setup push / pull Review & Pull Entwickler AClaude Code + projectstoreAgent Entwickler BCodex + projectstoreAgent Entwickler Cohne Agentreviewt auf GitHub/Obsidian your-project-vault eigenes Git-Repo · reines Markdown adr/ Entscheidungen, datiert specs/ das Sollverhalten epics/ · stories/ das Backlog kanban.md das Board graph.md alle Links code-map.md Epic ↔ Code jede Änderung gezeigt und freigegeben Git-Remote GitHub · GitLab · beliebig ADRs und Specs reviewt als Pull Requests: das Warum wird reviewt, nicht nur der Code
Leg den Vault in ein eigenes Repository. Alle installieren ProjectStore, binden denselben Vault und speichern Änderungen erst nach einer Freigabe. Ein Teammitglied ohne Agent reviewt auf GitHub oder in Obsidian.
Setup

Team-Setup, Schritt für Schritt

  1. 01

    Ein eigenes Vault-Repo

    Ein Repository mit Projektdokumenten pro Projekt, nicht pro Person. Es liegt neben dem Code-Repository.

  2. 02

    Eigene Checkouts, ein Vault

    Jede Person klont das Vault-Repository, führt dann npx projectstore setup in ihrer eigenen Kopie des Codes aus und gibt diesen Klon als Vault an. Die Bindung bleibt auf diesem Rechner und wird nicht committet.

  3. 03

    Ein Branch und ein Pull Request

    Ein Mensch reviewt jede Entscheidung, bevor sie akzeptiert wird. Der Critic prüft sie vor dem Pull Request, dein Team reviewt sie darin.

  4. 04

    Doctor in der CI

    npx projectstore doctor --json läuft in der CI ohne Agent und ohne Tokens. Bei Problemen schlägt der Schritt fehl. reconcile --write kann dort auch das Board neu aufbauen.

Claude Code und Codex können ein Projekt nebeneinander bearbeiten: Sie teilen die Bindung, und jedes behält seine eigenen Agentenmodelle und seinen eigenen Sitzungsstatus.

So funktioniert es →Warum es funktioniert →Installieren →