Swap Brand

Was macht Swap Brand?

Zweck

Dem Produkt eine eigenständige Identität geben: ein neuer Name, ein neues Aussehen und eine neue Stimme, die früh festgelegt werden, sowie ein mechanischer Sweep vor dem Start, der in den Textdateien des Codes nach dem Namen, der Domain und den Farben des Originals sucht. Es ist eine eingeschränkte Prüfung, kein Beweis: Alles, was es nicht lesen kann und wonach es nicht sucht, muss weiterhin eine Person überprüfen.

Voller (Sell)-Track, Schritte 5 (Identität) und 12 (Sweep). Liest swap/market.md, swap/recon.md; schreibt swap/brand.md, swap/sweep.json.

Kontext-Routing-Tabelle

Quelle	Wo	Was extrahieren
Markt	swap/market.md	Winkel, Zielgruppe, die belegte Lücke
Aufklärung	swap/recon.md	Name des Originals, Domains, Markenfarben (was zu vermeiden ist)
Der Benutzer	Seine Präferenzen, bestehende Marke, besessene Domains	Einschränkungen und Geschmack
Der Code	Das Produkt-Repository	Was der Sweep scannt

Schnellstart

Identitätsphase: 1) Auflisten, was aus der Aufklärung zu vermeiden ist; 2) 5 Namenskandidaten vorschlagen, die mit dem Winkel verbunden sind; 3) Die für jeden Kandidaten auszuführenden Prüfungen angeben; 4) Palette, Stimme und Logo-Brief festlegen; 5) swap/brand.md schreiben. Sweep-Phase: Führen Sie python3 -I <skill-ordner>/scripts/sweep.py <repo> --avoid "<ursprünglicher Name>" --domain <ursprüngliche Domain> --color "<ursprüngliche Farbe>" --exclude swap --json swap/sweep.json vom Projektstamm aus ( ist der Ordner dieses Skills). Jeden Treffer korrigieren, erneut ausführen, bis CLEAN.

Arbeitsablauf

1. Vermeidungsliste zuerst. Aus der Aufklärung: Name des Originals und alle Produktnamen, seine Domains, seine Markenfarben, seine charakteristischen Slogans. Schreibe sie in brand.md unter ## Avoid; der Sweep liest diese Datei nicht, übergib also jedes Element explizit als --avoid-, --domain- und --color-Flags.
2. Namenskandidaten (5). Jeder: Name, die Idee dahinter und warum ein Kunde ihn nicht mit dem Original verwechseln würde. Kein Name, der den Originalnamen enthält, abkürzt oder ähnlich klingt. Kein „X für Y“-Aufbau auf dem Namen des Originals.
3. Prüfungen, die der Benutzer vor dem Commit durchführt (Claude kann die Verfügbarkeit nicht überprüfen): eine Markenrecherche im Markt des Benutzers (nationales Register und internationales), ein Domain- und Social-Handle-Check, eine App-Store-Name-Suche und eine einfache Websuche nach dem Namen plus der Kategorie. Datum und Ergebnis jedes Schrittes festhalten. Ein Konflikt entfernt den Kandidaten.
4. Identität. Eine Palette, die sich eindeutig vom Original unterscheidet (andere Farbtonfamilie, kein Farbton davon), ein Schriftartenpaar aus freien oder lizenzierten Schriftarten, eine Stimme mit 5 Regeln mit jeweils einem „Tipp“ und einem „Nicht-Tipp“ und ein Logo-Brief, den der Benutzer oder ein Designer umsetzt. Beschreiben Sie kein Logo, das die Form oder das Konzept des Originals nachahmt.
5. Der Sweep (vor dem Start und noch einmal nach der letzten Codeänderung). Führen Sie ihn mit der Vermeidungsliste aus. Er findet Namen in Bezeichnern (OriginalAppEmbed, original_app), Domains, Farbwerte in Hex und RGB sowie Datei- und Ordnernamen. Korrigieren Sie durch Ersetzen, nicht durch Verstecken. Verwenden Sie --allow nur für harmlose längere Wörter und listen Sie jede Verwendung in brand.md auf. Der Sweep gibt den gefundenen Text, die Datei und die Zeile aus, niemals den Rest der Zeile.
6. Über den Code hinaus. Der Sweep liest nur Textdateien. Bilder, Schriftarten, Archive, Dateien über 2 MB und nicht lesbare Dateien werden als nicht gescannt aufgelistet, und der Durchlauf ist NICHT CLEAN, solange welche vorhanden sind. Überprüfen Sie jede manuell (Screenshots, Beispieldaten, Metadaten, E-Mail-Vorlagen, Alt-Text) und führen Sie dann den Sweep mit --accept-skipped erneut aus, was in sweep.json festhält, dass Sie es getan haben. --accept-skipped versteckt niemals einen Treffer.

