Лекция 2

От чата к Agentic Engineering

Prompt Engineering, Skills & Rules

Фокус: как управлять поведением агента

Представление

Добавьте фото по пути ../../assets/avatar.jpg

Кто выступает

ГТЛ в направлении СиВ
Процессный менеджер во Взыскании
ИИ Евангелист
Человек с веником в ...кхм голове (с) по мнению коллег

Формат: от чата к агентному подходу — prompt engineering, rules, skills.

Содержание

1. Чат vs Агент

Loop, tool use, автономность — в чём принципиальная разница

2. Prompt Engineering

System prompt, chain-of-thought, формулировка инструкций

3. Rules

Глобальные и проектные правила: .roo/rules, AGENTS.md, .rules

4. Skills

Модульные способности через файлы, шаблоны, примеры

5. Антипаттерны

Топ-3 ошибки в промптах и правилах, демо-разбор

Раздел 01

Чат vs Агент

Loop, tool use, автономность — три признака, которые меняют всё

Чат: запрос → ответ

Как работает

Один запрос — один ответ
Нет доступа к файлам, терминалу, браузеру
Контекст — только то, что вставили руками
Результат — текст, который надо применить самому

Ограничения

Не видит реальное состояние проекта
Не может проверить, работает ли его решение
Каждый шаг требует участия человека
Контекст теряется между сообщениями

Чат — это советник. Он предлагает, но не действует.

Агент: Think → Act → Observe → Loop

THINK

Анализирует задачу, строит план

→

ACT

Вызывает tool: читает, пишет, запускает

→

OBSERVE

Получает результат, анализирует

→

LOOP

Решает: продолжить или завершить

Tool Use

Читает файлы, запускает команды, редактирует код — работает с реальным проектом

Автономность

Сам решает следующий шаг на основе результата предыдущего

Цикл

Не останавливается после первого ответа — итерирует до решения

Три ключевых отличия

	Чат (ChatGPT, Claude.ai)	Агент (Roo Code, Kilo Code, OpenCode, Zed)
Цикл	Один запрос → один ответ	Многоходовый loop до завершения задачи
Инструменты	Только текст (copy-paste)	Read, Edit, Bash, Search, Browser...
Автономность	Ноль — человек выполняет всё	Настраиваемая: от ask-every-step до full auto
Контекст	То, что вставили в чат	Весь проект + результаты tool calls
Обратная связь	Нет: не видит, сработало ли	Видит ошибки компиляции, тесты, git diff

Агент — это исполнитель. Он думает, действует и проверяет результат сам.

Раздел 02

Prompt Engineering

System prompt, chain-of-thought, как формулировать инструкции для агента

Промпт для чата vs промпт для агента

Для чата

Максимум контекста в одном сообщении
Чёткая формулировка желаемого ответа
Few-shot примеры
Результат: текст, который копируешь

Для агента

Цель, а не пошаговая инструкция
Ограничения: что не менять, куда не лезть
Критерии готовности: тесты проходят, линтер чист
Результат: реальные изменения в проекте

Агенту не нужен контекст вашего файла в промпте — он прочитает его сам. Ему нужна цель и границы.

Анатомия system prompt

Из чего состоит

Роль — кто агент и для чего
Поведение — как принимать решения
Ограничения — что запрещено
Формат — как отвечать
Tools — какие инструменты доступны

Почему важен порядок

LLM лучше следует инструкциям в начале и конце
Критичные ограничения — ближе к началу
Примеры и детали — в середине
Финальное напоминание — в конце

Primacy + recency bias работает и для моделей

Chain-of-thought для агентов

Что это

Явное указание агенту думать перед действием: анализировать, планировать, обосновывать выбор.

# Перед каждым изменением:
1. Прочитай текущий код целиком
2. Определи, какие файлы затронуты
3. Объясни свой план в 2-3 предложениях
4. Только потом начинай редактирование

Зачем нужен

