Wettbewerbs-Redesign

Was macht Wettbewerbs-Redesign?

Wenn eine LOCAL.md neben dieser SKILL.md liegt, zuerst lesen – sie enthält die spezifischen Angaben für dieses Workspace (Pfade, Tools, Beispiele) und überschreibt die unten stehenden allgemeinen Standardwerte.

Recherchieren → Entscheiden → Gestalten. Parallele Sub-Agenten screenshoten UNSER Feature und 2-3 Wettbewerbsprodukte. Die Ergebnisse werden zu einer Lückenanalyse mit gebündelten Entscheidungen für den Nutzer zusammengeführt, und die gewählte Richtung wird als Design-Canvas ausgegeben: aktuelle UI-Screenshots neben neu gestalteten Artboards, wobei jede Änderung markiert ist. Die Ausgabe ist eine Entscheidung + ein Design (+ optional ein Implementierungsplan) – es wird kein Produktcode durch diesen Skill geschrieben.

Der unten erwähnte „Referenzlauf“ ist der erste reale Lauf dieses Skills (ein Redesign einer Aufzeichnungsbibliothek); LOCAL.md verweist darauf, wenn vorhanden. Nur ein durchgearbeitetes Beispiel – es beweist die Form und kalibriert die Tiefe; bei einem neuen Feature nicht als Inhaltsvorlage heranziehen.

Phase 1 – Parallele Recherche (günstigere Modell-Sub-Agenten, max. 3 gleichzeitig)

Starte bis zu 3 Sub-Agenten in einer Nachricht – Agent-Tool, general-purpose, model: "sonnet" (ein günstigeres Modell reicht für die reine Recherche; niemals mehr als 3 gleichzeitig – Rate-Limits zerstören Spawn-Bursts):

1. Unseres – screenshotet das Feature in UNSERER App.
2. • 3. Wettbewerber – vom Nutzer GENANNTE Produkte füllen zuerst diese Plätze, ein Agent pro Produkt. Verbleibende Plätze (falls der Nutzer null oder eins genannt hat): ein „Umfrage“-Agent, der die 2-3 Wettbewerber mit den umfangreichsten öffentlichen Dokumentationen des relevanten Feature-Bereichs auswählt. Bei 3+ genannten: Ein Agent erhält das primäre, ein Agent die restlichen als Batch.

Während sie laufen, dich auf dem Hauptthread in unserer Codebasis verankern: das Schema des Features, die Read-/Action-Layer und die Seiten. Empfehlungen müssen auf reale Felder abbilden („project-Tag existiert, UI zeigt ihn nie“) – Wettbewerbsrecherche ohne Code-Grundlage erzeugt eine Wunschliste, die niemand umsetzen kann.

Sub-Agenten-Anweisungen – die Teile, die bei Weglassen scheitern:

