Alle Guides
PersonasFortgeschritten30 Min.

Eine Frontend-Persona entwerfen

Erstellen Sie eine React-+-TypeScript-Spezialisten-Persona mit eigenen Guardrails, Hausstil-Regeln und einem auf Komponentenarbeit zugeschnittenen Tool-Set.

Von Daichi Mori
Principal Engineer
Aktualisiert 25. April 2026

Voraussetzungen

  • Den Getting-Started-Guide abgeschlossen
  • Ein React-+-TypeScript-Repo mit bestehender Komponenten-Bibliothek
  • Eine Linter-Config und einen vertrauten Test-Runner

Personas sind das am stärksten unterschätzte Feature in CodeCourier. Ein generischer Agent schreibt funktionierenden Code; eine gut entworfene Persona schreibt Code, der aussieht, als hätte ihn Ihr Team geschrieben. In diesem Guide bauen Sie eine Frontend-Specialist-Persona von Grund auf - Modell, Tools, Skills, Hausstil und Guardrails - die React-+-TypeScript-Arbeit liefert, die Sie ohne Bauchschmerzen mergen.

1. Mit der richtigen Basis starten

Öffnen Sie die Personas-Bibliothek und klonen Sie das Senior Engineer-Template. Starten Sie nicht leer; das Template kommt mit sinnvollen Defaults für Modellwahl, Thinking-Budget und Tool-Permissions. Sie überschreiben, was zählt, und erben den Rest.

Benennen Sie den Klon in Frontend Specialist v1 um. Der Versionssuffix zählt - Personas sind First-Class-Objekte mit Versionen. Künftiges Ich startet Sessions mit Frontend Specialist v3, während v1 noch existiert und replayed werden kann.

2. Den Hausstil definieren

Der System-Prompt der Persona ist der Ort des Hausstils. Seien Sie spezifisch. Seien Sie meinungsstark. Das Modell rät nicht, was Sie wollen.

Sie liefern React-+-TypeScript-Komponenten für ein Design System namens Atlas.

Regeln:
- Ausschließlich Function Components. Keine Class Components.
- Komponenten-, Test- und Story-Dateien co-located: Foo.tsx, Foo.test.tsx, Foo.stories.tsx.
- Props-Interfaces exportiert, benannt `<ComponentName>Props`.
- Kein Prop-Spreading auf DOM-Nodes - explizit bleiben.
- Tailwind fürs Styling. Keine Inline-Styles außer für dynamische Werte.
- Jede interaktive Komponente nimmt ein `data-testid`-Prop entgegen.

Im Zweifel nachfragen. Hausstil-Entscheidungen nicht erfinden.

3. Die richtigen Tools anbinden

Eine Persona ist nur so gut wie ihre Tools. Für Frontend-Arbeit beschränken Sie das Toolset, statt es zu erweitern. Der Agent soll:

  • jede Datei im Repo lesen können,
  • Dateien in src/components/ und src/stories/ schreiben können,
  • pnpm test, pnpm lint und pnpm typecheck ausführen können,
  • pnpm build:storybook ausführen können, um Stories zu verifizieren.

Geben Sie keinen Shell-Zugriff. Keinen Schreibzugriff auf die CI-Config. Keine Package-Install-Rechte - eine Dependency hinzuzufügen ist eine menschliche Entscheidung.

4. Die passenden Skills anhängen

Skills sind wiederverwendbare Wissens-Bundles. Hängen Sie react-patterns, tailwind-conventions und component-testing-rtl aus der Skill-Bibliothek an. Lassen Sie den generischen frontend-design-Skill weg - er überlappt mit Ihrem Hausstil und zieht den Agenten zu einem weniger meinungsstarken Default.

Mehr Skills ist nicht besser. Skills konkurrieren um die Aufmerksamkeit des Agenten. Drei scharfe Skills schlagen zehn vage.

5. Einen Guardrail-Check ergänzen

Personas können einen Judge anhängen - ein zweites Modell, das jedes Diff bewertet, bevor der PR aufgeht. Für eine Frontend-Persona sollte der Judge knapp und meinungsstark sein: Verletzt das Diff den Hausstil? Berührt es Dateien außerhalb des Komponenten-Scope? Sind Tests vorhanden?

judge_prompt: |
  Diff ablehnen, falls eines davon zutrifft:
  - Komponenten ohne co-located Test-Datei.
  - Tailwind-Klassen mit Inline-Styles für nicht-dynamische Werte gemischt.
  - Interaktive Elemente ohne data-testid.
  - Dateien außerhalb von src/components/ oder src/stories/ verändert.

  Andernfalls genehmigen.

6. Gegen ein echtes Ticket testen

Starten Sie eine Issue Session mit der neuen Persona gegen ein echtes Ticket aus Ihrem Backlog - etwa "Tooltip-Komponente mit Pfeil-Positionierung hinzufügen". Vergleichen Sie das Diff mit dem, was Sie selbst geschrieben hätten. Iterieren Sie an System-Prompt und Judge, bis die Lücke geschlossen ist.

7. Promoten und dokumentieren

Sobald die Persona durchgehend PRs liefert, die Sie kommentarlos mergen würden, befördern Sie sie von v1-draft zu v1. Schreiben Sie eine kurze interne Notiz: wann diese Persona nutzen, wann eine andere greifen. Personas ohne Dokumentation werden falsch eingesetzt - und anschließend beschuldigt.

Als nächstes: Diese Persona via Multi-Step-Workflow-Guide in eine Sprint Chain einbetten - oder vor dem Loslassen auf das volle Backlog das Operations-Handbuch lesen.

Daichi Mori
Principal Engineer
Tags
#personas#frontend#react#typescript#hausstil
Teilen

Weiterbauen

14 Tage kostenlos · keine Kreditkarte

Stellen Sie Ihren ersten KI-Ingenieur ein.
Bis zum Mittag live.

5 Minuten Onboarding. Erster PR innerhalb einer Stunde. Jederzeit kündbar.