claudianus/toss-ux-writing-skill

Toss UX Writing

Utilisez cette compétence pour générer, réécrire ou relire des microcontenus UX coréens dans un style inspiré de Toss. L'objectif n'est pas d'imiter Toss ou de copier ses exemples sources ; l'objectif est d'appliquer des patrons réutilisables : 해요체 amical, verbes actifs, formulation positive en premier lieu, respect casual, et exceptions claires.

Contrat principal

Lors de l'amélioration de microcontenus UX coréens :

1. Utilisez le 해요체 partout. Évitez le formel 합니다/됩니다/하십시오 et évitez le 반말.
2. Préférez une formulation active. Faites en sorte que l'utilisateur, le produit ou l'objet effectue l'action au lieu de se reposer sur 되다/됐어요/되어요.
3. Formulez positivement en premier. Dites ce que l'utilisateur peut faire et sous quelle condition avant de dire ce qui est bloqué.
4. Gardez les formes honorifiques casual. Supprimez les formes trop formelles ~시겠어요, 시나요, 셨나요, 께, 계시다, 여쭙다 sauf si une exception s'applique.
5. Dé-substantivez. Remplacez les constructions rigides {nom}+{nom} et les noms sino-coréens par des verbes, causes et actions concrètes.
6. Respectez les exceptions. N'imposez pas la positivité ou la voix active lorsque la clarté légale/politique, la réassurance de l'utilisateur, la fin/expiration du service ou l'explication de conséquences nécessite une phrase passive ou négative.

Flux de travail

1. Classifiez la surface

Identifiez où le microcontenu apparaît :

• Bouton ou CTA
• Boîte de dialogue / confirmation
• Toast / snack bar
• Message d'erreur / de récupération
• État vide
• Étiquette de formulaire, texte d'aide, validation
• Éligibilité à un avantage ou notification de récompense
• Restriction politique/légale
• Notification/push
• Confidentialité, consentement, enregistrement, utilisation des données

Utilisez references/surface-patterns.md pour les valeurs par défaut spécifiques à la surface.

2. Réécrivez avec les cinq transformations principales

Appliquez les transformations dans cet ordre :

1. Registre : convertissez en 해요체.
2. Agentivité : convertissez les formulations passives/statiques en formulations actives.
3. Valence : convertissez les négations évitables en conditions possibles.
4. Distance : abaissez le niveau honorifique tout en préservant le respect.
5. Verbes : transformez les empilements de noms en verbes ou clauses causales.

Utilisez references/vocabulary.md pour les patrons de remplacement.

3. Vérifiez les portes d'exception

Avant de finaliser, demandez :

• S'agit-il d'une restriction légale/politique/produit stricte ? Si oui, la formulation négative peut être plus claire.
• Concerne-t-il la fin de service, l'expiration de durée, le retard de paiement, la résiliation, l'application, l'enregistrement, l'enregistrement audio ou la collecte d'informations ? Si oui, la formulation passive peut être plus claire.
• La question utilise-t-elle le contexte réel de l'utilisateur, une situation inférée, ou demande-t-elle de la bonne volonté/opinion ? Si oui, 시나요/셨나요 peut être autorisé.
• Une formulation positive pourrait-elle faire croire à l'utilisateur que l'ensemble du service est indisponible ? Si oui, précisez l'avantage/fonction concerné.

Utilisez references/decision-tree.md.

4. Renvoyez un résultat vérifiable

Pour les réécritures, renvoyez ce tableau :

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

Pour les tâches de génération, regroupez par surface :

1. Microcontenu principal
2. Microcontenu secondaire/d'aide
3. Étiquettes CTA
4. Microcontenu d'erreur/vide/récupération le cas échéant
5. Notes sur le risque, l'exception ou le contexte manquant

Pour les audits, renvoyez :

1. Verdict global : 좋음, 수정 필요, ou 위험
2. Résultats par sévérité
3. Réécriture suggérée
4. Références aux règles

Règles strictes

• Ne produisez pas 되어요 ; utilisez 돼요 si le passif est intentionnellement autorisé.
• Dans les boîtes de dialogue, préférez le bouton gauche 닫기 à 취소 sauf si l'action annule vraiment une opération initiée par l'utilisateur.
• Évitez les CTA génériques comme 확인, 진행, 제출 lorsque l'action peut être nommée.
• Ne blâmez pas l'utilisateur. Préférez les contraintes du système/produit et les prochaines étapes.
• Ne cachez pas les restrictions politiques/légales derrière une formulation joyeuse.
• Ne prétendez pas que le microcontenu généré est un « microcontenu officiel de Toss ».
• Ne redistribuez pas et ne citez pas l'intégralité du guide Toss. Résumez les patrons et citez la source si nécessaire.

Patrons rapides

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

Quand l'utiliser

• Un microcontenu produit pour une application/site web coréen a besoin d'un ton similaire à celui de Toss.
• L'écriture UX pour les erreurs, dialogues, boutons, avantages, onboarding, formulaires, notifications ou politiques semble rigide.
• Une PR ajoute des chaînes UI coréennes et nécessite une relecture stylistique.
• Vous avez besoin de plusieurs variantes en 해요체 amical.
• Vous devez expliquer pourquoi une phrase coréenne semble trop formelle, passive, négative ou riche en noms.

Quand ne pas l'utiliser

• Les termes juridiques doivent être reproduits textuellement.
• La voix de la marque utilise intentionnellement le formel 합니다체.
• Le public nécessite des formes honorifiques institutionnelles ou gouvernementales.
• Le microcontenu n'est pas en coréen.
• On vous demande de cloner l'UI propriétaire de Toss ou de copier des exemples officiels complets.

Références

• references/tone-model.md — analyse approfondie du modèle vocal.
• references/decision-tree.md — portes de décision basées sur les exceptions.
• references/vocabulary.md — patrons de remplacement et anti-patrons.
• references/surface-patterns.md — recettes de microcontenu spécifiques à la surface UI.
• references/examples.md — exemples avant/après synthétiques.
• references/review-rubric.md — grille de notation pour les audits.
• scripts/toss_style_lint.py — linter heuristique local.