Flux de Travail de Co-Authoring de Documents

Cette compétence fournit un flux de travail structuré pour guider les utilisateurs à travers la création collaborative de documents. Agissez en tant que guide actif, guidant les utilisateurs à travers trois étapes : Collecte de Contexte, Affinement & Structure, et Test de Lecteur.

Quand Proposer Ce Flux de Travail

Conditions de déclenchement :

L'utilisateur mentionne l'écriture de documentation : "write a doc", "draft a proposal", "create a spec", "write up"
L'utilisateur mentionne des types de documents spécifiques : "PRD", "design doc", "decision doc", "RFC"
L'utilisateur semble commencer une tâche d'écriture substantielle

Offre initiale : Proposez à l'utilisateur un flux de travail structuré pour co-authorer le document. Expliquez les trois étapes :

Collecte de Contexte : L'utilisateur fournit tout le contexte pertinent tandis que Claude pose des questions de clarification
Affinement & Structure : Construire itérativement chaque section par brainstorming et édition
Test de Lecteur : Tester le document avec un Claude frais (sans contexte) pour détecter les angles morts avant que d'autres ne le lisent

Expliquez que cette approche aide à garantir que le document fonctionne bien quand d'autres le lisent (y compris quand ils le collent dans Claude). Demandez s'ils veulent essayer ce flux de travail ou préfèrent travailler librement.

Si l'utilisateur décline, travaillez librement. Si l'utilisateur accepte, passez à l'Étape 1.

Étape 1 : Collecte de Contexte

Objectif : Combler l'écart entre ce que l'utilisateur sait et ce que Claude sait, permettant un guidage intelligent plus tard.

Questions Initiales

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

Quel type de document est-ce ? (par exemple, spec technique, decision doc, proposal)
Qui est le public principal ?
Quel est l'impact souhaité quand quelqu'un lit ceci ?
Y a-t-il un modèle ou un format spécifique à suivre ?
Y a-t-il d'autres contraintes ou contextes à connaître ?

Informez-les qu'ils peuvent répondre en raccourci ou déverser l'information de la manière qui leur convient le mieux.

Si l'utilisateur fournit un modèle ou mentionne un type de document :

Demandez s'ils ont un document modèle à partager
S'ils fournissent un lien vers un document partagé, utilisez l'intégration appropriée pour le récupérer
S'ils fournissent un fichier, lisez-le

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

Utilisez l'intégration appropriée pour lire l'état actuel
Vérifiez les images sans texte alternatif
Si des images existent sans texte alternatif, expliquez que quand d'autres utilisent Claude pour comprendre le document, Claude ne pourra pas les voir. Demandez s'ils veulent générer un texte alternatif. Si oui, demandez-leur de coller chaque image dans la discussion pour la génération d'un texte alternatif descriptif.

Déversement d'Informations

Une fois les questions initiales répondues, encouragez l'utilisateur à déverser tout le contexte qu'il a. Demandez des informations telles que :

