Prompt-Optimizer

Was macht Prompt-Optimizer?

Analysiere einen Prompt-Entwurf, bewerte ihn, gleiche ihn mit ECC-Ökosystem-Komponenten ab und gib einen vollständigen optimierten Prompt aus, den der Benutzer kopieren und ausführen kann.

Wann verwenden

• Der Benutzer sagt "Optimieren Sie diesen Prompt", "Verbessern Sie meinen Prompt", "Schreiben Sie diesen Prompt um"
• Der Benutzer sagt "Helfen Sie mir, einen besseren Prompt zu schreiben für..."
• Der Benutzer sagt "Was ist der beste Weg, Claude Code zu bitten..."
• Der Benutzer sagt "优化prompt", "改进prompt", "怎么写prompt", "帮我优化这个指令"
• Der Benutzer fügt einen Prompt-Entwurf ein und bittet um Feedback oder Verbesserung
• Der Benutzer sagt "Ich weiß nicht, wie ich dafür prompten soll"
• Der Benutzer sagt "Wie sollte ich ECC für... verwenden"
• Der Benutzer ruft explizit /prompt-optimize auf

Nicht verwenden, wenn

• Der Benutzer die Aufgabe direkt erledigt haben möchte (einfach ausführen)
• Der Benutzer sagt "优化代码", "优化性能", "optimize this code", "optimize performance" – das sind Refactoring-Aufgaben, keine Prompt-Optimierung
• Der Benutzer nach ECC-Konfiguration fragt (stattdessen configure-ecc verwenden)
• Der Benutzer eine Fähigkeitsinventur wünscht (stattdessen skill-stocktake verwenden)
• Der Benutzer sagt "Mach es einfach" oder "直接做"

Funktionsweise

Nur beratend – die Aufgabe des Benutzers nicht ausführen.

Schreibe KEINEN Code, erstelle KEINE Dateien, führe KEINE Befehle aus und ergreife KEINE Implementierungsmaßnahmen. Deine EINZIGE Ausgabe ist eine Analyse plus ein optimierter Prompt.

Wenn der Benutzer "Mach es einfach", "直接做" oder "Nicht optimieren, einfach ausführen" sagt, wechsle nicht in den Implementierungsmodus innerhalb dieser Fähigkeit. Teile dem Benutzer mit, dass diese Fähigkeit nur optimierte Prompts erstellt, und weise ihn an, eine normale Aufgabenanfrage zu stellen, wenn er eine Ausführung wünscht.

Führe diese 6-phasige Pipeline nacheinander aus. Präsentiere die Ergebnisse unter Verwendung des Ausgabeformats unten.

Analyse-Pipeline

Phase 0: Projekterkennung

Bevor der Prompt analysiert wird, erkenne den aktuellen Projektkontext:

1. Überprüfe, ob im Arbeitsverzeichnis eine CLAUDE.md existiert – lese sie für Projektkonventionen
2. Erkenne den Tech-Stack aus den Projektdateien:
   • package.json → Node.js / TypeScript / React / Next.js
   • go.mod → Go
   • pyproject.toml / requirements.txt → Python
   • Cargo.toml → Rust
   • build.gradle / pom.xml → Java / Kotlin (dann prüfe auf quarkus in der Build-Datei → Quarkus, oder spring-boot → Spring Boot)
   • Package.swift → Swift
   • Gemfile → Ruby
   • composer.json → PHP
   • *.csproj / *.sln → .NET
   • Makefile / CMakeLists.txt → C / C++
   • cpanfile / Makefile.PL → Perl
3. Notiere den erkannten Tech-Stack zur Verwendung in Phase 3 und Phase 4

Wenn keine Projektdateien gefunden werden (z. B. der Prompt ist abstrakt oder für ein neues Projekt), überspringe die Erkennung und markiere "Tech-Stack unbekannt" in Phase 4.

Phase 1: Absichtserkennung

Klassifiziere die Aufgabe des Benutzers in eine oder mehrere Kategorien:

Kategorie	Signalwörter	Beispiel
Neue Funktion	build, create, add, implement, 创建, 实现, 添加	„Erstelle eine Anmeldeseite"
Fehlerbehebung	fix, broken, not working, error, 修复, 报错	„Repariere den Authentifizierungsablauf"
Refactoring	refactor, clean up, restructure, 重构, 整理	„Refaktorisiere die API-Ebene"
Recherche	how to, what is, explore, investigate, 怎么, 如何	„Wie füge ich SSO hinzu"
Testen	test, coverage, verify, 测试, 覆盖率	„Füge Tests für den Warenkorb hinzu"
Überprüfung	review, audit, check, 审查, 检查	„Überprüfe meinen PR"
Dokumentation	document, update docs, 文档	„Aktualisiere die API-Dokumentation"
Infrastruktur	deploy, CI, docker, database, 部署, 数据库	„Richte CI/CD-Pipeline ein"
Design	design, architecture, plan, 设计, 架构	„Entwerfe das Datenmodell"

Phase 2: Umfangsbewertung

Wenn Phase 0 ein Projekt erkannt hat, verwende die Codebasisgröße als Signal. Andernfalls schätze anhand der Prompt-Beschreibung allein und markiere die Schätzung als unsicher.

Umfang	Heuristik	Orchestrierung
TRIVIAL	Einzelne Datei, < 50 Zeilen	Direkte Ausführung
NIEDRIG	Einzelne Komponente oder Modul	Einzelner Befehl oder Fähigkeit
MITTEL	Mehrere Komponenten, gleiche Domäne	Befehlskette + /verify
HOCH	Domänenübergreifend, 5+ Dateien	/plan zuerst, dann phasenweise Ausführung
EPISCH	Mehrere Sitzungen, mehrere PRs, Architekturänderung	Verwende die Blueprint-Fähigkeit für einen Multi-Sitzungs-Plan

Phase 3: ECC-Komponentenzuordnung

Ordne Absicht + Umfang + Tech-Stack (aus Phase 0) spezifischen ECC-Komponenten zu.

Nach Absichtstyp

Absicht	Befehle	Fähigkeiten	Agenten
Neue Funktion	/plan, /tdd, /code-review, /verify	tdd-workflow, verification-loop	planner, tdd-guide, code-reviewer
Fehlerbehebung	/tdd, /build-fix, /verify	tdd-workflow	tdd-guide, build-error-resolver
Refactoring	/refactor-clean, /code-review, /verify	verification-loop	refactor-cleaner, code-reviewer
Recherche	/plan	search-first, iterative-retrieval	—
Testen	/tdd, /e2e, /test-coverage	tdd-workflow, e2e-testing	tdd-guide, e2e-runner
Überprüfung	/code-review	security-review	code-reviewer, security-reviewer
Dokumentation	/update-docs, /update-codemaps	—	doc-updater
Infrastruktur	/plan, /verify	docker-patterns, deployment-patterns, database-migrations	architect
Design (MITTEL-HOCH)	/plan	—	planner, architect
Design (EPISCH)	—	blueprint (als Fähigkeit aufrufen)	planner, architect

Nach Tech-Stack

Tech-Stack	Hinzuzufügende Fähigkeiten	Agent
Python / Django	django-patterns, django-tdd, django-security, django-verification, python-patterns, python-testing	python-reviewer
Go	golang-patterns, golang-testing	go-reviewer, go-build-resolver
Spring Boot / Java	springboot-patterns, springboot-tdd, springboot-security, springboot-verification, java-coding-standards, jpa-patterns	java-reviewer
Quarkus / Java	quarkus-patterns, quarkus-tdd, quarkus-security, quarkus-verification, java-coding-standards, jpa-patterns	java-reviewer
Kotlin / Android	kotlin-coroutines-flows, compose-multiplatform-patterns, android-clean-architecture	kotlin-reviewer
TypeScript / React	frontend-patterns, backend-patterns, coding-standards	code-reviewer
Swift / iOS	swiftui-patterns, swift-concurrency-6-2, swift-actor-persistence, swift-protocol-di-testing	code-reviewer
PostgreSQL	postgres-patterns, database-migrations	database-reviewer
Perl	perl-patterns, perl-testing, perl-security	code-reviewer
C++	cpp-coding-standards, cpp-testing	code-reviewer
Sonstige / Nicht aufgeführt	coding-standards (universell)	code-reviewer

