100 questions sur WorkBuddy

Préface

Ceci est un guide « 100 questions » : une façon de découper un grand sujet en questions, puis de le lire une question à la fois.

WorkBuddy ne sert pas d'abord à répondre à des questions. Il reçoit une tâche, lit le matériel, la découpe en étapes et livre un fichier vérifiable dans votre espace de travail. Le guide suit six étapes : fixer les attentes, comprendre Ask/Plan/Craft et les connecteurs, éviter les erreurs de débutant, construire des critères d'acceptation, exécuter de vrais flux de bureau et connaître les limites.

Réponses rapides

• Ne l'utilisez pas comme une boîte de chat. Donnez une vraie tâche, du vrai matériel et un chemin de sortie explicite.
• Demandez Ask pour inspecter le matériel, puis Plan, et seulement ensuite Craft. Arrêtez-vous à Plan en cas d'écrasement, d'envoi ou de suppression.
• L'espace de travail est la frontière de sécurité. N'accordez que les dossiers nécessaires et donnez aux connecteurs le minimum de permissions.
• Acceptez le résultat en ouvrant et modifiant le fichier et en traçant chaque conclusion jusqu'aux données source, pas en faisant confiance à « terminé ».
• Automatisez seulement après stabilisation du flux manuel. Envoi, publication et écrasement de fichiers exigent une confirmation humaine.

Compilé à partir de la documentation WorkBuddy et de sources publiques, structuré et légèrement complété pour ce site.

Ceci est une édition éditée : certains passages source étaient tronqués par l'OCR, le corps privilégie donc une liste de questions actionnable avec des réponses concises.

1. Fondamentaux et positionnement

1. Pourquoi beaucoup installent WorkBuddy et finissent par l'utiliser comme une boîte de chat ?

Parce qu'ils ne posent que des questions et ne confient jamais une tâche complète. La valeur de WorkBuddy est de lire du matériel, découper le travail et livrer un fichier vérifiable.

2. Quels trois profils obtiennent des résultats positifs la première semaine ?

Les profils produit, opérations et projet ; les personnes avec du matériel clair et un format de sortie défini ; celles qui acceptent de vérifier le résultat avec des critères objectifs.

3. Pourquoi les tâches de bureau ordinaires sont-elles un meilleur premier pas que la recherche ouverte ?

Les tâches de bureau ont des entrées, sorties et critères d'acceptation clairs. La recherche ouverte a des limites floues et un jugement subjectif.

4. Qu'est-ce qu'un « résultat vérifiable » et en quoi diffère-t-il d'une réponse de chat ?

C'est un document, tableur, page ou présentation que vous pouvez ouvrir, modifier et vérifier. Une réponse de chat n'est que du texte.

5. Pourquoi WorkBuddy met-il moins l'accent sur « savoir répondre » que sur « déposer le fichier fini dans votre dossier » ?

L'essentiel de l'effort de bureau se situe entre « j'ai une idée » et « j'ai un fichier utilisable ». WorkBuddy raccourcit ce chemin en produisant directement le fichier.

6. Quelles tâches réussissent le plus souvent du premier coup ?

Celles où le matériel est déjà là, le résultat est clair et peu de jugement externe est nécessaire : Excel vers rapport hebdomadaire, notes de réunion vers actions, renommage par règles.

7. Pourquoi « que peux-tu faire pour moi ? » donne-t-il souvent un mauvais résultat ?

C'est trop large : vous obtenez un menu de fonctions, pas une tâche. Donnez une vraie tâche pour voir s'il lit, planifie et livre dans votre contexte.

8. Comment distinguer un vrai flux de travail d'une expérience occasionnelle ?

Un vrai flux dit quatre choses : quel matériel est traité, quel résultat est produit, où il est placé et qui l'accepte. Si ce n'est pas clair, c'est une expérience.

9. Pourquoi les tâches de fichiers sont-elles un meilleur point de départ que la création ouverte ?

Les fichiers apportent des contraintes naturelles : noms, formats, dossiers, champs et plage de contenu. Ouvrir le fichier suffit à savoir si c'est correct.

10. Quand utiliser WorkBuddy plutôt que continuer à la main ?

Quand la tâche se répète, que les étapes sont stables et que l'entrée et la sortie sont cohérentes. Le coût de l'attention répétée dépasse souvent celui de la configuration.

11. Pourquoi les premiers échecs viennent-ils plus d'une tâche trop large que d'un modèle faible ?

