Zurück zur Prompt-Bibliothek
Prompt-BibliothekChat-Prompt

Refactoring-Tickets aufschlüsseln

Zerlege eine breite Refactoring-Anfrage in abgegrenzte Tickets mit Verantwortlichen, Risiken und Verifikation pro Ticket.

EntwicklungBacklogPlanung
Vorschau

Chat-Prompt

Empfohlenes Modell

GPT-5 Codex

Ausgabeformat

Refactoring-Tickets aufschlüsseln

Vorschau

Chat-Prompt

Chat-Thread

Anfrage: Asset-Verantwortung klären, einen alten Kompatibilitätspfad stilllegen, Dokumentation aktualisieren und Audit-Skripte verbessern.

Ticket 1: Aktuelle Asset-Pfade und temporäre Link-Referenzen prüfen. Ticket 2: Finale URLs ersetzen und öffentliche Seiten verifizieren. Ticket 3: Den Kompatibilitätspfad erst entfernen, wenn die Beispielabdeckung stabil ist. Ticket 4: Governance-Dokumente und Veröffentlichungscheckliste aktualisieren. Verifikation: Prompt-Prüfungen, Medienaudit, typecheck und build.

Output

Ticket / Umfang / Verantwortliche / Risiko / Verifikation

Zerlege eine breite Refactoring-Anfrage in abgegrenzte Tickets mit Verantwortlichen, Risiken und Verifikation pro Ticket.

Vollständiger Prompt

Refactoring-Tickets aufschlüsseln

Zerlege eine breite Refactoring-Anfrage in abgegrenzte Tickets mit Verantwortlichen, Risiken und Verifikation pro Ticket.

Empfohlenes Modell: GPT-5 CodexAusgabeformat: Refactoring-Tickets aufschlüsseln
Vollständiger Prompt
Chat-Prompt
Du bist ein Engineering Lead, der ein breites Refactoring in sichere Tickets aufteilt. Verwandle die bereitgestellten Notizen in eine praktische Prüfung, mit der ein Team arbeiten kann. Gib die Antwort mit folgenden Punkten zurück: Ticket, Umfang, Verantwortliche, Risiko, Verifikation. Stütze jede Aussage auf die bereitgestellten Notizen. Markiere fehlende Fakten, statt sie zu erfinden.

Nutzungshinweise

Füge echte Notizen, Einschränkungen und Quellmaterial ein. Lasse private Daten weg, sofern sie für die Review nicht nötig sind.

Prompt-FAQ

Bevor du diesen Prompt verwendest

Schnelle Checks für Eingaben, Modellfit und Anpassung des Templates, ohne das Ergebnis zu schwächen.

Wann sollte ich Refactoring-Tickets aufschlüsseln verwenden?

Zerlege damit eine breite Refactoring-Anfrage in abgegrenzte Tickets mit Verantwortlichen, Risiken und Verifikation pro Ticket. Nutze es, wenn bereits Notizen, Einschränkungen oder ein grober Entwurf vorliegen und du einen strukturierten nächsten Schritt brauchst, den ein Team prüfen kann.

Was sollte ich vor dem Ausführen einfügen?

Füge Quellmaterial, Zielgruppe, Einschränkungen, zentrale Fakten und Grenzen ein, die die Antwort nicht erfinden darf. Die Ausgabe wird als Ticket / Umfang / Verantwortliche / Risiko / Verifikation organisiert.

Thread-Vorschau

Anfrage: Asset-Verantwortung klären, einen alten Kompatibilitätspfad stilllegen, Dokumentation aktualisieren und Audit-Skripte verbessern.
Ticket 1: Aktuelle Asset-Pfade und temporäre Link-Referenzen prüfen. Ticket 2: Finale URLs ersetzen und öffentliche Seiten verifizieren. Ticket 3: Den Kompatibilitätspfad erst entfernen, wenn die Beispielabdeckung stabil ist. Ticket 4: Governance-Dokumente und Veröffentlichungscheckliste aktualisieren. Verifikation: Prompt-Prüfungen, Medienaudit, typecheck und build.

Output

Ticket / Umfang / Verantwortliche / Risiko / Verifikation

Weitere Prompts in diesem Modus

Chat-Thread

Wir möchten einen KI-Assistenten für kleine E-Commerce-Teams bauen, der Produktfotos in Kampagnenmaterial verwandelt.

Problemhypothese: Kleine E-Commerce-Teams verlieren Zeit, wenn sie rohe Produktfotos in kanalreifes Kampagnenmaterial verwandeln. Riskanteste Annahmen: Die Fotoqualität ist hoch genug, Teams vertrauen KI-Materialvarianten und Prüfzeit ist der eigentliche Engpass. Forschungsfragen: Wer verantwortet die Erstellung von Kampagnenmaterial, wo bleiben Überarbeitungen hängen und welche Qualitätslatte blockiert die Veröffentlichung. Validierungsplan: 5 Anwender interviewen, 3 promptgeführte Materialabläufe testen und die Zeit bis zum ersten freigegebenen Material vergleichen. Entscheidungstor: Nur weitermachen, wenn Teams schneller als im aktuellen Arbeitsablauf zu einem veröffentlichbaren Entwurf kommen.

Chat-Thread

Wir prüfen ein neues KI-Notizprodukt für Solo-Berater. Hilf mir, daraus ein Recherchebriefing zu machen.

Ziel: definieren, ob Solo-Berater einen KI-Notizarbeitsbereich oder eine leichtere Kundennachfass-Ebene brauchen. Arbeitsannahmen: Sie erfassen bereits Notizen, aber Synthese und Entwürfe für nächste Schritte sind uneinheitlich. Zielgruppe: Solo-Berater mit wiederkehrenden Kundengesprächen und begrenzter operativer Unterstützung. Kernfragen: Welche Notizen werden zu abrechenbarer Arbeit, was geht nach Gesprächen verloren und wo fühlen sich CRM-Tools zu schwergewichtig an. Forschungsplan: 6 Interviews führen, 10 aktuelle Gesprächsnotiz-Abläufe prüfen und einen Prototyp für Nachfass-Briefings testen.

Chat-Thread

Hier ist die Gliederung für unsere KI-Produkt-Landingpage. Sag mir, was unklar ist, bevor wir sie gestalten.

Kernversprechen: sichtbar, aber noch als Funktion statt als konkretes Nutzerergebnis formuliert. Unklarer Punkt: Die Seite erklärt nicht, wer zuerst Wert erhält oder welcher Arbeitsablauf sich nach der Anmeldung verändert. Beispiel-Lücke: Füge Vorher-Nachher-Beispiele, Muster von Modellausgaben und ein kurzes Vertrauenssignal in Hero-Nähe hinzu. CTA-Problem: Die primäre Aktion erscheint nach zu viel Erklärung; rücke einen nutzungsorientierten CTA näher an den Schnellnutzungsbereich. Revisionsplan: Hero-Bereich schärfen, Ergebnis-Karten ergänzen, dann Einwände umschreiben, bevor die visuellen Elemente poliert werden.