Снижает «галлюцинации» — модель проверяет себя
Делает действия агента предсказуемыми
Проще дебажить — видишь ход рассуждений
Уменьшает «прыжки к решению» без анализа

Extended thinking в Claude, reasoning в OpenAI — встроенный CoT

CoT на практике: Plan-агенты и Loop-паттерны

Plan-first агенты

Roo Code — режим Architect: сначала план, потом передача в Code
Kilo Code — тот же паттерн + Boomerang-делегация
Claude Code — режим --permission-mode plan: агент планирует, но не выполняет
OpenCode — агент Plan в .opencode/agents/

Принцип: «Сначала скажи что будешь делать, потом делай»

Итеративная проверка (Ralph Loop)

Агент работает в цикле: действие → проверка → исправление
На каждой итерации запускает тесты или линтер
Не останавливается, пока проверки не пройдут
Настраивается интервал и условие выхода

Похож на TDD-цикл: red → green → refactor, но автоматизированный

Примеры в правилах

# В rules для любого агента:
Before writing code:
1. Read existing implementation
2. Write a plan as a numbered list
3. Get user approval
4. Only then implement

After each change:
- Run tests
- If tests fail → fix and rerun
- Commit only when green

5 правил хорошего промпта для агента

1. Цель, не рецепт

«Добавь валидацию email в форму регистрации» вместо «открой файл X, найди строку Y, вставь Z»

2. Границы

«Не меняй API контракт», «Не трогай миграции», «Только файлы в src/auth/»

3. Критерии готовности

«Тесты проходят», «Линтер без ошибок», «Типы совпадают с API»

4. Контекст задачи

«Это баг из прода: пользователи видят 500 при пустом email» — зачем, а не только что

5. Одна задача

Не мешать рефакторинг с новой фичей. Один промпт — один фокус.

Демо: плохой vs хороший промпт

Плохой промпт

Почини баг с логином

Что пойдёт не так

Агент не знает, какой баг
Может «починить» не то
Нет способа проверить результат
Может сломать соседнюю логику

Хороший промпт

Баг: при логине с email без @ сервер
возвращает 500 вместо 422.

Файл: src/auth/login.ts, функция
validateCredentials.

Добавь валидацию формата email
до обращения к БД.
Тесты: npm test -- auth.
Не меняй API-ответ для валидного
логина.

Формула: Контекст (что сломано) + Локация (где) + Действие (что сделать) + Проверка (как убедиться) + Границы (что не трогать)

Ещё примеры: от размытого к точному

Размыто	Точно
Сделай код лучше	Вынеси дублирующуюся логику парсинга дат из `utils/date.ts` в одну функцию `parseISO`. Тесты должны проходить.
Добавь тесты	Добавь unit-тесты для `CartService.applyDiscount()`: пустая корзина, скидка > 100%, истекший купон. Используй vitest.
Задеплой это	Создай Dockerfile для `api/`: node:20-alpine, multi-stage build, порт 3000. Не включай devDependencies в финальный образ.
Перепиши на TypeScript	Мигрируй `src/utils/helpers.js` на TypeScript. Используй strict mode. Не меняй публичный API. Запусти `tsc --noEmit` для проверки.

Human in the Loop: когда не отпускать руль

Уровень	Когда	Пример
Full auto	Рутина, обратимые действия	Рефакторинг, тесты, линтинг
Plan → Approve	Значимые изменения	Новая фича, архитектура
Ask every step	Критичные операции	Миграции БД, деплой, удаление

В инструментах

Claude Code — --permission-mode plan
Roo / Kilo — Architect → Boomerang → Code
Cursor — YOLO-mode vs подтверждение

Задача: мигрировать users с MySQL на PostgreSQL.

1. Покажи план миграции — я проверю
2. Напиши SQL-скрипт — я проверю
3. Подготовь rollback-скрипт
4. НЕ запускай миграцию — только файлы

Промпт → Rules

