Personas intégrées

CodeCourier définit dix types de personas intégrées. Ces types ne sont pas des personas pré-créées elles-mêmes mais plutôt des définitions de rôle que chaque persona doit utiliser. Lorsque vous créez une nouvelle persona, vous lui assignez l’un de ces types, qui détermine son icône, sa couleur, son outil et modèle par défaut, et son rôle au sein des persona pipelines.

Les types intégrés sont définis dans la configuration des étapes de workflow (convex/config/workflows.config.ts) et sont partagés sur toute la plateforme. Comprendre chaque type vous aide à créer des personas bien adaptées à leur rôle dans le processus de développement.

Designer

Le Designer est l’agent d’implémentation principal. Il reçoit un task prompt et écrit du code pour l’accomplir. Les designers travaillent directement dans le système de fichiers de la sandbox : créant des fichiers, installant des packages, configurant des outils de build, et exécutant le serveur de développement.

Quand l’utiliser : Toute tâche nécessitant l’écriture ou la modification de code. Implémentation de fonctionnalités, correction de bugs, changements de configuration, rédaction de documentation, et scripts de migration. Si le résultat est du code dans un repository, une persona Designer est le bon choix.

Cas d’usage : Implémentation de composants React, développement d’API REST, migrations de schéma de base de données, génération de fichiers de configuration, mise en place de pipeline de build.

Configuration recommandée :Utilisez le modèle le plus capable disponible (Opus) pour les tâches complexes. Réglez l’effort de réflexion sur “high” pour les changements architecturaux. Incluez des skills pertinents pour la stack technologique (par ex., frontend-design pour le travail UI, convex-implementation pour le travail de base de données). Liez un document de contexte couvrant l’architecture de votre codebase ou vos standards de code.

Checker

Le Checker est un agent de review basé sur un verdict qui évalue le travail effectué par une étape précédente (typiquement un Designer). Il lit les changements de code, exécute éventuellement des tests, et produit un verdict structuré : pass ou fail avec un feedback détaillé. Ce verdict binaire est ce qui distingue le Checker du type Reviewer.

Lorsqu’un Checker retourne un verdict fail, le workflow peut reboucler vers l’étape Designer pour une nouvelle itération, créant un cycle design-review automatisé qui améliore la qualité sans intervention humaine.

Quand l’utiliser : Après toute étape Designer où l’assurance qualité compte. Code reviews, vérification de types, vérification de tests, audits de sécurité, et vérifications de conformité.

Cas d’usage : Application de la type safety TypeScript, gates de couverture de tests, conformité aux politiques de sécurité, adhérence au style guide, vérifications de budget de performance.

Configuration recommandée : Un modèle plus rapide (Sonnet) est souvent suffisant puisque la tâche du Checker est plus ciblée que celle du Designer. Les instructions doivent définir des critères pass/fail explicites - le checker ne doit jamais être ambigu quant à son verdict. Incluez le skill app-security si la revue de sécurité fait partie de la vérification.

Optimizer

L’Optimizer est un spécialiste du refactoring. Il prend du code qui fonctionne déjà et l’améliore : réduisant la duplication, améliorant les performances, augmentant la lisibilité, et appliquant les best practices. L’Optimizer n’ajoute pas de nouvelles fonctionnalités ; il améliore les existantes.

Quand l’utiliser : Comme étape de post-traitement après qu’un Designer a terminé l’implémentation. Particulièrement précieux pour les gros changements de code où le Designer s’est concentré sur le fonctionnement et l’Optimizer polit le résultat.

Cas d’usage : Élimination des patterns de requêtes N+1, réduction des re-renders React, extraction de hooks réutilisables, normalisation de la gestion d’erreurs, amélioration de la taille du bundle.

Configuration recommandée : Utilisez Opus pour sa capacité à comprendre des codebases complexes. Les instructions doivent indiquer explicitement ce qui ne doit PAS être changé (APIs publiques, exports) pour éviter les breaking changes pendant l’optimisation. Incluez le skill performance-optimization-addyosmani pour le travail axé sur la performance.

Prompter

