Eingebaute Personas

CodeCourier definiert zehn eingebaute Persona-Typen. Diese Typen sind keine vorab erstellten Personas, sondern Rollendefinitionen, die jede Persona nutzen muss. Beim Anlegen einer neuen Persona weisen Sie ihr einen dieser Typen zu, der ihr Icon, ihre Farbe, das Standardtool und -modell sowie ihre Rolle innerhalb von Workflow-Pipelines bestimmt.

Die eingebauten Typen sind in der Workflow-Schritt-Konfiguration definiert (convex/config/workflows.config.ts) und plattformweit geteilt. Das Verständnis jedes Typs hilft Ihnen, Personas zu erstellen, die optimal zu ihrer Rolle im Entwicklungsprozess passen.

Designer

Der Designer ist der primäre Implementierungs-Agent. Er erhält einen Task-Prompt und schreibt Code zur Erfüllung. Designer arbeiten direkt im Sandbox-Dateisystem: erstellen Dateien, installieren Pakete, konfigurieren Build-Tools und starten den Entwicklungsserver.

Wann verwenden: Jede Aufgabe, die Code-Schreiben oder -Ändern erfordert. Feature-Implementierung, Bugfixes, Konfigurationsänderungen, Dokumentation und Migrationsskripte. Wenn das Ergebnis Code in einem Repository ist, ist eine Designer-Persona die richtige Wahl.

Anwendungsfälle: Implementierung von React-Komponenten, REST-API-Entwicklung, Datenbank-Schema-Migrationen, Generierung von Konfigurationsdateien, Aufbau von Build-Pipelines.

Empfohlene Konfiguration:Verwenden Sie das leistungsfähigste verfügbare Modell (Opus) für komplexe Aufgaben. Setzen Sie die Denkleistung auf “high” für architektonische Änderungen. Binden Sie passende Skills ein (z. B. frontend-design für UI-Arbeit, convex-implementation für Datenbankarbeit). Binden Sie ein Kontext-Dokument ein, das Ihre Codebasis-Architektur oder Coding-Standards beschreibt.

Checker

Der Checker ist ein verdiktbasierter Review-Agent, der die Arbeit eines vorausgegangenen Schritts (typischerweise eines Designers) bewertet. Er liest Code-Änderungen, führt optional Tests aus und produziert ein strukturiertes Verdikt: Pass oder Fail mit detailliertem Feedback. Dieses binäre Verdikt unterscheidet den Checker vom Reviewer-Typ.

Liefert ein Checker ein Fail-Verdikt, kann der Workflow zum Designer-Schritt für eine weitere Iteration zurückkehren - ein automatisierter Design-Review-Zyklus, der die Qualität ohne menschliches Eingreifen verbessert.

Wann verwenden: Nach jedem Designer-Schritt, in dem Qualitätssicherung zählt. Code-Reviews, Typprüfung, Testverifikation, Sicherheitsaudits und Compliance-Prüfungen.

Anwendungsfälle: Durchsetzung von TypeScript-Typsicherheit, Testabdeckungs-Gates, Sicherheitsrichtlinien-Compliance, Style-Guide-Konformität, Performance-Budget-Checks.

Empfohlene Konfiguration: Ein schnelleres Modell (Sonnet) reicht oft, da der Checker eine fokussiertere Aufgabe hat als der Designer. Die Anweisungen müssen explizite Pass/Fail-Kriterien definieren - der Checker darf nie mehrdeutig sein. Nutzen Sie den app-security-Skill, wenn ein Sicherheits-Review Teil der Prüfung ist.

Optimizer

Der Optimizer ist ein Refactoring-Spezialist. Er nimmt funktionierenden Code und macht ihn besser: reduziert Duplikate, verbessert Performance, erhöht die Lesbarkeit und wendet Best Practices an. Der Optimizer fügt keine neuen Features hinzu; er verbessert bestehende.

Wann verwenden: Als Nachbearbeitungs-Schritt nach einem Designer. Besonders wertvoll bei großen Code-Änderungen, bei denen der Designer auf Funktionalität fokussiert war und der Optimizer das Ergebnis poliert.

Anwendungsfälle: Beseitigung von N+1-Query-Mustern, Reduktion von React-Re-Renders, Extraktion wiederverwendbarer Hooks, Vereinheitlichung der Fehlerbehandlung, Verbesserung der Bundle-Größe.

Empfohlene Konfiguration: Nutzen Sie Opus für seine Fähigkeit, komplexe Codebasen zu verstehen. Die Anweisungen sollten explizit benennen, was NICHT geändert werden darf (öffentliche APIs, Exports), um Breaking Changes während der Optimierung zu vermeiden. Binden Sie den Skill performance-optimization-addyosmani für performanceorientierte Arbeit ein.

Prompter