Вписывать точки контроля в каждый промпт — утомительно. Если правила повторяются, их стоит зафиксировать. Именно для этого существуют Rules →

Раздел 03

Rules

Глобальные и проектные правила — как задать рамки поведения агента

Что такое Rules

Суть

Текстовые инструкции, загружаемые в контекст каждого запроса
Определяют стиль, ограничения, стандарты
Работают как «конституция» для агента
Не требуют активации — действуют всегда

Два уровня

Глобальные — для всех проектов пользователя
Проектные — для конкретного репозитория, коммитятся в Git

Проектные правила — главный способ сделать поведение агента одинаковым для всей команды

Где живут правила: карта конфигов

Инструмент	Глобальные	Проектные
Roo Code	Custom instructions в UI	`.roo/rules/`, `.roo/rules-code/`, `.roo/rules-architect/`
Kilo Code	Custom instructions в UI	`.kilocode/rules/`, `.kilocode/rules-code/`
OpenCode	`~/.config/opencode/opencode.jsonc`	`AGENTS.md`, `.opencode/opencode.jsonc`
Zed	Rules Library (Agent Panel)	Файл `.rules` в корне проекта
Claude Code	`~/.claude/CLAUDE.md`	`CLAUDE.md` в корне проекта
Cursor	Settings → Rules for AI	`.cursor/rules/*.mdc`
AGENTS.md	—	Кросс-инструментный: Claude Code, OpenCode, Codex, Roo Code, Kilo Code, Zed

AGENTS.md — универсальная конвенция. Если команда использует разные агенты, начните с него.

Живой пример: .roo/rules/ (Roo Code / Kilo Code)

# .roo/rules/project.md

## Project
E-commerce API: Node.js + TypeScript
+ PostgreSQL. Monorepo: apps/api,
apps/web, packages/shared.

## Code Style
- Strict TypeScript, no `any`
- Functional style, avoid classes
- Error: Result<T, E>, no throw
- Tests: vitest, 80%+ coverage

## Architecture
- Clean Architecture: domain → infra
- Never import infra in domain
- All DB through repository pattern

# .roo/rules-code/security.md

## Forbidden
- NEVER modify .env files
- NEVER use `rm -rf` or `DROP TABLE`
- NEVER disable TypeScript strict
- NEVER add deps without asking

## Required
- Validate inputs at API boundary
- Parameterized queries only
- Log errors with requestId

Разделение: общие правила в rules/, безопасность для Code-режима в rules-code/

Живой пример: AGENTS.md (OpenCode, Claude Code, Codex)

# AGENTS.md

You are a senior React/TypeScript developer.

## Stack
- React 18, TypeScript 5, Tailwind CSS, Zustand
- Testing: Vitest + React Testing Library

## UI Rules
- All components use functional style with hooks
- Use Tailwind utility classes, no CSS modules
- Responsive: mobile-first, breakpoints sm/md/lg
- Accessibility: every interactive element needs
  aria-label or visible label

## File Structure
- components/: reusable UI components
- features/: domain-specific feature modules
- Each feature has: components/, hooks/, types.ts

## Git
- Conventional commits: feat:, fix:, refactor:
- One logical change per commit

AGENTS.md работает одинаково в OpenCode, Claude Code и Codex — один файл на всю команду, даже если используете разные инструменты.

Режимные правила (Roo Code / Kilo Code)

# .roo/rules-code/security.md

- NEVER read or modify `.env*` files
- NEVER run `rm -rf` or `DROP TABLE`
- Ask user before deleting any file
- Validate all user inputs at API boundary
- Use parameterized queries, never
  string concatenation for SQL

# .roo/rules-architect/planning.md

- Always start with a written plan
- List affected files before any changes
- Consider backward compatibility
- Estimate blast radius of changes

Как это работает

rules-code/ — только в режиме Code
rules-architect/ — только в режиме Architect
rules/ — во всех режимах
Можно создавать свои режимы в .roomodes

