claudianus/toss-ux-writing-skill

Toss UX Writing

Verwenden Sie dieses Skill, um koreanische Microcopy für Produkte im Toss-inspirierten Stil zu generieren, umzuschreiben oder zu überprüfen. Ziel ist es nicht, Toss zu imitieren oder dessen Quellbeispiele zu kopieren; Ziel ist es, wiederverwendbare Muster anzuwenden: freundliche 해요체, aktive Verben, positive Erst-Rahmung, lässiger Respekt und klare Ausnahmen.

Kernvertrag

Bei der Verbesserung koreanischer UX-Texte:

1. Verwenden Sie überall 해요체. Vermeiden Sie formelles 합니다/됩니다/하십시오 und vermeiden Sie 반말.
2. Bevorzugen Sie aktive Formulierungen. Lassen Sie den Benutzer, das Produkt oder das Objekt die Aktion ausführen, anstatt auf 되다/됐어요/되어요 zurückzugreifen.
3. Rahmen Sie zuerst positiv. Sagen Sie, was der Benutzer tun kann und unter welcher Bedingung, bevor Sie sagen, was blockiert ist.
4. Halten Sie Höflichkeitsformen lässig. Entfernen Sie übermäßig formelles ~시겠어요, 시나요, 셨나요, 께, 계시다, 여쭙다, es sei denn, eine Ausnahme liegt vor.
5. Entnominieren. Ersetzen Sie steife {Nomen}+{Nomen}-Konstruktionen und sino-koreanische Nomen durch Verben, Ursachen und konkrete Handlungen.
6. Respektieren Sie Ausnahmen. Erzwingen Sie keine Positivität oder aktive Stimme, wenn rechtliche/Richtlinienklarheit, Benutzerberuhigung, Dienst-Ende/-Ablauf oder Erklärung von Konsequenzen einen passiven oder negativen Satz erfordern.

Arbeitsablauf

1. Klassifizieren Sie die Oberfläche

Identifizieren Sie, wo der Text erscheint:

• Button oder CTA
• Dialog / Bestätigung
• Toast / Snackbar
• Fehler / Wiederherstellungsmeldung
• Leerer Zustand
• Formularbeschriftung, Hilfetext, Validierung
• Berechtigungs-/Vorteilsberechtigung oder Belohnungshinweis
• Richtlinien-/Rechtseinschränkung
• Benachrichtigung/Push
• Datenschutz, Einwilligung, Aufzeichnung, Datennutzung

Verwenden Sie references/surface-patterns.md für oberflächenspezifische Standardeinstellungen.

2. Umschreiben mit den fünf primären Transformationen

Wenden Sie Transformationen in dieser Reihenfolge an:

1. Register: Konvertieren Sie zu 해요체.
2. Aktivität: Konvertieren Sie passive/statische Formulierungen in aktive Formulierungen.
3. Valenz: Konvertieren Sie vermeidbare Negationen in mögliche Bedingungen.
4. Distanz: Senken Sie die Höflichkeitshöhe unter Beibehaltung des Respekts.
5. Verben: Wandeln Sie Nominalisierungen in Verben oder Ursachenklauseln um.

Verwenden Sie references/vocabulary.md für Ersetzungsmuster.

3. Prüfen Sie Ausnahmeregeln

Bevor Sie abschließen, fragen Sie:

• Handelt es sich um eine harte rechtliche/Richtlinien-/Produkteinschränkung? Wenn ja, kann eine negative Formulierung klarer sein.
• Geht es um Dienst-Ende, Ablauf, Verzug, Kündigung, Anwendung, Aufzeichnung, Tonaufnahme oder Datenerhebung? Wenn ja, kann eine passive Formulierung klarer sein.
• Bezieht sich die Frage auf den tatsächlichen Kontext des Benutzers, eine abgeleitete Situation oder bittet um Goodwill/Meinung? Wenn ja, können 시나요/셨나요 erlaubt sein.
• Könnte eine positive Formulierung den Benutzer zu dem Missverständnis führen, dass der gesamte Dienst nicht verfügbar ist? Wenn ja, geben Sie den betroffenen Vorteil/die betroffene Funktion an.