Phase 4: Erkennung fehlender Kontextinformationen

Scanne den Prompt auf fehlende kritische Informationen. Überprüfe jedes Element und markiere, ob Phase 0 es automatisch erkannt hat oder der Benutzer es angeben muss:

• Tech-Stack – In Phase 0 erkannt, oder muss der Benutzer es angeben?
• Zielumfang – Dateien, Verzeichnisse oder Module erwähnt?
• Anforderungskriterien – Woran erkennt man, dass die Aufgabe erledigt ist?
• Fehlerbehandlung – Grenzfälle und Fehlermodi behandelt?
• Sicherheitsanforderungen – Authentifizierung, Eingabevalidierung, Geheimnisse?
• Testerwartungen – Unit-, Integrations-, E2E-Tests?
• Leistungsbeschränkungen – Last, Latenz, Ressourcengrenzen?
• UI/UX-Anforderungen – Designspezifikationen, responsiv, a11y? (falls Frontend)
• Datenbankänderungen – Schema, Migrationen, Indizes? (falls Datenebene)
• Bestehende Muster – Referenzdateien oder Konventionen, die befolgt werden müssen?
• Umfangsgrenzen – Was NICHT getan werden soll?

Wenn 3+ kritische Elemente fehlen, stelle dem Benutzer bis zu 3 Klärungsfragen, bevor der optimierte Prompt generiert wird. Integriere dann die Antworten in den optimierten Prompt.

Phase 5: Arbeitsablauf- und Modell-Empfehlung

Bestimme, wo dieser Prompt im Entwicklungsworkflow steht:

Recherche → Plan → Implementieren (TDD) → Überprüfen → Verifizieren → Commit

Beginne bei Aufgaben mit MITTEL+ Umfang immer mit /plan. Verwende bei EPISCHEN Aufgaben die Blueprint-Fähigkeit.

Modell-Empfehlung (in die Ausgabe aufnehmen):

Umfang	Empfohlenes Modell	Begründung
TRIVIAL-NIEDRIG	Sonnet 5	Schnell, kosteneffizient für einfache Aufgaben
MITTEL	Sonnet 5	Bestes Codierungsmodell für Standardarbeit
HOCH	Sonnet 5 (Haupt) + Opus 5 (Planung)	Opus für Architektur, Sonnet für Implementierung
EPISCH	Opus 5 (Blueprint) + Sonnet 5 (Ausführung)	Tiefes Denken für Multi-Sitzungs-Planung

Multi-Prompt-Aufteilung (für HOCHEN/EPISCHEN Umfang):

Bei Aufgaben, die eine einzelne Sitzung überschreiten, teile sie in sequenzielle Prompts auf:

• Prompt 1: Recherche + Plan (verwende die search-first-Fähigkeit, dann /plan)
• Prompt 2-N: Implementiere eine Phase pro Prompt (jeder endet mit /verify)
• Letzter Prompt: Integrationstest + /code-review über alle Phasen hinweg
• Verwende /save-session und /resume-session, um den Kontext zwischen Sitzungen zu erhalten

---

Ausgabeformat

Präsentiere deine Analyse in dieser genauen Struktur. Antworte in derselben Sprache wie die Eingabe des Benutzers.

Abschnitt 1: Prompt-Diagnose

Stärken: Liste auf, was der ursprüngliche Prompt gut macht.

Probleme:

Problem	Auswirkung	Vorgeschlagene Korrektur
(Problem)	(Konsequenz)	(Wie zu beheben)

Klärungsbedarf: Nummerierte Liste der Fragen, die der Benutzer beantworten sollte. Wenn Phase 0 die Antwort automatisch erkannt hat, gib sie an, anstatt zu fragen.

Abschnitt 2: Empfohlene ECC-Komponenten