Разделение по режимам снижает расход контекста: агент загружает только релевантные правила

Условные правила по путям файлов

# .cursor/rules/api-layer.mdc
---
globs: ["apps/api/**/*.ts"]
---

- Use Express middleware pattern
- All routes return typed ResponseDTO
- Log every error with requestId
- Rate limiting on all public endpoints

# .cursor/rules/tests.mdc
---
globs: ["**/*.test.ts", "**/*.spec.ts"]
---

- Use describe/it structure
- One assertion per test preferred
- Mock external services, not internal
- Test behavior, not implementation

Зачем условные правила

Разный код — разные стандарты
API-слой ≠ фронтенд ≠ тесты ≠ миграции
Активируются только при работе с matching-файлами
Экономия контекста: нет лишних правил

Cursor: .mdc с globs:. Roo Code / Kilo Code: через режимы + fileRegex в .roomodes

Условные правила в AGENTS.md

# AGENTS.md

## Conditional Rules

If you are working on React components,
read and follow `docs/react-guidelines.md`.

If the user asks to write or modify tests,
read and follow `docs/testing-standards.md`.

If you are modifying database models,
read and follow `docs/db-conventions.md`.

If the task involves API endpoints,
read `docs/api-style-guide.md` before writing code.

Как это работает

Агент читает AGENTS.md при старте, видит условия на естественном языке и подгружает нужный файл, когда условие совпадает с задачей

Преимущества

Экономия контекста: 10 строк условий вместо 500 строк правил
Кросс-инструментность: Claude Code, OpenCode, Codex
Гибкость: любое условие на естественном языке, не только пути файлов

⚠ Ограничения

Нет гарантии — это просьба, а не enforcement как globs в Cursor
Зависит от модели — слабые модели могут пропускать условия
Критичные правила лучше держать в основном файле

Как писать эффективные правила

Хорошие правила

Конкретные: «используй vitest» вместо «пиши тесты»
Проверяемые: можно проверить автоматически
С примерами: покажи, как выглядит правильно
С причиной: почему это правило существует
Короткие: одно правило — одно предложение

Плохие правила

Размытые: «пиши хороший код»
Противоречивые: правило A конфликтует с B
Избыточные: 500 строк правил → агент игнорирует
Без контекста: «не используй X» — а почему?
Устаревшие: правило для старой версии стека

Практика: начните с 10-15 правил. Добавляйте новые, только когда агент ошибается в конкретном паттерне.

Раздел 04

Skills

Как давать агенту способности через файлы, шаблоны и примеры

Rules vs Skills: напоминание

	Rules	Skills
Когда активны	Всегда, в каждом запросе	Только при активации (on-demand)
Роль	Рамки: что можно / нельзя	Процедуры: как выполнить задачу
Расход контекста	Постоянный	Только при использовании
Аналогия	Конституция компании	Должностная инструкция на задачу
Пример	«Не используй any в TypeScript»	«Как написать E2E-тест для этого проекта»

Rules задают рамки, Skills дают способности.

Анатомия skill-файла

---
name: create-api-endpoint
description: >
  Use when creating a new REST API endpoint.
  Covers routing, validation, service layer, and tests.
---

# Creating a new API endpoint

## Steps
1. Create route in `apps/api/src/routes/`
2. Define request/response DTOs in `types/`
3. Implement service logic in `services/`
4. Add input validation with zod schema
5. Write tests: unit for service, integration for route
6. Update OpenAPI spec in `docs/api.yaml`

## Template
```typescript
// routes/[entity].ts
router.post('/[entity]',
  validate(Create[Entity]Schema),
  async (req, res) => {
    const result = await [entity]Service.create(req.body);
    res.status(201).json(result);
  }
);
```

## Checklist
- [ ] Route follows RESTful naming
- [ ] Zod schema validates all inputs
- [ ] Service has unit tests
- [ ] Error responses use standard format

Базовый механизм: как агент узнаёт о skills

SCAN

Агент сканирует директории skills при старте