Verwenden Sie references/decision-tree.md.

4. Geben Sie ein prüfbares Ergebnis zurück

Für Umschreibungen geben Sie diese Tabelle zurück:

원문	개선안	적용 규칙	예외 여부

Für Generierungsaufgaben gruppieren Sie nach Oberfläche:

1. Primärer Text
2. Sekundärer/Hilfstext
3. CTA-Beschriftungen
4. Fehler-/Leer-/Wiederherstellungstext, falls relevant
5. Hinweise zu Risiko, Ausnahme oder fehlendem Kontext

Für Audits geben Sie zurück:

1. Gesamtbewertung: 좋음, 수정 필요 oder 위험
2. Befunde nach Schweregrad
3. Vorgeschlagene Umschreibung
4. Regelverweise

Harte Regeln

• Geben Sie 되어요 nicht aus; verwenden Sie 돼요, wenn Passiv absichtlich erlaubt ist.
• Bevorzugen Sie in Dialogen den linken Button 닫기 gegenüber 취소, es sei denn, die Aktion bricht tatsächlich eine vom Benutzer initiierte Operation ab.
• Vermeiden Sie generische CTAs wie 확인, 진행, 제출, wenn die Aktion benannt werden kann.
• Geben Sie nicht dem Benutzer die Schuld. Bevorzugen Sie System-/Produkteinschränkungen und nächste Schritte.
• Verstecken Sie Richtlinien-/Rechtseinschränkungen nicht hinter fröhlichen Formulierungen.
• Behaupten Sie nicht, der generierte Text sei "offizieller Toss-Text".
• Verbreiten oder zitieren Sie nicht den vollständigen Toss-Leitfaden. Fassen Sie Muster zusammen und zitieren Sie die Quelle bei Bedarf.

Schnellmuster

카드를 해지하시겠어요?      → 카드를 해지할까요?
알림이 설정됐어요          → 알림을 설정했어요
보호자가 허락하기 전에는 가입할 수 없어요 → 보호자가 허락하면 가입할 수 있어요
잔액 부족으로 결제 실패    → 잔액이 부족해서 결제하지 못했어요
자동차를 가지고 계시나요?  → 자동차가 있나요?

Wann verwenden

• Koreanischer App-/Web-Produkttext benötigt einen Toss-ähnlichen Ton.
• UX-Texte für Fehler, Dialoge, Buttons, Vorteile, Onboarding, Formulare, Benachrichtigungen oder Richtlinienhinweise wirken steif.
• Ein PR fügt koreanische UI-Strings hinzu und benötigt eine Stilüberprüfung.
• Sie benötigen mehrere Varianten in freundlicher 해요체.
• Sie müssen erklären, warum ein koreanischer Satz zu formell, passiv, negativ oder nomenlastig wirkt.

Wann nicht verwenden

• Rechtliche Bedingungen müssen wörtlich wiedergegeben werden.
• Die Markenstimme verwendet absichtlich formelles 합니다체.
• Das Publikum erfordert institutionelle oder behördliche Höflichkeitsformen.
• Der Text ist nicht koreanisch.
• Sie werden aufgefordert, die proprietäre UI von Toss zu klonen oder vollständige offizielle Beispiele zu kopieren.

Referenzen

• references/tone-model.md — Tiefenanalyse des Sprachmodells.
• references/decision-tree.md — Ausnahme-zuerst-Entscheidungsgates.
• references/vocabulary.md — Ersetzungsmuster und Anti-Patterns.
• references/surface-patterns.md — Textspezifische Rezepte für UI-Oberflächen.
• references/examples.md — Synthetische Vorher-/Nachher-Beispiele.
• references/review-rubric.md — Bewertungsraster für Audits.
• scripts/toss_style_lint.py — Lokaler heuristischer Linter.