Une tâche large oblige le modèle à deviner ce qui compte. Sans dossier, format, actions interdites et critères d'acceptation, en faire plus revient souvent à dériver davantage.

12. Comment savoir quel travail répétitif mérite d'être confié à WorkBuddy ?

Deux signaux : il se répète et semble mécanique ; son entrée et sa sortie sont déjà stables. Si les deux sont vrais, cela vaut un essai.

13. Quelle est la différence entre « l'utiliser de temps en temps » et « l'ouvrir chaque jour » ?

Un flux stable, répétable et vérifiable. Sans flux fixe, cela reste une expérience occasionnelle.

14. Quelles tâches ont le plus de risque d'échouer avec WorkBuddy ?

Les tâches à haut risque et fort jugement ; tout ce qui touche aux paiements, à la publication ou à la suppression ; les limites de matériel floues ; les résultats invérifiables.

15. Pourquoi donner une vraie tâche révèle-t-il plus que demander ce qu'il sait faire ?

Une vraie tâche montre comment il lit, planifie, gère les exceptions et livre un fichier. Demander des fonctions ne montre que la couche marketing.

2. Architecture centrale et mécaniques clés

16. Quand utiliser Ask, Plan et Craft ?

Ask inspecte le matériel et l'état actuel. Plan définit les étapes, risques et sortie. Craft exécute et livre. Utilisez-les dans cet ordre.

17. Pourquoi passer d'un Ask incomplet à Craft abîme-t-il les fichiers ?

Sans liste de fichiers, structure de dossiers et actions interdites, Craft peut écraser, supprimer ou modifier les mauvais fichiers. Confirmez ce qui existe, ce qui peut changer et ce qui ne doit pas être touché.

18. Comment savoir qu'une tâche doit s'arrêter à Plan au lieu de commencer ?

Arrêtez-vous à Plan si la tâche touche plusieurs fichiers, écrase des originaux, envoie à l'extérieur, a des définitions de données floues ou un risque notable.

19. Quand le modèle Auto suffit-il, et quand choisir un modèle soi-même ?

Auto suffit pour des tâches routinières, à faible risque et format modéré. Choisissez un modèle plus fort pour des données critiques, un jugement complexe, des documents longs ou un format strict.

20. Pourquoi changer de modèle modifie-t-il visiblement la stabilité du livrable ?

Les modèles diffèrent dans le suivi des instructions, la tenue du format, les textes longs et l'usage d'outils. Après un changement, refaites l'acceptation.

21. Quelle couche de jugement appartient au modèle et à l'expert ?

Le modèle exécute, génère et appelle des outils. L'expert possède le jugement métier, les compromis, l'identification des risques et les critères d'acceptation.

22. Quand un panel d'experts vaut-il le coup, et quand un seul suffit-il ?

Un seul expert convient à un domaine bien défini. Un panel convient à un travail pluridisciplinaire qui gagne à être critiqué et confronté.

23. Pourquoi installer plus de compétences ne rend-il pas forcément plus fort ?

Plus de compétences signifie plus de coût de sélection, de conflits d'activation et de maintenance. Installez par flux fréquent, pas par quantité.

24. Comment décider si un processus répété doit devenir une skill ?

S'il se répète, que les étapes sont stables, que la sortie est vérifiable et que vous réexpliquez à chaque fois, transformez-le en skill.

25. Quelles étapes pénibles de téléchargement, d'envoi et de changement les connecteurs suppriment-ils ?

Les connecteurs permettent de lire et écrire directement des documents externes, supprimant export, téléchargement, envoi, conversion de format et changement de plateforme.

26. Pourquoi connecter Tencent Docs change-t-il votre façon de travailler ?

Vous n'exportez plus le matériel d'abord. WorkBuddy lit, organise et réécrit dans Tencent Docs, passant du déplacement de fichiers au travail direct sur le contenu.

27. Comment décider si une tâche a besoin d'un connecteur ou de fichiers locaux ?

Utilisez un connecteur quand le matériel vit dans un service externe et doit être lu/écrit en direct. Utilisez l'espace local quand le matériel est déjà sur disque et traité une fois.

28. Pourquoi l'espace de travail est-il à la fois un gain d'efficacité et une frontière de sécurité ?

Il limite ce que WorkBuddy peut lire et écrire. Une frontière claire améliore l'efficacité et réduit les dégâts ; une frontière large augmente les risques de suppression, modification et fuite.