→

COLLECT

Собирает name + description каждого skill

→

PROMPT

Список описаний попадает в system prompt

→

SELECT

Кто-то решает, какой skill активировать

Что одинаково у всех

Skills хранятся как Markdown-файлы с описанием
Агент при старте сканирует директории и находит их
Список (name + description) попадает в контекст
При активации — полный текст skill загружается в промпт

Что отличается: шаг SELECT

LLM сама выбирает — читает описания и решает (OpenCode, Claude Code)
Режимы — фильтрация доступных skills по режиму (Roo Code)
Режим определяет — skills привязаны к режимам (Roo Code)
Пользователь вызывает — через /command или UI (Zed)

Как агент выбирает skill

LLM выбирает сама

Все description skills вставляются в промпт
Модель сама решает, какой skill вызвать
Это основной подход большинства инструментов

Claude Code · OpenCode · Kilo Code · Roo Code

Усиление: semantic similarity

Плагин opencode-agent-skills для OpenCode
Автоматически обнаруживает релевантные skills
Инжектирует промпт, побуждающий агента загрузить skill

Pre-filter поверх LLM-выбора

Режимы фильтруют набор

Skills в skills-code/, skills-architect/ — только в своём режиме
Оркестратор делегирует через Boomerang

Roo Code · Kilo Code

Итого

LLM-выбор — стандарт для всех инструментов
Режимы — дополнительная фильтрация
Semantic similarity — усиление через плагин

Skills по инструментам: где, как, сколько

Инструмент	Путь	Выбор skill	Масштаб
Claude Code	`.claude/skills/`, `.agents/skills/`	LLM по description	Десятки
OpenCode	`.opencode/skills/`, `.agents/skills/`	LLM + semantic similarity (плагин)	Десятки
Kilo Code	`.kilocode/skills/`, `.agents/skills/`	LLM по description	Десятки
Roo Code	`.roo/skills/`, `.agents/skills/`	LLM + фильтрация по режимам	По режимам
Zed	Rules Library, файл `.rules`	Пользователь (slash / UI)	Любой

Командные → в Git

Новый разработчик получает все skills вместе с git clone

Личные → `~/`

Глобальные skills в домашней директории, не в репо

Два паттерна skills

Workflow · write-e2e-test

Пошаговая процедура — агент выполняет шаги по порядку

description	«Use when writing E2E tests» — trigger-фраза
Steps	Изучи тесты в `e2e/`, пиши через `getByRole`, запусти playwright
Anti-patterns	Запрет на `waitForTimeout`
Checklist	Assert на каждый кейс + eslint clean

Guard · debug-production

Протокол с точками остановки — думай перед каждым действием

description	«Use when fixing production bugs» — trigger-фраза
Protocol	Логи → reproduce → root cause → fix
Gates	Нет root cause — не фикси. DROP — спроси юзера
Checklist	Regression test обязателен

Workflow = «сделай по шагам». Guard = «думай перед каждым действием».

.agents/skills/ — открытый стандарт Agent Skills

В команде разные инструменты → skills дублируются в .claude/, .opencode/, .kilocode/

.agents/skills/
├── write-e2e-test/SKILL.md
└── manual-qa/
    ├── SKILL.md
    └── examples/

Стандарт Agent Skills

Спецификация agentskills.io — единый формат, 30+ инструментов: Claude Code, OpenCode, Kilo Code, Roo Code, Cursor, Copilot, Gemini CLI

Как работает

Инструменты сканируют .agents/skills/ наряду со своими путями
Для rules — файл AGENTS.md
Коммитится в Git — git clone и всё на месте

Skill как папка: вынос примеров

.agents/skills/manual-qa/
├── SKILL.md            ← description + шаги
├── examples/
│   ├── checkout-flow.md
│   └── login-flow.md
└── templates/
    └── bug-report.md

Зачем выносить примеры

