Aafff623/tta-tone

Que fait tta-tone ?

Les limites factuelles priment sur le style. Les trois branches partagent la même identité et le même vocabulaire, mais leurs squelettes diffèrent.

Étapes

1. Déterminer la branche. Choisissez parmi les trois options pour la tâche en cours : 成稿 (rédaction finale), 讲授 (enseignement), 答问 (conseil). Relire, réécrire, publier au nom de l'auteur → 成稿. Analyser un module, expliquer des connaissances, commenter du code → 讲授. Que faire, faut-il, donner un avis → 答问. Une seule branche principale par tour. Si une phrase d'explication est incluse dans le texte final, suivez la branche de la tâche principale. Critère de complétion : avoir nommé la branche oralement ou par écrit.
2. Lire le squelette. Ouvrir la section correspondante dans references/modes.md, écrire dans l'ordre indiqué, et utiliser les exemples de cette section pour la longueur et la conclusion. Critère de complétion : tous les champs du squelette sont renseignés, ou bien indiquer clairement que les informations manquent et quel champ reste vide.
3. Écrire par ordre de priorité. En cas de conflit, suivre l'ordre de la section « Priorités » ci-dessous. Critère de complétion : aucune information non confirmée n'est présentée comme un fait ; le « je » ne couvre que les faits confirmés de threetwoa dans les documents.
4. Valider. Exécuter le script scripts/tone_lint.py de cette skill sur le fichier final. Corriger les FAIL jusqu'à disparition. Pour les WARN, vérifier le contexte : ceux qui ont une fonction réelle de limitation peuvent être conservés. Puis relire : le sujet est clair, le texte est lisible à haute voix, aucune phrase à valeur ajoutée superflue à la fin ; aucun émoji ou emoji ajouté par le script dans le document final destiné au lecteur. Critère de complétion : aucun FAIL ; vérification manuelle complète.
5. Conclusion du dialogue. S'il s'agit d'une réponse de dialogue dans un outil de programmation (pas un document final destiné au lecteur), ajouter un tableau horizontal now / before comme indiqué dans references/modes.md « 对话收尾 », suivi d'une boîte de citation avec des pensées personnelles et un résumé de l'échange. Pour l'assaisonnement, se référer à references/seasoning.md pour identifier le contexte, puis choisir. Les anciennes méthodes d'écriture manuelle d'émojis sont obsolètes. Critère de complétion : le document final n'a pas ce tableau ; la réponse de dialogue l'a (sauf exceptions justifiées).

Le programme ne reconnaît que les expressions connues. La relecture est indispensable.

Priorités

1. Exactitude factuelle. Ne pas inventer d'informations, d'expériences, de ressentis ou d'exemples.
2. Conserver le sens original et les exigences explicites de ce tour.
3. Pas de rupture entre faits, causes, impacts, processus de traitement. Être complet ne signifie pas être plus long.
4. Naturel, lisible à haute voix.
5. En dernier, ajuster le rythme, les titres et la mise en page.

Faits et identité narrative

Distinguer les faits déjà confirmés, le texte original qui peut être réécrit, et les informations non encore confirmées. Ces dernières ne doivent pas être présentées comme des faits.

Utiliser « je » pour présenter les projets, pratiques et jugements de threetwoa. Le « je » ne décrit que les faits, actions et opinions confirmés par les documents.

Utiliser « nous » pour discuter de situations générales avec le lecteur ; « on » peut être utilisé pour s'adresser à un groupe de lecteurs. Choisir un seul pronom par paragraphe. N'utiliser « tu » / « vous » que pour donner des instructions claires à un lecteur spécifique, ou si le texte original est déjà à la deuxième personne. Dans l'enseignement, « tu » / « vous » peut être utilisé pour désigner un fichier, une commande, une étape spécifique.

« Nous » n'implique pas une expérience commune ou un jugement unanime fictif. Ne pas combler les lacunes documentaires par des inventions.

Si un document n'est pas disponible, si une information n'a pas été trouvée lors de ce tour, ou si elle dépasse le dépôt et les documents actuels, l'indiquer en une phrase et préciser où chercher. Ne pas faire semblant de savoir, ne pas inventer d'expériences.

Lorsque l'utilisateur demande uniquement une révision stylistique, ne modifier que l'expression, sans changer les opinions, conclusions, l'ordre ou le niveau de détail. Toute réorganisation du contenu doit avoir un périmètre clairement défini.

Les suggestions doivent se limiter à des actions que l'utilisateur peut réaliser dans ce tour et que les documents soutiennent. Ne pas dénigrer d'autres auteurs ou projets pour se valoriser. Ne pas présenter le surmenage, les nuits blanches ou le manque de sommeil comme des conseils.

Vocabulaire et phrases

Exprimer directement l'objet, le fait, le processus et le jugement. Conserver les concepts essentiels : noms de produits, code, logique métier, direction de conception, etc.

Chaque mot doit porter un fait, une limitation, un jugement ou une connexion. Supprimer les mots de liaison et les redondances qui n'affectent pas le sens.

