name: prompt-optimizer description: Analysiert Roh-Prompts, erkennt Absichten und Lücken, gleicht ECC-Komponenten (Skills/Befehle/Agents/Hooks) ab und gibt einen optimierten, fertig einfügbaren Prompt aus. Nur beratend – führt die Aufgabe niemals selbst aus. AUSLÖSUNG wenn der Benutzer sagt: „optimize prompt“, „improve my prompt“, „how to write a prompt for“, „help me prompt“, „rewrite this prompt“ oder explizit um Verbesserung der Promptqualität bittet. Löst auch bei chinesischen Äquivalenten aus: „优化prompt“, „改进prompt“, „怎么写prompt“, „帮我优化这个指令“. NICHT AUSLÖSEN wenn der Benutzer die Aufgabe direkt ausgeführt haben möchte.
Was macht Prompt-Optimizer?
Analysiert einen Prompt-Entwurf, bewertet ihn, gleicht ihn mit dem ECC-Ökosystem ab und gibt einen vollständigen optimierten Prompt aus, den der Benutzer einfügen und ausführen kann.
Wann verwenden
- Der Benutzer sagt „optimize this prompt“, „improve my prompt“, „rewrite this prompt“
- Der Benutzer sagt „help me write a better prompt for…“
- Der Benutzer sagt „what's the best way to ask Claude Code to…“
- Der Benutzer sagt „优化prompt“, „改进prompt“, „怎么写prompt“, „帮我优化这个指令“
- Der Benutzer fügt einen Prompt-Entwurf ein und bittet um Feedback oder Verbesserung
- Der Benutzer sagt „I don't know how to prompt for this“
- Der Benutzer sagt „how should I use ECC for…“
- Der Benutzer ruft explizit
/prompt-optimizeauf
Nicht verwenden wenn
- Der Benutzer die Aufgabe direkt ausgeführt haben möchte (einfach ausführen)
- Der Benutzer sagt „优化代码“, „优化性能“, „optimize this code“, „optimize performance“ – das sind Refactoring-Aufgaben, keine Prompt-Optimierung
- Der Benutzer fragt nach ECC-Konfiguration (stattdessen
configure-eccverwenden) - Der Benutzer eine Skill-Inventur wünscht (stattdessen
skill-stocktakeverwenden) - Der Benutzer sagt „just do it“ oder „直接做“
So funktioniert es
Nur beratend – führen Sie die Aufgabe des Benutzers nicht aus.
Schreiben Sie KEINEN Code, erstellen Sie KEINE Dateien, führen Sie KEINE Befehle aus und ergreifen Sie KEINE Implementierungsmaßnahmen. Ihre EINZIGE Ausgabe ist eine Analyse plus ein optimierter Prompt.
Wenn der Benutzer „just do it“, „直接做“ oder „don't optimize, just execute“ sagt, wechseln Sie NICHT in den Implementierungsmodus innerhalb dieses Skills. Teilen Sie dem Benutzer mit, dass dieses Skill nur optimierte Prompts erstellt, und weisen Sie ihn an, eine normale Aufgabenanfrage zu stellen, wenn er eine Ausführung wünscht.
Durchlaufen Sie diese 6-Phasen-Pipeline nacheinander. Präsentieren Sie die Ergebnisse mit dem untenstehenden Ausgabeformat.
Analyse-Pipeline
Phase 0: Projekterkennung
Bevor Sie den Prompt analysieren, erkennen Sie den aktuellen Projektkontext:
- Prüfen Sie, ob im Arbeitsverzeichnis eine
CLAUDE.mdexistiert – lesen Sie sie für Projektkonventionen - Erkennen Sie den Tech-Stack aus Projektdateien:
package.json→ Node.js / TypeScript / React / Next.jsgo.mod→ Gopyproject.toml/requirements.txt→ PythonCargo.toml→ Rustbuild.gradle/pom.xml→ Java / Kotlin / Spring BootPackage.swift→ SwiftGemfile→ Rubycomposer.json→ PHP*.csproj/*.sln→ .NETMakefile/CMakeLists.txt→ C / C++cpanfile/Makefile.PL→ Perl
- Notieren Sie den erkannten Tech-Stack für die Verwendung in Phase 3 und Phase 4
Wenn keine Projektdateien gefunden werden (z. B. der Prompt ist abstrakt oder für ein neues Projekt), überspringen Sie die Erkennung und markieren Sie „tech stack unknown“ in Phase 4.
Phase 1: Absichtserkennung
Klassifizieren Sie die Aufgabe des Benutzers in eine oder mehrere Kategorien:
| Kategorie | Signalwörter | Beispiel |
|---|---|---|
| Neue Funktion | build, create, add, implement, 创建, 实现, 添加 | „Eine Login-Seite erstellen“ |
| Bugfix | fix, broken, not working, error, 修复, 报错 | „Den Auth-Flow reparieren“ |
| Refactoring | refactor, clean up, restructure, 重构, 整理 | „Die API-Schicht refaktorisieren“ |
| Recherche | how to, what is, explore, investigate, 怎么, 如何 | „Wie füge ich SSO hinzu“ |
| Testen | test, coverage, verify, 测试, 覆盖率 | „Tests für den Warenkorb hinzufügen“ |
| Review | review, audit, check, 审查, 检查 | „Meinen PR überprüfen“ |
| Dokumentation | document, update docs, 文档 | „Die API-Dokumentation aktualisieren“ |
| Infrastruktur | deploy, CI, docker, database, 部署, 数据库 | „CI/CD-Pipeline einrichten“ |
| Design | design, architecture, plan, 设计, 架构 | „Das Datenmodell entwerfen“ |
Phase 2: Umfangsbewertung
Wenn Phase 0 ein Projekt erkannt hat, verwenden Sie die Codebasis-Größe als Signal. Andernfalls schätzen Sie allein anhand der Prompt-Beschreibung und markieren Sie die Schätzung als unsicher.
| Umfang | Heuristik | Orchestrierung |
|---|---|---|
| TRIVIAL | Einzelne Datei, < 50 Zeilen | Direkte Ausführung |
| NIEDRIG | Einzelne Komponente oder Modul | Einzelner Befehl oder Skill |
| MITTEL | Mehrere Komponenten, gleiche Domäne | Befehlsverkettung + /verify |
| HOCH | Domänenübergreifend, 5+ Dateien | Zuerst /plan, dann phasenweise Ausführung |
| EPISCH | Mehrere Sitzungen, mehrere PRs, architektonische Verschiebung | blueprint-Skill für mehrsitzigen Plan verwenden |
Phase 3: ECC-Komponentenabgleich
Ordnen Sie Absicht + Umfang + Tech-Stack (aus Phase 0) bestimmten ECC-Komponenten zu.
Nach Absichtsart
| Absicht | Befehle | Skills | Agents |
|---|---|---|---|
| Neue Funktion | /plan, /tdd, /code-review, /verify | tdd-workflow, verification-loop | planner, tdd-guide, code-reviewer |
| Bugfix | /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 |
| Review | /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 Skill aufrufen) | planner, architect |
Nach Tech-Stack
| Tech-Stack | Hinzuzufügende Skills | 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 | code-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 |
| Andere / nicht aufgeführt | coding-standards (universell) | code-reviewer |
Phase 4: Erkennung fehlender Kontextinformationen
Durchsuchen Sie den Prompt nach fehlenden kritischen Informationen. Prüfen Sie jedes Element und markieren Sie, 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 genannt?
- Akzeptanzkriterien – Wie erkennt man, dass die Aufgabe erledigt ist?
- Fehlerbehandlung – Randfälle und Fehlermodi behandelt?
- Sicherheitsanforderungen – Auth, Eingabevalidierung, Secrets?
- Testerwartungen – Unit-, Integrations-, E2E-Tests?
- Leistungsbeschränkungen – Auslastung, Latenz, Ressourcengrenzen?
- UI/UX-Anforderungen – Designspezifikationen, Responsivität, Barrierefreiheit? (wenn Frontend)
- Datenbankänderungen – Schema, Migrationen, Indizes? (wenn Datenschicht)
- Vorhandene Muster – Referenzdateien oder Konventionen, die befolgt werden sollen?
- Umfangsgrenzen – Was NICHT getan werden soll?
Wenn 3+ kritische Elemente fehlen, stellen Sie dem Benutzer bis zu 3 Klärungsfragen, bevor Sie den optimierten Prompt generieren. Integrieren Sie dann die Antworten in den optimierten Prompt.
Phase 5: Workflow- und Modell-Empfehlung
Bestimmen Sie, wo dieser Prompt im Entwicklungslebenszyklus steht:
Recherche → Plan → Implementieren (TDD) → Review → Verify → Commit
Beginnen Sie bei MITTEL+ Aufgaben immer mit /plan. Verwenden Sie bei EPISCHEN Aufgaben das blueprint-Skill.
Modell-Empfehlung (in die Ausgabe aufnehmen):
| Umfang | Empfohlenes Modell | Begründung |
|---|---|---|
| TRIVIAL-NIEDRIG | Sonnet 4.6 | Schnell, kosteneffizient für einfache Aufgaben |
| MITTEL | Sonnet 4.6 | Bestes Codier-Modell für Standardarbeit |
| HOCH | Sonnet 4.6 (Haupt) + Opus 4.6 (Planung) | Opus für Architektur, Sonnet für Implementierung |
| EPISCH | Opus 4.6 (Blueprint) + Sonnet 4.6 (Ausführung) | Tiefgehendes Denken für mehrsitzige Planung |
Aufteilung in mehrere Prompts (für HOCHEN/EPISCHEN Umfang):
Bei Aufgaben, die eine einzelne Sitzung überschreiten, teilen Sie sie in aufeinanderfolgende Prompts auf:
- Prompt 1: Recherche + Plan (zuerst
search-first-Skill verwenden, dann/plan) - Prompt 2-N: Eine Phase pro Prompt implementieren (jeder endet mit
/verify) - Abschlussprompt: Integrationstest +
/code-reviewüber alle Phasen - Verwenden Sie
/save-sessionund/resume-session, um den Kontext zwischen Sitzungen zu erhalten
Ausgabeformat
Präsentieren Sie Ihre Analyse in dieser genauen Struktur. Antworten Sie in derselben Sprache wie die Eingabe des Benutzers.
Abschnitt 1: Prompt-Diagnose
- Stärken: Listen Sie auf, was der ursprüngliche Prompt gut macht.
- Probleme:
Problem Auswirkung Vorgeschlagene Behebung (Problem) (Konsequenz) (Behebung) - Klärungsbedarf: Nummerierte Liste der Fragen, die der Benutzer beantworten sollte. Wenn Phase 0 die Antwort automatisch erkannt hat, geben Sie diese stattdessen an, anstatt zu fragen.
Abschnitt 2: Empfohlene ECC-Komponenten
| Typ | Komponente | Zweck |
|---|---|---|
| Befehl | /plan | Architektur vor dem Codieren planen |
| Skill | tdd-workflow | Anleitung zur TDD-Methodik |
| Agent | code-reviewer | Review nach der Implementierung |
| Modell | Sonnet 4.6 | Für diesen Umfang empfohlen |
Abschnitt 3: Optimierter Prompt – Vollversion
Präsentieren Sie den vollständigen optimierten Prompt innerhalb eines einzelnen Codeblocks. Der Prompt muss in sich geschlossen und kopierbar sein. Enthalten sein müssen:
- Klare Aufgabenbeschreibung mit Kontext
- Tech-Stack (erkannt oder angegeben)
/command-Aufrufe in den richtigen Workflow-Phasen- Akzeptanzkriterien
- Verifikationsschritte
- Umfangsgrenzen (was NICHT getan werden soll)
Schreiben Sie für Elemente, die auf blueprint verweisen: „Verwenden Sie das blueprint-Skill, um …“ (nicht /blueprint, da blueprint ein Skill ist, kein Befehl).
Abschnitt 4: Optimierter Prompt – Kurzversion
Eine kompakte Version für erfahrene ECC-Benutzer. Variieren Sie je nach Absichtsart:
| Absicht | Kurzmuster |
|---|---|
| Neue Funktion | /plan [Funktion]. /tdd zum Implementieren. /code-review. /verify. |
| Bugfix | /tdd – fehlschlagenden Test für [Bug] schreiben. Auf Grün korrigieren. /verify. |
| Refactoring | /refactor-clean [Umfang]. /code-review. /verify. |
| Recherche | search-first-Skill für [Thema] verwenden. /plan basierend auf Ergebnissen. |
| Testen | /tdd [Modul]. /e2e für kritische Abläufe. /test-coverage. |
| Review | /code-review. Dann security-reviewer-Agenten verwenden. |
| Dokumentation | /update-docs. /update-codemaps. |
| EPISCH | Verwenden Sie das blueprint-Skill für „[Ziel]“. Phasen mit /verify-Gates ausführen. |
Abschnitt 5: Verbesserungsbegründung
| Verbesserung | Grund |
|---|---|
| (was hinzugefügt wurde) | (warum es wichtig ist) |
Beispiele
Beispiel 1: Vager chinesischer Prompt (Projekt erkannt)
Benutzereingabe: 帮我写一个用户登录页面
Phase 0 erkennt: package.json mit Next.js 15, TypeScript, Tailwind CSS
Optimierter Prompt (Vollversion):
Verwenden Sie den vorhandenen Tech-Stack des Projekts (Next.js 15 + TypeScript + Tailwind CSS), um eine Benutzeranmeldeseite zu implementieren.
Technische Anforderungen:
- Übernehmen Sie die vorhandenen Komponentenstrukturen und Routing-Konventionen des Projekts
- Verwenden Sie für die Formularvalidierung das im Projekt bereits vorhandene Validierungsschema (prüfen Sie, ob bereits Zod/Yup/anderes verwendet wird)
- Authentifizierungsmethode: Verwenden Sie das vorhandene Authentifizierungsschema des Projekts (falls nicht vorhanden, standardmäßig JWT)
- Enthalten sein müssen: E-Mail-/Passwort-Anmeldeformular, Formularvalidierung, Fehlermeldungen, Ladezustand, responsives Layout
Workflow:
1. /plan – Planen Sie zuerst die Komponentenstruktur und den Authentifizierungsablauf unter Berücksichtigung vorhandener Seitenmuster
2. /tdd – Test zuerst: Schreiben Sie Unit-Tests für das Anmeldeformular und Integrationstests für den Authentifizierungsablauf
3. Implementieren Sie die Anmeldeseite und die Authentifizierungslogik
4. /code-review – Überprüfen Sie die Implementierung
5. /verify – Stellen Sie sicher, dass alle Tests bestanden werden und die Seite korrekt rendert
Sicherheitsanforderungen:
- Passwort nicht im Klartext übertragen
- Brute-Force-Schutz (Rate Limiting)
- XSS-Schutz
- CSRF-Token
Akzeptanzkriterien:
- Alle Tests bestanden, Codeabdeckung 80%+
- Seite rendert korrekt auf Mobilgeräten und Desktops
- Erfolgreiche Anmeldung leitet zum Dashboard weiter, Fehler zeigen Fehlermeldungen an
Nicht tun:
- Keine Registrierungsseite implementieren
- Keine Funktion „Passwort vergessen“ implementieren
- Vorhandene Routing-Struktur nicht ändern