29. Pourquoi donner tout le bureau est-il généralement une mauvaise idée ?

Le bureau contient des fichiers privés, des comptes, des projets sans rapport et du matériel sensible. Donner tout le bureau supprime la frontière et rend le risque incontrôlable.

30. L'assistant distant change-t-il le point d'entrée ou la façon d'exécuter quand vous êtes absent ?

Les deux. Le point d'entrée passe de l'ordinateur au téléphone, et l'exécution passe de « il faut être au bureau » à « vous pouvez instruire, suivre et confirmer de n'importe où ».

31. Pourquoi l'automatisation doit-elle venir après un flux manuel qui fonctionne ?

L'automatisation multiplie les erreurs. Stabilisez d'abord entrées, sorties, exceptions et confirmations à la main, puis planifiez.

32. MCP et skills ressemblent à des extensions. Que résout chacun ?

MCP connecte des outils et données externes. Les skills codifient un flux et son jugement. Les connecteurs relient une plateforme précise.

33. Pourquoi mémoire, gestion des données et archivage des tâches affectent-ils la continuité ?

Sans traces, vous réexpliquez le matériel, les définitions et le progrès. Mémoire, archivage et données propres rendent le travail continu.

3. Erreurs et antipatterns de débutant

34. Pourquoi un espace de travail mal délimité finit-il presque toujours par poser problème ?

D'anciens fichiers, caches, permissions et dossiers sans rapport se mélangent, et WorkBuddy ne sait pas ce qu'il peut modifier. Une frontière floue rend modifications et suppressions accidentelles inévitables.

35. Quels signaux anormaux surveiller pendant une inspection Ask ?

Nombres ou chemins inattendus, données manquantes, doublons, permissions excessives, dossier de sortie flou et formats illisibles.

36. Pourquoi « écraser le fichier original » dans un Plan doit-il faire arrêter ?

L'écrasement détruit la source et est difficile à récupérer. Sauvegardez d'abord ou écrivez dans un nouveau fichier ou dossier.

37. Pourquoi laisser remplir les données manquantes pose-t-il une mine ?

Le modèle peut deviner ou inventer des valeurs. Les données manquantes doivent être marquées « à confirmer » par un humain, pas remplies pour faire complet.

38. Quels signaux de danger manquez-vous quand le résultat semble crédible ?

Source des données, définitions, dates, unités, permissions et étapes de calcul. Plus c'est crédible, plus il faut remonter à la source.

39. Pourquoi un rapport hebdomadaire ou une présentation finis ne prouvent-ils pas la fiabilité de la conclusion ?

Un fichier fini prouve le format, pas la justesse des données, la cohérence des définitions ou la validité de la conclusion. Chaque conclusion doit remonter à la source.

40. Pourquoi les cellules vides sont-elles les plus faciles à mal traiter ?

Les vides peuvent devenir zéro, être ignorés ou mal remplis, ce qui fausse totaux, comparaisons et croissance. Définissez d'abord la règle des vides.

41. Quand comparaisons et définitions se mélangent, quels jugements se faussent d'abord ?

Croissance, baisse, regroupement, déduplication et classement. Sans définition partagée, graphiques et conclusions ne sont pas fiables.

42. Pourquoi dire « refais-le » aggrave-t-il souvent le résultat ?

Refaire jette les parties déjà confirmées et oblige le modèle à deviner à nouveau. Une révision locale est plus sûre : quoi garder, quoi changer.

43. Comment demander une révision locale sans détruire ce qui était juste ?

Indiquez le fichier, l'emplacement, les parties à garder et celles à changer. Demandez un plan ou un diff d'abord, puis approuvez l'exécution.

44. Pourquoi une autorisation de connecteur trop large rend-elle la confiance difficile ensuite ?

Plus l'autorisation est large, plus il peut lire et écrire, et plus le risque d'erreur et de fuite augmente. Accordez le minimum, en lecture d'abord.

45. Quelle porte de confirmation oublie-t-on le plus en instruisant à distance ?

La confirmation avant envoi. Envoyer, publier, supprimer et payer exigent une seconde confirmation, surtout depuis un téléphone.

46. Pourquoi une automatisation qui a marché une fois n'est-elle pas stable en planification ?

Les identifiants expirent, les chemins changent, le client se déconnecte et les permissions de l'espace cible changent. Le premier succès n'est que le début.

