Prompts

Übersetzen Sie den Text unten in klares Deutsch. Behalten Sie Fachbegriffe, Code und Eigennamen. Geben Sie zuerst die Übersetzung, nennen Sie dann drei Stellen, die Sie geändert haben, und warum. Markieren Sie, wo Sie unsicher sind. Erfinden Sie nichts. {Originaltext}

Sie führen das Gespräch für die Stelle {Stelle}. Stellen Sie jeweils nur eine Frage. Nach meiner Antwort nennen Sie die fehlenden Punkte und stellen dann die nächste Frage. Nach 8 Fragen geben Sie für diese Stelle eine kurze Bewertung: geeignet, zurückgestellt oder ungeeignet, und die Begründung.

Prüfen Sie die Änderung unten. Nennen Sie nur Probleme, die sie falsch, langsam oder schwer zu warten machen. Schreiben Sie zu jedem die Datei, die Schwere (hoch, mittel, niedrig) und die Korrektur. Schreiben Sie nicht die ganze Datei neu. Wenn nichts vorliegt, schreiben Sie „keine“.

Machen Sie aus den Notizen unten einen Wochenbericht. Drei Teile: diese Woche erledigt, nicht erledigt und warum, drei Punkte für die nächste Woche. Jeder Punkt ein Satz. Behalten Sie die Zahlen. Schreiben Sie keine Selbstbewertung.

Schreiben Sie nach den Spaltennamen unten eine Excel-Formel für: {Aufgabe}. Schreiben Sie zuerst die Formel und rechnen Sie sie dann an zwei Beispielzeilen aus. Wenn eine andere Spalte nötig ist, sagen Sie das zuerst. Verwenden Sie keine Spalte, die ich nicht genannt habe.

Beantworten Sie dies mit Standard-SQL: {Frage}. Die Tabellenstruktur steht unten. Schreiben Sie zuerst die Abfrage, dann welche Tabellen sie nutzt. Erfinden Sie keine Spalten, die es nicht gibt. Wenn die Frage unklar ist, stellen Sie mir zuerst eine Frage, bevor Sie SQL schreiben.

Schreiben Sie einen regulären Ausdruck in JavaScript, der dies trifft: {ZuPassendes}. Er trifft dies nicht: {NichtPassendes}. Geben Sie den Ausdruck an, dazu je zwei Beispiele, die passen, und zwei, die nicht passen.

Erklären Sie den Code unten einer Person, die das Repository gerade übernimmt. Sagen Sie in drei Sätzen, was er tut, und gehen Sie dann die Ausführungsreihenfolge durch. Nennen Sie Eingaben, Ausgaben und die Fälle, in denen er scheitert. Ändern Sie den Code nicht.

Schreiben Sie zum diff unten einen Commit-Text. Die erste Zeile hat höchstens 72 Zeichen und sagt, was sich geändert hat. Nach einer Leerzeile steht, warum. Schreiben Sie nicht „update“, „fix bug“ oder ähnlich leere Formulierungen.

Setzen Sie diese Änderung um: {Aufgabe}. Fassen Sie nur die Zeilen an, die dafür nötig sind. Formatieren Sie nicht nebenbei, benennen Sie nichts um und schreiben Sie benachbarten Code nicht neu. Nennen Sie danach die Dateien, die Sie geändert haben, und wie sich prüfen lässt, dass das Verhalten gleich geblieben ist.

Der Defekt ist: {Symptom}. Schreiben Sie zuerst die Schritte oder den Test, der ihn reproduziert. Ändern Sie davor keinen Produktcode. Machen Sie danach nur die kleinste Änderung und sagen Sie, warum das die Ursache ist.

Schreiben Sie für {Verhalten} zuerst einen Test, der fehlschlägt. Zeigen Sie die Fehlerausgabe, dann die Umsetzung, die ihn bestehen lässt. Schreiben Sie nicht zuerst die Umsetzung. Fügen Sie nach dem Bestehen keine Funktion hinzu, die nicht verlangt war.

Lesen Sie zuerst die Dateien, die zu {Aufgabe} gehören. Listen Sie die Fakten, die Sie sehen, und was noch unklar ist. Ändern Sie in diesem Schritt keine Datei. Ändern Sie erst, nachdem ich bestätigt habe.

Schreiben Sie noch keinen Code. Geben Sie zu {Ziel} einen kurzen Plan: welche Dateien Sie ändern, was Sie nicht tun und woran die Fertigstellung zu erkennen ist. Wenn zwei Wege gleich sinnvoll sind, halten Sie an und fragen Sie, welchen ich will.

