Personas de agentes
Crea archivos de persona reutilizables que definen el rol, el enfoque y el acceso a tools de un subagent. Define en qué se fija un subagent, cómo formatea su salida y qué no puede hacer.
Las personas de agentes son archivos markdown que configuran el rol y el comportamiento de un subagent lanzado. Mientras que un modo personalizado determina cómo funciona la tarea principal, una persona determina cómo trabaja un subagent auxiliar. Controla la identidad, la lista de verificación, el formato de salida y las restricciones del subagent.
Cómo funcionan las personas
Cuando Bob lanza un subagent, busca en .bob/agents/ un archivo de persona cuya descripción coincida con la tarea. Si encuentra uno, carga la persona como el modo del subagent: el cuerpo del rol se inyecta en el system prompt del subagent y se superpone a sus instrucciones base.
Las personas no se cargan automáticamente en la conversación principal. Solo tienen efecto cuando se lanza un subagent, ya sea por iniciativa propia de Bob o cuando le pides a Bob que delegue una tarea específica.
Formato del archivo de persona
Los archivos de persona usan front matter YAML seguido de un cuerpo de rol de formato 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.Campos del front matter
| Campo | Requerido | Tipo | Propósito |
|---|---|---|---|
name | Sí | string | Identificador en los logs. Debe coincidir con el nombre del archivo sin .md. |
description | Sí | string | Bob usa esto para asociar la persona con una tarea. Escríbelo como una declaración de misión de una línea. |
tools | No | list | Restringe qué grupos de tools puede usar el subagent. Omitir para heredar los valores predeterminados. |
Grupos de tools
El campo tools acepta los mismos grupos que los modos personalizados: read, edit, command, browser, mcp.
Para personas de solo lectura como revisores, planificadores y resumidores, establece tools: [read] para evitar ediciones accidentales.
El campo tools es un límite máximo, no una concesión. Establecer tools: [edit] en una persona no tiene efecto si la tarea activa no tiene permisos de edición habilitados. Una persona solo puede restringir el acceso a tools, nunca ampliarlo más allá de lo que permite la tarea.
Ubicación de archivos
| Ubicación | Alcance | Caso de uso |
|---|---|---|
<proyecto>/.bob/agents/ | Solo este proyecto | Personas compartidas por el equipo incorporadas al repositorio |
~/.bob/agents/ | Todos los proyectos en este equipo | Personas personales que aplican en todos los repositorios |
Si ambas ubicaciones contienen una persona con el mismo nombre, el archivo a nivel de proyecto tiene prioridad.
El directorio .bob/ puede contener personas junto con el resto de tu configuración:
Crear tu primera persona
Crea el directorio de agentes en la raíz de tu proyecto:
mkdir -p .bob/agentsCrea un archivo de persona. El nombre del archivo (sin .md) debe coincidir con el campo name en el front matter.
touch .bob/agents/code-reviewer.mdAñade el front matter y el cuerpo del rol. Consulta Formato del archivo de persona arriba para ver la estructura.
Incorpora el archivo a tu repositorio para que tu equipo comparta las mismas personas.
Personas de ejemplo
code-reviewer.md
Revisa archivos fuente en busca de corrección, legibilidad y mantenibilidad. Produce una tabla de hallazgos ordenada por gravedad y no sugiere correcciones.
---
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
Lee un conjunto de archivos modificados y produce una descripción estructurada de pull request que cubre qué cambió, la intención probable y las áreas a las que el revisor debe prestar atención.
---
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.Usar una persona
Haz referencia a una persona por nombre cuando le pidas a Bob que delegue una tarea:
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 cargará la persona correspondiente desde .bob/agents/ y la aplicará al subagent lanzado.
Personas en línea
Para una tarea de una sola vez, puedes describir el rol directamente en tu prompt sin crear un archivo:
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.Los roles en línea funcionan igual de bien que las personas basadas en archivos para una sola tarea. Los archivos de persona valen la pena cuando quieres reutilizar el mismo rol en múltiples tareas o compartirlo con tu equipo.
Pasar el historial de conversación
Por defecto, un subagent solo recibe la descripción de la tarea. No ve tus turnos de conversación anteriores. Esto mantiene su contexto pequeño y enfocado.
Cuando un subagent necesita respetar decisiones o restricciones anteriores de la conversación, formula tu prompt haciendo referencia al contexto previo:
Use the code-reviewer persona to review src/payments/.
Take into account what we discussed about the error handling approach.Bob deduce fork_context: true a partir de frases como "what we discussed" o "our earlier decision", y pasa el historial de conversación al subagent.
Pasar el historial de conversación copia toda tu conversación en el context window del subagent. En una conversación larga, esto añade un coste de tokens significativo. Prefiere el comportamiento predeterminado (sin contexto bifurcado) a menos que el subagent realmente necesite el contexto previo para hacer su trabajo.
Personas, modos y reglas
| Mecanismo | Alcance | Qué controla | Cuándo usar |
|---|---|---|---|
| Modo | Toda la tarea | Límite de tools y definición de rol para la tarea principal | Cuando el agente principal necesita una postura diferente, como solo lectura, escritor de docs o revisor de seguridad |
| Regla | Tarea o modo | Instrucciones permanentes cargadas en el system prompt | Convenciones del equipo, estándares de formato, barreras que aplican en todo momento |
| Persona | Un subagent | Rol, enfoque, formato de salida y restricciones de tools para un subagent lanzado | Cuando un asistente necesita enfoque de dominio: revisar código, resumir cambios, planificar pruebas |
Modos personalizados
Puedes crear modos personalizados para adaptar el comportamiento de Bob a tareas o flujos de trabajo específicos. Los modos personalizados en Bob Shell funcionan de manera similar a los modos de Bob IDE.
Ignorar archivos
Controla a qué archivos puede acceder Bob Shell creando un archivo `.bobignore` en tu proyecto.