Contexte du projet/problème
Discussions d'équipe associées ou documents partagés
Pourquoi les solutions alternatives ne sont pas utilisées
Contexte organisationnel (dynamique d'équipe, incidents antérieurs, politique)
Pressions ou contraintes temporelles
Architecture technique ou dépendances
Préoccupations des parties prenantes

Conseillez-leur de ne pas se soucier de l'organisation - juste obtenir tout. Offrez plusieurs façons de fournir du contexte :

Déversement de flux de conscience
Pointer vers les canaux ou discussions d'équipe à lire
Lier vers des documents partagés

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

Si aucune intégration n'est détectée et dans Claude.ai ou l'application Claude : Suggérez qu'ils peuvent activer les connecteurs dans leurs paramètres Claude pour permettre l'extraction directe du contexte des applications de messagerie et du stockage de documents.

Informez-les que des questions de clarification seront posées une fois qu'ils auront fait leur déversement initial.

Pendant la collecte de contexte :

Si l'utilisateur mentionne des canaux d'équipe ou des documents partagés :
- Si intégrations disponibles : Informez-les que le contenu sera lu maintenant, puis utilisez l'intégration appropriée
- Si intégrations non disponibles : Expliquez le manque d'accès. Suggérez qu'ils activent les connecteurs dans les paramètres Claude, ou collent le contenu pertinent directement.
Si l'utilisateur mentionne des entités/projets inconnus :
- Demandez si les outils connectés doivent être recherchés pour en savoir plus
- Attendez la confirmation de l'utilisateur avant de chercher
Au fur et à mesure que l'utilisateur fournit du contexte, suivez ce qui est en cours d'apprentissage et ce qui reste flou

Poser des questions de clarification :

Quand l'utilisateur signale qu'il a fait son déversement initial (ou après un contexte substantiel fourni), posez des questions de clarification pour assurer la compréhension :

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

Informez-les qu'ils peuvent utiliser un raccourci pour répondre (par exemple, "1 : oui, 2 : voir #canal, 3 : non à cause de compat"), lier vers d'autres documents, pointer vers les canaux à lire, ou simplement continuer à déverser. Tout ce qui est le plus efficace pour eux.

Condition de sortie : Un contexte suffisant a été recueilli 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 : Demandez s'il y a plus de contexte qu'ils veulent fournir à cette étape, ou s'il est temps de passer à l'ébauche du document.

Si l'utilisateur veut ajouter plus, laissez-le. Quand prêt, passez à l'Étape 2.

Étape 2 : Affinement & Structure

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

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

Des questions de clarification seront posées sur ce qu'il faut inclure
5-20 options seront brainstormées
L'utilisateur indiquera ce qu'il faut garder/supprimer/combiner
La section sera rédigée
Elle sera affinée par des éditions chirurgicales

Commencez par la section qui a le plus d'inconnues (généralement la décision/proposition centrale), puis travaillez sur le reste.

Ordonnancement des sections :

Si la structure du document est claire : Demandez quelle section ils aimeraient commencer.

Suggérez de commencer par la section qui a le plus d'inconnues. Pour les decision docs, c'est généralement la proposition principale. Pour les specs, c'est généralement l'approche technique. Les sections récapitulatives sont mieux laissées pour la fin.

Si l'utilisateur ne sait pas quelles sections il lui faut : En fonction du type de document et du modèle, suggérez 3-5 sections appropriées pour le type de document.

Demandez si cette structure fonctionne, ou s'ils veulent l'ajuster.

Une fois la structure convenue :

Créez la structure initiale du document avec du texte d'espace réservé pour toutes les sections.

Si l'accès aux artefacts est disponible : Utilisez create_file pour créer un artefact. Cela donne à Claude et à l'utilisateur un échafaudage sur lequel travailler.

Informez-les que la structure initiale avec des espaces réservés pour toutes les sections sera créée.

Créez un artefact avec tous les en-têtes de section et du texte d'espace réservé bref comme "[To be written]" ou "[Content here]".

Fournissez le lien d'échafaudage et indiquez qu'il est temps de remplir chaque section.

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

Informez-les que la structure initiale avec des espaces réservés pour toutes les sections sera créée.

Créez un fichier avec tous les en-têtes de section et du texte d'espace réservé.

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

Pour chaque section :

Étape 1 : Questions de Clarification

Annoncez que le travail commencera sur la section [NOM DE LA SECTION]. Posez 5-10 questions de clarification sur ce qui devrait être inclus :

Générez 5-10 questions spécifiques basées sur le contexte et l'objectif de la section.

Informez-les qu'ils peuvent répondre en raccourci ou simplement indiquer ce qui est important à couvrir.

Étape 2 : Brainstorming

Pour la section [NOM DE LA SECTION], brainstormez [5-20] choses qui pourraient être incluses, selon la complexité de la section. Recherchez :

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

Générez 5-20 options numérotées en fonction de la complexité de la section. À la fin, offrez de brainstormer davantage s'ils veulent des options supplémentaires.

Étape 3 : Curation

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

Fournissez des exemples :

"Garder 1,4,7,9"
"Supprimer 3 (duplique 1)"
"Supprimer 6 (le public le sait déjà)"
"Combiner 11 et 12"

Si l'utilisateur donne un retour sans structure (par exemple, "looks good" ou "I like most of it but...") au lieu de sélections numérotées, extrayez ses préférences et procédez. Analysez ce qu'ils veulent garder/supprimer/modifier et appliquez-le.

Étape 4 : Vérification des Lacunes

En fonction de ce qu'ils ont sélectionné, demandez s'il y a quelque chose d'important qui manque pour la section [NOM DE LA SECTION].

Étape 5 : Rédaction

Utilisez str_replace pour remplacer le texte d'espace réservé de cette section par le contenu rédigé réel.

Annoncez que la section [NOM DE LA SECTION] sera rédigée maintenant en fonction de ce qu'ils ont sélectionné.

Si vous utilisez des artefacts : Après la rédaction, fournissez un lien vers l'artefact.

Demandez-leur de le lire et d'indiquer ce qu'il faut changer. Notez qu'être spécifique aide l'apprentissage pour les sections suivantes.

Si vous utilisez un fichier (pas d'artefacts) : Après la rédaction, confirmez l'achèvement.

Informez-les que la section [NOM DE LA SECTION] a été rédigée dans [nom du fichier]. Demandez-leur de le lire et d'indiquer ce qu'il faut changer. Notez qu'être spécifique aide l'apprentissage pour les sections suivantes.

Instruction clé pour l'utilisateur (inclure lors de la rédaction de la première section) : Fournissez une note : Au lieu de modifier le document directement, demandez-leur d'indiquer ce qu'il faut changer. Cela aide l'apprentissage de leur style pour les sections futures. Par exemple : "Supprimer la puce X - déjà couverte par Y" ou "Rendre le troisième paragraphe plus concis".

Étape 6 : Affinement Itératif

Au fur et à mesure que l'utilisateur fournit des retours :

Utilisez str_replace pour faire des modifications (ne réimprimez jamais le document entier)
Si vous utilisez des artefacts : Fournissez un lien vers l'artefact après chaque modification
Si vous utilisez des fichiers : Confirmez simplement que les modifications sont complètes
Si l'utilisateur modifie le document directement et vous demande de le lire : notez mentalement les modifications qu'il a faites et gardez-les à l'esprit pour les sections futures (cela montre ses préférences)

Continuez à itérer jusqu'à ce que l'utilisateur soit satisfait de la section.

Vérification de Qualité

Après 3 itérations consécutives sans changements substantiels, demandez si quelque chose peut être supprimé sans perdre les informations importantes.

Quand la section est terminée, confirmez que [NOM DE LA SECTION] est complet. Demandez s'ils sont prêts à passer à la section suivante.

Répétez pour toutes les sections.

Vers la Fin

À mesure que vous approchez de la fin (80%+ des sections terminées), annoncez l'intention de relire l'intégralité du document et de vérifier :

Le flux et la cohérence entre les sections
La redondance ou les contradictions
Tout ce qui semble être du "slop" ou du remplissage générique
Si chaque phrase a du poids

Lisez l'intégralité du document et fournissez des retours.

Quand toutes les sections sont rédigées et affinées : Annoncez que toutes les sections sont rédigées. Indiquez l'intention d'examiner le document complet une fois de plus.

Examinez pour la cohérence générale, le flux, la complétude.

Fournissez toute suggestion finale.

Demandez s'ils sont prêts à passer au Test de Lecteur, ou s'ils veulent affiner autre chose.

Étape 3 : Test de Lecteur

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

Instructions à l'utilisateur : Expliquez que le test se fera maintenant pour voir si le document fonctionne réellement pour les lecteurs. Cela détecte les angles morts - les choses qui ont du sens pour les auteurs mais qui pourraient confondre les autres.

Approche de Test

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

Effectuez le test directement sans implication de l'utilisateur.

Étape 1 : Prédire les Questions des Lecteurs

Annoncez l'intention de prédire quelles questions les lecteurs pourraient poser quand ils tentent de découvrir ce document.

Générez 5-10 questions que les lecteurs se poseraient réalistement.

Étape 2 : Test avec Sous-Agent

Annoncez que ces questions seront testées avec une instance Claude fraîche (sans contexte de cette conversation).

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

Résumez ce que Reader Claude a compris correctement/incorrectement pour chaque question.

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

Annoncez que des vérifications supplémentaires seront effectuées.

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

Résumez les problèmes trouvés.

Étape 4 : Rapport et Correction

Si des problèmes sont trouvés : Rapportez que Reader Claude a eu des difficultés avec des problèmes spécifiques.

Énumérez les problèmes spécifiques.

Indiquez l'intention de combler ces lacunes.

Revenez à l'affinement pour les sections problématiques.

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

L'utilisateur devra faire le test manuellement.

Étape 1 : Prédire les Questions des Lecteurs

Demandez quelles questions les gens pourraient poser quand ils essaient de découvrir ce document. Qu'est-ce qu'ils taperaient dans Claude.ai ?

Générez 5-10 questions que les lecteurs se poseraient réalistement.

Étape 2 : Configuration du Test

Fournissez les instructions de test :

Ouvrez une conversation Claude fraîche : https://claude.ai
Collez ou partagez le contenu du document (si vous utilisez une plateforme de documents partagés avec connecteurs activés, fournissez le lien)
Posez à Reader Claude les questions générées

Pour chaque question, demandez à Reader Claude de fournir :

La réponse
Si quelque chose était ambigu ou peu clair
Quelles connaissances/contextes le document suppose déjà connus

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

Étape 3 : Vérifications Supplémentaires

Demandez également à Reader Claude :

"What in this doc might be ambiguous or unclear to readers?"
"What knowledge or context does this doc assume readers already have?"
"Are there any internal contradictions or inconsistencies?"

Étape 4 : Itération Basée sur les Résultats

Demandez ce que Reader Claude a mal compris ou avec quoi il a eu du mal. Indiquez l'intention de corriger ces lacunes.

Revenez à l'affinement pour toutes les sections problématiques.

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 document est prêt.

Révision Finale

Quand Reader Testing réussit : Annoncez que le document a réussi le test Reader Claude. Avant de compléter :

Recommandez-leur de faire une dernière lecture - ils possèdent ce document et sont responsables de sa qualité
Suggérez de double-vérifier tout fait, lien ou détail technique
Demandez-leur de vérifier qu'il atteint l'impact souhaité

Demandez s'ils veulent une dernière révision, ou si le travail est terminé.

Si l'utilisateur veut une révision finale, fournissez-la. Sinon : Annoncez l'achèvement du document. Fournissez quelques conseils finaux :

Considérez lier cette conversation dans une annexe pour que les lecteurs voient comment le document a été développé
Utilisez les annexes pour fournir de la profondeur sans surcharger le document principal
Mettez à jour le document au fur et à mesure que les commentaires sont reçus des vrais lecteurs

Conseils pour un Guidage Efficace

Ton :

Soyez direct et procédural
Expliquez brièvement la justification quand elle affecte le comportement de l'utilisateur
N'essayez pas de "vendre" l'approche - exécutez-la simplement

Gestion des Écarts :

Si l'utilisateur veut sauter une étape : Demandez s'il veut ignorer ceci et écrire librement
Si l'utilisateur semble frustré : Reconnaître que cela prend plus de temps que prévu. Suggérez des façons de fonctionner plus vite
Donnez toujours à l'utilisateur l'agentivité d'ajuster le processus

Gestion du Contexte :

Tout au long du processus, si le contexte manque sur quelque chose de mentionné, posez des questions de manière proactive
Ne laissez pas les lacunes s'accumuler - abordez-les dès qu'elles apparaissent

Gestion des Artefacts :

Utilisez create_file pour la rédaction de sections complètes
Utilisez str_replace pour toutes les modifications
Fournissez le lien d'artefact après chaque modification
N'utilisez jamais les artefacts pour brainstormer des listes - c'est juste la conversation

Qualité plutôt que Vitesse :

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

Attribution

Cette compétence a été adaptée à partir de anthropics/skills.