Kontexte erstellen

Schritt-für-Schritt-Anleitung zum Erstellen von Kontext-Dokumenten in CodeCourier, zum Schreiben effektiver Markdown-Inhalte, zum Veröffentlichen Ihrer ersten Version und zum Verknüpfen von Kontexten mit Personas und Session-Typen.

8 min Lesezeit
contextscreatemarkdown

Diese Anleitung führt Sie durch die Erstellung eines Kontext-Dokuments von Grund auf - von der Navigation zur Kontext-Seite über das Schreiben gut strukturierter Markdown-Inhalte und das Veröffentlichen Ihrer ersten Version bis hin zur Verknüpfung des Kontexts mit den Session-Typen oder Personas, die ihn erhalten sollen.

Zur Kontext-Seite navigieren

Kontexte werden über die Projekt-Sidebar erreicht. Suchen Sie den Eintrag Kontexte im linken Navigationsbereich. Falls Sie ihn nicht sehen, stellen Sie sicher, dass Sie mindestens Mitglied-Zugriff auf das Projekt haben. Die Kontext-Seite befindet sich unter /p/{projectId}/context.

Die Seite listet alle vorhandenen Kontexte im Projekt auf und zeigt für jeden Kontext den Namen, die Beschreibung, die Anzahl der veröffentlichten Versionen und das Veröffentlichungsdatum der aktiven Version. Falls noch keine Kontexte erstellt wurden, sehen Sie einen leeren Zustand mit einer prominenten Schaltfläche Kontext erstellen.

Einen neuen Kontext erstellen

1

Erstell-Dialog öffnen

Klicken Sie auf + Kontext erstellen in der oberen rechten Ecke der Kontext-Seite. Ein Dialog öffnet sich und fragt nach den grundlegenden Metadaten des Kontexts.

2

Namen eingeben (erforderlich)

Geben Sie dem Kontext einen beschreibenden Namen, der seinen Inhalt widerspiegelt. Gute Namen vermitteln die Absicht auf einen Blick:

  • Projektarchitektur - Full-Stack-Übersicht und Konventionen
  • Coding-Standards - Style-Regeln, TypeScript-Konfiguration, Linting
  • Sicherheits-Checkliste - OWASP-Anforderungen, Input-Sanitization-Regeln
  • API-Referenz - wichtige Endpoints, Authentifizierungsmuster, Rate-Limits
  • Test-Konventionen - Vitest-Setup, Mock-Muster, Coverage-Ziele

Namen dürfen nicht leer sein und werden beim Absenden validiert. Sie können den Kontext später auf seiner Detailseite umbenennen.

3

Beschreibung hinzufügen (optional, aber empfohlen)

Die Beschreibung erscheint auf der Kontext-Listenseite und in Bindungs-Dropdowns in den gesamten Projekteinstellungen. Eine klare Beschreibung hilft Teammitgliedern zu verstehen, welcher Kontext mit einem Session-Typ verknüpft werden soll, ohne den vollen Inhalt öffnen und lesen zu müssen. Zum Beispiel:

„Vollständige Architekturübersicht des Next.js + Convex + Clerk Stacks, einschließlich Datei-Konventionen und Datenfluss. In alle Designer-Sessions einspeisen.“

4

Formular absenden

Klicken Sie auf Erstellen. Sie werden zur Kontext-Detailseite weitergeleitet, auf der Sie den vollständigen Markdown-Inhalt schreiben und Ihre erste Version veröffentlichen können.

Den Kontext-Inhalt schreiben

Die Kontext-Detailseite enthält einen vollwertigen Markdown-Editor. Der Inhalt, den Sie hier schreiben, ist genau das, was in Sandbox-Sessions eingespeist wird. Schreiben Sie ihn so, wie Sie eine CLAUDE.md-Datei schreiben würden - klar strukturiert, mit Überschriften für die Navigation und Aufzählungspunkten für überfliegbare Regeln.

Was hineingehört

Effektiver Kontext-Inhalt ist spezifisch und handlungsorientiert. Agenten arbeiten am besten, wenn sie konkrete, eindeutige Regeln statt vager Richtlinien haben. Strukturieren Sie Ihren Inhalt mit:

  • Einem Übersichts-Abschnitt, der den Technologie-Stack auf hoher Ebene beschreibt
  • Abschnitten zu Datei-Konventionen, die auflisten, wo verschiedene Dateitypen liegen
  • Coding-Standards zu Benennungen, Mustern und Anti-Mustern, die zu vermeiden sind
  • Wichtige Einschränkungen in expliziter „niemals“- und „immer“-Sprache
  • Wichtige Abhängigkeiten oder Konfigurationen, die Agenten kennen müssen

Beispiel für Kontext-Inhalt

Nachfolgend ein Beispiel für einen gut geschriebenen Projektarchitektur-Kontext für eine Full-Stack-TypeScript-Anwendung:

project-architecture-context.md
# Project Architecture

This is a Next.js 16 application with:
- **Frontend**: React 19, TypeScript, Tailwind CSS, shadcn/ui
- **Backend**: Convex (reactive database + server functions)
- **Auth**: Clerk

