Persona agenti
Crea file di persona riutilizzabili che definiscono il ruolo, il focus e l'accesso ai tool di un subagent. Definisci cosa cerca un subagent, come formatta il suo output e cosa non può fare.
Le persona agenti sono file markdown che configurano il ruolo e il comportamento di un subagent avviato. Mentre un modo personalizzato determina come funziona il task principale, una persona determina come lavora un subagent ausiliario. Controlla l'identità, la checklist, il formato di output e i vincoli del subagent.
Come funzionano le persona
Quando Bob avvia un subagent, controlla in .bob/agents/ se esiste un file di persona la cui descrizione corrisponde al task. Se ne trova uno, la persona viene caricata come modo del subagent: il corpo del ruolo viene iniettato nel system prompt del subagent e si aggiunge alle sue istruzioni base.
Le persona non vengono caricate automaticamente nella conversazione principale. Hanno effetto solo quando viene avviato un subagent, sia su iniziativa di Bob sia quando chiedi a Bob di delegare un task specifico.
Formato del file di persona
I file di persona usano front matter YAML seguito da un corpo del ruolo in formato libero:
---
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.Campi del front matter
| Campo | Richiesto | Tipo | Scopo |
|---|---|---|---|
name | Sì | string | Identificatore usato nei log. Deve corrispondere al nome del file senza .md. |
description | Sì | string | Bob usa questo per abbinare la persona a un task. Scrivilo come una dichiarazione di missione su una riga. |
tools | No | list | Limita i gruppi di tool che il subagent può usare. Ometti per ereditare i valori predefiniti. |
Gruppi di tool
Il campo tools accetta gli stessi gruppi dei modi personalizzati: read, edit, command, browser, mcp.
Per le persona in sola lettura come revisori, pianificatori e riassuntori, imposta tools: [read] per evitare modifiche accidentali.
Il campo tools è un limite massimo, non una concessione. Impostare tools: [edit] su una persona non ha effetto se il task attivo non ha i permessi di modifica abilitati. Una persona può solo limitare l'accesso ai tool, mai estenderlo oltre quanto consentito dal task.
Posizione dei file
| Posizione | Ambito | Caso d'uso |
|---|---|---|
<progetto>/.bob/agents/ | Solo questo progetto | Persona condivise dal team e versionate nel repository |
~/.bob/agents/ | Tutti i progetti su questa macchina | Persona personali che si applicano a tutti i repository |
Se entrambe le posizioni contengono una persona con lo stesso nome, il file a livello di progetto ha la precedenza.
La directory .bob/ può contenere persona insieme alla tua altra configurazione:
Creare la prima persona
Crea la directory agents nella root del tuo progetto:
mkdir -p .bob/agentsCrea un file di persona. Il nome del file (senza .md) deve corrispondere al campo name nel front matter.
touch .bob/agents/code-reviewer.mdAggiungi il front matter e il corpo del ruolo. Consulta Formato del file di persona sopra per la struttura.
Versiona il file nel tuo repository in modo che il tuo team condivida le stesse persona.
Persona di esempio
code-reviewer.md
Esamina i file sorgente per correttezza, leggibilità e manutenibilità. Produce una tabella di risultati ordinata per gravità e non suggerisce correzioni.
---
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
Legge un insieme di file modificati e produce una descrizione strutturata di pull request che copre cosa è cambiato, l'intento probabile e le aree a cui il revisore deve prestare attenzione.
---
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.Usare una persona
Fai riferimento a una persona per nome quando chiedi a Bob di delegare un task:
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 caricherà la persona corrispondente da .bob/agents/ e la applicherà al subagent avviato.
Persona inline
Per un task occasionale, puoi descrivere il ruolo direttamente nel tuo prompt senza creare un file:
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.I ruoli inline funzionano altrettanto bene delle persona basate su file per un singolo task. I file di persona vale la pena crearli quando vuoi riutilizzare lo stesso ruolo su più task o condividerlo con il tuo team.
Passare la cronologia della conversazione
Per impostazione predefinita, un subagent riceve solo la descrizione del task. Non vede i turni precedenti della conversazione. Questo mantiene il suo contesto piccolo e focalizzato.
Quando un subagent deve rispettare decisioni o vincoli espressi in precedenza nella conversazione, formula il tuo prompt facendo riferimento al contesto precedente:
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 da frasi come "what we discussed" o "our earlier decision", e passa la cronologia della conversazione al subagent.
Passare la cronologia della conversazione copia l'intera conversazione nel context window del subagent. Su una conversazione lunga, questo aggiunge un costo in token significativo. Preferisci il comportamento predefinito (nessun contesto forkato) a meno che il subagent non abbia realmente bisogno del contesto precedente per svolgere il suo lavoro.
Persona, modi e regole
| Meccanismo | Ambito | Cosa controlla | Quando usarlo |
|---|---|---|---|
| Modo | Intero task | Limite di tool e definizione di ruolo per il task principale | Quando l'agente principale ha bisogno di una postura diversa, come sola lettura, scrittore di docs o revisore di sicurezza |
| Regola | Task o modo | Istruzioni permanenti caricate nel system prompt | Convenzioni del team, standard di formattazione, barriere che si applicano ogni volta |
| Persona | Un subagent | Ruolo, focus, formato di output e vincoli di tool per un subagent avviato | Quando un assistente ha bisogno di un focus di dominio: revisionare codice, riassumere modifiche, pianificare test |
Modalità personalizzate
Puoi creare modalità personalizzate per adattare il comportamento di Bob a task o flussi di lavoro specifici. Le modalità personalizzate in Bob Shell funzionano in modo simile alle modalità di Bob IDE.
Ignorare file
Controlla a quali file Bob Shell può accedere creando un file `.bobignore` nel tuo progetto.