Lesen Sie den diff unten und suchen Sie nur Sicherheitsprobleme: Injection, unerlaubter Zugriff, ein Schlüssel im Repository, unsichere Deserialisierung. Nennen Sie zu jedem die Datei und wie es ausgelöst wird. Wenn es keine gibt, schreiben Sie „keine“. Machen Sie keine Kommentare zum Stil.

Schreiben Sie 5 title und 5 meta description für diese Seite. Sie behandelt: {Thema}. Ein title hat höchstens 60 Zeichen, eine description höchstens 160 Zeichen. Jeder Text enthält Wörter, nach denen jemand suchen würde. Stapeln Sie keine Schlüsselwörter.

Schreiben Sie den ersten Bildschirm für {Produkt}: ein Ergebnis, einen Text von höchstens 40 Zeichen und einen Button. Der Button sagt, was der Klick öffnet. Kein Slogan, keine drei Verkaufspunkte nebeneinander.

Schreiben Sie den Text unten so um, dass er klingt, als sprächen Sie mit einer bestimmten Person. Streichen Sie leere Phrasen und parallele Reihungen. Behalten Sie alle Fakten, Zahlen und Dateipfade. Listen Sie danach die gestrichenen Floskeln auf.

Geben Sie dem Text unten 10 Titel. 5 nennen das Ergebnis direkt, 5 enthalten ein konkretes Detail. Verwenden Sie nicht „schockierend“, „ultimativ“ oder „befähigen“. Jeder Titel hat höchstens 22 Zeichen.

Schreiben Sie 3 kurze Anzeigen für {Produkt}. Jede zielt auf eine kaufende Person und eine Sache. Schreiben Sie, wer kauft, welches Problem jetzt besteht und was der Klick bringt. Stapeln Sie keine Adjektive.

Schreiben Sie eine Xiaohongshu-Notiz zum Thema {Thema}. Die erste Zeile ist der Titel. Der Text hat höchstens 300 Zeichen, enthält ein konkretes Detail aus Ihrer eigenen Nutzung und endet mit einer Frage. Nicht „家人们“ und nicht „绝绝子“. Nennen Sie 3 passende Bilder.

Beantworten Sie die E-Mail unten. Beantworten Sie die Bitte im ersten Satz, schreiben Sie dann, was die andere Seite tun soll, und nennen Sie am Ende einen Zeitpunkt. Der Ton ist direkt. Beginnen Sie nicht mit „Ich hoffe, diese E-Mail erreicht Sie gut“.

Machen Sie aus der Aufzeichnung unten ein Protokoll. Behalten Sie nur Entscheidungen, Verantwortliche, Fristen und offene Fragen. Streichen Sie den Verlauf der Diskussion. Markieren Sie Punkte ohne Verantwortliche einzeln.

Die Zielstelle ist {Stelle}. Schreiben Sie die Erfahrung unten in 5 Zeilen für den Lebenslauf um. Jede Zeile beginnt mit einem Verb und enthält eine Zahl oder ein Ergebnis. Streichen Sie, was die Stelle nicht braucht. Erfinden Sie keine Erfahrung, die ich nicht aufgeschrieben habe.

Die Anforderungen der Stelle stehen oben, die Unterlagen der Bewerbung unten. Listen Sie erfüllte Anforderungen, nicht erfüllte und solche, die in den Unterlagen fehlen. Schätzen Sie nicht den Charakter. Geben Sie am Ende eine Empfehlung, ob ein Gespräch stattfinden soll, mit der Begründung.

Planen Sie 3 Tage in {Stadt}. Jeden Tag eine Sache am Vormittag, eine am Nachmittag und eine am Abend, und wie man von einem Ort zum nächsten kommt. Markieren Sie, was eine Reservierung braucht. Setzen Sie keine Einkaufsorte an, die ich nicht genannt habe. Das Budget ist {Budget}.

Schreiben Sie aus dieser Vorgabe eine Kurzgeschichte von höchstens 800 Zeichen: {Vorgabe}. Eine Hauptfigur, eine Sache, die abgeschlossen werden muss, und am Ende eine Veränderung. Keine Kapitel. Keine Belehrung.

