Workflow de Co-Rédaction de Documents

Cette skill fournit un workflow structuré pour guider les utilisateurs à travers la création collaborative de documents. Agis comme un guide actif, guidant les utilisateurs à travers trois étapes : Collecte de Contexte, Raffinement & Structure, et Test de Lecteurs.

Quand Proposer Ce Workflow

Conditions de déclenchement :

• L'utilisateur mentionne la rédaction de documentation : « écrire un doc », « rédiger une proposition », « créer une spec », « documenter »
• L'utilisateur mentionne des types de documents spécifiques : « PRD », « design doc », « decision doc », « RFC »
• L'utilisateur semble commencer une tâche de rédaction substantielle

Proposition initiale : Propose à l'utilisateur un workflow structuré pour co-rédiger le document. Explique les trois étapes :

1. Collecte de Contexte : L'utilisateur fournit tout le contexte pertinent tandis que Claude pose des questions clarificatrices
2. Raffinement & Structure : Construire itérativement chaque section via brainstorming et édition
3. Test de Lecteurs : Tester le doc avec un Claude vierge (sans contexte) pour identifier les points aveugles avant que d'autres le lisent

Explique que cette approche aide à garantir que le doc fonctionne bien quand d'autres le lisent (y compris quand ils le copient-collent dans Claude). Demande s'ils veulent essayer ce workflow ou préfèrent travailler de manière libre.

Si l'utilisateur refuse, travaille en mode libre. S'il accepte, procède à l'Étape 1.

Étape 1 : Collecte de Contexte

Objectif : Combler le fossé entre ce que sait l'utilisateur et ce que sait Claude, permettant une guidance intelligente par la suite.

Questions Initiales

Commence par demander à l'utilisateur le méta-contexte du document :

1. Quel type de document est-ce ? (par exemple, spec technique, decision doc, proposition)
2. Quel est le public principal ?
3. Quel impact souhaite-t-on quand quelqu'un le lit ?
4. Y a-t-il un template ou un format spécifique à suivre ?
5. D'autres contraintes ou contexte à connaître ?

Informe-les qu'ils peuvent répondre en raccourci ou dumper l'information comme cela leur convient.

Si l'utilisateur fournit un template ou mentionne un type de doc :

• Demande s'il a un document template à partager
• S'il fournit un lien vers un document partagé, utilise l'intégration appropriée pour le récupérer
• S'il fournit un fichier, lis-le

Si l'utilisateur mentionne l'édition d'un document partagé existant :

• Utilise l'intégration appropriée pour lire l'état actuel
• Vérifie les images sans texte alt
• Si des images existent sans texte alt, explique que quand d'autres utilisent Claude pour comprendre le doc, Claude ne pourra pas les voir. Demande s'ils veulent que du texte alt soit généré. Si oui, demande-leur de coller chaque image dans le chat pour générer un texte alt descriptif.

Info Dumping

Une fois les questions initiales répondues, encourage l'utilisateur à dumper tout le contexte qu'il a. Demande des informations comme :