Der Prompter ist ein Prompt-Engineering-Agent. Er nimmt eine informelle, potenziell vage Nutzeranfrage und überführt sie in eine klare, strukturierte Spezifikation mit expliziten Akzeptanzkriterien. Der verfeinerte Prompt wird dann an den nächsten Pipeline-Schritt weitergegeben.

Wann verwenden: Als erster Schritt in einer Pipeline, wenn Nutzeranfragen wahrscheinlich unterspezifiziert sind. Besonders wertvoll für Teams, in denen nicht-technische Stakeholder Feature-Anfragen einreichen, die in technische Spezifikationen übersetzt werden müssen.

Anwendungsfälle: Übersetzung von Produktanforderungen in technische Specs, Erweiterung kurzer Task-Beschreibungen zu detaillierten Implementierungsleitfäden, Generierung von Akzeptanzkriterien aus User Stories.

Empfohlene Konfiguration:Sonnet ist meist ausreichend für Prompt-Verfeinerung. Die Anweisungen sollten das Ausgabeformat festlegen (z. B. “Akzeptanzkriterien stets als nummerierte Liste und betroffene Dateien explizit nennen”).

Investigator

Der Investigator ist ein Recherche-Agent, der die Codebasis vor Beginn der Implementierung analysiert. Er liest Dateien, verfolgt Abhängigkeiten, kartiert die Architektur und erstellt eine strukturierte Zusammenfassung. Dieser Kontext hilft nachfolgenden Agenten, bessere Entscheidungen zu treffen.

Wann verwenden: Vor einem Designer-Schritt in unbekannten Codebasen, fokussierten Bug-Untersuchungen oder wenn die Aufgabe das Verständnis eines bestimmten Subsystems erfordert. Der Investigator zielt auf einen bestimmten Bereich der Codebasis und berichtet kompakt.

Anwendungsfälle: Verstehen eines Authentifizierungs-Subsystems vor Ergänzung eines neuen OAuth-Providers, Nachverfolgung eines bestimmten Datenflusses vor dem Refactoring, Identifikation der von einer Änderung betroffenen Dateien.

Empfohlene Konfiguration:Nutzen Sie Opus für überlegenes Codebasis-Verständnis. Setzen Sie die Denkleistung auf “high”. Die Anweisungen sollten angeben, was untersucht werden soll (z. B. “Fokus auf Datenbank-Queries und API-Routen im Zusammenhang mit Authentifizierung”). Für umfassende übergreifende Analysen bevorzugen Sie stattdessen den Deep-Dive-Typ.

Planner

Der Planner ist ein Architektur-Agent, der Codebasen analysiert und strukturierte Bewertungen erstellt. Er sichtet das Repository, versteht die Anforderungen und zerlegt die Arbeit in umsetzbare Items. Jedes Item hat Namen, Beschreibung und detaillierten Prompt. Dieser Typ treibt das Issue-Sitzungen-Feature von CodeCourier an.

Wann verwenden: Für komplexe, mehrstufige Projekte, die von einer vorgelagerten Analyse profitieren. Die Ausgabe des Planners kann direkt vom Work-Chain-System von CodeCourier ausgeführt werden.

Anwendungsfälle: Aufteilung einer großen Feature-Anfrage in diskrete Issues, Identifikation technischer Schulden in der Codebasis, Erstellung priorisierter Verbesserungslisten, Generierung von Issue-Backlogs für die Sprintplanung.

Empfohlene Konfiguration: Verwenden Sie immer Opus mit hoher Denkleistung. Der Planner benötigt maximale Reasoning-Kapazität, um komplexe Projekte effektiv zu zerlegen. Binden Sie für beste Ergebnisse ein Architektur-Kontext-Dokument ein.

Deep-Dive

Der Deep-Dive ist ein intensiver Analyse-Agent für komplexe, vielschichtige Probleme, die ein umfassendes Codebasis-Verständnis erfordern. Er ähnelt dem Investigator, agiert aber in einem breiteren Umfang - statt sich auf ein Subsystem zu konzentrieren, erkundet er übergreifende Belange, verfolgt Interaktionen mehrerer Systeme und liefert einen erschöpfenden Analysebericht.

Deep-Dive-Sitzungen laufen typischerweise länger und mit höherer Denkleistung als Investigator-Sitzungen. Die Ausgabe ist gründlicher: nicht nur “so funktioniert dieses Subsystem”, sondern “so interagieren alle relevanten Systeme, wo sind die Grenzen mehrdeutig, wie sieht die Risikofläche aus und welche architektonischen Entscheidungen führten zum aktuellen Zustand.”

Wann verwenden: Architekturanalyse vor einem größeren Refactor, Ursachenforschung bei komplexen Produktionsstörungen, Verstehen einer Legacy-Codebasis vor dem Onboarding eines neuen Teams oder jede Analyseaufgabe, bei der Tiefe wichtiger ist als Geschwindigkeit.