47. Quelles tâches de rangement en masse causent le plus d'erreurs de classement et de déplacement ?

Noms irréguliers, dossiers en désordre, règles vagues, noms en double ou fichiers sensibles. Inspectez d'abord, exécutez ensuite.

48. Pourquoi beaucoup de versions sans nom rendent-elles tout plus confus ?

On ne sait plus laquelle est finale, laquelle est modifiable et laquelle a été envoyée. Utilisez date, numéro de version et objectif dans le nom.

49. Pourquoi des étapes désordonnées sont-elles difficiles à réutiliser même avec un résultat produit ?

Elles ne peuvent être reproduites, acceptées ni transmises. Écrivez le processus en checklist ou skill.

50. Quand un panel d'experts passe-t-il de l'aide à la confusion ?

Quand les experts se contredisent, produisent trop d'avis et que personne ne tranche. Utilisez un panel seulement quand plusieurs perspectives sont vraiment nécessaires.

51. Pourquoi trop de skills peuvent-elles faire dériver une tâche ?

Les skills se disputent le déclenchement, se contredisent et peuvent faire choisir le mauvais flux. Gardez peu de skills très fréquentes et bien délimitées.

52. Si l'automatisation ne voit pas l'espace cible, où regarder d'abord ?

Vérifiez l'autorisation et l'existence de l'espace, puis si le client est en ligne, le compte correct et le chemin inchangé.

53. Pourquoi la dernière passe d'un envoi d'e-mail ou d'une publication doit-elle être humaine ?

Une fois envoyé ou publié, on ne peut plus revenir. L'IA peut rédiger et vérifier, mais un humain doit confirmer l'action finale.

4. Validation des résultats et stabilité

54. Comment fixer un standard de fin réellement acceptable ?

Indiquez le fichier de sortie, les champs, le format, la plage de données, le délai et la personne qui accepte. C'est fini quand le fichier s'ouvre, se modifie et se vérifie.

55. Pourquoi est-il difficile de confirmer la livraison sans chemin de sortie ?

Sans chemin, pas d'emplacement de livraison connu. Précisez dossier, nom et version pour trouver et accepter le résultat.

56. Comment demander des rapports d'avancement par étapes sans flot de bruit ?

Demandez seulement quatre choses : ce qui est fait, ce qui reste, la prochaine étape et les risques. Évitez le récit pas à pas.

57. Comment vérifier que chaque conclusion d'un rapport remonte aux données source ?

Reliez chaque conclusion à la table, la ligne, le champ et le calcul d'origine. Une conclusion non traçable doit être marquée « à confirmer ».

58. Pourquoi transformer une corrélation en causalité est-il l'illusion de bureau la plus dangereuse ?

Une corrélation signifie que deux choses varient ensemble, pas que l'une cause l'autre. L'écrire comme causalité trompe les décisions et est difficile à détecter.

59. Quand un fichier ne s'ouvre pas, faut-il inspecter le matériel ou changer de modèle ?

Inspectez d'abord le matériel : format, permissions, corruption, chiffrement, chemin. S'il est correct, essayez un autre modèle ou parseur.

60. Comment utiliser « à confirmer » pour garder le risque visible au lieu de le cacher ?

Listez à part les données, définitions, hypothèses et lacunes incertaines. Ne remplissez pas le livrable de suppositions.

61. Pourquoi vérifier que le fichier reste modifiable, et pas seulement regarder l'aperçu ?

Un aperçu prouve seulement que ça semble correct. Il faut que le fichier s'ouvre, que les formules calculent et que le format ou les calques restent modifiables.

62. Comment savoir qu'une automatisation est prête à tourner presque seule ?

Elle produit des résultats stables de façon répétée, alerte sur les exceptions, a une sortie vérifiable et peut être annulée en cas d'échec.

63. Pourquoi refaire l'acceptation après un changement de skill, connecteur ou modèle ?

Changer un composant change la lecture, le traitement et l'écriture du matériel. L'ancienne acceptation peut ne plus valoir ; relancez-la.

64. Après une mise à jour ou un redémarrage, l'espace de travail semble « disparu ». Où regarder ?

Vérifiez le chemin, le compte, les permissions et la version du client, puis si l'espace a changé ou si la synchronisation n'est pas terminée.

65. En ajoutant un nouveau modèle, que comparer avant de tout basculer ?

