Создание агентов для плагинов Claude Code
Объясняет, как написать автономного агента: структуру файла, условия срабатывания, системный промт, модель, цвет и инструменты.
- Что делает
- Объясняет, как написать автономного агента: структуру файла, условия срабатывания, системный промт, модель, цвет и инструменты.
- Когда брать
- Когда нужно создать или улучшить агента (субагента) для плагина Claude Code и добиться, чтобы он срабатывал вовремя.
- Когда не брать
- Если нужна не автономная работа, а команда для действий пользователя, — для этого есть скилл command-development.
- Пример запроса
- Создай агента для плагина, который проверяет код на уязвимости и срабатывает после каждого крупного изменения.
- Нужно подключить
- Claude Code
Входит в плагин plugin-dev. В Cowork и Claude Code можно поставить плагин целиком.
Как включить
- Скачайте архив и распакуйте его.
- Положите папку
agent-developmentв~/.claude/skills/. - Откройте Claude Code и опишите задачу своими словами: Claude подхватит скилл по описанию.
Текст
---
name: agent-development
description: Этот скилл следует использовать, когда пользователь просит «создать агента», «добавить агента», «написать субагента», спрашивает про «шапку агента (frontmatter)», «поле description: когда использовать», «примеры для агента», «инструменты агента», «цвета агентов», «автономного агента» или нуждается в рекомендациях по структуре агентов, системным промтам, условиям срабатывания и лучшим практикам разработки агентов для плагинов Claude Code.
version: 0.1.0
---
Разработка агентов для плагинов Claude Code
Обзор
Агенты — это автономные подпроцессы, которые самостоятельно выполняют сложные многошаговые задачи. Понимание структуры агента, условий его срабатывания и устройства системного промта позволяет создавать мощные автономные возможности.
Ключевые понятия:
- Агенты предназначены для автономной работы, команды — для действий по инициативе пользователя
- Формат файла — Markdown с YAML-шапкой (frontmatter)
- Срабатывание задаётся полем description с примерами
- Системный промт определяет поведение агента
- Настраиваются модель и цвет
Структура файла агента
Полный формат
---
name: agent-identifier
description: Используй этого агента, когда [условия срабатывания]. Типичные триггеры: [сценарий 1 прозой], [сценарий 2 прозой] и [сценарий 3 прозой]. Разобранные сценарии см. в разделе «Когда вызывать» в теле агента.
model: inherit
color: blue
tools: ["Read", "Write", "Grep"]
---
Ты — [описание роли агента]...
## Когда вызывать
[От двух до четырёх характерных сценариев, написанных прозой, например:]
- **[Название сценария].** [Как выглядит ситуация и что должен делать агент.]
- **[Название сценария].** [То же.]
**Твои основные обязанности:**
1. [Обязанность 1]
2. [Обязанность 2]
**Процесс анализа:**
[Пошаговый порядок работы]
**Формат результата:**
[Что вернуть]
Поля шапки
name (обязательное)
Идентификатор агента, по которому его вызывают и по которому строятся пространства имён.
Формат: только строчные латинские буквы, цифры и дефисы Длина: 3–50 символов Правило: должен начинаться и заканчиваться буквой или цифрой
Хорошие примеры:
code-reviewertest-generatorapi-docs-writersecurity-analyzer
Плохие примеры:
helper(слишком общее)-agent-(начинается и заканчивается дефисом)my_agent(подчёркивания не допускаются)ag(слишком коротко, < 3 символов)
description (обязательное)
Определяет, когда Claude должен запускать этого агента. Это самое важное поле: оно загружается в контекст всякий раз, когда агент зарегистрирован, чтобы среда выполнения (harness) могла решить, когда его вызывать.
Должно содержать:
- Условия срабатывания («Используй этого агента, когда…»)
- Краткое описание прозой типичных сценариев срабатывания
- Указание на раздел «Когда вызывать» в теле агента, где подробно разобраны сценарии
Формат:
Используй этого агента, когда [условия]. Типичные триггеры: [сценарий 1 прозой], [сценарий 2 прозой] и [сценарий 3 прозой]. Разобранные сценарии см. в разделе «Когда вызывать» в теле агента.
Лучшие практики:
- Назови в кратком описании 2–4 сценария срабатывания
- Охвати и проактивный запуск (ассистент вызывает сам), и реактивный (по просьбе пользователя)
- Охвати разные формулировки одного и того же намерения
- Точно укажи, когда агента НЕ следует использовать
- Подробные сценарии положи в тело, в раздел «Когда вызывать», маркированным списком с описаниями прозой
model (обязательное)
Какую модель должен использовать агент.
Варианты:
inherit— та же модель, что у родителя (рекомендуется)sonnet— Claude Sonnet (сбалансированная)opus— Claude Opus (самая мощная, дорогая)haiku— Claude Haiku (быстрая, дешёвая)
Рекомендация: используй inherit, если агенту не нужны возможности конкретной модели.
color (обязательное)
Визуальный идентификатор агента в интерфейсе.
Варианты: blue, cyan, green, yellow, magenta, red
Рекомендации:
- Выбирай разные цвета для разных агентов одного плагина
- Используй одинаковые цвета для однотипных агентов
- Синий/голубой: анализ, проверка
- Зелёный: задачи, нацеленные на успешный результат
- Жёлтый: осторожность, валидация
- Красный: критичное, безопасность
- Пурпурный: творчество, генерация
tools (необязательное)
Ограничивает агента конкретными инструментами.
Формат: массив имён инструментов
tools: ["Read", "Write", "Grep", "Bash"]
По умолчанию: если поле опущено, агенту доступны все инструменты
Лучшая практика: ограничивай инструменты необходимым минимумом (принцип наименьших привилегий)
Типовые наборы инструментов:
- Анализ только для чтения:
["Read", "Grep", "Glob"] - Генерация кода:
["Read", "Write", "Grep"] - Тестирование:
["Read", "Bash", "Grep"] - Полный доступ: опусти поле или используй
["*"]
Устройство системного промта
Тело Markdown-файла становится системным промтом агента. Пиши от второго лица, обращаясь к агенту напрямую.
Структура
Стандартный шаблон:
Ты — [роль], специализирующийся на [предметной области].
**Твои основные обязанности:**
1. [Главная обязанность]
2. [Вторая обязанность]
3. [Дополнительные обязанности...]
**Процесс анализа:**
1. [Шаг первый]
2. [Шаг второй]
3. [Шаг третий]
[...]
**Стандарты качества:**
- [Стандарт 1]
- [Стандарт 2]
**Формат результата:**
Выдай результаты в таком формате:
- [Что включить]
- [Как структурировать]
**Граничные случаи:**
Обрабатывай такие ситуации:
- [Граничный случай 1]: [Как обработать]
- [Граничный случай 2]: [Как обработать]
Лучшие практики
✅ ДЕЛАЙ:
- Пиши от второго лица («Ты — …», «Ты будешь…»)
- Конкретно описывай обязанности
- Давай пошаговый процесс
- Определяй формат результата
- Включай стандарты качества
- Учитывай граничные случаи
- Укладывайся в 10 000 знаков
❌ НЕ ДЕЛАЙ:
- Не пиши от первого лица («Я — …», «Я буду…»)
- Не будь расплывчатым или общим
- Не пропускай шаги процесса
- Не оставляй формат результата неопределённым
- Не пропускай указания по качеству
- Не игнорируй случаи ошибок
Создание агентов
Способ 1: генерация с помощью ИИ
Используй такой образец промта (взят из Claude Code):
Создай конфигурацию агента по этому запросу: "[ТВОЁ ОПИСАНИЕ]"
Требования:
1. Выдели основное намерение и обязанности
2. Продумай экспертную роль для предметной области
3. Составь исчерпывающий системный промт, включающий:
- Чёткие границы поведения
- Конкретные методики
- Обработку граничных случаев
- Формат результата
- Раздел «Когда вызывать» с 2–4 сценариями срабатывания в виде пунктов прозой
4. Создай идентификатор (строчные буквы, дефисы, 3–50 символов)
5. Напиши description с условиями срабатывания и кратким описанием сценариев срабатывания прозой
Верни JSON:
{
"identifier": "agent-name",
"whenToUse": "Используй этого агента, когда... Типичные триггеры: [...]. См. раздел \"Когда вызывать\" в теле агента.",
"systemPrompt": "Ты — ..."
}
Затем преобразуй результат в формат файла агента с шапкой.
Полный шаблон см. в examples/agent-creation-prompt.md.
Способ 2: создание вручную
- Выбери идентификатор агента (3–50 символов, строчные буквы, дефисы)
- Напиши description с примерами
- Выбери модель (обычно
inherit) - Выбери цвет для визуального различения
- Определи инструменты (если ограничиваешь доступ)
- Напиши системный промт по структуре выше
- Сохрани как
agents/agent-name.md
Правила проверки
Проверка идентификатора
✅ Допустимо: code-reviewer, test-gen, api-analyzer-v2
❌ Недопустимо: ag (слишком коротко), -start (начинается с дефиса), my_agent (подчёркивание)
Правила:
- 3–50 символов
- Только строчные буквы, цифры и дефисы
- Должен начинаться и заканчиваться буквой или цифрой
- Без подчёркиваний, пробелов и спецсимволов
Проверка описания
Длина: 10–5 000 знаков Обязательно включить: условия срабатывания и примеры Лучше всего: 200–1 000 знаков с 2–4 примерами
Проверка системного промта
Длина: 20–10 000 знаков Лучше всего: 500–3 000 знаков Структура: чёткие обязанности, процесс, формат результата
Организация агентов
Каталог агентов плагина
plugin-name/
└── agents/
├── analyzer.md
├── reviewer.md
└── generator.md
Все файлы .md в agents/ обнаруживаются автоматически.
Пространства имён
Пространства имён для агентов задаются автоматически:
- Один плагин:
agent-name - С подкаталогами:
plugin:subdir:agent-name
Тестирование агентов
Проверка срабатывания
Создай тестовые сценарии, чтобы убедиться, что агент срабатывает правильно:
- Напиши агента с конкретными примерами срабатывания
- В тесте используй формулировки, похожие на примеры
- Проверь, что Claude загружает агента
- Убедись, что агент выполняет ожидаемую функцию
Проверка системного промта
Убедись, что системный промт полон:
- Дай агенту типичную задачу
- Проверь, что он следует шагам процесса
- Убедись, что формат результата верный
- Проверь граничные случаи, упомянутые в промте
- Подтверди, что стандарты качества соблюдены
Краткая справка
Минимальный агент
---
name: simple-agent
description: Используй этого агента, когда [условие]. Типичные триггеры: [триггер 1] и [триггер 2]. См. раздел «Когда вызывать» в теле агента.
model: inherit
color: blue
---
Ты — агент, который [делает X].
## Когда вызывать
- **[Сценарий A].** [Описание.]
- **[Сценарий B].** [Описание.]
Процесс:
1. [Шаг 1]
2. [Шаг 2]
Результат: [Что выдать]
Сводка полей шапки
| Поле | Обязательное | Формат | Пример |
|---|---|---|---|
| name | Да | строчные буквы и дефисы | code-reviewer |
| description | Да | Триггеры прозой | Используй, когда... Типичные триггеры:... |
| model | Да | inherit/sonnet/opus/haiku | inherit |
| color | Да | Название цвета | blue |
| tools | Нет | Массив имён инструментов | ["Read", "Grep"] |
Лучшие практики
ДЕЛАЙ:
- ✅ Называй в description 2–4 сценария срабатывания (прозой)
- ✅ Подробные разобранные сценарии клади в раздел «Когда вызывать» в теле, пунктами прозой
- ✅ Пиши конкретные условия срабатывания
- ✅ Используй
inheritдля модели, если нет особой нужды - ✅ Выбирай подходящие инструменты (наименьшие привилегии)
- ✅ Пиши чёткие, структурированные системные промты
- ✅ Тщательно проверяй срабатывание агента
НЕ ДЕЛАЙ:
- ❌ Не используй общие описания без сценариев срабатывания
- ❌ Не опускай условия срабатывания
- ❌ Не давай всем агентам один цвет
- ❌ Не давай лишний доступ к инструментам
- ❌ Не пиши расплывчатые системные промты
- ❌ Не пропускай тестирование
Дополнительные ресурсы
Справочные файлы
Подробные рекомендации см. в:
- **
references/system-prompt-design.md** — готовые приёмы построения системного промта - **
references/triggering-examples.md** — форматы примеров и лучшие практики - **
references/agent-creation-system-prompt.md** — точный промт из Claude Code
Файлы с примерами
Рабочие примеры в examples/:
- **
agent-creation-prompt.md** — шаблон генерации агента с помощью ИИ - **
complete-agent-examples.md** — полные примеры агентов для разных сценариев
Служебные скрипты
Инструменты разработки в scripts/:
- **
validate-agent.sh** — проверка структуры файла агента - **
test-agent-trigger.sh** — проверка, срабатывает ли агент правильно
Порядок реализации
Чтобы создать агента для плагина:
- Определи назначение агента и условия его срабатывания
- Выбери способ создания (с помощью ИИ или вручную)
- Создай файл
agents/agent-name.md - Напиши шапку со всеми обязательными полями
- Напиши системный промт по лучшим практикам
- Назови 2–4 сценария срабатывания в description (прозой) и распиши их подробно в разделе «Когда вызывать» в теле
- Проверь с помощью
scripts/validate-agent.sh - Проверь срабатывание на реальных сценариях
- Задокументируй агента в README плагина
Сосредоточься на чётких условиях срабатывания и исчерпывающих системных промтах для автономной работы.
Перевод: iiuniversitet. Оригинал: https://github.com/anthropics/claude-plugins-official/tree/main/plugins/plugin-dev/skills/agent-development, лицензия Apache-2.0. Изменения: перевод на русский язык.
Оригинал на английском
---
name: agent-development
description: This skill should be used when the user asks to "create an agent", "add an agent", "write a subagent", "agent frontmatter", "when to use description", "agent examples", "agent tools", "agent colors", "autonomous agent", or needs guidance on agent structure, system prompts, triggering conditions, or agent development best practices for Claude Code plugins.
version: 0.1.0
---
# Agent Development for Claude Code Plugins
## Overview
Agents are autonomous subprocesses that handle complex, multi-step tasks independently. Understanding agent structure, triggering conditions, and system prompt design enables creating powerful autonomous capabilities.
**Key concepts:**
- Agents are FOR autonomous work, commands are FOR user-initiated actions
- Markdown file format with YAML frontmatter
- Triggering via description field with examples
- System prompt defines agent behavior
- Model and color customization
## Agent File Structure
### Complete Format
```markdown
---
name: agent-identifier
description: Use this agent when [triggering conditions]. Typical triggers include [scenario 1 in prose], [scenario 2 in prose], and [scenario 3 in prose]. See "When to invoke" in the agent body for worked scenarios.
model: inherit
color: blue
tools: ["Read", "Write", "Grep"]
---
You are [agent role description]...
## When to invoke
[Two to four representative scenarios written as prose, e.g.:]
- **[Scenario name].** [What the situation looks like and what the agent should do.]
- **[Scenario name].** [Same.]
**Your Core Responsibilities:**
1. [Responsibility 1]
2. [Responsibility 2]
**Analysis Process:**
[Step-by-step workflow]
**Output Format:**
[What to return]
```
## Frontmatter Fields
### name (required)
Agent identifier used for namespacing and invocation.
**Format:** lowercase, numbers, hyphens only
**Length:** 3-50 characters
**Pattern:** Must start and end with alphanumeric
**Good examples:**
- `code-reviewer`
- `test-generator`
- `api-docs-writer`
- `security-analyzer`
**Bad examples:**
- `helper` (too generic)
- `-agent-` (starts/ends with hyphen)
- `my_agent` (underscores not allowed)
- `ag` (too short, < 3 chars)
### description (required)
Defines when Claude should trigger this agent. **This is the most critical field** — it is loaded into context whenever the agent is registered, so the harness can decide when to dispatch.
**Must include:**
1. Triggering conditions ("Use this agent when...")
2. A short prose summary of the typical trigger scenarios
3. A pointer to a "When to invoke" section in the agent body for the detailed worked scenarios
**Format:**
```
Use this agent when [conditions]. Typical triggers include [scenario 1 in prose], [scenario 2 in prose], and [scenario 3 in prose]. See "When to invoke" in the agent body for worked scenarios.
```
**Best practices:**
- Name 2-4 trigger scenarios in the prose summary
- Cover both proactive (assistant invokes itself) and reactive (user requests) triggering
- Cover different phrasings of the same intent
- Be specific about when NOT to use the agent
- Put detailed scenarios in the body under "When to invoke" as a bullet list of prose descriptions
### model (required)
Which model the agent should use.
**Options:**
- `inherit` - Use same model as parent (recommended)
- `sonnet` - Claude Sonnet (balanced)
- `opus` - Claude Opus (most capable, expensive)
- `haiku` - Claude Haiku (fast, cheap)
**Recommendation:** Use `inherit` unless agent needs specific model capabilities.
### color (required)
Visual identifier for agent in UI.
**Options:** `blue`, `cyan`, `green`, `yellow`, `magenta`, `red`
**Guidelines:**
- Choose distinct colors for different agents in same plugin
- Use consistent colors for similar agent types
- Blue/cyan: Analysis, review
- Green: Success-oriented tasks
- Yellow: Caution, validation
- Red: Critical, security
- Magenta: Creative, generation
### tools (optional)
Restrict agent to specific tools.
**Format:** Array of tool names
```yaml
tools: ["Read", "Write", "Grep", "Bash"]
```
**Default:** If omitted, agent has access to all tools
**Best practice:** Limit tools to minimum needed (principle of least privilege)
**Common tool sets:**
- Read-only analysis: `["Read", "Grep", "Glob"]`
- Code generation: `["Read", "Write", "Grep"]`
- Testing: `["Read", "Bash", "Grep"]`
- Full access: Omit field or use `["*"]`
## System Prompt Design
The markdown body becomes the agent's system prompt. Write in second person, addressing the agent directly.
### Structure
**Standard template:**
```markdown
You are [role] specializing in [domain].
**Your Core Responsibilities:**
1. [Primary responsibility]
2. [Secondary responsibility]
3. [Additional responsibilities...]
**Analysis Process:**
1. [Step one]
2. [Step two]
3. [Step three]
[...]
**Quality Standards:**
- [Standard 1]
- [Standard 2]
**Output Format:**
Provide results in this format:
- [What to include]
- [How to structure]
**Edge Cases:**
Handle these situations:
- [Edge case 1]: [How to handle]
- [Edge case 2]: [How to handle]
```
### Best Practices
✅ **DO:**
- Write in second person ("You are...", "You will...")
- Be specific about responsibilities
- Provide step-by-step process
- Define output format
- Include quality standards
- Address edge cases
- Keep under 10,000 characters
❌ **DON'T:**
- Write in first person ("I am...", "I will...")
- Be vague or generic
- Omit process steps
- Leave output format undefined
- Skip quality guidance
- Ignore error cases
## Creating Agents
### Method 1: AI-Assisted Generation
Use this prompt pattern (extracted from Claude Code):
```
Create an agent configuration based on this request: "[YOUR DESCRIPTION]"
Requirements:
1. Extract core intent and responsibilities
2. Design expert persona for the domain
3. Create comprehensive system prompt with:
- Clear behavioral boundaries
- Specific methodologies
- Edge case handling
- Output format
- A "When to invoke" section listing 2-4 trigger scenarios as prose bullets
4. Create identifier (lowercase, hyphens, 3-50 chars)
5. Write description with triggering conditions and a short prose summary of trigger scenarios
Return JSON with:
{
"identifier": "agent-name",
"whenToUse": "Use this agent when... Typical triggers include [...]. See \"When to invoke\" in the agent body.",
"systemPrompt": "You are..."
}
```
Then convert to agent file format with frontmatter.
See `examples/agent-creation-prompt.md` for complete template.
### Method 2: Manual Creation
1. Choose agent identifier (3-50 chars, lowercase, hyphens)
2. Write description with examples
3. Select model (usually `inherit`)
4. Choose color for visual identification
5. Define tools (if restricting access)
6. Write system prompt with structure above
7. Save as `agents/agent-name.md`
## Validation Rules
### Identifier Validation
```
✅ Valid: code-reviewer, test-gen, api-analyzer-v2
❌ Invalid: ag (too short), -start (starts with hyphen), my_agent (underscore)
```
**Rules:**
- 3-50 characters
- Lowercase letters, numbers, hyphens only
- Must start and end with alphanumeric
- No underscores, spaces, or special characters
### Description Validation
**Length:** 10-5,000 characters
**Must include:** Triggering conditions and examples
**Best:** 200-1,000 characters with 2-4 examples
### System Prompt Validation
**Length:** 20-10,000 characters
**Best:** 500-3,000 characters
**Structure:** Clear responsibilities, process, output format
## Agent Organization
### Plugin Agents Directory
```
plugin-name/
└── agents/
├── analyzer.md
├── reviewer.md
└── generator.md
```
All `.md` files in `agents/` are auto-discovered.
### Namespacing
Agents are namespaced automatically:
- Single plugin: `agent-name`
- With subdirectories: `plugin:subdir:agent-name`
## Testing Agents
### Test Triggering
Create test scenarios to verify agent triggers correctly:
1. Write agent with specific triggering examples
2. Use similar phrasing to examples in test
3. Check Claude loads the agent
4. Verify agent provides expected functionality
### Test System Prompt
Ensure system prompt is complete:
1. Give agent typical task
2. Check it follows process steps
3. Verify output format is correct
4. Test edge cases mentioned in prompt
5. Confirm quality standards are met
## Quick Reference
### Minimal Agent
```markdown
---
name: simple-agent
description: Use this agent when [condition]. Typical triggers include [trigger 1] and [trigger 2]. See "When to invoke" in the agent body.
model: inherit
color: blue
---
You are an agent that [does X].
## When to invoke
- **[Scenario A].** [Description.]
- **[Scenario B].** [Description.]
Process:
1. [Step 1]
2. [Step 2]
Output: [What to provide]
```
### Frontmatter Fields Summary
| Field | Required | Format | Example |
|-------|----------|--------|---------|
| name | Yes | lowercase-hyphens | code-reviewer |
| description | Yes | Prose triggers | Use when... Typical triggers include... |
| model | Yes | inherit/sonnet/opus/haiku | inherit |
| color | Yes | Color name | blue |
| tools | No | Array of tool names | ["Read", "Grep"] |
### Best Practices
**DO:**
- ✅ Name 2-4 trigger scenarios in the description (as prose)
- ✅ Put detailed worked scenarios in a "When to invoke" body section, as prose bullets
- ✅ Write specific triggering conditions
- ✅ Use `inherit` for model unless specific need
- ✅ Choose appropriate tools (least privilege)
- ✅ Write clear, structured system prompts
- ✅ Test agent triggering thoroughly
**DON'T:**
- ❌ Use generic descriptions without trigger scenarios
- ❌ Omit triggering conditions
- ❌ Give all agents same color
- ❌ Grant unnecessary tool access
- ❌ Write vague system prompts
- ❌ Skip testing
## Additional Resources
### Reference Files
For detailed guidance, consult:
- **`references/system-prompt-design.md`** - Complete system prompt patterns
- **`references/triggering-examples.md`** - Example formats and best practices
- **`references/agent-creation-system-prompt.md`** - The exact prompt from Claude Code
### Example Files
Working examples in `examples/`:
- **`agent-creation-prompt.md`** - AI-assisted agent generation template
- **`complete-agent-examples.md`** - Full agent examples for different use cases
### Utility Scripts
Development tools in `scripts/`:
- **`validate-agent.sh`** - Validate agent file structure
- **`test-agent-trigger.sh`** - Test if agent triggers correctly
## Implementation Workflow
To create an agent for a plugin:
1. Define agent purpose and triggering conditions
2. Choose creation method (AI-assisted or manual)
3. Create `agents/agent-name.md` file
4. Write frontmatter with all required fields
5. Write system prompt following best practices
6. Name 2-4 trigger scenarios in description (prose) and detail them in a "When to invoke" body section
7. Validate with `scripts/validate-agent.sh`
8. Test triggering with real scenarios
9. Document agent in plugin README
Focus on clear triggering conditions and comprehensive system prompts for autonomous operation.
Источник: anthropics/claude-plugins-official / plugin-dev / agent-development ↗. Ссылка проверена 2026-10-10.