• Nur Playwright MCP, niemals das Browser-Fenster – Screenshots aus dem Browser-Fenster können nicht auf die Festplatte gespeichert werden und sind für den Orchestrator unsichtbar. Dem Agenten explizit mitteilen: mcp__playwright__playwright_screenshot mit savePng: true + downloadsDir gesetzt auf ein Pro-Agent-Scratchpad-Unterverzeichnis (ours/, loom/, competitors/), zuerst mkdir -p ausführen und absolute Pfade mit ls verifizieren.
• Gleichzeitige Agenten teilen sich einen Playwright-Browser und KÖNNEN Sitzungen gegenseitig verunreinigen (ein Agent screenshotet die Seite eines anderen Agenten – passiert im Referenzlauf). Jeden Agenten anweisen: Überprüfe visuell, ob jeder Screenshot mit der gerade aufgerufenen URL übereinstimmt, bevor er behalten wird; bei einer veralteten/fremden Aufnahme den Playwright-Browser schließen, neu öffnen, erneut aufnehmen.
• Playwright-Chromium fehlt möglicherweise („Executable doesn't exist …“): npx playwright install chromium aus dem npx-Cache-Verzeichnis des MCPs ausführen, dann fortfahren (dauerhafte Stolperfalle, überlebt Versionssprünge).
• Login unserer App: Dem Agenten das exakte Rezept geben – z. B. ein dev-only Login-Formular (E-Mail + Passwort auf /login) mit einer E-Mail, die ALS AKTIVER BENUTZER in der Entwicklungsdatenbank existiert, plus das Dev-Login-Passwort aus der Umgebung des Dev-Servers. Beides selbst überprüfen (den env-Wert auf dem Dev-Server auslesen, die Dev-DB nach aktiven Benutzern durchsuchen), BEVOR der Agent gestartet wird. Der Referenzlauf verbrauchte einen ganzen Agenten wegen CredentialsSignin von einer E-Mail, die nicht in der Dev-DB war. Den Dev-Auth-Pfad der App in der AGENTS.md / README finden. Agenten niemals auf die Produktion richten.
• Wettbewerber-Bibliotheken hinter Login – Agenten anweisen, Hilfecenter-Artikel, Marketing-/Feature-Seiten und Dokumentationen (support.loom.com usw.) zu verwenden, keine Registrierung zu versuchen. Um eine strukturierte Feature-Inventur bitten (Organisation, Entdeckung/Suche, Freigabe, Workflow, KI, Administration) + welche Features Kern/Beliebt vs. Enterprise-Gated sind + eine Liste „lohnenswerte Eigenheiten, die man übernehmen sollte“.

Phase 2 – Synthese + gebündelte Entscheidungen

EINE Nachricht für den Nutzer zusammenstellen:

1. Aktueller Stand – was unser Feature hat und vermisst, verifiziert anhand der Screenshots und des Codes (Dateien zitieren).
2. Was Wettbewerber tun – ein paar Zeilen pro Produkt, nur die übertragbaren Teile.
3. Empfehlungen nach Phasen – erst die günstigste Hebelwirkung: (a) freischalten, was der Code bereits unterstützt, (b) kleine Migrations-Organisationsfeatures, (c) Workflow-Features. Eigene Ideen des Nutzers aus der Eingabeaufforderung einbeziehen. Markieren, was bewusst übersprungen wird (Enterprise-förmig, YAGNI).
4. Gebündelte Multiple-Choice-Entscheidungen: die 2-4 Verzweigungen, die das Lieferergebnis ändern, mit Buchstaben-Optionen + einer Empfehlung pro Option. Fragen nicht häppchenweise stellen.

Anhalten und auf die Entscheidungen warten. Nicht mit dem Gestalten eines unentschiedenen Umfangs beginnen.

Phase 3 – Design-Canvas der gewählten Richtung

ERFORDERLICHER SUB-SKILL: der design-Skill (Claude Design Canvas → Artifact). Er besitzt die Canvas-Mechanik; diese Phase fügt die Vergleichskonventionen hinzu:

• Aktuelle-UI-Screenshots als eigene Artboards („Aktuell – X“) neben den redesigneten Artboards („Redesign – X“). Screenshots vor dem Einsetzen auf ~70-100 KB JPEGs herunterrechnen (sips -Z 900 -s format jpeg -s formatOptions 60 …).
• Redesign-Artboards entsprechen dem echten Designsystem der App – zuerst Token-Dateien und Komponenten lesen, exakte Werte übernehmen (Schriftarten, Farb-Tokens, Kartenradius, Buttonform).
• Jedes Delta markieren: gestrichelte Umrandung in der Akzentfarbe der App + kleines „NEU“-Label auf jedem Element, das es heute nicht gibt (Label-Variante „GEÄNDERT“ für modifizierte). Unveränderte Bereiche erhalten keine Dekoration – das Fehlen macht die Markierungen lesbar.
• Canvas-Haftnotizen fassen die Deltas pro Artboard zusammen + eine Übersichtsnotiz. Beispieldaten in Mockups sind in Ordnung; bei der Übergabe darauf hinweisen.
• Statische Mockups sind das Standard-Lieferergebnis; einen klickbaren Prototyp nur erstellen, wenn der Nutzer darum gebeten hat.

Phase 4 (nur wenn der Nutzer fragt) – Implementierungsplan

ERFORDERLICHER SUB-SKILL: superpowers:writing-plans. Jede Aufgabe auf der Phase-1-Code-Lektüre aufbauen; den phasenweisen Umfang und die Entscheidungen wörtlich übernehmen; mit Ausführungsmodus-Optionen (paralleles Fan-out / Sub-Agent / inline) enden; nicht unaufgefordert mit dem Bauen beginnen.

Stolperfallen (alle haben den Referenzlauf gebissen)

Symptom	Lösung
Agent meldet Screenshots, Orchestrator kann sie nicht sehen	Browser-Fenster wurde verwendet – neu anweisen: Playwright MCP savePng + downloadsDir
Screenshot zeigt andere Seite als die, zu der der Agent navigiert ist	Verunreinigung der gemeinsamen Playwright-Sitzung – Browser schließen, neu öffnen, erneut aufnehmen, visuell überprüfen
CredentialsSignin beim Dev-Login	E-Mail ist kein aktiver Benutzer in der Dev-DB – Dev-DB abfragen, eine verwenden, die es ist
„Executable doesn't exist … chromium“	npx playwright install chromium (pro Cache-Verzeichnis, nach Playwright-Updates erneut ausführen)
Fan-out gibt leere Ergebnisse / Rate-Limited	>3 gleichzeitige Agenten – Wellen von ≤3, tote Pfade wiederholen, Ergebnisse lautstark melden
Empfehlungen stimmen nicht mit dem Code überein	Phase-1-Code-Verankerung auf dem Hauptthread wurde übersprungen – vor der Synthese durchführen