Faites tourner le même lot de tâches avec les mêmes critères dans un petit test, en regardant format, précision, stabilité et gestion des exceptions.

66. Comment savoir si l'échec vient du modèle ou du flux ?

Regardez d'abord le matériel d'entrée, les limites de la tâche, le chemin de sortie et les critères d'acceptation. Si le flux est flou, changer de modèle ne règle rien.

67. Pourquoi la zone de résultats est-elle plus fiable que « terminé » dans le chat ?

« Terminé » est une affirmation du modèle. Un fichier dans la zone de résultats s'ouvre et se vérifie : c'est la vraie livraison.

68. Comment ajouter une couche « confirmer avant envoi » aux tâches avec connecteur ?

Avant l'envoi, listez destinataire, objet, corps, pièces jointes et portée, et exigez une confirmation humaine avant d'exécuter.

69. Pourquoi aucune automatisation ne tourne-t-elle si le client est hors ligne ?

Les fichiers locaux, les capacités du client et l'espace de travail vivent sur votre ordinateur. Sans client, la tâche n'a pas d'environnement d'exécution.

70. Quelles trois zones renforcer d'abord pour des résultats plus stables ?

Matériel d'entrée, chemin de sortie et critères d'acceptation. Clarifier ces trois points améliore nettement la stabilité.

5. Flux de bureau réels

71. Pourquoi Excel → rapport hebdomadaire → présentation est-il le premier circuit recommandé ?

Il a des entrées claires, des sorties standard et une acceptation simple, et couvre la lecture de données, le résumé, la rédaction et la présentation.

72. Comment transformer des notes de réunion en désordre en liste d'actions avec responsables ?

Extrayez tâche, responsable, échéance, source et statut. Marquez les manques « à confirmer » et livrez un tableau suivi.

73. Pourquoi « matériel vers page web » est-il un bon test de livraison réelle ?

Il faut combiner des sources, générer une page, gérer structure et style, prévisualiser et publier : un test complet de livraison.

74. Comment faire une page avec WorkBuddy sans trop compliquer ?

Définissez d'abord structure, sources de contenu et style, puis générez. Gardez un fichier source modifiable et une URL d'aperçu ; n'ajoutez pas de backend complexe au début.

75. Comment utiliser un connecteur pour transformer du contenu Tencent Docs en livrable ?

Accordez les permissions minimales, lisez le document indiqué, organisez-le au format cible, puis réécrivez ou exportez un nouveau document pour acceptation humaine.

76. Pourquoi « résumé d'e-mails » est-il un meilleur premier circuit que « envoyer automatiquement » ?

Un résumé est en lecture seule et à faible risque. Un envoi automatique ne se rattrape pas s'il rate. Commencez par résumer, puis ajoutez une confirmation d'envoi.

77. Comment faire un renommage massif rapide sans perdre de fichiers ?

Inspectez les fichiers, générez une table ancien/nouveau nom, confirmez les conflits et exceptions, renommez et gardez une liste de retour arrière.

78. Comment inspecter et archiver un dossier en désordre sans tout déplacer d'un coup ?

Listez les fichiers et les règles de classement, produisez un plan d'archivage, confirmez-le, puis déplacez en gardant le dossier d'origine ou une sauvegarde.

79. Quels trois scénarios « je suis absent mais ça doit être fait maintenant » conviennent à l'assistant distant ?

Modifications rapides de fichiers, recherche d'information à distance, et confirmation ou publication en déplacement. Envoi et suppression exigent toujours une seconde confirmation.

80. Pourquoi « générer le rapport hebdomadaire le vendredi » est-il une bonne première automatisation ?

Son entrée, sa sortie et son moment sont fixes et ses critères d'acceptation sont clairs : idéal pour un flux de bureau récurrent.

81. Comment connecter Google Calendar et Drive sans bloquer au départ ?

Accordez les permissions minimales, commencez en lecture, validez la connexion avec une petite tâche, puis élargissez à l'écriture.

82. Pourquoi les tâches « je dois repenser le prompt chaque fois » doivent-elles devenir un flux fixe ou une Skill ?

Repenser indique un processus stable au coût d'expression élevé. Une Skill réduit la réexplication et la variance du résultat.

83. Quels petits projets conviennent pour tester des applications locales sans code ?

De petits outils : budget, checklist, consultation interne ou tableau de bord personnel. Entrées et sorties simples, acceptation facile et faible risque de données.

84. Où le mode autonome de l'IA aide-t-il, et où perd-il le contrôle ?

