Que fait feishu-doc-style ?
Règles à suivre lors de la rédaction d'un document Feishu. Applicables aux plans techniques, PRD, rétrospectives, notes explicatives. Un seul objectif : que tout soit clair dès la première lecture.
Quand utiliser ce skill
Lors de toute rédaction, modification, relecture ou révision d'un document Feishu ou d'un document technique, ces règles s'appliquent par défaut, sans attendre que l'utilisateur les mentionne.
Lorsque l'utilisateur saisit explicitement /feishu-doc-style ou demande « Est-ce clair ? », « Comment puis-je rendre ce passage plus compréhensible ? », se référer aux principes directeurs et à la liste de vérification finale pour proposer des modifications.
En aidant quelqu'un à réviser son texte, parcourir d'abord la liste de vérification point par point, relever les infractions, donner la version corrigée, puis expliquer ce qui a été modifié.
Principes directeurs
-
Ne garder que la conclusion, pas le raisonnement. Supprimer les passages de déduction comme « pourquoi ce choix, ce qui a été pesé ». Donner directement la conclusion. Le lecteur veut la réponse, pas votre processus de réflexion.
-
Un paragraphe ne dépasse pas deux ou trois lignes. Ne pas accumuler plusieurs phrases en un long bloc. Les longs paragraphes fatiguent la lecture.
-
Les processus doivent être représentés par un schéma, pas par du texte. L'ordre des étapes, le flux des données, les changements d'état : utilisez un schéma, pas une longue description textuelle. Un diagramme de séquence vaut bien mieux qu'un long texte.
-
Les flèches ne se trouvent que dans les schémas. Dans le texte principal et les tableaux, interdire les chaînes de flèches comme « A → B ; C → D ». Cela oblige le lecteur à une gymnastique mentale, ce qui revient à lui faire payer le coût de la traduction.
-
Parler comme tout le monde, pas comme un initié. Les termes internes que le lecteur ne comprend pas doivent être soit remplacés par un langage clair, soit expliqués en une phrase dès leur première occurrence. Voir
references/jargon.mdpour une table de correspondance du jargon courant. -
Les cellules des tableaux contiennent des phrases complètes et courtes. Ne pas entasser d'abréviations techniques. Écrire « qui fait quoi, quel est le résultat ».
-
Pas de smiley décoratif ni de cadre de surbrillance. Les smiley 📌 ⭐ 🔒 💡 ✅ 🚧 et les cadres colorés de type callout alourdissent et salissent la page. Pour mettre en avant quelque chose, utiliser un sous-titre en gras suivi du texte normal. Pour les notes ou indicateurs d'état au niveau du document, utiliser le blocquote
>. Sur l'ensemble du document, il ne doit y avoir aucun smiley décoratif ni cadre de surbrillance. -
Utiliser le gras avec parcimonie. Maximum un ou deux endroits par section, uniquement pour les conclusions globales ou les principes directeurs. Ne pas mettre en gras les listes de noms, les noms de champs, les mots de direction (gauche / centre / droite) — la hiérarchie est exprimée par la structure des phrases et des tableaux, pas par du gras envahissant.
-
Ne pas utiliser de caractères impossibles à taper au clavier. Les chiffres encerclés ①②③④⑤, les smileys d'état ✓ ◐ ◑ ● ○, le point d'exclamation
!utilisé comme icône, les icônes fonctionnelles ⚡ ⌘ — tout cela ne se tape pas normalement à la main et donne l'impression de « recopier le texte de l'interface ». Pour les listes, utiliser des listes ordonnées normales (1. 2. 3.) ou des termes comme « premièrement, deuxièmement ». Pour les états, écrire directement « Terminé / En cours ». Pour les étapes, utiliser des numéros normaux (Étape 1 / STEP 1). -
Le titre décrit le contenu, pas la structure. Le titre doit dire directement ce dont traite la section (par exemple « Objectifs et moyens principaux de cette année », « Ce qui est fait et l'avancement »). Ne pas insérer de logique d'organisation ou d'échafaudage rédactionnel. Éviter les préfixes structurels comme « Partie générale : », « Partie spécifique : », « Première section : » — la hiérarchie (général / spécifique, parallèle, succession) se manifeste naturellement par l'ordre du contenu et le niveau des titres. Ne pas ajouter de métadonnées dans les titres (par exemple « (Ajout quotidien par IA) » à mettre dans le corps du texte ou dans un blocquote
>). Éviter également de plaquer un cadre inadapté sur le contenu — par exemple forcer « Quelques sujets en cours par direction » dans une coquille temporelle comme « Avancement au premier semestre » ; réfléchir d'abord à la véritable dimension d'organisation du contenu (l'état actuel par direction, le flux seulement par ordre chronologique). Auto-vérification : lisez le titre à voix haute : est-ce qu'il ressemble à un nom normal qu'une personne donnerait ? « Partie générale : objectifs de cette année » ne sonne pas comme un titre normal ; « Objectifs de cette année » sonne juste.
Comment rédiger un tableau
Les en-têtes de colonnes doivent être des phrases claires, de préférence sous forme interrogative. Par exemple « Que fait l'utilisateur ? / Que fait le système en arrière-plan ? / Faut-il attendre ? », pas des termes internes comme « Entrée de synchronisation / Chaîne asynchrone et écriture en base ».
Les cellules contiennent des phrases complètes et courtes : une phrase pour expliquer qui fait quoi et quel est le résultat.
Les détails techniques vont dans le texte principal ; le tableau sert uniquement à rendre le message compréhensible. Les instructions complètes de création de table, les définitions d'interface, etc., vont dans une section dédiée du texte principal, pas dans le tableau.
Illustrations : quel type d'image pour quel usage
Pour tout processus qui peut être représenté par un schéma, ne pas utiliser de texte. Choisir l'image en fonction de ce que l'on veut exprimer :
| Ce que l'on veut exprimer | Quel type d'image utiliser |
|---|---|
| Flux logique, ordre des étapes, circulation pas à pas des données | Diagramme de séquence (mermaid sequenceDiagram), avec des couloirs par rôle |
| Hiérarchie des modules, dépendances entre modules | Diagramme d'architecture (nœuds en cartes : icône + titre + une phrase de description, couleurs par couche) |
| Changement d'état (par exemple brouillon → publié → retiré) | Organigramme ou diagramme d'états (mermaid flowchart) |
Comment insérer réellement ces images dans Feishu (utilisation de mermaid board, lark-whiteboard, lark-cli) → voir references/feishu-tooling.md.
Liste de vérification avant remise
Avant de remettre le document, parcourir cette liste point par point. Si un point n'est pas respecté, le corriger :
- Absence de chaîne de flèches (A → B) dans le texte principal et les tableaux ? Les flèches n'apparaissent que dans les schémas ?
- Chaque paragraphe ne dépasse pas deux ou trois lignes ?
- Aucun jargon non expliqué ? À la première occurrence d'un terme, une explication simple est donnée ?
- Les processus sont exprimés par des schémas, pas par du texte ?
- Les cellules des tableaux contiennent des phrases complètes ? Les en-têtes sont en langage clair ?
- Les longs raisonnements (« pourquoi ce choix ») sont supprimés, seules les conclusions sont conservées ?
- Absence de smiley décoratif, de cadre coloré de surbrillance (callout) ? La mise en avant se fait par des sous-titres en gras, les notes par des blocs de citation ?
- Aucun caractère impossible à taper au clavier (chiffres encerclés ①②③, smiley d'état ✓ ◐ …) ?
- Utilisation sobre du gras — maximum un ou deux points globaux par section, pas de mise en gras des listes de noms / mots de direction ?
- Les titres et les tableaux n'utilisent pas de mots anglais nus comme sujet ? Si un maquette en anglais a été fournie, une traduction en chinois entre parenthèses est donnée ?
- Les titres nomment directement le contenu, sans préfixe structurel comme « Partie générale : / Partie spécifique : / Première section : » ni métadonnées ? Aucun contenu n'est plaqué dans une coquille temporelle inappropriée ?
Références associées
references/jargon.md: Table de correspondance du jargon — les mots de gauche sont systématiquement remplacés par le langage clair de droite ; à compléter au fur et à mesure.references/feishu-tooling.md: Mémo sur comment insérer des images dans Feishu (mermaid board, lark-whiteboard, lark-cli).
Ce skill respecte également ces règles
Le SKILL.md, le README et les références de ce skill sont tous rédigés conformément aux règles ci-dessus. Lors des modifications, commencer par utiliser la « liste de vérification avant remise » comme auto-contrôle : pas de smiley décoratif, pas de chaîne de flèches, paragraphes courts, titres qui décrivent le contenu. Si les règles changent, mettre à jour simultanément le SKILL.md et le README pour qu'ils restent cohérents.