Примеры на 500+ строк не загружаются при каждом запросе
Можно обновлять независимо от инструкций
Агент подгрузит только релевантный пример
Шаблоны используются как есть, без «пересказа»

Как это работает

При старте агент читает только name + description из основного файла. Примеры не загружаются.

Когда skill активирован, агент видит инструкцию:

## Примеры
Перед началом тестирования прочитай
релевантный пример из `./examples/`.

Агент сам прочитает нужный файл — это просто чтение файла с диска.

Никакой специальной поддержки не нужно. Любой агент умеет читать файлы — паттерн работает везде.

Публичные репозитории skills

skills.sh

Открытый каталог ready-to-use skills. Издатели: Anthropic, Vercel, Microsoft и сообщество.

Формат Agent Skills с frontmatter
Установка: npx skills add <owner/repo>
Skill скачивается в .agents/skills/

neuraldeep.ru

Русскоязычный агрегатор skills, MCP-серверов и AI-инструментов для российских сервисов.

Яндекс, Битрикс24, 1C, GigaChat, Wildberries, YooKassa
Установка: npx skillsbd add <owner/repo>

Как оценивать чужие skills

description — конкретный trigger, а не «helps with code»?
Шаги — пронумерованный список действий?
Примеры — привязаны к реальному стеку?
Чеклист — есть критерии завершения?
Безопасность — нет деструктивных команд?
Итого: чужой skill — отправная точка, всегда адаптируй

Пример: skill для ручного QA-тестирования

Основной файл: SKILL.md

---
name: manual-qa-test
description: >
  Use when asked to manually test
  a web feature or verify a user flow.
---

# Testing process
For each step in the scenario:
1. **Act** — perform user action
2. **Observe** — check result:
   - Page loaded? No console errors?
   - UI matches expected state?
3. **Screenshot** — capture state
4. **Note** — record pass/fail

# If a bug is found
Create bug report from template:
→ ./templates/bug-report.md

## Completion checklist
- [ ] All scenario steps executed
- [ ] Screenshots taken
- [ ] Console checked for errors
- [ ] Bug reports filed
- [ ] Summary: X passed, Y failed

Пример: examples/checkout-flow.md

# Тестирование оформления заказа

## Предусловия
- Пользователь авторизован
- В корзине минимум 1 товар

## Шаги
1. Открыть корзину → проверить
   список товаров и сумму
2. Нажать «Оформить заказ» →
   форма доставки отобразилась
3. Заполнить адрес → валидация
   работает (пустые поля, индекс)
4. Выбрать оплату → сумма
   пересчиталась с доставкой
5. Нажать «Подтвердить» →
   редирект на страницу успеха

## Граничные случаи
- Пустая корзина → кнопка
  «Оформить» недоступна
- Товар закончился → сообщение
- Двойной клик → не дублируется

Skill описывает процесс, а не код. Агент с браузером может автоматизировать любую повторяемую процедуру.

Как написать хороший skill: чек-лист

Обязательно

name — глагол + существительное: write-e2e-test
description — когда именно активировать
Шаги — пронумерованный список действий
Примеры из проекта — реальные пути, реальный код
Чеклист — что проверить перед завершением

Антипаттерны

Топ-3 ошибки в промптах и правилах — и как их исправить

Ошибка #1: «Простыня» — слишком много правил

Сломано

# Rules файл (800 строк)
- Use TypeScript strict mode
- Always add JSDoc to every function
- Use camelCase for variables
- Use PascalCase for types
- Use SCREAMING_SNAKE for constants
- Always add error handling
- Log every function entry/exit
- Use dependency injection
- Follow SOLID principles
- Add metrics to every endpoint
- Use circuit breaker pattern
- ... (ещё 200 правил)

Агент начинает игнорировать правила или противоречить сам себе.

Починено

# .roo/rules/project.md (40 строк)
## Must
- TypeScript strict, no `any`
- Vitest for tests
- Result<T,E> for error handling

## Architecture
- Clean Architecture layers
- Never import infra in domain

