Prompt-Templates für Entwicklungsteams: Ein praktischer Leitfaden

Warum Standardisierung wichtig ist

Hier ist eine Szene, die täglich in Engineering-Teams abläuft:

Entwickler A bittet Claude Code, seinen Pull Request zu reviewen. Er erhält gründliches Feedback zu Code-Struktur, potenziellen Bugs und Performance-Implikationen. Er braucht 10 Minuten, um einen guten Prompt zu schreiben, aber das Review ist exzellent.

Entwickler B bittet Claude Code mit einem schnellen, generischen Prompt um ein Review seines Pull Requests. Er bekommt oberflächliches Feedback, das kritische Probleme übersieht. Der PR passiert das Review, und ein Bug erreicht die Produktion.

Entwickler C ist neu im Team. Er weiß nicht, wie der effektive Ansatz von Entwickler A aussieht. Er verbringt 30 Minuten damit, verschiedene Prompts auszuprobieren, gibt schließlich auf und macht das Review manuell.

Das ist das Prompt-Roulette-Problem: ähnliche Aufgaben produzieren völlig unterschiedliche Ergebnisse, abhängig davon, wer promptet und wie. Es ist verschwenderisch, inkonsistent und frustrierend.

Prompt-Templates lösen dies, indem sie effektive Muster in wiederverwendbare Strukturen kodieren. Anstatt dass jeder Entwickler Prompts neu erfindet, nutzen sie Templates, die konsistent hochwertige Outputs produzieren.

Die Vorteile

Konsistenz: Gleiche Aufgabe, gleicher Ansatz, ähnliche Qualitäts-Outputs. Code-Reviews folgen der gleichen Struktur. Dokumentation entspricht dem gleichen Stil. Tests decken die gleichen Muster ab.

Wissenssicherung: Wenn Ihre besten Prompt-Ingenieure gehen, bleibt ihr Wissen. Templates erfassen institutionelle Intelligenz, die sonst mit ihnen gehen würde.

Einarbeitungsbeschleunigung: Neue Entwickler fangen nicht bei null an. Sie erhalten sofortigen Zugang zu effektiven Mustern, deren Entwicklung Monate gedauert hat.

Qualitätsbasis: Templates etablieren einen Mindestqualitätsboden. Auch schnelle, geringfügige Nutzung produziert akzeptable Ergebnisse.

Iterationsgrundlage: Templates bieten eine stabile Basis für Verbesserungen. Sie können Template-Varianten A/B-testen und messen, welche bessere Ergebnisse produziert.

Template-Kategorien

Die meisten Entwicklungsteams benötigen Templates in diesen Kategorien. Beginnen Sie mit einer Kategorie, perfektionieren Sie sie, dann erweitern Sie.

Code-Review-Templates

Code-Review ist oft die ROI-stärkste Template-Kategorie. Reviews finden ständig statt, die Qualität variiert stark, und die Kosten übersehener Probleme sind hoch.

Template-Typen:

• Allgemeines Code-Review (sprachspezifisch)
• Sicherheitsfokussiertes Review
• Performance-Review
• Architektur/Design-Review
• Migrations/Refactoring-Review

Beispielstruktur:

# TypeScript Code-Review Template

## Kontext
Du reviewst TypeScript-Code für die Codebasis von [TEAM_NAME].
Unsere Coding-Standards: [LINK_ZU_STANDARDS]
Unsere Architekturmuster: [LINK_ZU_MUSTERN]

## Anweisungen
Review den folgenden Code auf:
1. Korrektheit: Logikfehler, Randfälle, Fehlerbehandlung
2. TypeScript: Typsicherheit, korrekte Typisierung, any vermeiden
3. Architektur: Ausrichtung mit unseren Mustern
4. Performance: Offensichtliche Ineffizienzen
5. Sicherheit: Eingabevalidierung, Injection-Risiken
6. Wartbarkeit: Lesbarkeit, Benennung, Komplexität

## Format
Gib Feedback als:
- 🔴 KRITISCH: Probleme, die behoben werden müssen
- 🟡 VORSCHLAG: Verbesserungen zum Überlegen
- 🟢 GUT: Gut gemachte Dinge (kurz)

Für jedes Element, beinhalte:
- Ort (datei:zeile)
- Problembeschreibung
- Vorgeschlagene Lösung

## Zu reviewender Code
[CODE_ÄNDERUNGEN]

Dokumentations-Templates

Dokumentation wird oft vernachlässigt, weil sie mühsam ist. Gute Templates reduzieren die Reibung.

Template-Typen:

• API-Dokumentation
• Architecture Decision Records (ADRs)
• Runbooks und Playbooks
• README-Generierung
• Code-Kommentare
• Changelog-Einträge

