Dokumente gemeinsam erstellen

Überblick

Geführter Workflow zum kollaborativen Schreiben von Dokumenten, Vorschlägen, Specs und Entscheidungsdokumenten. Drei Phasen: Kontexterfassung, iterative Verfeinerung und Leser-Test.

Erste Schritte

Legen Sie Ihre Quellen im Projektarbeitsbereich ab und aktivieren Sie den Skill Dokumente gemeinsam erstellen. Der Agent führt Sie Schritt für Schritt durch den Prozess.

Beispiel-Dialog

Sie: Ich möchte ein einseitiges Entscheidungsdokument zur Auth-Migration auf OAuth2. Können wir den strukturierten Workflow nutzen?
Agent: Ja. Drei Phasen: (1) Kontexterfassung — ich frage nach Zielgruppe, gewünschter Wirkung und Vorlage; (2) Verfeinerung — wir bauen jeden Abschnitt mit Brainstorming und Bearbeitung; (3) Leser-Test — prüfen, ob ein frischer Leser zentrale Fragen aus dem Dokument beantworten kann. Zum Start: Wer ist die primäre Zielgruppe? Was sollen sie nach dem Lesen tun? Gibt es eine Vorlage?
Sie: Zielgruppe: Tech-Leads und Security. Ziel: Go/No-Go. Keine Vorlage — nur klare Abschnitte.
Agent: Ich schlage vor: Kontext & Problem, Optionen, Empfehlung, Risiken & Mitigation, Nächste Schritte. Wir starten mit „Optionen“ und „Empfehlung“. Geben Sie Ihren Kontext (Randbedingungen, frühere Diskussionen, warum andere Optionen nicht). Dann brainstormen und abschnittsweise entwerfen. Bereit für Ihren Kontext.
Sie: [Gibt Kontext.]
Agent: Ich habe decision-doc-auth-oauth2.md mit Platzhaltern angelegt. Beim Abschnitt Empfehlung: Hier sind 8 mögliche Punkte basierend auf Ihrem Input. Welche behalten, streichen oder zusammenführen? [Listet Optionen.] Danach verfasse ich den Abschnitt und wir iterieren.

Ausschnitt Beispielausgabe

Typischer Ausschnitt eines mit dem Co-Authoring-Workflow erstellten Entscheidungsdokuments.

Entscheidung: Authentifizierung auf OAuth2 umstellen

Kontext und Problem

Die aktuelle cookie-basierte Auth unterstützt weder Mobile noch Drittanbieter-Integrationen. Wir brauchen eine standardisierte, wartbare Auth-Schicht für Web, Mobile und API.

Optionen

Option	Vorteile	Nachteile
Beim aktuellen System bleiben	Keine Migrationskosten	Erfüllt Mobile/API-Anforderungen nicht
OAuth2 + OIDC	Standard, Bibliotheken, passt zum Stack	Migrations- und Key-Management-Aufwand
Eigene Token-Schicht	Volle Kontrolle	Nicht standardkonform, höhere Langfristkosten

Empfehlung

OAuth2 mit OpenID Connect für Identity. [Provider X] für Ausstellung, bestehender User Store. Phase 1: Web und API; Phase 2: Mobile. Zeitrahmen: 8 Wochen bis Pilot, 12 Wochen bis Rollout.

Risiken und Mitigation

Risiko: Token-Widerruf und Session-Invalidierung. Mitigation: Kurzlebige Access Tokens, Refresh-Rotation, Revocation-Endpoint bis Phase 2.
Risiko: Key-Rotation. Mitigation: Automatisierte Rotation und Dual-Key-Unterstützung beim Wechsel.

Nächste Schritte

Security-Freigabe für Provider und Flow (Woche 1).
Issuer implementieren und in Web-App integrieren (Wochen 2–6).
Pilot mit internen API-Nutzern (Wochen 7–8).