Kontext-Dokumente

Kontext-Dokumente sind wiederverwendbare Wissensartefakte, die versioniert werden und automatisch als System-Prompts oder CLAUDE.md-Inhalte in Sandboxes eingespeist werden. Anstatt dieselbe Architekturübersicht oder dieselben Coding-Standards in die Anweisungen jeder Persona einzubetten, schreiben Sie sie einmal als Kontext, veröffentlichen sie und binden sie an die Session-Typen oder Personas, die sie benötigen. Bei jeder Bereitstellung einer passenden Sandbox wird die aktive Version dieses Kontexts automatisch eingespeist.

Kontexte befinden sich unter /p/{projectId}/context und sind auf ein einzelnes Projekt beschränkt. Ein Projekt kann beliebig viele Kontexte haben, die jeweils einen anderen Wissensbereich abdecken - einen für Architekturkonventionen, einen für die API-Dokumentation, einen für Sicherheitsregeln.

Was Kontexte sind

Im Kern ist ein Kontext ein benanntes, versioniertes Markdown-Dokument. Jeder Kontext-Datensatz speichert:

• Name - Eine menschenlesbare Bezeichnung (z. B. „Projektarchitektur“, „Sicherheitsstandards“)
• Beschreibung - Eine optionale Zusammenfassung dessen, was der Kontext abdeckt und wann er zu verwenden ist
• Inhalt - Der vollständige Markdown-Text, der in Sandboxes eingespeist wird
• Versionshistorie - Ein vollständiges Audit-Protokoll jeder veröffentlichten Version

Kontexte sind für die Art von dauerhaftem, projektbezogenem Wissen konzipiert, das jeder Agent eines bestimmten Typs mitbringen sollte. Beispiele sind:

• Vollständige Architekturübersichten, die den Technologie-Stack, Service-Grenzen und Datenfluss beschreiben
• Coding-Standards und Style-Guides, die Agenten beim Schreiben von Code befolgen müssen
• CLAUDE.md-Inhalte, die vor Agenten-Start in das Sandbox-Dateisystem geschrieben werden
• Domänenspezifische API-Dokumentation oder Integrationsmuster, auf die Agenten verweisen müssen
• Sicherheits-Checklisten und Compliance-Anforderungen für Agenten, die Code-Reviews durchführen

Lebenszyklus einer Kontext-Version

Jedes Mal, wenn Sie den Inhalt eines Kontexts bearbeiten und die Änderung veröffentlichen, wird eine neue Version erstellt. Versionen haben zwei Status:

Der Lebenszyklus einer typischen Kontext-Bearbeitung ist:

1. Sie öffnen den Kontext-Editor und ändern den Markdown-Inhalt
2. Sie klicken auf Veröffentlichen - dadurch wird eine neue Version mit Status active erstellt
3. Die zuvor aktive Version wird automatisch auf inactive gesetzt
4. Alle künftigen Sandboxes, die diesen Kontext referenzieren, erhalten die neue aktive Version
5. Die alte Version bleibt für Audit- und Rollback-Zwecke in der Versionshistorie erhalten

Bindungen an Session-Typen

Kontexte können auf der Projekteinstellungs-Seite an bestimmte Session-Typengebunden werden. Wenn eine Session dieses Typs erstellt wird, wird die aktive Version des gebundenen Kontexts automatisch eingespeist. CodeCourier definiert sechs Session-Typen, die jeweils einer anderen Stufe der KI-Workflow-Pipeline entsprechen:

Jeder Session-Typ hat seinen eigenen Setup-Tab in den Projekteinstellungen, in dem Sie genau einen Kontext verknüpfen können. Dadurch ist es einfach, beispielsweise dem Evaluator-Agenten andere Qualitätskriterien zu geben als dem Issue-Discovery-Agenten.

Persona-spezifischer Kontext-Override

Zusätzlich zu Session-Typ-Bindungen können einzelne Personas auf ihrer Persona-Detailseite im Kontext-Tab an einen bestimmten Kontext gebunden werden. Eine Bindung auf Persona-Ebene hat Vorrang vor der Session-Typ-Vorgabe - das bedeutet, dass eine Persona mit eigener Kontext-Bindung beim Ausführen den Kontext der Persona statt der Session-Typ-Vorgabe verwendet.

Dieser Override-Mechanismus ermöglicht feingranulare Kontrolle. Stellen Sie sich ein Projekt mit zwei Designer-Personas vor - eine für Frontend-Arbeit und eine für Backend-Arbeit. Der Frontend-Designer ist an einen Kontext „Frontend-Architektur“ gebunden, während der Backend-Designer an einen Kontext „Backend-Architektur“ gebunden ist. Beide erben die Session-Typ-Vorgabe als Fallback, wenn keine Bindung auf Persona-Ebene gesetzt ist.

Warum Kontexte wichtig sind

Vor Kontexten mussten Teams Architekturwissen in die Anweisungen jeder Persona einfügen oder separate CLAUDE.md-Dateien pro Workflow pflegen. Dadurch entstand Drift: Verschiedene Agenten hatten ein subtil unterschiedliches Verständnis der Codebasis, weil ihre Anweisungen unabhängig voneinander bearbeitet wurden. Kontexte lösen dies, indem sie eine einzige Quelle der Wahrheit bereitstellen, die alle relevanten Agenten teilen.

Die wichtigsten Vorteile sind:

• Konsistenz - Alle Agenten eines Session-Typs teilen denselben aktuellen Wissensstand. Wenn sich die Architektur ändert, aktualisieren Sie einen Kontext und alle künftigen Sessions erhalten die Änderung sofort.
• Versionskontrolle - Agenten-Anweisungen werden wie Code versioniert. Sie können sehen, wer welche Version wann veröffentlicht hat, und auf eine vorherige Version zurückrollen, falls eine Änderung Regressionen verursacht.
• Trennung von Belangen - Persona-Anweisungen bleiben auf rollenspezifisches Verhalten fokussiert. Geteiltes Wissen lebt in Kontexten. Jedes hat einen klaren Platz.
• Auditierbarkeit - Wenn ein Agent unerwartete Ausgaben produziert, können Sie in der Versionshistorie nachsehen, welche Kontext-Version zum Zeitpunkt dieser Session genau aktiv war.

Nächste Schritte