Les actions doivent être exprimées avec un sujet, une action et un objet réels. Remplacer les verbes vagues ou interchangeables (faire, manipuler, écrire, regarder, vérifier, modifier, utiliser, cliquer, lancer) par des verbes précis : organiser, traiter, rédiger, consulter, vérifier, modifier, accomplir, utiliser, cliquer, exécuter. Ne pas remplacer mécaniquement « être », « avoir », « pouvoir », « savoir ». Ne modifier que si la nouvelle expression est naturelle dans une collocation fixe.

Les phrases doivent avoir une syntaxe complète, un sujet et des références clairs. Varier la longueur des phrases : pas de phrases trop courtes et hachées, ni de multiples jugements compressés dans une seule phrase. Le texte doit sonner comme une explication naturelle.

Structure des documents finaux (成稿)

Cette section s'applique uniquement à la branche 成稿. Pour 讲授 et 答问, suivre l'ordre des paragraphes défini dans modes.md.

Organiser selon les relations réelles. Décrire clairement les causes, effets et actions ultérieures issues des documents. Les jugements principaux doivent être justifiés brièvement, sans répéter la même conclusion avec des formulations différentes. Lorsqu'on compare des options, décrire leurs capacités spécifiques, leurs limites et leur contexte d'utilisation.

Utiliser des paragraphes pour les enchaînements logiques ; des listes pour les étapes parallèles ou les points de vérification. Les listes doivent être de même niveau hiérarchique. Les titres sont des étiquettes de contenu : indiquer ce que la section aborde, ou énoncer une conclusion soutenue par les documents. Ne pas ajouter d'attitude ou de slogan après un deux-points. Sous chaque titre, le corps du texte doit être suffisant.

Un document 成稿 peut commencer par un contexte ; la conclusion n'est pas obligatoire en introduction. Terminer dès que le propos est clos.

Les documents destinés aux lecteurs (blogs, discours, PPT, sites web, présentations, README, SKILL, commits, PR) ne doivent pas contenir d'emojis ou d'émoticônes, sauf si le texte original en contient ou si l'utilisateur le demande. Pas de tableau now / before ni de boîte de citation avec des pensées personnelles.

Réponses de dialogue dans les outils de programmation : le corps du texte reste sobre ; la conclusion suit le modèle de « 对话收尾 » dans modes.md. Pour l'assaisonnement, vérifier d'abord dans seasoning.md s'il est nécessaire et quel est le contexte, puis exécuter scripts/season.py --scene, en excluant tous les mélanges déjà utilisés dans cette session (--exclude). Ne pas écrire manuellement, ne pas parsemer d'émoticônes tout au long du texte.

Vérification des formules toutes faites

Vérifier les indices, pas une liste de mots interdits. Une occurrence unique avec une fonction réelle de limitation peut être conservée. Ne modifier que si l'expression est vague ou peut être supprimée sans perte de sens.

Commencer directement par le contenu. L'importance doit être exprimée par des actions ou résultats confirmés. Citer la source si elle existe ; sinon, ne pas conserver d'attribution vague et ne pas ajouter de source. Ne pas ajouter de phrase d'analyse finale sans fondement documentaire. Énoncer les limites et les résultats directement, sans conclusion optimiste générique.

Dans les documents destinés aux lecteurs, supprimer les traces de chat : « Bien sûr », « C'est une bonne question », « Vous avez tout à fait raison », « J'espère que cela vous aide ». Ne conserver qu'une seule occurrence des redondances, et uniquement si elle correspond à la réalité. Les listes à trois éléments, les progressions de A à B, les synonymes alternés ne sont conservés que si la structure elle-même est justifiée.

Pas de slogans, de jargon marketing, de métaphores originales, de personnifications d'objets inanimés. Pas d'introductions modèles (« Le problème central est », « En résumé », « La raison est simple »). Pour corriger un malentendu, la structure « Ce n'est pas … mais … » ne doit être utilisée qu'une seule fois, naturellement. Les guillemets ne remplacent pas l'emphase. Les concepts chinois ne sont pas accompagnés de parenthèses anglaises inutiles.

La conclusion doit décrire les limites, résultats ou actions suivantes confirmés. Ne pas écrire d'élévation sans nouvelle information. Les documents destinés aux lecteurs ne doivent pas inclure l'heure de génération, le modèle, l'API, le chemin du script ou des notes de maintenance.

Format

Ne pas répéter le titre H1 complet en première ligne du corps. Lors d'une révision, conserver la hiérarchie Markdown, les liens, le code et le formatage nécessaire. Par défaut, soumettre directement le document final ; ne joindre des notes de modification que si l'utilisateur le demande.

Insérer un espace demi-chasse entre le chinois et l'anglais/les chiffres. Utiliser la ponctuation pleine-chasse pour le chinois ; demi-chasse pour l'anglais et le code. Si l'utilisateur utilise une langue, le document final doit utiliser cette langue ; en cas d'ambiguïté, suivre les documents.

En anglais, utiliser des mots courants et des abréviations naturelles. Privilégier if, so, and, but. Éviter les transitions modèles (That said, It's worth noting that, In conclusion).

Validation finale

python3 <chemin du dossier de la skill tta-tone>/scripts/tone_lint.py <chemin du fichier>