Twórz wielokrotnego użytku pliki person, które definiują rolę, fokus i dostęp do tooli subagenta. Określ, czego szuka subagent, jak formatuje wyniki i czego nie może robić.

Persony agentów to pliki markdown konfigurujące rolę i zachowanie zainicjowanego subagenta. Podczas gdy tryb niestandardowy określa sposób działania głównego zadania, persona określa sposób działania pomocniczego subagenta. Kontroluje tożsamość, listę kontrolną, format wyjścia i ograniczenia subagenta.

Jak działają persony

Gdy Bob inicjuje subagenta, sprawdza w .bob/agents/ plik persony, którego opis pasuje do zadania. Jeśli zostanie znaleziony, persona jest ładowana jako tryb subagenta: treść roli jest wstrzykiwana do system promptu subagenta i nakłada się na jego podstawowe instrukcje.

Persony nie są ładowane automatycznie do głównej rozmowy. Działają tylko wtedy, gdy subagent zostaje zainicjowany — z własnej inicjatywy Boba lub gdy prosisz Boba o delegowanie konkretnego zadania.

Format pliku persony

Pliki person używają front matter YAML, a następnie treści roli w dowolnym formacie:

---
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.

Pola front matter

Pole	Wymagane	Typ	Cel
`name`	Tak	string	Identyfikator używany w logach. Powinien odpowiadać nazwie pliku bez `.md`.
`description`	Tak	string	Bob używa tego do dopasowania persony do zadania. Napisz jako jednolinijkowe oświadczenie misji.
`tools`	Nie	list	Ogranicza grupy tooli, których może używać subagent. Pomiń, aby odziedziczyć ustawienia domyślne.

Grupy tooli

Pole tools akceptuje te same grupy co tryby niestandardowe: read, edit, command, browser, mcp.

Dla person tylko do odczytu, takich jak recenzenci, planiści i twórcy podsumowań, ustaw tools: [read], aby zapobiec przypadkowym edycjom.

Pole tools jest limitem górnym, a nie przyznaniem uprawnień. Ustawienie tools: [edit] w personie nie ma efektu, jeśli aktywne zadanie nie ma włączonych uprawnień do edycji. Persona może jedynie ograniczać dostęp do tooli, nigdy go nie rozszerzać poza to, co pozwala zadanie.

Lokalizacja plików

Lokalizacja	Zakres	Przypadek użycia
`<projekt>/.bob/agents/`	Tylko ten projekt	Persony współdzielone przez zespół, zatwierdzone do repozytorium
`~/.bob/agents/`	Wszystkie projekty na tej maszynie	Osobiste persony stosowane we wszystkich repozytoriach

Jeśli obie lokalizacje zawierają personę o tej samej nazwie, pierwszeństwo ma plik na poziomie projektu.

Katalog .bob/ może zawierać persony obok reszty konfiguracji:

code-reviewer.md

pr-summarizer.md

custom_modes.yaml

Tworzenie pierwszej persony

Utwórz katalog agents w katalogu głównym projektu:

mkdir -p .bob/agents

Utwórz plik persony. Nazwa pliku (bez .md) powinna odpowiadać polu name we front matter.

touch .bob/agents/code-reviewer.md

Dodaj front matter i treść roli. Struktura opisana jest powyżej w Format pliku persony.

Zatwierdź plik do repozytorium, aby zespół współdzielił te same persony.

Przykładowe persony

code-reviewer.md

Sprawdza pliki źródłowe pod kątem poprawności, czytelności i możliwości utrzymania. Tworzy tabelę wyników posortowaną według wagi i nie sugeruje poprawek.

---
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

Odczytuje zestaw zmienionych plików i tworzy ustrukturyzowany opis pull requesta obejmujący to, co się zmieniło, prawdopodobny cel i obszary, na które recenzent powinien zwrócić uwagę.

---
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.

Używanie persony

Odwołaj się do persony po nazwie, gdy prosisz Boba o delegowanie zadania:

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 załaduje pasującą personę z .bob/agents/ i zastosuje ją do zainicjowanego subagenta.

Persony inline

W przypadku jednorazowego zadania możesz opisać rolę bezpośrednio w swoim prompcie bez tworzenia pliku:

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.

Role inline działają równie dobrze jak persony oparte na plikach dla pojedynczego zadania. Pliki person warto tworzyć, gdy chcesz wielokrotnie używać tej samej roli w wielu zadaniach lub udostępniać ją zespołowi.

Przekazywanie historii rozmowy

Domyślnie subagent otrzymuje tylko opis zadania. Nie widzi poprzednich tur rozmowy. Dzięki temu jego kontekst jest mały i skupiony.

Gdy subagent musi uwzględniać wcześniejsze decyzje lub ograniczenia z rozmowy, sformułuj prompt z odwołaniem do poprzedniego kontekstu:

Use the code-reviewer persona to review src/payments/.
Take into account what we discussed about the error handling approach.

Bob wnioskuje fork_context: true z fraz takich jak "what we discussed" lub "our earlier decision" i przekazuje historię rozmowy do subagenta.

Uwaga:

Przekazanie historii rozmowy kopiuje całą rozmowę do context window subagenta. W przypadku długiej rozmowy dodaje to znaczący koszt tokenów. Preferuj ustawienie domyślne (brak sforkowanego kontekstu), chyba że subagent naprawdę potrzebuje poprzedniego kontekstu do wykonania swojej pracy.

Persony, tryby i reguły

Mechanizm	Zakres	Co kontroluje	Kiedy używać
Tryb	Całe zadanie	Limit tooli i definicja roli dla głównego zadania	Gdy główny agent potrzebuje innej postawy, np. tylko do odczytu, pisarz dokumentacji lub recenzent bezpieczeństwa
Reguła	Zadanie lub tryb	Stałe instrukcje ładowane do system promptu	Konwencje zespołu, standardy formatowania, zabezpieczenia stosowane za każdym razem
Persona	Jeden subagent	Rola, fokus, format wyjścia i ograniczenia tooli dla zainicjowanego subagenta	Gdy pomocnik potrzebuje skupienia na domenie: recenzowanie kodu, podsumowywanie zmian, planowanie testów

Persony agentów

Na tej stronie