Il aide pour l'exploration, l'organisation et la répétition. Il perd le contrôle sur les décisions à haut risque, les envois externes, les suppressions et les paiements, où la confirmation humaine doit rester.

85. Quand fait-il vraiment gagner du temps, et quand remplace-t-il seulement la panique manuelle par la surveillance de l'IA ?

Il fait gagner du temps sur l'organisation de matériel, la conversion de format et les résumés répétés. Il stresse quand les exigences sont floues, que le travail se refait et que l'acceptation n'est pas claire.

86. Comment choisir le prochain flux qui doit devenir un circuit WorkBuddy ?

Choisissez un flux fréquent, avec entrées stables, sorties vérifiables et coût d'échec maîtrisable. Validez un circuit, puis copiez-le à des flux similaires.

6. Limites, alternatives et jugement futur

87. Pourquoi ne pas confier des backends complexes et du développement de production juste parce qu'il « sait aussi faire des pages et du code » ?

Les systèmes de production exigent architecture, permissions, sécurité, supervision et maintenance. Générer des pages et du code n'est pas assumer la responsabilité de production.

88. Quelles tâches doivent rester dans WorkBuddy, et lesquelles doivent passer à une approche spécialisée ?

Documents de bureau, organisation, résumés et pages légères peuvent rester. Systèmes de production, code central, sécurité et haute disponibilité exigent une équipe et des outils spécialisés.

89. Quand le traitement manuel est-il plus direct et plus stable ?

Les tâches ponctuelles, à fort jugement, à haut risque ou nécessitant un retour immédiat sont souvent plus rapides à la main.

90. Pourquoi ne pas livrer tous les documents et dossiers à WorkBuddy d'un coup ?

Données sensibles, dossiers trop larges et fichiers sans rapport élargissent la surface de risque. Ne donnez que le matériel et la portée nécessaires.

91. Pourquoi la gestion des frontières importe-t-elle davantage à mesure que connecteurs et plateformes se multiplient ?

Plus d'intégrations signifient plus de systèmes lus et écrits, et des permissions, flux de données et risques d'actions accidentelles plus complexes.

92. Quand espace local, assistant distant et intégrations se combinent, quel coût de gestion augmente vraiment ?

Gestion des permissions, flux de données, cohérence des versions, responsabilité et traitement des exceptions.

93. Avec tant de modèles, comment éviter de faire de « changer de modèle » l'unique solution ?

Corrigez d'abord la structure de la tâche, le matériel d'entrée, le chemin de sortie et les critères d'acceptation. Le modèle est une couche ; le changer ne corrige pas un flux flou.

94. Avec l'expansion des skills, de MCP et des connecteurs, quelle frontière d'autorisation protéger d'abord ?

Le moindre privilège : uniquement les dossiers et données nécessaires, la lecture d'abord, et une confirmation pour envoyer et écrire.

95. Pourquoi l'écart vient-il souvent de la structure de la tâche et de l'acceptation, pas du prompt ?

Un prompt affecte une expression. La structure et l'acceptation décident si le résultat peut être reproduit et livré.

96. Quand WorkBuddy passe-t-il d'une expérience ponctuelle à un poste de travail fixe ?

Quand vous avez un flux stable, une sortie fixe et une acceptation claire, et qu'il fait gagner du temps de façon constante.

97. Faut-il lui confier les envois externes, la publication formelle et les modifications directes de fichiers ?

Laissez-le préparer des brouillons, vérifier le contenu et générer des fichiers. Les actions irréversibles comme envoyer, publier et écraser des originaux exigent une confirmation humaine.

98. Pourquoi une longue liste de fonctions ne signifie-t-elle pas tout utiliser dès le premier jour ?

Plus de fonctions signifie plus de coût d'apprentissage et de sélection. Protégez d'abord le flux central, puis ajoutez skills, connecteurs et automatisation selon le besoin.

99. Si je n'apprends qu'une partie d'abord, quels fondamentaux protéger ?

Espace de travail, Ask/Plan/Craft, chemins de sortie, critères d'acceptation et autorisation minimale.

100. Quels mauvais usages et jugements ces 100 questions doivent-elles m'aider à éviter ?

L'utiliser comme boîte de chat, des tâches trop larges, sauter l'acceptation, trop autoriser, automatiser avant que le manuel fonctionne, et confondre un fichier fini avec une conclusion correcte.