Le Prompter est un agent de prompt engineering. Il prend une demande informelle, potentiellement vague, de l’utilisateur et la réécrit en une spécification claire et structurée avec des critères d’acceptation explicites. Le prompt affiné est ensuite transmis à l’étape suivante du pipeline.

Quand l’utiliser : Comme première étape d’un pipeline lorsque les demandes utilisateur sont susceptibles d’être sous-spécifiées. Particulièrement précieux pour les équipes où des parties prenantes non techniques soumettent des demandes de fonctionnalités qui nécessitent une traduction en spécifications techniques.

Cas d’usage : Traduction des exigences produit en specs techniques, expansion de courtes descriptions de tâches en guides d’implémentation détaillés, génération de critères d’acceptation à partir de user stories.

Configuration recommandée :Sonnet est généralement suffisant pour l’affinage de prompts. Les instructions doivent spécifier le format de sortie (par ex., “toujours inclure les critères d’acceptation sous forme de liste numérotée et identifier explicitement les fichiers affectés”).

Investigator

L’Investigator est un agent de recherche qui analyse la codebase avant que l’implémentation ne commence. Il lit des fichiers, trace des dépendances, cartographie l’architecture, et produit un résumé structuré des constats. Ce contexte aide les agents suivants à prendre de meilleures décisions.

Quand l’utiliser : Avant une étape Designer sur des codebases inconnues, des investigations de bugs ciblées, ou lorsque la tâche nécessite de comprendre comment fonctionne un sous-système spécifique. L’Investigator cible une zone particulière de la codebase et en rend compte de manière concise.

Cas d’usage : Comprendre un sous-système d’authentification avant d’ajouter un nouveau fournisseur OAuth, tracer un flux de données spécifique avant de le refactoriser, identifier les fichiers qui seront affectés par un changement proposé.

Configuration recommandée :Utilisez Opus pour sa compréhension supérieure de la codebase. Réglez l’effort de réflexion sur “high”. Les instructions doivent spécifier ce qu’il faut investiguer (par ex., “concentrez-vous sur les requêtes de base de données et les routes API liées à l’authentification”). Pour une analyse transversale complète, préférez plutôt le type Deep-Dive.

Planner

Le Planner est un agent d’architecture qui analyse les codebases et crée des évaluations structurées. Il examine le repository, comprend les exigences, et décompose le travail en items exploitables. Chaque item a un nom, une description, et un prompt détaillé. Ce type alimente la fonctionnalité d’issue sessions de CodeCourier.

Quand l’utiliser : Pour des projets complexes et multi-étapes qui bénéficient d’une analyse en amont. La sortie du Planner peut être directement exécutée par le système de work chain de CodeCourier.

Cas d’usage : Décomposer une grande demande de fonctionnalité en issues distinctes, identifier la dette technique à travers la codebase, produire une liste priorisée d’améliorations, générer des backlogs d’issues pour la planification de sprint.

Configuration recommandée : Utilisez toujours Opus avec un effort de réflexion élevé. Le Planner a besoin d’une capacité de reasoning maximale pour décomposer efficacement des projets complexes. Liez un document de contexte d’architecture pour de meilleurs résultats.

Deep-Dive

Le Deep-Dive est un agent d’analyse intensive conçu pour des problèmes complexes et multidimensionnels qui nécessitent une compréhension exhaustive de la codebase. Il est similaire à l’Investigator mais opère à une portée plus large - plutôt que de se concentrer sur un sous-système, il explore les préoccupations transversales, trace les interactions entre plusieurs systèmes, et produit un rapport d’analyse exhaustif.

Les sessions Deep-Dive s’exécutent typiquement plus longtemps et avec un effort de réflexion plus élevé que les sessions Investigator. La sortie est plus approfondie : pas seulement “voici comment fonctionne ce sous-système” mais “voici comment tous les systèmes pertinents interagissent, où les frontières sont ambiguës, à quoi ressemble la surface de risque, et quelles décisions architecturales ont mené à l’état actuel.”

Quand l’utiliser : Analyse architecturale avant un refactor majeur, investigation de cause racine pour un incident de production complexe, comprendre une codebase legacy avant l’onboarding d’une nouvelle équipe, ou toute tâche d’analyse où la profondeur compte plus que la vitesse.