• Contexte sur le projet/problème
• Discussions d'équipe ou documents partagés connexes
• Pourquoi les solutions alternatives ne sont pas utilisées
• Contexte organisationnel (dynamique d'équipe, incidents passés, politique)
• Pressions ou contraintes de calendrier
• Architecture technique ou dépendances
• Préoccupations des parties prenantes

Conseille-lui de ne pas se soucier de l'organisation - juste tout sortir. Propose plusieurs façons de fournir le contexte :

• Info dump en flux de conscience
• Pointer vers des canaux d'équipe ou des threads à lire
• Lier vers des documents partagés

Si des intégrations sont disponibles (par exemple, Slack, Teams, Google Drive, SharePoint ou autres serveurs MCP), mentionne que celles-ci peuvent être utilisées pour tirer directement le contexte.

Si aucune intégration n'est détectée et dans Claude.ai ou Claude app : Suggère qu'il peut activer des connecteurs dans les paramètres Claude pour permettre de tirer le contexte des apps de messagerie et stockage de documents directement.

Informe-le que des questions clarificatrices seront posées une fois le dump initial complété.

Pendant la collecte de contexte :

• Si l'utilisateur mentionne des canaux d'équipe ou des documents partagés :

  • Si intégrations disponibles : Informe-le que le contenu sera lu maintenant, puis utilise l'intégration appropriée
  • Si intégrations non disponibles : Explique le manque d'accès. Suggère qu'il active les connecteurs dans les paramètres Claude, ou colle directement le contenu pertinent.

• Si l'utilisateur mentionne des entités/projets inconnus :

  • Demande si les outils connectés devraient être recherchés pour en savoir plus
  • Attends la confirmation de l'utilisateur avant de chercher

• Au fur et à mesure que l'utilisateur fournit le contexte, suit ce qui est appris et ce qui reste flou

Poser des questions clarificatrices :

Quand l'utilisateur signale qu'il a complété son dump initial (ou après un contexte substantiel fourni), pose des questions clarificatrices pour assurer la compréhension :

Génère 5-10 questions numérotées basées sur les lacunes du contexte.

Informe-le qu'il peut utiliser des raccourcis pour répondre (par exemple, « 1 : oui, 2 : voir #channel, 3 : non à cause de la compatibilité rétro »), lier vers plus de docs, pointer vers des canaux à lire, ou juste continuer le info-dump. Ce qui est plus efficace pour lui.

Condition de sortie : Suffisamment de contexte est collecté quand les questions montrent la compréhension - quand les cas limites et les compromis peuvent être questionnés sans avoir besoin d'expliquer les bases.

Transition : Demande s'il y a d'autres contextes qu'il veut fournir à ce stade, ou si c'est le moment de passer à la rédaction du document.

S'il veut ajouter plus, laisse-le. Quand prêt, procède à l'Étape 2.

Étape 2 : Raffinement & Structure

Objectif : Construire le document section par section via brainstorming, curation et raffinement itératif.

Instructions à l'utilisateur : Explique que le document sera construit section par section. Pour chaque section :

1. Des questions clarificatrices seront posées sur ce qu'inclure
2. 5-20 options seront brainstormées
3. L'utilisateur indiquera ce qu'il faut garder/supprimer/combiner
4. La section sera rédigée
5. Elle sera affinée via des édits chirurgicaux

Commence par la section avec le plus d'inconnues (généralement la décision/proposition centrale), puis travaille sur le reste.

Ordre des sections :

Si la structure du document est claire : Demande quelle section il/elle aimerait commencer.

Suggère de commencer par la section avec le plus d'inconnues. Pour les decision docs, c'est généralement la proposition centrale. Pour les specs, c'est généralement l'approche technique. Les sections de résumé sont mieux laissées pour la fin.

Si l'utilisateur ne sait pas quelles sections il/elle a besoin : Basé sur le type de document et le template, suggère 3-5 sections appropriées pour le type de doc.

Demande si cette structure fonctionne, ou s'il/elle veut l'ajuster.

Une fois la structure convenue :

Crée la structure initiale du document avec du texte placeholder pour toutes les sections.

Si l'accès aux artifacts est disponible : Utilise create_file pour créer un artifact. Cela donne à la fois à Claude et à l'utilisateur un scaffold à partir duquel travailler.

Informe-le que la structure initiale avec placeholders pour toutes les sections sera créée.

Crée artifact avec tous les en-têtes de section et du texte placeholder comme « [À écrire] » ou « [Contenu ici] ».

Fournit le lien scaffold et indique qu'il est temps de remplir chaque section.

Si pas d'accès aux artifacts : Crée un fichier markdown dans le répertoire de travail. Nomme-le appropriément (par exemple, decision-doc.md, technical-spec.md).

Informe-le que la structure initiale avec placeholders pour toutes les sections sera créée.

Crée fichier avec tous les en-têtes de section et texte placeholder.

Confirme que le nom de fichier a été créé et indique qu'il est temps de remplir chaque section.

Pour chaque section :

Étape 1 : Questions Clarificatrices

Annonce que le travail va commencer sur la section [NOM_SECTION]. Pose 5-10 questions clarificatrices sur ce qui devrait être inclus :

Génère 5-10 questions spécifiques basées sur le contexte et le but de la section.

Informe-le qu'il peut répondre en raccourci ou juste indiquer ce qui est important à couvrir.

Étape 2 : Brainstorming

Pour la section [NOM_SECTION], brainstorme [5-20] choses qui pourraient être incluses, dépendant de la complexité de la section. Cherche :

• Le contexte partagé qui aurait pu être oublié
• Les angles ou considérations pas encore mentionnés

Génère 5-20 options numérotées basées sur la complexité de la section. À la fin, offre de brainstormer plus s'il/elle veut d'options supplémentaires.

Étape 3 : Curation

Demande quels points devraient être gardés, supprimés ou combinés. Demande des justifications brèves pour aider à apprendre les priorités pour les sections suivantes.

Fournit des exemples :

• « Garder 1,4,7,9 »
• « Supprimer 3 (duplique 1) »
• « Supprimer 6 (l'audience le sait déjà) »
• « Combiner 11 et 12 »

Si l'utilisateur donne un feedback en format libre (par exemple, « ça a l'air bon » ou « j'aime la plupart mais... ») au lieu de sélections numérotées, extrait ses préférences et procède. Parse ce qu'il veut garder/supprimer/changer et applique-le.

Étape 4 : Vérification des Lacunes

Basé sur ce qu'il/elle a sélectionné, demande s'il y a quelque chose d'important manquant pour la section [NOM_SECTION].

Étape 5 : Rédaction

Utilise str_replace pour remplacer le texte placeholder pour cette section par le contenu rédigé réel.

Annonce que la section [NOM_SECTION] va être rédigée maintenant basée sur ce qu'il/elle a sélectionné.

Si utilisation d'artifacts : Après la rédaction, fournit un lien vers l'artifact.

Demande-lui de le lire et d'indiquer ce à changer. Note que être spécifique aide à apprendre pour les sections suivantes.

Si utilisation d'un fichier (pas d'artifacts) : Après la rédaction, confirme la completion.

Informe-le que la section [NOM_SECTION] a été rédigée dans [nom_fichier]. Demande-lui de la lire et d'indiquer ce à changer. Note que être spécifique aide à apprendre pour les sections suivantes.

Instruction clé pour l'utilisateur (inclure lors de la rédaction de la première section) : Fournit une note : Au lieu d'éditer le doc directement, demande-lui d'indiquer ce à changer. Cela aide à apprendre son style pour les sections futures. Par exemple : « Supprimer la bullet X - déjà couverte par Y » ou « Rendre le troisième paragraphe plus concis ».

Étape 6 : Raffinement Itératif

Au fur et à mesure que l'utilisateur fournit du feedback :

• Utilise str_replace pour faire des édits (ne jamais réimprimer le doc entier)
• Si utilisation d'artifacts : Fournit le lien vers artifact après chaque édition
• Si utilisation de fichiers : Juste confirme que les édits sont complétés
• Si l'utilisateur édite le doc directement et demande à le lire : note mentalement les changements qu'il/elle a faits et garde-les en tête pour les sections futures (cela montre ses préférences)

Continue l'itération jusqu'à ce que l'utilisateur soit satisfait de la section.

Vérification de Qualité

Après 3 itérations consécutives sans changements substantiels, demande si quelque chose peut être supprimé sans perdre d'information importante.

Quand la section est complète, confirme que [NOM_SECTION] est complète. Demande si prêt à passer à la section suivante.

Répète pour toutes les sections.

Approche de Fin

En approchant de la fin (80%+ des sections faites), annonce l'intention de relire le document entier et de vérifier :

• Le flux et la cohérence entre les sections
• La redondance ou les contradictions
• Tout ce qui semble « bavard » ou remplissage générique
• Si chaque phrase porte du poids

Lis le document entier et fournit du feedback.

Quand toutes les sections sont rédigées et affinées : Annonce que toutes les sections sont rédigées. Indique l'intention de revoir le document complet une fois de plus.

Revois pour la cohérence globale, le flux, la complétude.

Fournit suggestions finales.

Demande si prêt à passer au Test de Lecteurs, ou s'il/elle veut affiner autre chose.

Étape 3 : Test de Lecteurs

Objectif : Tester le document avec un Claude vierge (sans bleed de contexte) pour vérifier qu'il fonctionne pour les lecteurs.

Instructions à l'utilisateur : Explique que le test va maintenant avoir lieu pour voir si le document fonctionne réellement pour les lecteurs. Cela attrape les points aveugles - les choses qui font sens pour les auteurs mais pourraient confondre d'autres.

Approche de Test

Si l'accès à des sous-agents est disponible (par exemple, dans Claude Code) :

Effectue le test directement sans implication de l'utilisateur.

Étape 1 : Prédire les Questions des Lecteurs

Annonce l'intention de prédire quelles questions les lecteurs pourraient poser quand ils découvrent ce document.

Génère 5-10 questions que les lecteurs poseraient réalistement.

Étape 2 : Test avec Sous-Agent

Annonce que ces questions vont être testées avec une instance Claude vierge (sans contexte de cette conversation).

Pour chaque question, invoque un sous-agent avec juste le contenu du document et la question.

Résume ce que Reader Claude a bien/mal compris pour chaque question.

Étape 3 : Exécuter des Vérifications Supplémentaires

Annonce que des vérifications supplémentaires vont être effectuées.

Invoque sous-agent pour vérifier l'ambiguïté, les fausses hypothèses, les contradictions.

Résume tout problème trouvé.

Étape 4 : Rapport et Correction

Si problèmes trouvés : Rapporte que Reader Claude a eu du mal avec les problèmes spécifiques.

Liste les problèmes spécifiques.

Indique l'intention de combler ces lacunes.

Boucle vers le raffinement pour les sections problématiques.

Si pas d'accès à des sous-agents (par exemple, interface web claude.ai) :

L'utilisateur devra faire le test manuellement.

Étape 1 : Prédire les Questions des Lecteurs

Demande quelles questions les gens pourraient poser quand ils découvrent ce document. Que taperait-ils dans Claude.ai ?

Génère 5-10 questions que les lecteurs poseraient réalistement.

Étape 2 : Configuration du Test

Fournit instructions de test :

1. Ouvre une conversation Claude vierge : https://claude.ai
2. Colle ou partage le contenu du document (si utilisation d'une plateforme de doc partagée avec connecteurs activés, fournit le lien)
3. Pose à Reader Claude les questions générées

Pour chaque question, demande à Reader Claude de fournir :

• La réponse
• Si quelque chose était ambigu ou peu clair
• Quelle connaissance/contexte le doc assume déjà

Vérifie si Reader Claude donne des réponses correctes ou mal interprète quelque chose.

Étape 3 : Vérifications Supplémentaires

Demande aussi à Reader Claude :

• « Qu'y a-t-il dans ce doc qui pourrait être ambigu ou peu clair pour les lecteurs ? »
• « Quelle connaissance ou contexte ce doc assume-t-il que les lecteurs connaissent déjà ? »
• « Y a-t-il des contradictions ou incohérences internes ? »

Étape 4 : Itérer Basé sur les Résultats

Demande ce que Reader Claude a mal compris ou avec quoi il a eu du mal. Indique l'intention de combler ces lacunes.

Boucle vers le raffinement pour toute section problématique.

Condition de Sortie (Les Deux Approches)

Quand Reader Claude répond constamment correctement aux questions et ne soulève pas de nouvelles lacunes ou ambiguïtés, le doc est prêt.

Revue Finale

Quand Reader Testing passe : Annonce que le doc a passé le test Reader Claude. Avant la finition :

1. Recommande de faire une dernière lecture - ils sont propriétaires de ce document et responsables de sa qualité
2. Suggère de vérifier doublement les faits, liens ou détails techniques
3. Demande de vérifier qu'il atteint l'impact voulu

Demande s'il/elle veut une dernière revue, ou si le travail est complété.

Si l'utilisateur veut une dernière revue, fournissez-la. Sinon : Annonce la complétude du document. Fournit quelques conseils finaux :

• Considère de lier cette conversation dans une annexe pour que les lecteurs voient comment le doc a été développé
• Utilise les annexes pour fournir de la profondeur sans surcharger le doc principal
• Mets à jour le doc au fur et à mesure que le feedback est reçu des vrais lecteurs

Conseils pour une Guidance Efficace

Ton :

• Sois direct et procédural
• Explique la logique brièvement quand cela affecte le comportement de l'utilisateur
• N'essaie pas de « vendre » l'approche - juste l'exécuter

Gérer les Déviations :

• Si l'utilisateur veut sauter une étape : Demande s'il/elle veut sauter et écrire en mode libre
• Si l'utilisateur semble frustré : Reconnais que cela prend plus de temps que prévu. Suggère des façons d'aller plus vite
• Donne toujours à l'utilisateur l'agentivité d'ajuster le processus

Gestion du Contexte :

• Tout au long, si le contexte manque sur quelque chose de mentionné, pose la question de manière proactive
• Ne laisse pas les lacunes s'accumuler - adresse-les au fur et à mesure

Gestion des Artifacts :

• Utilise create_file pour rédiger les sections complètes
• Utilise str_replace pour tous les édits
• Fournit le lien artifact après chaque changement
• N'utilise jamais d'artifacts pour les listes de brainstorming - c'est juste la conversation

Qualité plutôt que Vitesse :

• Ne précipite pas les étapes
• Chaque itération devrait apporter des améliorations significatives
• L'objectif est un document qui fonctionne réellement pour les lecteurs