Typ	Komponente	Zweck
Befehl	/plan	Architektur vor dem Codieren planen
Fähigkeit	tdd-workflow	TDD-Methodik-Leitfaden
Agent	code-reviewer	Überprüfung nach der Implementierung
Modell	Sonnet 5	Für diesen Umfang empfohlen

Abschnitt 3: Optimierter Prompt – Vollversion

Präsentiere den vollständigen optimierten Prompt innerhalb eines einzigen Code-Blocks. Der Prompt muss in sich geschlossen und bereit zum Kopieren und Einfügen sein. Füge Folgendes ein:

• Klare Aufgabenbeschreibung mit Kontext
• Tech-Stack (erkannt oder angegeben)
• /command-Aufrufe in den richtigen Workflow-Phasen
• Anforderungskriterien
• Verifizierungsschritte
• Umfangsgrenzen (was NICHT getan werden soll)

Schreibe für Elemente, die auf Blueprint verweisen: "Verwende die Blueprint-Fähigkeit, um ..." (nicht /blueprint, da Blueprint eine Fähigkeit und kein Befehl ist).

Abschnitt 4: Optimierter Prompt – Kurzversion

Eine kompakte Version für erfahrene ECC-Benutzer. Variiere nach Absichtstyp:

Absicht	Kurzes Muster
Neue Funktion	/plan [Feature]. /tdd zur Implementierung. /code-review. /verify.
Fehlerbehebung	/tdd – Schreibe fehlschlagenden Test für [Bug]. Repariere bis grün. /verify.
Refactoring	/refactor-clean [Umfang]. /code-review. /verify.
Recherche	Verwende die search-first-Fähigkeit für [Thema]. /plan basierend auf Ergebnissen.
Testen	/tdd [Modul]. /e2e für kritische Abläufe. /test-coverage.
Überprüfung	/code-review. Verwende dann den security-reviewer-Agenten.
Dokumentation	/update-docs. /update-codemaps.
EPISCH	Verwende die Blueprint-Fähigkeit für "[Ziel]". Führe Phasen mit /verify-Gates aus.

Abschnitt 5: Begründung der Verbesserungen

Verbesserung	Grund
(was wurde hinzugefügt)	(warum es wichtig ist)

Fußzeile

Nicht das, was Sie brauchen? Teilen Sie mir mit, was angepasst werden soll, oder stellen Sie eine normale Aufgabenanfrage, wenn Sie eine Ausführung anstelle einer Prompt-Optimierung wünschen.

---

Beispiele

Auslöser-Beispiele

• "Optimieren Sie diesen Prompt für ECC"
• "Schreiben Sie diesen Prompt um, damit Claude Code die richtigen Befehle verwendet"
• "帮我优化这个指令"
• "Wie sollte ich ECC für diese Aufgabe prompten?"

Beispiel 1: Vager deutscher Prompt (Projekt erkannt)

Benutzereingabe:

Hilf mir, eine Benutzeranmeldeseite zu schreiben

Phase 0 erkennt: package.json mit Next.js 15, TypeScript, Tailwind CSS

Optimierter Prompt (Vollversion):

Verwende den vorhandenen Tech-Stack des Projekts (Next.js 15 + TypeScript + Tailwind CSS), um eine Benutzeranmeldeseite zu implementieren.

Technische Anforderungen:
- Verwende die vorhandenen Komponentenstrukturen und Routenkonventionen des Projekts
- Verwende für die Formularvalidierung das bereits im Projekt verwendete Validierungsschema (prüfe, ob Zod/Yup/anderes verwendet wird)
- Authentifizierungsmethode: Verwende das vorhandene Authentifizierungsschema des Projekts (falls nicht vorhanden, standardmäßig JWT)
- Enthält: E-Mail/Passwort-Anmeldeformular, Formularvalidierung, Fehlermeldungen, Ladezustand, responsives Layout

Workflow:
1. /plan zuerst die Komponentenstruktur und den Authentifizierungsablauf planen, unter Bezugnahme auf bestehende Seitenmuster
2. /tdd test-first: Schreibe Unit-Tests für das Anmeldeformular und Integrationstests für den Authentifizierungsablauf
3. Implementiere die Anmeldeseite und die Authentifizierungslogik
4. /code-review überprüfe die Implementierung
5. /verify verifiziere, dass alle Tests bestehen und die Seite normal gerendert wird

