Personas d'agents
Crée des fichiers de persona réutilisables qui définissent le rôle, le focus et l'accès aux tools d'un subagent. Définis ce qu'un subagent recherche, comment il formate ses résultats et ce qu'il n'est pas autorisé à faire.
Les personas d'agents sont des fichiers markdown qui configurent le rôle et le comportement d'un subagent lancé. Alors qu'un mode personnalisé détermine comment fonctionne la tâche principale, une persona détermine comment travaille un subagent auxiliaire. Elle contrôle l'identité, la liste de vérification, le format de sortie et les contraintes du subagent.
Comment fonctionnent les personas
Quand Bob lance un subagent, il vérifie dans .bob/agents/ s'il existe un fichier de persona dont la description correspond à la tâche. Si un fichier est trouvé, la persona est chargée en tant que mode du subagent : le corps du rôle est injecté dans le system prompt du subagent et s'ajoute à ses instructions de base.
Les personas ne sont pas chargées automatiquement dans la conversation principale. Elles ne prennent effet que lorsqu'un subagent est lancé, soit à l'initiative de Bob, soit quand tu demandes à Bob de déléguer une tâche spécifique.
Format du fichier de persona
Les fichiers de persona utilisent un front matter YAML suivi d'un corps de rôle libre :
---
name: code-reviewer
description: Reviews code for correctness, readability, and maintainability. Read-only.
tools:
- read
---
You are a senior software engineer conducting a structured code review.
Review each file against this checklist:
1. Correctness: logic errors, missing null checks, unhandled edge cases
2. Readability: long methods, deep nesting, unclear naming
3. Maintainability: tight coupling, missing abstraction, duplicated logic
Report findings in a table with columns: Severity, File, Lines, Description.
Use severity levels: HIGH, MEDIUM, LOW.
Do not suggest fixes. Describe issues only.Champs du front matter
| Champ | Requis | Type | Rôle |
|---|---|---|---|
name | Oui | string | Identifiant utilisé dans les logs. Doit correspondre au nom de fichier sans .md. |
description | Oui | string | Bob utilise ceci pour associer la persona à une tâche. Rédige-le comme une déclaration de mission en une ligne. |
tools | Non | list | Limite les groupes de tools que le subagent peut utiliser. Omettre pour hériter des valeurs par défaut. |
Groupes de tools
Le champ tools accepte les mêmes groupes que les modes personnalisés : read, edit, command, browser, mcp.
Pour les personas en lecture seule comme les réviseurs, planificateurs et résumeurs, définis tools: [read] pour éviter les modifications accidentelles.
Le champ tools est un plafond, pas une autorisation. Définir tools: [edit] sur une persona n'a aucun effet si la tâche active n'a pas les permissions d'édition activées. Une persona peut uniquement restreindre l'accès aux tools, jamais l'étendre au-delà de ce que la tâche autorise.
Emplacement des fichiers
| Emplacement | Portée | Cas d'utilisation |
|---|---|---|
<projet>/.bob/agents/ | Ce projet uniquement | Personas partagées par l'équipe et versionnées dans le dépôt |
~/.bob/agents/ | Tous les projets sur cette machine | Personas personnelles qui s'appliquent à tous les dépôts |
Si les deux emplacements contiennent une persona portant le même nom, le fichier au niveau du projet a la priorité.
Ton répertoire .bob/ peut contenir des personas aux côtés de ta configuration existante :
Créer ta première persona
Crée le répertoire agents à la racine de ton projet :
mkdir -p .bob/agentsCrée un fichier de persona. Le nom du fichier (sans .md) doit correspondre au champ name dans le front matter.
touch .bob/agents/code-reviewer.mdAjoute le front matter et le corps du rôle. Consulte Format du fichier de persona ci-dessus pour la structure.
Versionne le fichier dans ton dépôt pour que ton équipe partage les mêmes personas.
Exemples de personas
code-reviewer.md
Examine les fichiers sources pour en vérifier la correction, la lisibilité et la maintenabilité. Produit un tableau de résultats classé par gravité et ne suggère pas de corrections.
---
name: code-reviewer
description: Reviews code for correctness, readability, and maintainability. Read-only.
tools:
- read
---
You are a senior software engineer conducting a structured code review.
Review each file against this checklist:
1. Correctness: logic errors, missing null checks, unhandled edge cases
2. Readability: long methods, deep nesting, unclear naming
3. Maintainability: tight coupling, missing abstraction, duplicated logic
Report findings in a table with columns: Severity, File, Lines, Description.
Use severity levels: HIGH, MEDIUM, LOW.
Do not suggest fixes. Describe issues only.
If a file has no findings, list it explicitly as clean.pr-summarizer.md
Lit un ensemble de fichiers modifiés et produit une description structurée de pull request couvrant ce qui a changé, l'intention probable et les zones auxquelles le réviseur doit prêter attention.
---
name: pr-summarizer
description: Reads changed files and produces a structured pull request description. Read-only.
tools:
- read
---
You are a developer writing a pull request description for a teammate.
Read the provided files and produce a PR description with these sections:
**Summary**: One or two sentences describing what this change does.
**Why**: The likely motivation, inferred from the code changes.
**What changed**: A bullet list of the key changes, grouped by area if there are several.
**Reviewer notes**: Anything the reviewer should pay particular attention to, including edge cases, intentional trade-offs, or areas of uncertainty.
Write in plain, direct language. Do not pad the description.
Do not list every file changed. Focus on what matters to the reviewer.Utiliser une persona
Fais référence à une persona par son nom lorsque tu demandes à Bob de déléguer une tâche :
Use the code-reviewer persona to review the files in src/auth/.Spawn a subagent using the pr-summarizer persona.
Read the changed files in this branch and produce a PR description.Bob chargera la persona correspondante depuis .bob/agents/ et l'appliquera au subagent lancé.
Personas en ligne
Pour une tâche ponctuelle, tu peux décrire le rôle directement dans ton prompt sans créer de fichier :
Spawn an Explore subagent with this role:
You are a naming auditor. Read all files under src/ and flag variable and
function names that use abbreviations or are misleading. Return a table:
File, Line, Current Name, Issue.Les rôles en ligne fonctionnent aussi bien que les personas basées sur des fichiers pour une seule tâche. Les fichiers de persona valent la peine d'être créés quand tu veux réutiliser le même rôle sur plusieurs tâches ou le partager avec ton équipe.
Passer l'historique de conversation
Par défaut, un subagent ne reçoit que la description de la tâche. Il ne voit pas tes tours de conversation précédents. Cela maintient son contexte petit et focalisé.
Quand un subagent doit respecter des décisions ou des contraintes exprimées plus tôt dans la conversation, formule ton prompt en faisant référence au contexte antérieur :
Use the code-reviewer persona to review src/payments/.
Take into account what we discussed about the error handling approach.Bob déduit fork_context: true à partir de formulations comme "what we discussed" ou "our earlier decision", et passe l'historique de conversation au subagent.
Passer l'historique de conversation copie toute ta conversation dans le context window du subagent. Sur une longue conversation, cela ajoute un coût en tokens significatif. Préfère le comportement par défaut (pas de contexte forké) sauf si le subagent a vraiment besoin du contexte antérieur pour faire son travail.
Personas, modes et règles
| Mécanisme | Portée | Ce qu'il contrôle | Quand l'utiliser |
|---|---|---|---|
| Mode | Tâche entière | Plafond de tools et définition de rôle pour la tâche principale | Quand l'agent principal a besoin d'une posture différente, comme lecture seule, rédacteur de docs ou réviseur de sécurité |
| Règle | Tâche ou mode | Instructions permanentes chargées dans le system prompt | Conventions d'équipe, standards de formatage, garde-fous qui s'appliquent à chaque fois |
| Persona | Un subagent | Rôle, focus, format de sortie et contraintes de tools pour un subagent lancé | Quand un assistant a besoin d'un focus de domaine : réviser du code, résumer des modifications, planifier des tests |
Modes personnalisés
Tu peux créer des modes personnalisés pour adapter le comportement de Bob à des tâches ou workflows spécifiques. Les modes personnalisés dans Bob Shell fonctionnent de façon similaire aux modes Bob IDE.
Ignorer des fichiers
Contrôle les fichiers auxquels Bob Shell peut accéder en créant un fichier `.bobignore` dans ton projet.