Anti-Rationalisierung

Was Claude denken könnte	Warum es falsch ist
„Es ist ein Clean-Room-Build, kein Rebrand nötig“	Clean-Room betrifft den Code. Ein Name oder Aussehen, das Kunden verwirrt, ist ein separates Problem.
„Ähnlich genug zum Original hilft den Leuten, uns zu finden“	Verwechslungsgefahr ist das Markenrisiko. Bewusst unterscheidbar.
„Der Sweep hat nur einen Kommentar gefunden, ignoriere ihn“	Ein Kommentar, der das Original nennt, wird im Bundle ausgeliefert. Entfernen Sie ihn.
„Ich habe überprüft, dass der Name frei ist“	Nur eine Registerrecherche durch den Benutzer zeigt das. Halten Sie fest, wer sie wann durchgeführt hat.
„Bilder und Screenshots überspringen“	Der Sweep kann sie nicht lesen. Überprüfen Sie sie per Augenschein und sagen Sie, dass Sie es getan haben.

Ausgabeformat

EXAKT. Überschriften in swap/brand.md in der Reihenfolge: ## Avoid, ## Name candidates (jeweils mit Idee und durchgeführten Prüfungen, mit Daten und Ergebnissen), ## Chosen name, ## Palette and type, ## Voice, ## Logo brief, ## Sweep log (jeder Durchlauf: Befehl, Treffer, Korrekturen). swap/sweep.json ist die unbearbeitete Ausgabe des Skripts.

Referenzausgabe (erfundenes Beispiel, gekürzt):

## Chosen name
Skyline. Markenrecherche (UK, EU, US): noch nicht durchgeführt. Domain- und Store-Name-Recherche: noch nicht durchgeführt.

## Sweep log
Durchlauf 1: 7 Treffer (Name x4, Domain x1, Farbe x1, Pfad x1). Alle ersetzt.
Durchlauf 2: CLEAN, 4 Dateien gescannt, 0 nicht gescannt.

Regeln

• Ursprünglicher Name, Palette, Logo, Wörter. Niemals das Logo, die Marken, den Text oder die Assets des Originals in irgendeiner Form.
• Nicht behaupten, dass ein Name verfügbar oder eintragbar ist; das ist die Prüfung des Benutzers und die Entscheidung eines Anwalts.
• Niemals sweep.json von Hand bearbeiten.

Skill-übergreifendes Routing

Identität gewählt -> swap-architect dann swap-design (das die Palette von hier übernimmt). Sweep CLEAN -> swap-launch. Der Sweep wird niemals aufgrund eines vendor-eigenen Assets im Produkt bestanden -> entfernen Sie das Asset; setzen Sie es nicht auf die Allow-Liste.

Exit-Checkliste

Beweisblock mit Nachweisen; dann „konnte nicht verifiziert werden“. Identitätsphase (bevor es Code gibt):

• ## Avoid listet den Namen des Originals, seine Domain(s) und mindestens eine Markenfarbe auf
• Jeder Namenskandidat hat die vier Prüfungen mit Datum aufgezeichnet oder sagt „noch nicht durchgeführt“
• Palette, Stimme und Logo-Brief sind geschrieben und unterscheiden sich vom Original

Sweep-Phase (vor dem Start und noch einmal nach der letzten Codeänderung):

• swap/sweep.json hat "passed": true, von einem Durchlauf nach der letzten Codeänderung
• Der Sweep-Befehl verwendete --exclude swap (oder scannte einen Baum ohne die Notizen); jede nicht gescannte Datei wurde manuell überprüft und skipped_accepted ist true, oder die Liste ist leer
• Jede Verwendung von --allow ist im Sweep-Log aufgeführt
• Screenshots, Texte und Metadaten wurden manuell überprüft und dem Benutzer wurde mitgeteilt, dass der Sweep sie nicht lesen kann

Selbstverbesserung

Nach jedem Durchlauf einmal fragen: „Gibt es Feedback, das für diesen Skill festgehalten werden soll?“ Schweigen oder Nein bedeutet, dass sich nichts ändert. Falls ja: das Muster entwerfen, zeigen, an references/learnings.md anhängen, aber nur nach einem Ja; „Skill aktualisieren“ zeigt die genaue Bearbeitung, bestätigt, schreibt, erhöht metadata.version und protokolliert eine Zeile. Niemals ein protokolliertes Muster in derselben Sitzung, in der es erfasst wurde, in diese Datei übernehmen. Nach dem ersten Durchlauf die verwendeten gebündelten Dateien und alles, was von Grund auf neu erstellt wurde und wieder benötigt wird, benennen und anbieten, es zu speichern (ebenfalls mit derselben Hürde).