Schreiben Sie aus dieser Handlung eine Szene: {Handlung}. Nur Szenenüberschrift, Aktion und Dialog. Der Dialog muss sich vorlesen lassen. Keine Kamerabegriffe. Keine Gedanken der Figuren.

Die Streitfrage lautet: {Streitfrage}. Zuerst die drei stärksten Punkte dafür, dann die drei stärksten dagegen. Jeder Punkt ein Satz, dazu die Tatsache, auf der er ruht. Erklären Sie am Ende nicht, welche Seite gewinnt.

Bringen Sie mir {Thema} bei. Erklären Sie den Kern zuerst an einem konkreten Beispiel und stellen Sie dann zwei Fragen. Beginnen Sie den nächsten Abschnitt nicht, bevor ich geantwortet habe. Liege ich falsch, zeigen Sie nur auf den Schritt, der falsch war.

Ich will {Frage} verstehen. Geben Sie die Antwort nicht direkt. Stellen Sie jedes Mal nur eine Frage, die den Bereich enger macht. Warten Sie meine Antwort ab, bevor Sie die nächste stellen. Erklären Sie erst, wenn ich ausdrücklich sage: „Geben Sie die Antwort“.

Lesen Sie die Arbeit unten. Fassen Sie sie in 8 Sätzen zusammen: Problem, Methode, Daten, Ergebnis und die Grenzen, die die Autoren selbst nennen. Setzen Sie nach jedem Satz in Klammern den Abschnitt, aus dem er stammt. Ergänzen Sie nichts, was die Arbeit nicht sagt.

Vergleichen Sie {OptionA} und {OptionB} für {Ziel}. Legen Sie eine Tabelle an: Kosten, was sich ändern muss, was bei einem Fehlschlag geschieht. Jede Zelle braucht eine Begründung. Reicht sie nicht, schreiben Sie „unbekannt“. Raten Sie nicht.

Sehen Sie sich die Oberfläche unten an. Kommentieren Sie nur Hierarchie, Abstände, die klickbare Fläche und den Fokuszustand. Nennen Sie drei Änderungen. Sagen Sie bei jeder, was jetzt falsch ist und wie es danach aussieht. Wechseln Sie nicht den ganzen visuellen Stil.

Schreiben Sie einen Bildprompt für {Motiv}. Nennen Sie, was im Bild ist, das Licht, den Bildaufbau und was nicht vorkommen darf. Ein Absatz, kein Stapel aus Schlüsselwörtern. Zwei Fassungen: eine quadratisch, eine quer.

Schlagen Sie 12 Namen für {Produkt} vor. Jeder muss als Domain taugen: kurz, aussprechbar, ohne Bindestrich. Meiden Sie allgemeine Wörter, die schon abgenutzt sind. Schreiben Sie hinter jeden Namen einen Satz, worauf er zeigt.

Ich will dies sagen: {Satz}. Geben Sie zuerst eine natürlichere Fassung, dann woran meine Fassung hakt (Wortwahl, Stellung oder Ton). Danach eine kürzere Fassung zum Nachsprechen.

Ich muss auf {System} Folgendes erledigen: {Aufgabe}. Listen Sie die Befehle auf, einen pro Zeile, und was jeder ändert. Tun Sie nicht so, als wären Sie das Terminal. Halten Sie bei einem zerstörenden Befehl an und fragen Sie mich.

Lesen Sie das JavaScript unten. Listen Sie in der Ausführungsreihenfolge auf, was jedes console ausgibt. Wenn ein Fehler fliegt, nennen Sie den Fehlertyp und die Zeile. Ändern Sie den Code nicht, außer ich bitte Sie danach, ihn zu reparieren.

Teilen Sie {System} in Module. Schreiben Sie bei jedem, wofür es zuständig ist, wofür nicht, und eine Schnittstelle nach außen. Höchstens 6 Module. Schreiben Sie keinen Umsetzungscode.

Lesen Sie das Material unten. Schreiben Sie eine Zusammenfassung von höchstens 40 Zeichen. Listen Sie dann Ideen, die der Text wirklich sagt, höchstens 8. Zitieren Sie nur Sätze, die im Text stehen, höchstens 5. Nennen Sie am Ende einen Punkt, den Sie mitnehmen. Ist eine Rubrik leer, schreiben Sie „keine“. Erfinden Sie keine Zitate. {Material}