## Coding Standards
- Always use TypeScript strict mode
- Prefer server components over client components
- Use Convex mutations for all data writes
- Never use `dangerouslySetInnerHTML` without sanitization

## File Conventions
- Components: PascalCase in `/components/`
- Hooks: camelCase with `use` prefix in `/hooks/`
- Utils: camelCase in `/lib/`

## Convex Rules
- Never use `.collect()` on large tables - use `.take(N)` or paginate
- Batch work goes to `ctx.scheduler.runAfter` to avoid timeout
- Mutations validate input with Convex validators, not Zod

## Next.js Specifics
- The middleware file is `proxy.ts`, NOT `middleware.ts`
- All API routes live in `/app/api/`
- Use `generateStaticParams` for static paths, not `getStaticPaths`

## Testing
- Unit tests: Vitest with `@testing-library/react`
- E2E tests: Playwright in `/e2e/`
- Run `bun test` before every commit

Halten Sie den Inhalt fokussiert

Widerstehen Sie der Versuchung, Ihr gesamtes Codebasis-Wiki in einen einzigen Kontext zu kippen. Agenten haben begrenzte Context-Fenster. Schreiben Sie fokussierte, relevante Informationen und erstellen Sie separate Kontexte für unterschiedliche Domänen (Architektur, Sicherheit, Tests) statt eines riesigen Dokuments.

Ihre erste Version veröffentlichen

1

Inhalt schreiben oder einfügen

Geben Sie den Markdown-Inhalt im Editor auf der Kontext-Detailseite ein. Der Editor unterstützt eine Live-Vorschau, sodass Sie sehen können, wie der Inhalt gerendert wird.

2

Auf Veröffentlichen klicken

Klicken Sie auf die Schaltfläche Veröffentlichen, um Version 1 dieses Kontexts zu erstellen. Bei der Veröffentlichung erstellt CodeCourier einen neuen Versions-Datensatz mit dem Status active und protokolliert den aktuellen Zeitstempel sowie Ihre Benutzeridentität als Veröffentlicher.

3

Aktive Version überprüfen

Nach der Veröffentlichung zeigt die Seite die Versionsnummer und das Veröffentlichungsdatum im Versions-History-Panel an. Das Badge der aktiven Version zeigt Aktiv. Dies ist die Version, die in Sandboxes eingespeist wird.

Nicht veröffentlichte Änderungen

Wenn Sie den Inhalt bearbeiten, ohne auf Veröffentlichen zu klicken, werden Ihre Änderungen als Entwurf gespeichert. Die aktive Version in Sandboxes bleibt die zuvor veröffentlichte Version, bis Sie erneut veröffentlichen. Der Editor zeigt einen Indikator „Nicht veröffentlichte Änderungen“, wenn sich Ihr Entwurf von der aktiven Version unterscheidet.

Versionshistorie ansehen

Das Panel Versionshistorie auf der Kontext-Detailseite listet jede veröffentlichte Version in umgekehrt-chronologischer Reihenfolge auf. Jeder Eintrag zeigt:

  • Versionsnummer (v1, v2, v3, …)
  • Zeitstempel der Veröffentlichung
  • Wer veröffentlicht hat (Anzeigename des Benutzers)
  • Status-Badge aktiv oder inaktiv

Klicken Sie auf eine beliebige Version, um deren Inhalt im schreibgeschützten Modus anzusehen. So können Sie die aktuelle aktive Version mit historischen Versionen vergleichen, um zu verstehen, was sich geändert hat.

Einen Kontext an eine Persona binden

Um einen Kontext an eine bestimmte Persona zu binden, navigieren Sie zur Persona-Detailseite unter /p/{projectId}/personas/{personaId} und öffnen Sie den Tab Kontext. Verwenden Sie dort das Dropdown, um den Kontext auszuwählen, den diese Persona verwenden soll. Nach dem Speichern wird jede von dieser Persona ausgeführte Session den gebundenen Kontext der Persona statt der Session-Typ-Vorgabe einspeisen.

Persona-Override hat Vorrang

Das Setzen eines Kontexts auf einer Persona überschreibt die Session-Typ-Vorgabe. Wenn Sie möchten, dass eine Persona keinen Kontext verwendet (auch wenn der Session-Typ eine Vorgabe hat), müssen Sie die Kontext-Bindung der Persona explizit leeren, statt sie unbelegt zu lassen - eine unbelegte Persona-Bindung fällt auf die Session-Typ-Vorgabe zurück.

Einen Kontext an einen Session-Typ binden

Session-Typ-Bindungen werden über die Projekteinstellungen verwaltet. Jeder Session-Typ hat seinen eigenen Setup-Tab:

  • Answering Setup - /p/{id}/answering-setup
  • Issues Setup - /p/{id}/issues-setup
  • Learning Setup - /p/{id}/learning-setup
  • Merging Setup - /p/{id}/merging-setup
  • Evaluator Setup - /p/{id}/evaluator-setup
  • Judge Setup - /p/{id}/judge-setup

Suchen Sie auf jedem Setup-Tab das Feld Kontext und wählen Sie den Kontext aus, den alle Sessions dieses Typs standardmäßig erhalten sollen. Die Bindung wird sofort bei der Auswahl gespeichert.

Nächste Schritte