## Forbidden
- No .env modifications
- No rm -rf or DROP TABLE

## Details
→ see rules-code/ for Code mode
→ see rules-architect/ for planning

Фокус на критичном. Детали — в отдельных файлах по назначению.

Ошибка #2: Промпт-рецепт вместо цели

Сломано

1. Открой файл src/api/users.ts
2. Найди функцию getUser на строке 42
3. Добавь после строки 45:
   if (!user.email) return null;
4. Сохрани файл
5. Запусти npm test
6. Если тест упал, добавь mock
   в __mocks__/userService.ts

Если код поменялся, все номера строк неверны. Агент не понимает зачем — не может адаптироваться.

Починено

В src/api/users.ts функция getUser
не проверяет наличие email у
пользователя, что приводит к 500
при обращении к /api/users/:id.

Добавь early return с 422, если
email отсутствует или невалиден.

Тесты: npm test -- users
Не меняй поведение для валидных
пользователей.

Агент сам найдёт нужное место, адаптируется к текущему коду, проверит результат.

Ошибка #3: Правила без примеров и причин

Сломано

# Rules
- Use proper error handling
- Follow best practices
- Write clean code
- Be consistent
- Don't use bad patterns

Агент интерпретирует каждое слово по-своему. «Proper» и «clean» — не конкретика.

Починено

# Error Handling
Use Result<T, AppError> pattern.
Why: throw breaks type safety and
makes error paths invisible.

## Good
const result = await getUser(id);
if (result.isErr()) {
  return res.status(404).json({
    error: result.error.message
  });
}

## Bad
try {
  const user = await getUser(id);
} catch (e) {
  // what type is e? unknown
}

Шаблон: Правило + Почему + Пример правильно + Пример неправильно

Бонус: ещё частые ошибки

Противоречивые правила

AGENTS.md: «используй классы»
.roo/rules-code/: «используй функции»
Результат: агент чередует стили случайным образом.

Решение: один источник правды на стиль. Остальные ссылаются.

Skills без description

Skill с пустым или размытым description: «General helper for code tasks»
Результат: агент либо никогда не активирует, либо активирует не к месту.

Решение: description = trigger-фраза: «Use when writing E2E tests with Playwright»

Правила в промпте вместо файла

Каждый раз пишете «не используй any, пиши тесты, используй vitest...»

Решение: вынесите в rules-файл проекта — один раз написали, работает всегда.

Никогда не обновляют правила

Стек мигрировал с Jest на Vitest, а в правилах по-прежнему «use Jest».

Решение: ревью правил при смене зависимостей. Добавьте в чеклист обновления стека.

Итоги

Ключевые выводы

Что забрать с собой из этой лекции

5 вещей, которые стоит запомнить

1

Агент ≠ чат. Цикл Think-Act-Observe и tool use — фундаментальная разница. Промпты для агентов — это цели и границы, не рецепты.

2

Хороший промпт: контекст + локация + действие + проверка + границы. Одна задача — один промпт.

3

Rules = конституция. Действуют всегда. Держите их короткими, конкретными и с примерами.

4

Skills = способности. Активируются по требованию. Экономят контекст и стандартизируют процедуры.

5

Коммитьте в Git. Rules и Skills — часть проекта. Вся команда работает по одним стандартам.

Практическое задание

Задание 1: Rules

Создайте rules для своего инструмента: .roo/rules/, AGENTS.md или .rules
Опишите стек, стиль, архитектуру
Добавьте 5-7 запретов (Forbidden)
Закоммитьте в репозиторий

Задание 2: Skill

Определите повторяющуюся задачу в вашем проекте
Напишите skill с шагами, шаблоном и чеклистом
Протестируйте: дайте агенту задачу, которая должна активировать skill
Итерируйте description, пока активация не станет стабильной

Дальше

Лекция 3

Tools, MCP и интеграции — как расширять возможности агента

Слайды · Лекция 1 Главная