Beispielstruktur:

# API-Dokumentations-Template

## Kontext
Dokumentiere diesen API-Endpunkt für unsere Entwicklerdokumentation.
Folge unserem Dokumentations-Styleguide: [LINK]
Zielgruppe: Externe Entwickler, die unsere API integrieren

## Anweisungen
Generiere Dokumentation inklusive:
1. Endpunkt-Zusammenfassung (ein Satz)
2. Authentifizierungsanforderungen
3. Request-Format (Methode, Pfad, Header, Body)
4. Response-Format (Erfolgs- und Fehlerfälle)
5. Code-Beispiele (curl und JavaScript)
6. Häufige Fehler und Troubleshooting

## Format
Verwende unser Dokumentations-Markdown-Format:
- H2 für Endpunkt-Pfad
- H3 für Abschnitte
- Code-Blöcke mit Sprach-Tags
- Tabellen für Parameter

## Zu dokumentierender Endpunkt
[ENDPUNKT_DEFINITION]
[IMPLEMENTIERUNGS_CODE]

Test-Templates

Testgenerierung profitiert von Templates, weil Tests konsistent, umfassend sein sollten und zu Team-Mustern passen sollten.

Template-Typen:

• Unit-Test-Generierung
• Integrations-Test-Szenarien
• E2E-Testfälle
• Testdaten-Generierung
• Randfall-Identifikation

Beispielstruktur:

# Unit-Test Template

## Kontext
Generiere Unit-Tests für [TEAM_NAME] mit unserem Test-Stack:
- Framework: Jest mit TypeScript
- Mocking: jest.mock für Abhängigkeiten
- Assertions: expect().toBe/toEqual/toThrow-Muster
- Struktur: describe/it mit klarer Benennung

Unsere Test-Namenskonvention: "should [erwartetes Verhalten] when [Bedingung]"

## Anweisungen
Generiere umfassende Tests inklusive:
1. Happy Path: Normale erfolgreiche Ausführung
2. Randfälle: Grenzwerte, leere Eingaben, Nulls
3. Fehlerfälle: Erwartete Fehlermodi
4. Typsicherheit: TypeScript-spezifische Checks

Jeder Test sollte:
- Unabhängig sein (keine Test-Interdependenzen)
- Externe Abhängigkeiten mocken
- Beschreibende Namen verwenden
- AAA-Muster beinhalten (Arrange, Act, Assert)

