Workflow R&D Agentique
Utilisez ce package de compétence autonome pour automatiser un workflow de laboratoire multi-agent, en Markdown d'abord, dans l'espace de travail actuel.
Il s'agit d'une adaptation généraliste du modèle Agent Laboratory : analyse indépendante des preuves, formulation collaborative du plan, exécution ou investigation des tâches, analyse des résultats, revue qualité et rédaction du rapport final. Cette compétence ne se limite pas à la recherche scientifique ; appliquez le même workflow de laboratoire aux cas d'usage produit, business, technique, stratégique, juridique, conformité, sécurité, UX, marché et opérationnel.
Conçue pour les agents de codage compatibles avec les compétences, disposant d'un accès au système de fichiers. Privilégiez les véritables sous-agents parallèles lorsque l'environnement le permet ; n'utilisez des simulations isolées que lorsque les vrais sous-agents ne sont pas disponibles.
Contenu du Package
SKILL.md: règles d'activation et instructions de fonctionnement principales.references/generalized-lab-model.md: modèle universel du laboratoire agentique et mapping des cas d'usage.references/workflow.md: séquence complète des phases et point de contrôle.references/agent-roles.md: guide de sélection des rôles spécialisés.references/quality-rules.md: normes de preuve, d'incertitude, de revue et de sécurité.references/implementation-notes.md: notes sur l'installation, la structure, les sous-agents et la gestion des fichiers.references/example-run.md: exemple complet et compact montrant la trace de fichiers et la qualité des livrables.assets/templates/: templates Markdown pour tous les fichiers du workflow.scripts/init-rd-workflow.mjs: script facultatif pour la création de la structure.scripts/validate-skill.mjs: validation du dépôt pour le package de compétence public.
Première Action
- Recherchez
project-brief.mddans l'espace de travail actuel. - S'il existe, lisez-le complètement avant toute autre étape du workflow.
- S'il n'existe pas et que l'utilisateur a fourni suffisamment de contexte, créez-le avec
assets/templates/project-brief.md. - Si le contexte essentiel manque, posez uniquement les questions bloquantes minimales.
- Une fois le brief créé, continuez sans demander la permission entre les phases normales du workflow.
Exécutez scripts/init-rd-workflow.mjs pour créer la structure project-brief.md et les fichiers work/ requis. Le script ne doit pas créer work/06-final-output.md.
Livrables Requis
Créez et utilisez cette structure dans l'espace de travail actif :
work/
├── 00-lab-notes.md
├── 01-orchestration-plan.md
├── 02-specialist-outputs/
├── 03-team-collaboration.md
├── 04-cross-review-notes.md
├── 05-stage-gate-review.md
└── 06-final-output.md
Chaque phase du workflow correspond à un chemin de livrable spécifique. Les phases numérotées du laboratoire (analyse des preuves, formulation du plan, exécution, analyse des résultats) ne sont pas des fichiers séparés : elles sont matérialisées sous forme d'un fichier par spécialiste dans work/02-specialist-outputs/.
| Phase | Chemin du livrable |
|---|---|
| Mise en place du laboratoire | work/00-lab-notes.md |
| Orchestration | work/01-orchestration-plan.md |
| Analyse des preuves, plan, exécution, résultats (un fichier par spécialiste) | work/02-specialist-outputs/NN-<role>.md |
| Collaboration d'équipe (consolidée par l'orchestrateur) | work/03-team-collaboration.md |
| Revue croisée | work/04-cross-review-notes.md |
| Revue par porte | work/05-stage-gate-review.md |
| Synthèse finale | work/06-final-output.md |
Ne créez ni n'écrivez work/06-final-output.md tant que work/05-stage-gate-review.md ne contient pas Approuvé.
Workflow
- Lisez
references/workflow.mdpour la séquence canonique des phases. - Lisez
references/generalized-lab-model.mdpour mapper le cas d'usage de l'utilisateur sur les phases du laboratoire. - Lisez
references/agent-roles.mdavant de sélectionner les spécialistes. - Lisez
references/quality-rules.mdavant la revue croisée, la revue par porte et la synthèse finale. - Utilisez
references/implementation-notes.mdpour l'utilisation des scripts, le comportement des sous-agents et les détails de gestion des fichiers. - Utilisez les templates de
assets/templates/pour les fichiers générés du workflow. - Consultez
references/example-run.mdpour un exemple complet lorsque vous n'êtes pas sûr de la qualité attendue des livrables.
Adapter à la Taille du Brief
Adaptez le poids du workflow au brief. N'exécutez pas un laboratoire complet multi-vagues pour une petite question.
- Brief trivial : l'orchestrateur peut effectuer un simple passage inline sans sous-agents. Enregistrez les preuves, hypothèses et risques dans
work/00-lab-notes.md, écrivez une courte auto-vérificationwork/05-stage-gate-review.md, puiswork/06-final-output.md. Les fichiers intermédiaires (spécialistes, collaboration, revue croisée) sont facultatifs à ce niveau. La règle de la porte reste valable : n'écrivez pas06-final-output.mdtant que05-stage-gate-review.mdne contient pasApprouvé. - Brief petit ou étroit : utilisez un ou deux spécialistes, lancez une seule vague, et intégrez la collaboration dans les notes de l'orchestrateur plutôt que dans un échange séparé. Gardez la revue croisée, la revue par porte et la synthèse finale sous forme d'un seul passage rapide chacune.
- Brief moyen : utilisez quelques spécialistes sur une ou deux vagues avec une étape de collaboration d'équipe légère.
- Brief important ou réglementé : utilisez la séquence complète des phases, plusieurs vagues, une collaboration d'équipe explicite et les rôles de revue appropriés.
Respectez toujours le minimum obligatoire quelle que soit la taille : analyse des preuves/contexte, formulation du plan, exécution ou investigation, analyse des résultats, couverture des risques/hypothèses et la porte qualité avant la synthèse finale. Tout le reste est facultatif et ajouté uniquement lorsque cela change matériellement le livrable. Voir references/generalized-lab-model.md pour le détail de l'adaptation.
Règles d'Exécution
- Sélectionnez le plus petit nombre de rôles spécialisés qui couvrent bien le brief.
- Incluez toujours l'analyse des preuves/contexte, la formulation du plan, l'exécution ou investigation, l'analyse des résultats et la couverture des risques/hypothèses.
- Privilégiez les véritables sous-agents parallèles. Ils constituent le modèle d'exécution principal de cette compétence, et non une amélioration facultative.
- À chaque phase, lancez tous les spécialistes indépendants avant d'attendre les résultats. N'exécutez pas les spécialistes indépendants un par un lorsque des sous-agents parallèles sont disponibles.
- Sinon, simulez les spécialistes sous forme de passes isolées. Chaque passe doit lire uniquement le brief, le plan d'orchestration et son périmètre assigné avant d'écrire son propre fichier.
- Ne fusionnez jamais l'analyse des spécialistes, la revue croisée, la revue par porte et la synthèse finale en une seule réponse.
- Parallélisez le travail des spécialistes indépendants, mais maintenez les dépendances séquentielles : analyse avant plan, plan avant exécution, exécution avant analyse des résultats, analyse avant rapport final.
- Exigez des citations ou des notes de source pour les affirmations factuelles lorsque des sources sont disponibles.
- Marquez les affirmations non étayées comme hypothèses ou inférences.
- Préservez l'incertitude et les limites de la revue dans les domaines réglementés.
Protocole de Collaboration d'Équipe
- Traitez les sous-agents comme une équipe collaborative, et non comme des rédacteurs de rapports déconnectés.
- L'orchestrateur maître définit les rôles de l'équipe, les responsabilités, les dépendances et les règles de collaboration dans
work/01-orchestration-plan.md. - Chaque sous-agent écrit uniquement son propre fichier de sortie spécialisé et transmet ses questions, dépendances, désaccords et notes de transmission à l'orchestrateur (dans son résultat, et non en modifiant un fichier partagé).
- L'orchestrateur consolide ces notes dans
work/03-team-collaboration.md. Ne demandez jamais à plusieurs sous-agents d'écrire le même fichier simultanément. - L'équipe doit concilier les hypothèses partagées avant la revue croisée.
- La revue croisée évalue à la fois les sorties des spécialistes et le registre de collaboration d'équipe.
- La synthèse finale doit refléter les accords résolus, les désaccords non résolus et les opinions minoritaires importantes.
Conditions d'Arrêt
Arrêtez-vous et demandez à l'utilisateur uniquement lorsque :
- Le sujet ou l'objectif n'est pas identifiable.
- Le livrable souhaité ne peut pas être déduit.
- Les contraintes clés sont en conflit.
- Des données externes, des identifiants, des systèmes privés, des outils payants ou un accès réseau indisponible bloquent le travail.
- Les conseils juridiques, médicaux, financiers, de conformité, de sécurité ou critiques ne peuvent pas être maintenus dans une limite informationnelle sûre.
Achèvement
Lorsque le workflow est terminé, indiquez à l'utilisateur quels fichiers ont été créés et si la porte a approuvé la synthèse finale. Gardez le message d'achèvement concis.