Sicherheitsanforderungen:
- Passwort wird nicht im Klartext übertragen
- Schutz vor Brute-Force-Angriffen (Rate Limiting)
- XSS-Schutz
- CSRF-Token

Anforderungskriterien:
- Alle Tests bestehen, Abdeckung 80%+
- Seite wird auf Mobilgeräten und Desktop normal gerendert
- Erfolgreiche Anmeldung leitet zum Dashboard weiter, Fehler zeigen Fehlermeldungen an

Nicht tun:
- Keine Registrierungsseite implementieren
- Keine Passwort-vergessen-Funktion implementieren
- Vorhandene Routenstruktur nicht ändern

Beispiel 2: Englischer Prompt mit mittlerem Umfang

Benutzereingabe:

Füge einen REST-API-Endpunkt für Benutzerprofilaktualisierungen mit Validierung hinzu

Phase 0 erkennt: go.mod mit Go 1.22, Chi Router

Optimierter Prompt (Vollversion):

Füge einen REST-API-Endpunkt für Benutzerprofilaktualisierungen hinzu (PATCH /api/users/:id).

Tech-Stack: Go 1.22 + Chi Router (aus Projekt erkannt)

Anforderungen:
- PATCH /api/users/:id – teilweise Aktualisierung des Benutzerprofils
- Eingabevalidierung für Felder: name, email, avatar_url, bio
- Auth: gültiges Token erforderlich, Benutzer können nur ihr eigenes Profil aktualisieren
- Rückgabe 200 mit aktualisiertem Benutzer bei Erfolg
- Rückgabe 400 mit Validierungsfehlern bei ungültiger Eingabe
- Rückgabe 401/403 bei Authentifizierungsfehlern
- Befolge vorhandene API-Muster in der Codebasis

Workflow:
1. /plan die Endpunktstruktur, Middleware-Kette und Validierungslogik
2. /tdd – Schreibe tabellengesteuerte Tests für Erfolg, Validierungsfehler, Authentifizierungsfehler, nicht gefunden
3. Implementiere gemäß vorhandenen Handler-Mustern
4. /go-review
5. /verify – führe die vollständige Testsuite aus, bestätige keine Regressionen

Nicht tun:
- Vorhandene Endpunkte nicht ändern
- Das Datenbankschema nicht ändern (vorhandene Benutzertabelle verwenden)
- Keine neuen Abhängigkeiten hinzufügen, ohne zuerst vorhandene zu prüfen (search-first-Fähigkeit verwenden)

Beispiel 3: EPISCHES Projekt

Benutzereingabe:

Migriere unseren Monolithen zu Microservices

Optimierter Prompt (Vollversion):

Verwende die Blueprint-Fähigkeit, um zu planen: "Monolith zu Microservices-Architektur migrieren"

Beantworte vor der Ausführung diese Fragen im Blueprint:
1. Welche Domänengrenzen existieren im aktuellen Monolithen?
2. Welcher Dienst sollte zuerst extrahiert werden (geringste Kopplung)?
3. Kommunikationsmuster: REST-APIs, gRPC oder ereignisgesteuert (Kafka/RabbitMQ)?
4. Datenbankstrategie: Geteilte Datenbank anfangs oder Datenbank-pro-Dienst von Anfang an?
5. Bereitstellungsziel: Kubernetes, Docker Compose oder serverlos?

Der Blueprint sollte Phasen wie diese erzeugen:
- Phase 1: Dienstgrenzen identifizieren und Domänenkarte erstellen
- Phase 2: Infrastruktur einrichten (API-Gateway, Service Mesh, CI/CD pro Dienst)
- Phase 3: Ersten Dienst extrahieren (Strangler-Fig-Muster)
- Phase 4: Mit Integrationstests verifizieren, dann nächsten Dienst extrahieren
- Phase N: Monolithen außer Betrieb nehmen

Jede Phase = 1 PR, mit /verify-Gates zwischen den Phasen.
Verwende /save-session zwischen den Phasen