## Format
```typescript
describe('[Funktions/Klassenname]', () => {
  describe('[Methode oder Szenario]', () => {
    it('should [Verhalten] when [Bedingung]', () => {
      // Arrange
      // Act
      // Assert
    });
  });
});

Zu testender Code

[FUNKTION_ODER_KLASSE]

### Refactoring-Templates

Refactoring-Unterstützung hilft, die Code-Qualität über Zeit zu erhalten.

**Template-Typen**:
- Code-Modernisierung
- Muster-Migration
- Performance-Optimierung
- Dependency-Updates
- Technical-Debt-Reduktion

## Template-Anatomie

Jedes effektive Prompt-Template hat vier Komponenten:

### 1. Kontext

Kontext sagt Claude Code, wer es ist und was es weiß. Guter Kontext beinhaltet:

**Rollendefinition**: Welche Expertise sollte Claude annehmen?

Du bist ein Senior TypeScript-Ingenieur mit tiefer Expertise in React-Performance-Optimierung.

**Domänenwissen**: Was muss Claude über Ihre spezifische Situation wissen?

Unsere Anwendung ist ein B2B SaaS-Dashboard mit 50.000 DAU. Wir nutzen React 18 mit Server Components. Performance-Budget: LCP < 2,5s, FID < 100ms.

**Einschränkungen**: Welche Limitierungen oder Anforderungen existieren?

Wir können keine externen State-Management-Bibliotheken verwenden. Alle Änderungen müssen abwärtskompatibel sein. Wir folgen semantischer Versionierung.

### 2. Anweisung

Anweisungen sagen Claude Code, was zu tun ist. Gute Anweisungen sind:

**Spezifisch**: "Prüfe auf Sicherheitslücken" nicht "check den Code"

**Strukturiert**: Nummerierte Schritte oder klare Phasen

**Vollständig**: Alle erforderlichen Outputs werden erwähnt

**Priorisiert**: Wichtigste Punkte zuerst

Beispiel:

Analysiere diese Datenbank-Migration auf:

1. Datenintegrität: Werden bestehende Daten korrekt erhalten?
2. Rollback-Sicherheit: Können wir diese Migration rückgängig machen?
3. Performance: Wird die Migration in <5 Minuten für 1M Zeilen abgeschlossen?
4. Locking: Welche Tabellen/Zeilen werden wie lange gesperrt?

Bei kritischen Problemen, stoppe und erkläre bevor du fortfährst.

### 3. Format

Format spezifiziert, wie Claude Code seinen Output strukturieren soll. Ohne Format-Anleitung variieren Outputs stark in der Struktur.

**Markdown-Struktur**: Überschriften, Listen, Code-Blöcke

Verwende diese Struktur:

Zusammenfassung

Kritische Probleme

Empfehlungen

Implementierungsschritte

**Spezifische Formate**: JSON, YAML, bestimmte Code-Muster

Gib deine Analyse als JSON zurück: { “risk_level”: “low|medium|high|critical”, “issues”: [{“type”: ”…”, “description”: ”…”, “location”: ”…”}], “recommendations”: [”…”] }

**Längenangabe**: Wie viel Detail wird erwartet?

Gib eine kurze Zusammenfassung (2-3 Sätze) gefolgt von detaillierter Analyse. Halte die gesamte Antwort unter 500 Wörtern, außer kritische Probleme erfordern mehr Detail.

### 4. Beispiele

Beispiele (Few-Shot Learning) verbessern die Output-Qualität dramatisch für komplexe Aufgaben.

**Input/Output-Paare**: Zeige, wie gut aussieht

Beispiel Review-Kommentar: Input: const data = await fetch(url); Output: 🟡 VORSCHLAG: Füge Fehlerbehandlung für fetch hinzu. Erwäge:

const response = await fetch(url);
if (!response.ok) {
  throw new ApiError(`HTTP ${response.status}`, response);
}
const data = await response.json();

**Anti-Beispiele**: Zeige, was zu vermeiden ist

Vermeide generische Kommentare wie “sieht gut aus” oder “erwäge Refactoring”. Jeder Kommentar sollte spezifisch und umsetzbar sein.

## Implementierungsmuster

Wie Sie Templates implementieren ist genauso wichtig wie die Templates selbst.

### Versionskontrolle

Behandle Templates wie Code. Speichere sie in Git mit korrekter Versionierung.

templates/ ├── code-review/ │ ├── typescript-review.v2.1.0.md │ ├── security-review.v1.3.0.md │ └── CHANGELOG.md ├── documentation/ │ ├── api-docs.v1.2.0.md │ └── adr-template.v1.0.0.md └── testing/ ├── unit-test.v2.0.0.md └── e2e-scenarios.v1.1.0.md

**Semantische Versionierung**:
- **Major**: Breaking Changes in Template-Struktur
- **Minor**: Neue Fähigkeiten, abwärtskompatibel
- **Patch**: Bugfixes, Formulierungsverbesserungen

### Variablen und Anpassung

Templates sollten ohne Modifikation anpassbar sein. Verwende klare Variablenmuster.

**Variablen-Syntax**:

[VARIABLEN_NAME] - Erforderlich, muss angegeben werden [OPTIONAL_VAR?] - Optional, kann weggelassen werden [VAR:default] - Hat Standardwert wenn nicht angegeben

**Häufige Variablen**:
- `[CODE]` - Der zu analysierende Code
- `[LANGUAGE]` - Programmiersprache
- `[TEAM_STANDARDS]` - Link zu Coding-Standards
- `[OUTPUT_FORMAT]` - Gewünschte Output-Struktur

### Kontext-Injection

Verbinde Templates mit deiner spezifischen Codebasis und Standards.

**Statischer Kontext**: Immer eingeschlossene Information

Team-Standards

• TypeScript strict mode erforderlich
• Keine any-Typen
• Alle öffentlichen Funktionen müssen JSDoc haben
• Maximale Funktionskomplexität: 10

**Dynamischer Kontext**: Zur Laufzeit eingespeist

Aktueller Kontext

Repository: {{repo_name}} Branch: {{branch_name}} Verwandte Dateien: {{related_files}} Letzte Änderungen: {{git_log_summary}}

**MCP-Integration**: Kontext von Servern abrufen

Projektkontext

prompt-library/
├── README.md                    # Bibliotheksübersicht, Nutzung
├── CONTRIBUTING.md              # Wie man Templates hinzufügt/ändert
├── catalog.json                 # Maschinenlesbarer Template-Index
│
├── by-category/                 # Nach Anwendungsfall organisiert
│   ├── code-review/
│   ├── documentation/
│   ├── testing/
│   └── refactoring/
│
├── by-language/                 # Sprachspezifische Varianten
│   ├── typescript/
│   ├── python/
│   └── go/
│
├── experimental/                # Templates in Entwicklung
│   └── README.md               # Experimentelle Nutzungsrichtlinie
│
└── archived/                    # Veraltete Templates
    └── README.md               # Migrationsanleitung