Cas d’usage : Évaluation architecturale pré-migration, threat modeling de sécurité sur toute une application, analyse de dépendances avant la mise à niveau d’une bibliothèque majeure, tracer un flux de données qui s’étend sur plusieurs services et bases de données.

Configuration recommandée : Utilisez toujours Opus avec un effort de réflexion max ou xhigh. Budgétez pour un temps d’exécution sandbox plus long (augmentez le timeout). Incluez des skills larges : app-security, performance-optimization-addyosmani, superpower-debugging. Liez un document de contexte qui fournit un contexte architectural au niveau du projet pour que l’agent puisse se concentrer sur la profondeur plutôt que sur l’orientation.

Reviewer

Le Reviewer est un agent de code review spécialisé axé sur la sécurité, la maintenabilité, les design patterns, et la qualité du code. Il est fondamentalement différent du Checker sur un point crucial : le Reviewer ne produit pas de verdicts pass/fail. Il produit à la place un feedback de review détaillé et nuancé - observations, suggestions, préoccupations, et félicitations - sur lequel un développeur humain ou un agent suivant peut agir.

Cela rend le Reviewer idéal pour les situations où un gate binaire est trop brutal. Un Checker pourrait rejeter du code à cause d’un problème mineur qui échoue à un critère strict ; un Reviewer noterait le même problème comme une “préoccupation mineure” tout en reconnaissant que l’implémentation est fondamentalement solide.

Quand l’utiliser : Code reviews pré-merge devant éclairer une décision humaine, revue architecturale d’une conception proposée, revue de sécurité produisant une évaluation de risque plutôt qu’un blocage, ou tout scénario de revue où un feedback qualitatif est plus précieux qu’un verdict binaire.

Cas d’usage : Commentaires de review de pull request, évaluation du risque de sécurité pour une nouvelle surface d’API, audit de conformité des design patterns, revue d’accessibilité pour une bibliothèque de composants UI.

Configuration recommandée :Utilisez Opus pour un reasoning nuancé. Réglez l’effort de réflexion sur “high”. Les instructions doivent définir explicitement le format de sortie (par ex., des sections pour Forces, Préoccupations majeures, Préoccupations mineures, Suggestions). Incluez les skills app-security et superpower-codereview. Le Reviewer ne devrait pas être placé dans une boucle - son objectif est de produire une revue complète unique, pas de gate-loop.

Custom

Le type Custom est un type de persona libre pour les agents qui ne correspondent à aucune des neuf catégories standard. Il n’impose aucune attente structurelle sur le comportement de l’agent - celui-ci se comporte exactement comme le dictent ses instructions, skills, contexte, commands et scripts. Le type Custom offre une flexibilité maximale pour des rôles spécialisés et non standard.

Quand l’utiliser : Lorsqu’aucun des neuf types intégrés ne décrit précisément ce que fait la persona. Les personas Custom remplissent souvent des rôles uniques spécifiques au workflow d’un projet plutôt que des étapes de développement générales.

Cas d’usage :

• Rédacteur de documentation - Génère ou met à jour JSDoc, fichiers README, documentation API, et commentaires de code inline.
• Générateur de changelog - Lit la sortie de git diff et produit des entrées de changelog lisibles par un humain dans un format spécifié.
• Assistant de migration - Applique systématiquement un pattern de migration de base de données ou d’API spécifique sur plusieurs fichiers.
• Auditeur de dépendances - Scanne package.json à la recherche de dépendances obsolètes ou vulnérables et produit un plan de mise à niveau.
• Agent de localisation - Extrait les chaînes codées en dur et remplit les fichiers de ressources i18n.
• Résumeur de PR - Lit un git diff et rédige une description de pull request structurée.

Configuration recommandée : Comme le type Custom n’a pas de rôle prédéfini, la qualité de la persona dépend presque entièrement de la qualité de ses instructions. Écrivez des instructions hautement spécifiques et structurées qui ne laissent rien d’ambigu. Choisissez le modèle en fonction de la complexité de la tâche - les tâches simples de transformation de texte peuvent utiliser Sonnet, tandis que les tâches complexes de reasoning multi-fichiers devraient utiliser Opus.

Résumé de sélection des types

Étapes suivantes