Lesen Sie den git diff unten und schreiben Sie in Markdown einen Text zum Merge Request mit diesen Abschnitten: Zusammenfassung, Geänderte Dateien, Grund, Auswirkung, Testplan. Schreiben Sie bei jeder Datei, was sich geändert hat. Zeigt der diff keinen Test, schreiben Sie, dass der Testplan fehlt. Schreiben Sie den Code nicht um.

Lesen Sie das Log unten. Listen Sie Auffälligkeiten und Probleme, die wiederkehren, und geben Sie zu jedem die stützende Zeile oder Zeit an. Schreiben Sie danach nur Änderungen, die das Log selbst stützt. Liegt die Ursache nicht im Log, schreiben Sie das. Raten Sie keine Reparatur von außerhalb der Datei.

Machen Sie aus dieser Produktangabe ein PRD in Markdown mit diesen Abschnitten: Überblick, Ziele, Zielgruppe, Funktionen, Funktionale Anforderungen, Nichtfunktionale Anforderungen, Erfolgsmaße. Jede Anforderung muss sich prüfen lassen. Fehlende Fakten schreiben Sie als „unbekannt“. Fügen Sie keine Funktion hinzu, die die Angabe nicht nennt. {Erläuterung}

Schreiben Sie eine User Story für {Funktion}. Nutzen Sie drei Zeilen: Als {Rolle} / möchte ich / damit. Schreiben Sie danach gewöhnliche Aufzählungspunkte mit Abnahmekriterien, die sich beim Test prüfen lassen. Schreiben Sie keine zweite Story. Schreiben Sie kein Kriterium, das die Angabe nicht stützt. {Erläuterung}

Schreiben Sie eine Designnotiz für {System}. Abschnitte: Geschäftsziel, Kontext, Container, Bereitstellung, Risiken, Fragen und Annahmen. Kontext, Container und Bereitstellung bekommen je ein mermaid-Diagramm und eine Tabelle mit Name, Typ und Verantwortung. Nennen Sie bei der Sicherheit nur Kontrollen, die die Beschreibung schon nennt. Steht keine da, schreiben Sie „nicht angegeben“. Schreiben Sie nicht, wie das System anzugreifen ist. {Beschreibung}

Lesen Sie den Terraform-Plan unten. Schreiben Sie in einem Satz, was sich ändern wird. Listen Sie dann die wichtigen Neuanlagen, Aktualisierungen und Löschungen. Nennen Sie Kosten und Zugriffe nur, wenn der Plantext sie enthält. Fehlen die Kosten, schreiben Sie „Kosten nicht ausgewiesen“. Erfinden Sie keine Preise und keine Angriffsschritte.

Lesen Sie den diff unten. Die erste Zeile hat höchstens 100 Zeichen, steht im Präsens und setzt eines dieser Präfixe davor: feat, fix, docs, refactor, test, chore. Danach höchstens 6 Punkte. Jeder Punkt ist ein kurzer Satz im Präsens über eine Verhaltensänderung. Überspringen Sie Dateien, die nur Leerraum ändern.

Lesen Sie die Argumentation unten. Nennen Sie bei jedem Schritt, der nicht trägt, in einfachen Worten den Fehlschluss, zitieren Sie den Satz und sagen Sie, warum der Schritt die Schlussfolgerung nicht beweist. Ein schwacher Schritt heißt nicht, dass die Schlussfolgerung falsch ist. Trägt die Argumentation, schreiben Sie „sie trägt“. Nennen Sie keinen Fehlschluss, den der Text nicht benutzt.

Schreiben Sie den Prompt unten so um, dass ein Modell ihn ausführen kann. Die Aufgabe bleibt. Ergänzen Sie die Form der Ausgabe, die Länge, was wegzulassen ist, und einen Platzhalter für die Eingabe. Setzen Sie die Eingabe in einen klar markierten Block. Fügen Sie keine Persona hinzu. Geben Sie nur den umgeschriebenen Prompt zurück. {Prompt}

Schreiben Sie einen Fehlerbericht für {Symptom}. Felder: Titel, Umgebung, Schritte, Erwartet, Tatsächlich, Schweregrad. Der Titel nennt Komponente, Aktion und Symptom. Die Schritte sind nummeriert und kurz. Der Schweregrad ist kritisch, hoch, mittel oder niedrig, mit der Folge für die nutzende Person. Felder, die ich nicht gegeben habe, schreiben Sie als „unbekannt“. Schlagen Sie keine Codeänderung vor.

