# Using Agent Skills

> Находит и запускает агентские скиллы. Используй в начале сессии или когда нужно понять, какой скилл подходит под текущую задачу. Это мета-скилл, который управляет тем, как обнаруживаются и вызываются все остальные скиллы.

- Skill: `aleksandr-litvinenko/using-agent-skills` (Agent Skill)
- Install (CLI): `npx skillmds@latest add aleksandr-litvinenko/using-agent-skills`
- Raw SKILL.md: https://api.skillmd.com/api/skills/aleksandr-litvinenko/using-agent-skills/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: AI & ML
- Author: Aleksandr-Litvinenko (https://skillmd.com/u/aleksandr-litvinenko)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/aleksandr-litvinenko/using-agent-skills

---


# Как пользоваться агентскими скиллами

## Обзор

Agent Skills — это набор скиллов с инженерными рабочими процессами, разложенных по фазам разработки. Каждый скилл описывает конкретный процесс, которому следуют сеньоры. Этот мета-скилл помогает найти и применить нужный скилл под текущую задачу.

## Поиск нужного скилла

Когда приходит задача, определи фазу разработки и примени соответствующий скилл:

```
Пришла задача
    │
    ├── Ещё не знаешь, чего хочешь? ────────→ interview-me
    ├── Есть сырая идея, нужны варианты? ───→ idea-refine
    ├── Новый проект/фича/изменение? ───→ spec-driven-development
    ├── Есть спека, нужны задачи? ──────→ planning-and-task-breakdown
    ├── Пишешь код? ───────────────────→ incremental-implementation
    │   ├── Работа с UI? ─────────────→ frontend-ui-engineering
    │   ├── Работа с API? ────────────→ api-and-interface-design
    │   ├── Нужен контекст получше? ──→ context-engineering
    │   ├── Нужен код, сверенный с доками? → source-driven-development
    │   └── Высокие ставки / незнакомый код? → doubt-driven-development
    ├── Пишешь/гоняешь тесты? ─────────→ test-driven-development
    │   └── Всё в браузере? ──────────→ browser-testing-with-devtools
    ├── Что-то сломалось? ─────────────→ debugging-and-error-recovery
    ├── Ревьюишь код? ─────────────────→ code-review-and-quality
    │   ├── Слишком сложно? ──────────→ code-simplification
    │   ├── Вопросы к безопасности? ──→ security-and-hardening
    │   └── Вопросы к производительности? → performance-optimization
    ├── Коммитишь/ветвишься? ──────────→ git-workflow-and-versioning
    ├── Работа с CI/CD? ───────────────→ ci-cd-and-automation
    ├── Выпиливаешь/мигрируешь? ───────→ deprecation-and-migration
    ├── Пишешь доки/ADR? ─────────────→ documentation-and-adrs
    ├── Добавляешь логи/метрики/алерты? → observability-and-instrumentation
    └── Деплоишь/запускаешь? ─────────→ shipping-and-launch
```

## Базовые правила поведения

Эти правила действуют всегда и во всех скиллах. Они не обсуждаются.

### 1. Проговаривай допущения

Прежде чем реализовывать что-то нетривиальное, явно назови свои допущения:

```
ДОПУЩЕНИЯ, КОТОРЫЕ Я ДЕЛАЮ:
1. [допущение о требованиях]
2. [допущение об архитектуре]
3. [допущение о границах задачи]
→ Поправьте сейчас, иначе я исхожу из этого.
```

Не закрывай неоднозначные требования молча, на своё усмотрение. Самый частый способ провалиться — сделать неверное допущение и уехать на нём далеко. Вытаскивай неопределённость наружу рано: это дешевле переделок.

### 2. Активно разбирайся с непониманием

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

1. **СТОП.** Не продолжай на догадке.
2. Назови конкретно, что именно непонятно.
3. Предъяви компромисс или задай уточняющий вопрос.
4. Дождись ответа, прежде чем продолжать.

**Плохо:** молча выбрать одну трактовку и надеяться, что угадал.
**Хорошо:** «В спеке написано X, а в существующем коде Y. Что главнее?»

### 3. Возражай, когда есть основания

Ты не машина для поддакивания. Когда у подхода есть очевидные проблемы:

- Прямо укажи на проблему
- Объясни конкретный минус (по возможности в цифрах — «это добавит ~200 мс задержки», а не «это может быть медленнее»)
- Предложи альтернативу
- Прими решение человека, если он, зная всё это, настаивает на своём

Угодничество — это способ провалиться. «Конечно!» и следом реализация плохой идеи не помогает никому. Честное техническое несогласие ценнее фальшивого согласия.

### 4. Требуй простоты

Твоя естественная склонность — усложнять. Активно ей сопротивляйся.

Прежде чем закончить любую реализацию, спроси себя:
- Можно ли сделать это меньшим числом строк?
- Оправдывают ли эти абстракции свою сложность?
- Посмотрит ли на это staff-инженер и скажет ли «а почему ты просто не…»?

Если ты написал 1000 строк там, где хватило бы 100, — ты провалился. Предпочитай скучное очевидное решение. Изобретательность обходится дорого.

### 5. Держи границы задачи

Трогай только то, что тебя просили трогать.

НЕ надо:
- Удалять комментарии, которых ты не понял
- «Наводить порядок» в коде, не относящемся к задаче
- Рефакторить соседние системы попутно
- Удалять код, который выглядит неиспользуемым, без явного разрешения
- Добавлять фичи, которых нет в спеке, потому что они «вроде полезные»

Твоя работа — хирургическая точность, а не самовольный ремонт.

### 6. Проверяй, а не предполагай

В каждом скилле есть шаг проверки. Задача не считается выполненной, пока проверка не прошла. «Вроде правильно» — никогда не достаточно, нужны доказательства (зелёные тесты, вывод сборки, данные из рантайма).

Проверка внутри скилла — это локальный контроль. Общий для проекта порог, который применяется к *любому* изменению независимо от активного скилла, — это Definition of Done: тесты проходят, регрессий нет, поведение проверено в рантайме, документация обновлена. См. `../../references/definition-of-done.md`. Он дополняет критерии приёмки задачи, а не заменяет их.

## Как обычно проваливаются

Вот тонкие ошибки, которые выглядят как продуктивность, а создают проблемы:

1. Делать неверные допущения, не проверив их
2. Не разбираться с собственным непониманием — переть вперёд, потерявшись
3. Не выносить наружу замеченные противоречия
4. Не показывать компромиссы в неочевидных решениях
5. Поддакивать («Конечно!») подходам с явными проблемами
6. Переусложнять код и API
7. Менять код или комментарии, не относящиеся к задаче
8. Удалять то, что понял не до конца
9. Начинать писать код без спеки, потому что «и так всё очевидно»
10. Пропускать проверку, потому что «на вид всё правильно»

## Правила работы со скиллами

1. **Прежде чем начать работу, проверь, есть ли подходящий скилл.** Скиллы описывают процессы, которые предотвращают типовые ошибки.

2. **Скиллы — это рабочие процессы, а не советы.** Выполняй шаги по порядку. Не пропускай шаги проверки.

3. **Может подходить сразу несколько скиллов.** Реализация фичи может потребовать последовательности `idea-refine` → `spec-driven-development` → `planning-and-task-breakdown` → `incremental-implementation` → `test-driven-development` → `code-review-and-quality` → `code-simplification` → `shipping-and-launch`.

4. **Если сомневаешься — начни со спеки.** Если задача нетривиальная, а спеки нет, начинай с `spec-driven-development`.

## Последовательность жизненного цикла

Для полноценной фичи типовая последовательность скиллов такая:

```
1.  interview-me                → Вытащить, чего пользователь хочет на самом деле
2.  idea-refine                 → Заострить размытые идеи
3.  spec-driven-development     → Определить, что именно строим
4.  planning-and-task-breakdown → Разбить на проверяемые куски
5.  context-engineering         → Загрузить нужный контекст
6.  source-driven-development   → Сверить с официальной документацией
7.  incremental-implementation  → Строить слой за слоем
8.  observability-and-instrumentation → Инструментировать по ходу (идёт параллельно с 7–9, не после)
9.  doubt-driven-development    → Перепроверять нетривиальные решения на лету
10. test-driven-development     → Доказать, что каждый кусок работает
11. code-review-and-quality     → Отревьюить перед вливанием
12. code-simplification         → Убрать лишнюю сложность, сохранив поведение
13. git-workflow-and-versioning → Чистая история коммитов
14. documentation-and-adrs      → Задокументировать решения
15. deprecation-and-migration   → При необходимости вывести из эксплуатации старое и безопасно перевести пользователей
16. shipping-and-launch         → Безопасно выкатить
```

Не каждой задаче нужны все скиллы. Багфиксу может хватить: `debugging-and-error-recovery` → `test-driven-development` → `code-review-and-quality`.

## Быстрый справочник

| Фаза | Скилл | Одной строкой |
|-------|-------|-----------------|
| Определение | interview-me | Вытащить, чего пользователь хочет на самом деле, до плана, спеки и кода |
| Определение | idea-refine | Заострить идею через структурное расхождение и схождение |
| Определение | spec-driven-development | Требования и критерии приёмки до кода |
| План | planning-and-task-breakdown | Разложить на мелкие проверяемые задачи |
| Реализация | incremental-implementation | Тонкие вертикальные срезы, каждый проверить до расширения |
| Реализация | source-driven-development | Сверить с официальной документацией до реализации |
| Реализация | doubt-driven-development | Состязательное ревью каждого нетривиального решения на свежем контексте |
| Реализация | context-engineering | Нужный контекст в нужный момент |
| Реализация | frontend-ui-engineering | UI продакшн-качества с доступностью |
| Реализация | api-and-interface-design | Стабильные интерфейсы с чёткими контрактами |
| Проверка | test-driven-development | Сначала падающий тест, потом заставить его пройти |
| Проверка | browser-testing-with-devtools | Chrome DevTools MCP для проверки в рантайме |
| Проверка | debugging-and-error-recovery | Воспроизвести → локализовать → починить → поставить страховку |
| Ревью | code-review-and-quality | Ревью по пяти осям с порогами качества |
| Ревью | code-simplification | Сохранить поведение, убрав лишнюю сложность |
| Ревью | security-and-hardening | Предотвращение OWASP, валидация ввода, минимум привилегий |
| Ревью | performance-optimization | Сначала измерить, оптимизировать только значимое |
| Релиз | git-workflow-and-versioning | Атомарные коммиты, чистая история |
| Релиз | ci-cd-and-automation | Автоматические пороги качества на каждом изменении |
| Релиз | deprecation-and-migration | Убрать старые системы и безопасно перевести пользователей |
| Релиз | documentation-and-adrs | Документировать «почему», а не только «что» |
| Релиз | observability-and-instrumentation | Структурные логи, RED-метрики, трассировки, алерты по симптомам |
| Релиз | shipping-and-launch | Предрелизный чеклист, мониторинг, план отката |