Custom subagent — це версіонований workflow

Кастомний subagent зберігає повторювані правила роботи в Markdown-файлі. Проєктна команда може переглядати його в Git, обговорювати зміни та перевіряти, чи не розширилися його дозволи непомітно.

Файл описує роль і контракт, але не робить результат автоматично правильним. Його scope, інструменти й інструкції мають відповідати реальній задачі.

РозташуванняОбласть діїТиповий випадок
~/.claude/agents/Особисте середовищеВаш універсальний помічник між проєктами
.claude/agents/Конкретний проєктКомандний reviewer із правилами репозиторію
Plugin-providedПакет розширенняПовторно доставлений workflow
ManagedЦентралізована конфігураціяОрганізаційно керовані правила

Мінімальна структура файлу

Концептуальний frontmatter; звіряйте синтаксис із /help
---
name: reviewer
description: Read-only reviewer for prepared diffs.
tools: [read, grep, diff]
---

## Роль
Перевіряй готовий diff у визначеній області.

## Заборони
Не редагуй код і не розширюй scope без рішення власника.

## Результат
Поверни findings із severity, file:line, evidence і confidence.

Description — це маршрутизатор використання

Опис має пояснювати, яку роль виконує subagent, коли його викликати та що він не робить. Надто загальний опис провокує неправильне делегування, а відсутність заборон перетворює read-only роль на нечітке доручення.

Для проєктного reviewer корисно прямо вказати: вхід — підготовлений diff; область — визначені файли; результат — структурований звіт; запис — заборонений.

Кроки створення і перевірки

  1. Виберіть scope, який відповідає аудиторії ролі.
  2. Створіть .claude/agents/reviewer.md у проєктному випадку.
  3. Опишіть роль, умови використання, дозволені дії та stop conditions.
  4. Обмежте інструменти найменшим потрібним набором.
  5. Запустіть subagent на безпечному prepared diff.
  6. Перевірте, що він повертає докази й не вносить змін.
  7. Збережіть файл у Git і переглядайте його як інженерний артефакт.

Не плутайте файл ролі з дозволом на все

  • Markdown-інструкція не замінює permissions і підтвердження.
  • Наявність shell або write-інструмента збільшує capability surface.
  • Кастомний subagent не повинен самостійно переходити від review до implementation.
  • Усе version-sensitive звіряйте з поточною CLI-документацією.

Канонічне джерело уроку · JavaRush

Відкрити матеріал JavaRush