Schreiben Sie für {Verhalten} einen Testplan in drei Gruppen: Unit, Integration, Ende-zu-Ende. Jeder Fall ist ein Satz in der Form Gegeben / Wenn / Dann und prüft nur eines. Die meisten Fälle stehen bei Unit. Bei Ende-zu-Ende höchstens 2 Fälle, und nur für einen Weg, den eine Person geht. Schreiben Sie keinen Testcode. Verwenden Sie keine feste Wartezeit.

Machen Sie aus {Funktion} Anforderungen, die ein Test prüfen kann. Jede Zeile nutzt eine Form: Wenn [Ereignis], soll das System [Verhalten]; während [Zustand] soll das System [Verhalten]; wenn [unerwünschte Bedingung], soll das System [Reaktion]. Listen Sie danach Grenzen, die in der Angabe noch fehlen, und markieren Sie jede mit „vorgeschlagen“. Schreiben Sie kein Design und keinen Code.

Halten Sie eine Entscheidung zu {Wahl} fest. Abschnitte: Entscheidung, Kontext, Optionen, Begründung, Auswirkung, Wann erneut prüfen. Schreiben Sie bei den Optionen nur solche, die ich genannt habe. Habe ich nur eine genannt, schreiben Sie, dass keine Alternative vorliegt. Die Begründung nennt den Kompromiss. Der Abschnitt zum erneuten Prüfen nennt, was die Entscheidung wieder öffnen würde. Erfinden Sie keine Kennzahl.

Lesen Sie den diff unten. Nennen Sie nur Dokumente, die eine lesende Person nachziehen müsste: README, Änderungsprotokoll, API-Beschreibung, Konfigurationsbeispiel oder Migrationshinweis. Schreiben Sie zu jedem den Abschnitt und die Tatsache im diff, die ihn veraltet. Hat der diff keine Änderung, die jemand bemerkt, schreiben Sie, dass kein Dokument nachzuziehen ist. Entwerfen Sie keine Funktion, die der diff nicht enthält.

Zuerst kommen die Beispiele, dann die neue Eingabe. Die Antwort hat dieselbe Form wie die Beispiele. Verwenden Sie nur Beschriftungen, die in den Beispielen vorkommen. Passt die neue Eingabe auf kein Beispiel, schreiben Sie „passt nicht“ und nennen Sie das ähnlichste Beispiel. Erfinden Sie keine Beschriftung. {Beispiele} Neue Eingabe: {Eingabe}

Beantworten Sie {Frage} mit drei verschiedenen Methoden. Jede bleibt unter 80 Zeichen und endet mit „Antwort:“. Sagen Sie dann, ob die drei Antworten übereinstimmen. Wenn ja, geben Sie diese Antwort. Wenn nicht, listen Sie die Abweichung auf. Ziehen Sie sie nicht zu einer neuen Zahl zusammen.

Schreiben Sie über {Thema}. Nutzen Sie nur diese Abschnitte, in dieser Reihenfolge: {Abschnitte}. Insgesamt höchstens {Zeichenzahl} Zeichen. Braucht ein Abschnitt eine Tatsache, die ich nicht gegeben habe, schreiben Sie dort „unbekannt“. Fügen Sie keinen Abschnitt hinzu, keinen Slogan und keine Tatsache, die nicht in meiner Notiz steht.

Schreiben Sie über {Thema}. Das Folgende darf nicht vorkommen: {Ausschluss}. Nennen Sie diese Dinge nicht und beschreiben Sie sie nicht unter anderem Namen. Streichen Sie danach jeden Satz, der die Liste noch berührt. Bleibt nichts übrig, schreiben Sie, dass die Ausschlussbedingung die Antwort entfernt hat.

Suchen Sie einen Skill, der aus einer Markdown-Gliederung eine PPT macht, und installieren Sie ihn.

Hinterfragen Sie diesen Migrationsplan mit Grill Me. Überspringen Sie Rollback, Datenmenge und fehlende Verantwortliche nicht.

Bauen Sie diese Marketing-Startseite nach Frontend Design neu. Kein lila Verlauf, keine Reihe aus drei Funktionskarten.

Öffnen Sie die Staging-Konsole, melden Sie sich mit dem Konto aus den Umgebungsvariablen an und listen Sie die Aufgaben auf, die in der letzten Stunde gescheitert sind.

Prüfen Sie src/app/dashboard/page.tsx nach den Best Practices für Vercel React und beheben Sie zuerst die drei Punkte mit der größten Wirkung.

