Кастомизация agents

Coding agents уже очень сильны «из коробки»: знают нормальные engineering-подходы и часто принимают здравые решения.

Но они не знают, как любит писать софт именно твоя команда, какие у вас тулы и какой бизнес-контекст. Здесь начинается кастомизация.

В Cursor два слоя — как онбординг нового тиммейта: rules (всегда знать) и skills (подтянуть, когда релевантно).

Rules: статический context

Rules — markdown-файлы в .cursor/rules/. Agent видит их в начале каждого разговора. Это always-on инструкции.

Хороший rule-файл короткий, конкретный и ссылается на примеры, а не копирует их целиком:

# Commands

- `npm run build`: Build the project
- `npm run typecheck`: Run the typechecker
- `npm run test`: Run tests (prefer single test files for speed)

# Code style

- Use ES modules (import/export), not CommonJS (require)
- Destructure imports: `import { foo } from 'bar'`
- See `components/Button.tsx` for canonical component structure

# Workflow

- Always typecheck after making a series of code changes
- API routes go in `app/api/` following existing patterns

Rules хорошо держат:

• build/test команды проекта
• code conventions
• указатели на canonical examples
• guardrails (что не трогать, каких паттернов избегать)

Чего избегать

• Не копируй весь style guide — для этого linter. Rules дополняют tooling, не заменяют.
• Не документируй каждую unix-команду — agent и так знает. Только project-specific.
• Начинай с малого. Rules едят context в каждом чате. Добавляй, когда ловишь повторную ошибку, и держи коротко.

Коммить rules в git — пусть вся команда качается на одном shared knowledge.

Skills: динамический context

Skills дают специализированные знания и workflow. В отличие от rules, грузятся динамически: agent сам решает, когда skill уместен.

Skills живут в SKILL.md и могут включать domain knowledge, сценарии и даже скрипты.

---
description: Deploy to staging. Use when the user asks to deploy, ship, or push to staging.
---

# Deploy to staging

## Steps

1. Run `npm run build` and confirm it succeeds
2. Run `npm run test` and confirm all tests pass
3. Run `npm run deploy:staging`
4. Verify the deployment by checking https://staging.example.com/health
5. Report the deployment status and URL

	Rules	Skills
Когда грузятся	Каждый разговор	Только когда релевантно
Зачем	Always-on conventions	Specialized workflows
Цена context	Всегда занимают место	Полный вес — только при вызове
Лучше для	Что agent должен знать всегда	Что умеет сделать по запросу

MCP: внешние tools

MCP (Model Context Protocol) подключает внешние tools и context по требованию.

Примеры:

• Slack — читать/постить
• Datadog — копать прод-логи
• Sentry — ошибки и stack traces
• Базы — прямые запросы
• Figma — tokens и specs компонентов

Серверы ищи в Marketplace.

CLI как capabilities

Поверх MCP agent может гонять любой CLI из твоего терминала: gh, aws, kubectl, docker — без отдельной настройки.

Подскажи полезные тулы через rule:

- Use `gh` for all GitHub operations (issues, PRs, CI checks)
- Use `aws s3` for file storage operations

Это ускоряет и дебаг: «проверь через gh, почему CI упал на этом PR» — agent сам выполнит команды, прочитает output и действует.

Сохраняй reusable workflows

Skills можно звать через / в agent input — превращаются в именованные workflow на каждый день.

Пример skill /pr:

---
description: Create a pull request for the current changes.
---

1. Look at the staged and unstaged changes with `git diff`
2. Write a clear commit message based on what changed
3. Commit and push to the current branch
4. Use `gh pr create` to open a pull request with title/description
5. Return the PR URL when done

Другие удачные кандидаты:

• /fix-issue [number] — gh issue view → найти код → починить → PR
• /review — линтеры + типичные проблемы + summary
• /update-deps — обновлять зависимости по одной с прогоном тестов

Коммить skills в git — команда шарит одни и те же рычаги.

До и после

Команда на Next.js + Tailwind + Vitest.

До rules: agent тащит Jest (потому что чаще в training data), CSS modules, API routes «куда попало».

После трёх коротких rules:

- Tests use Vitest, not Jest. See `src/__tests__/example.test.ts` for patterns.
- Style with Tailwind utility classes. No CSS modules or styled-components.
- API routes go in `app/api/[resource]/route.ts` following existing patterns.

Теперь conventions по умолчанию. Меньше одних и тех же правок в каждом чате.

Частый fail: over-engineering rules

Соблазн — написать rules на всё. Не надо. Слишком много rules жрут context и путают модель.

Держи набор минимальным и живым. Shared artifact, который команда постоянно подчищает. Нужно редко — клади в skill, не в always-on rule.

Что дальше

Agent подогнан под паттерны команды. В финале соберём end-to-end пример на всём, что прошли.