Anwendungsfälle: Architekturbewertung vor einer Migration, Sicherheits-Threat-Modeling über eine ganze Anwendung, Abhängigkeitsanalyse vor dem Upgrade einer großen Bibliothek, Nachverfolgung eines Datenflusses über mehrere Services und Datenbanken.

Empfohlene Konfiguration: Verwenden Sie immer Opus mit max oder xhigh Denkleistung. Planen Sie längere Sandbox-Laufzeit ein (Timeout erhöhen). Binden Sie breite Skills ein: app-security, performance-optimization-addyosmani, superpower-debugging. Binden Sie ein Kontext-Dokument mit projektweiter Architektur ein, damit sich der Agent auf Tiefe statt Orientierung konzentrieren kann.

Reviewer

Der Reviewer ist ein spezialisierter Code-Review-Agent mit Fokus auf Sicherheit, Wartbarkeit, Design-Muster und Codequalität. Er unterscheidet sich fundamental vom Checker in einem entscheidenden Punkt: Der Reviewer erzeugt keine Pass/Fail-Verdikte. Stattdessen liefert er detailliertes, nuanciertes Review-Feedback - Beobachtungen, Vorschläge, Bedenken und Lob - auf das ein menschlicher Entwickler oder ein nachfolgender Agent reagieren kann.

Das macht den Reviewer ideal für Situationen, in denen ein binäres Gate zu grob ist. Ein Checker könnte Code wegen eines Nit-Issues ablehnen; ein Reviewer würde dasselbe Issue als “geringfügiges Bedenken” notieren und gleichzeitig anerkennen, dass die Umsetzung grundsätzlich solide ist.

Wann verwenden: Pre-Merge-Code-Reviews, die eine menschliche Entscheidung unterstützen sollen, Architektur-Review eines Designvorschlags, Sicherheits-Review mit Risikobewertung statt Blockade oder jedes Review-Szenario, in dem qualitatives Feedback wertvoller ist als ein binäres Verdikt.

Anwendungsfälle: Kommentare zu Pull-Request-Reviews, Risikobewertung einer neuen API-Oberfläche, Compliance-Audit für Design-Muster, Accessibility-Review einer UI-Komponenten-Bibliothek.

Empfohlene Konfiguration:Verwenden Sie Opus für nuanciertes Reasoning. Setzen Sie die Denkleistung auf “high”. Die Anweisungen sollten das Ausgabeformat explizit definieren (z. B. Sektionen für Stärken, Größere Bedenken, Kleinere Bedenken, Vorschläge). Binden Sie die Skills app-security und superpower-codereview ein. Der Reviewer sollte nicht in einer Schleife platziert werden - sein Zweck ist es, ein umfassendes Review zu produzieren, nicht ein Gate-Loop.

Custom

Der Custom-Typ ist ein freier Persona-Typ für Agenten, die in keine der neun Standardkategorien passen. Er stellt keine strukturellen Erwartungen an das Verhalten des Agenten - dieser verhält sich exakt, wie es seine Anweisungen, Skills, Kontext, Commands und Scripts vorgeben. Der Custom-Typ bietet maximale Flexibilität für spezialisierte, nicht-standardisierte Rollen.

Wann verwenden: Wenn keiner der neun eingebauten Typen genau beschreibt, was die Persona tut. Custom-Personas füllen oft einzigartige Rollen, die spezifisch für den Workflow eines Projekts sind, statt allgemeiner Entwicklungsphasen.

Anwendungsfälle:

• Dokumentations-Autor - Generiert oder aktualisiert JSDoc, README-Dateien, API-Dokumentation und Inline-Kommentare.
• Changelog-Generator - Liest git-diff-Ausgaben und erzeugt menschenlesbare Changelog-Einträge in einem bestimmten Format.
• Migrationsassistent - Wendet ein bestimmtes Datenbank- oder API-Migrationsmuster systematisch auf mehrere Dateien an.
• Abhängigkeits-Auditor - Scannt package.json auf veraltete oder verwundbare Abhängigkeiten und erstellt einen Upgrade-Plan.
• Lokalisierungs-Agent - Extrahiert fest codierte Strings und füllt i18n-Ressourcendateien.
• PR-Zusammenfasser - Liest einen git-diff und schreibt eine strukturierte Pull-Request-Beschreibung.

Empfohlene Konfiguration: Da der Custom-Typ keine vordefinierte Rolle hat, hängt die Qualität fast vollständig von der Qualität der Anweisungen ab. Schreiben Sie sehr spezifische, strukturierte Anweisungen, die nichts mehrdeutig lassen. Wählen Sie das Modell je nach Aufgabenkomplexität - einfache Texttransformationen können Sonnet nutzen, während komplexe Mehrdatei-Reasoning-Aufgaben Opus erfordern.

Typ-Auswahl-Zusammenfassung

Nächste Schritte