Prüfen Sie diese Landingpage mit Web Design Guidelines und listen Sie die nicht bestandenen Punkte mit Dateipfad auf.

Schreiben Sie einen Skill, der aus einem GitHub-Issue einen Implementierungsplan macht, bei dem die Tests zuerst kommen.

Führen Sie diese drei PDFs zusammen, setzen Sie einen echten Dokumenttitel und ziehen Sie die Tabelle von Seite 4 heraus.

Machen Sie aus dieser einseitigen Erklärung eine Unterlage von 10 Seiten für Investoren. Lassen Sie auf jeder Seite nur einen Punkt.

Führen Sie diese drei CSVs über sku zusammen, entfernen Sie doppelte Zeilen und schreiben Sie inventory.xlsx.

Entwerfen Sie einen MCP-Server für unsere interne Ticket-API. Höchstens drei Werkzeuge. Zeigen Sie zuerst das Schema.

Der Kassenbetrag ist nur bei Euro falsch. Diagnostizieren Sie zuerst. Bringen Sie keinen Patch an, solange Sie es nicht reproduzieren können.

Schlagen Sie für das Verzeichnis billing eine Modulkarte vor. Nennen Sie die Nähte und die Tests, die jede Naht braucht.

Modellieren Sie die Erstattung für diesen Shop. Listen Sie unzulässige Zustandspaare auf, bevor Sie eine Funktion schreiben.

Vergleichen Sie Agent Skills und MCP an einem Coding-Agenten. Zitieren Sie die Originaldokumente. Markieren Sie, was noch unklar ist.

Bearbeiten Sie diese README. Entfernen Sie die KI-Spuren. Befehle und Dateipfade müssen unverändert bleiben.

Bringen Sie mir Astro Content Collections bei. Prüfen Sie mich vor der nächsten Lektion. Speichern Sie den Fortschritt in ./notes.

Merken Sie sich: Wir verwenden trailingSlash never, und die Standardsprache ist Englisch. Schreiben Sie das in die Notizen des Agenten.

Schreiben Sie diese Komponente auf die kompositionelle API von Vue 3 um. Richten Sie sich nach der lokalen vue-Version. Kein Vuex.

Prüfen Sie /guides/install-agent-skills auf die Titellänge, auf canonical und darauf, ob es nur ein h1 gibt.

Schreiben Sie den ersten Bildschirm neu. Nur ein Ergebnis. Keine leeren Phrasen. Der Button muss sagen, was der Klick öffnet.

Machen Sie aus dieser Gliederung ein Word-Briefing: Überschriftenformate, ein Deckblatt und Kommentare an offenen Fragen.

Starten Sie den Entwicklungsserver und testen Sie den Kassenablauf mit Playwright: einmal mit leerem Warenkorb, einmal mit angemeldeter Person.

Fügen Sie eine Tabelle orders hinzu und sorgen Sie per RLS dafür, dass Benutzer nur die eigenen Zeilen sehen. Geben Sie die Migration und die Policies an.

Bauen Sie diese Einstellungsseite aus zusammengesetzten Komponenten neu. Reichen Sie theme und title nicht mehr über fünf Ebenen weiter.

Bauen Sie mit Expo eine Profilseite. Die Beitragsliste nutzt FlatList. Kein div-Layout, das nur im Web funktioniert.

Ergänzen Sie Checkout für einen einmaligen Kauf. Prüfen Sie die Signatur des Webhooks und speichern Sie den Zahlungsstatus idempotent.

Legen Sie für diesen PR einen Branch in Neon an, führen Sie darauf die Migrationen aus und richten Sie die Preview-Umgebung darauf aus.

Machen Sie mit Remotion einen Produktvorspann von 15 Sekunden: Titelkarte, drei Verkaufspunkte, Logo am Ende. 1080p.

Dieser instabile Test schlägt einmal in fünf Läufen fehl. Debuggen Sie systematisch. Bringen Sie keinen Patch an, solange Sie ihn nicht reproduzieren können.

Ergänzen Sie eine Ratenbegrenzung mit TDD. Zeigen Sie zuerst den fehlschlagenden Test, dann die Umsetzung.

Bauen Sie diese Einstellungsseite neu. Korrigieren Sie Hierarchie, Abstände und den Fokuszustand. Kein lila Verlauf von der Stange.

Ergänzen Sie für diese API eine Authentifizierung. Wenn etwas unklar ist, fragen Sie mich, bevor Sie selbst ein Verfahren festlegen.