Навыки для coding-агента: измеряем пользу на реальной задаче

Что получится

Мы сравним два режима одного coding-агента при неизменных модели, репозитории, задаче и доступных инструментах:

1. Режим A — универсальный. Агент получает только формулировку задачи и обычные инструкции проекта.
2. Режим B — с навыками. Агент получает ту же задачу, но может применить три локальных руководства: для ревью, проектирования тестов и обновления документации.

После работы останутся следующие артефакты:

• три установленных файла навыков;
• неизменяемый снимок исходной задачи;
• отдельные рабочие каталоги для режимов A и B;
• ответы агента, изменения кода и журналы запусков;
• ручная разметка полноты ревью;
• результаты запуска тестов и проверки документации;
• фактическое время выполнения;
• входные и выходные токены, если их сообщает используемая среда;
• итоговая таблица без заранее назначенного победителя.

Что именно исправляют навыки

Универсальный агент умеет читать код, запускать команды и редактировать файлы. Но просьба «сделай качественно» не определяет, какие проверки обязательны. В одном запуске модель начнёт с тестов, в другом — с реализации, а в третьем ограничится объяснением.

Навык в этой лаборатории — небольшой версионируемый документ с условиями применения, последовательностью действий, критериями завершения и запретами. Это не дополнительная модель и не скрытая база знаний. Навык управляет уже доступными способностями агента.

Важно отличать навык от длинного промпта. Промпт формулирует текущую цель, а навык описывает повторяемый рабочий метод. Если метод полезен для многих задач, его лучше хранить отдельно, версионировать и подключать только по подходящему условию.

Конкретный кейс: резервирование товара

Для сравнения нужна задача, в которой одновременно есть код, тесты и публичная документация. Используйте небольшой учебный сервис или выделите похожий модуль в собственном репозитории. В примере ниже функция резервирует позиции заказа:

def reserve_order(inventory, order):
    reserved = []

    for item in order.items:
        inventory.reserve(item.sku, item.quantity)
        reserved.append(item.sku)

    return {
        "order_id": order.id,
        "reserved": reserved,
    }

Поставим агенту одну задачу:

Проведи ревью функции резервирования, исправь обнаруженные проблемы, добавь необходимые тесты и обнови документацию публичного поведения. Не меняй внешний формат успешного ответа без необходимости. Запусти подходящие проверки и сообщи, что было подтверждено.

До запуска эксперимента человек фиксирует известные требования:

1. Количество должно быть положительным целым числом.
2. Один SKU может встретиться в заказе несколько раз.
3. Если резервирование любой позиции не удалось, ранее сделанные резервы должны быть отменены.
4. Ошибка не должна возвращать частично успешный ответ.
5. Пустой заказ должен обрабатываться согласно явно выбранному контракту.
6. Документация должна описывать атомарность операции и ожидаемые ошибки.

Эти пункты образуют эталон проверки, но не передаются агенту. Иначе эксперимент измерит способность переписать готовый список, а не пользу навыков. Если вы используете собственную задачу, составьте аналогичный эталон до первого запуска.

Почему этот кейс подходит

Изменение достаточно мало для двух повторных запусков, но требует нескольких типов рассуждения. Поверхностный ответ может добавить только тест успешного заказа. Более полный анализ заметит частичный побочный эффект, повторяющиеся позиции, валидацию количества и необходимость описать контракт отказа.

Не подмешивайте в эксперимент секреты, производственные данные или неизвестные сетевые зависимости. Используйте локальные фикстуры и тестовый адаптер склада.

Дизайн сравнения

Сравнение навыков — это небольшой бенчмарк. Чтобы результат можно было объяснить, между режимами должна измениться только доступность навыков.

Зафиксируйте неизменные условия

• одна модель и одна её версия;
• одинаковые параметры генерации, если они настраиваются;
• одинаковый начальный commit;
• одинаковая формулировка задачи;
• одинаковый набор команд и инструментов;
• одинаковый сетевой режим;
• одинаковые ограничения времени и числа шагов;
• чистый кэш зависимостей либо одинаково прогретый кэш;
• отдельные рабочие каталоги без результатов другого режима.

Не сравнивайте последовательные правки в одном каталоге

Второй агент не должен видеть код, тесты, заметки или логи первого. Создайте две независимые рабочие копии из одного commit:

git rev-parse HEAD > experiment/base-sha.txt

git worktree add ../skills-exp-baseline "$(cat experiment/base-sha.txt)"
git worktree add ../skills-exp-skilled  "$(cat experiment/base-sha.txt)"

Если навыки должны находиться внутри репозитория, не добавляйте их только в skilled-копию после создания worktree: это изменит исходное состояние файлов. Храните исследуемые навыки во внешнем каталоге агента либо создайте общий commit с навыками, но в режиме A явно отключите их загрузку. Способ отключения зависит от используемого продукта и должен быть записан в отчёте.

Порядок запусков

При одном запуске порядок имеет небольшое значение, но при серии задач чередуйте режимы: A–B для первой задачи, B–A для второй. Это уменьшает влияние прогрева среды, нагрузки провайдера и обучения человека-оценщика на предыдущем ответе.

Сначала создайте рубрику качества

Метрики определяются до просмотра результатов. Иначе красивый ответ одного режима невольно изменит правила оценки.

Полнота ревью

Для учебного кейса создайте файл experiment/review-rubric.csv:

id,requirement,weight,evidence_rule
R1,"Отмена ранее созданных резервов при поздней ошибке",3,"Назван сценарий частичного резерва и указано место в коде"
R2,"Проверка положительного целого количества",2,"Указан конкретный некорректный ввод"
R3,"Определённое поведение повторяющегося SKU",2,"Рассмотрено суммирование или последовательная обработка"
R4,"Явный контракт пустого заказа",1,"Поведение названо и проверено"
R5,"Отсутствие частично успешного ответа",2,"Есть связь между исключением и внешним контрактом"
R6,"Синхронизация документации",1,"Указаны атомарность и ошибки"

Вес 3 используется для риска нарушения данных, 2 — для существенного поведения, 1 — для полноты контракта. Не меняйте веса после чтения ответов.

Качество тестов

Тест получает балл не за существование файла, а за наблюдаемое свойство:

Документация

Отдельно оцените: указан ли публичный вход, успешный результат, поведение при частичном отказе, допустимые количества, пустой заказ и команда запуска тестов. Максимальный балл документации в этой рубрике — 6.

Набор из трёх навыков

Формат и каталог обнаружения зависят от конкретного агента. Ниже используется переносимая структура: один каталог на навык и файл SKILL.md с метаданными и инструкциями. Если ваша среда требует другой manifest, сохраните смысл и перенесите поля в её формат.

skills-src/
├── evidence-code-review/
│   └── SKILL.md
├── behavior-test-design/
│   └── SKILL.md
└── contract-doc-sync/
    └── SKILL.md

Навык 1. Ревью с доказательствами

Содержимое skills-src/evidence-code-review/SKILL.md:

---
name: evidence-code-review
description: Применяй при ревью изменения кода или поиске дефектов перед правкой.
---

# Evidence-based code review

1. Сначала прочитай задачу, diff и локальные инструкции проекта.
2. Выпиши изменённые публичные контракты, побочные эффекты и границы данных.
3. Для каждого риска сформулируй сценарий отказа:
   вход → состояние → действие → наблюдаемый неверный результат.
4. Проверяй гипотезу по коду, тестам и конфигурации.
5. Не сообщай замечание без конкретного места и доказательства.
6. Отделяй:
   - подтверждённый дефект;
   - риск, требующий дополнительной информации;
   - улучшение стиля.
7. До редактирования составь короткий план исправления.
8. После правки повторно проверь каждый подтверждённый сценарий.

Обязательные классы риска:
- неверная валидация и граничные значения;
- частичные побочные эффекты и откат;
- повторные и конкурентные операции;
- обработка исключений;
- изменение внешнего контракта;
- безопасность и границы доверия.

Формат замечания:
- severity;
- file и строка;
- сценарий отказа;
- доказательство;
- минимальная проверка или исправление.

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

Навык 2. Проектирование тестов по поведению

Содержимое skills-src/behavior-test-design/SKILL.md:

---
name: behavior-test-design
description: Применяй при добавлении, исправлении или оценке автоматических тестов.
---

# Behavior-oriented test design

1. До написания теста составь матрицу:
   поведение, вход, предусловие, наблюдение, ожидаемый результат.
2. Покрой как минимум:
   - типовой успешный путь;
   - границы входных значений;
   - отказ внешней зависимости;
   - частично выполненную последовательность;
   - пустой или отсутствующий ввод, если он допустим;
   - повтор операции, если есть побочный эффект.
3. Проверяй публичное поведение и значимые побочные эффекты.
4. Не привязывайся к внутренней реализации без необходимости.
5. Не ослабляй существующие ожидания ради зелёного запуска.
6. Новый тест дефекта сначала запусти на исходной реализации.
   Он должен упасть по ожидаемой причине.
7. Затем внеси минимальное исправление и запусти:
   - новый тест;
   - тесты модуля;
   - полный доступный набор.
8. Если полный набор запустить нельзя, сообщи точную причину.

Финальный отчёт:
- какие сценарии добавлены;
- какие команды выполнены;
- сколько тестов прошло или упало по фактическому выводу;
- что осталось непроверенным.

Навык 3. Синхронизация контракта и документации

Содержимое skills-src/contract-doc-sync/SKILL.md:

---
name: contract-doc-sync
description: Применяй, когда код меняет публичное поведение, ошибки, конфигурацию или команды использования.
---

# Contract documentation sync

1. Определи аудиторию и публичную точку входа.
2. Сравни прежний и новый контракт:
   входы, выходы, ошибки, побочные эффекты, ограничения.
3. Найди документацию, примеры и комментарии, описывающие этот контракт.
4. Обновляй только подтверждённое поведение.
5. Не обещай гарантий, которых нет в коде и тестах.
6. Для примера использования проверь:
   - имена функций и параметров;
   - формат результата;
   - ожидаемую ошибку;
   - команду запуска.
7. Если пример исполняемый, запусти его или добавь проверку синтаксиса.
8. В финальном отчёте перечисли обновлённые документы и ограничения.

Документация завершена, если читатель может понять:
- что делает операция;
- какие входы допустимы;
- что считается успехом;
- что происходит при ошибке;
- как проверить описанное поведение.

Каждый файл короток намеренно. Навык, который пытается одновременно управлять архитектурой, безопасностью, Git, тестами и документацией, снова превращается в общий расплывчатый промпт.

Установка и проверка обнаружения

Сначала узнайте документированный каталог пользовательских или проектных навыков вашего агента. Не угадывайте путь: некоторые среды читают навыки из репозитория, другие — из пользовательского каталога, третьи требуют регистрации в конфигурации.

Если агент поддерживает проектный каталог .agent/skills, установка выглядит так:

install -d .agent/skills

cp -R skills-src/evidence-code-review .agent/skills/
cp -R skills-src/behavior-test-design .agent/skills/
cp -R skills-src/contract-doc-sync .agent/skills/

find .agent/skills -maxdepth 2 -name SKILL.md -print

Ожидается ровно три пути:

.agent/skills/evidence-code-review/SKILL.md
.agent/skills/behavior-test-design/SKILL.md
.agent/skills/contract-doc-sync/SKILL.md

Затем используйте штатную команду или интерфейс списка навыков. Поскольку синтаксис различается между продуктами, в журнале эксперимента запишите фактическую команду, а не переносите неподходящий пример.

Проверка обнаружения:
[ ] evidence-code-review отображается в списке
[ ] behavior-test-design отображается в списке
[ ] contract-doc-sync отображается в списке
[ ] описание каждого навыка доступно агенту
[ ] в режиме A загрузка этих навыков отключена
[ ] в режиме B разрешены все три навыка

Проверьте не только наличие файлов

Файл может находиться в правильном каталоге, но не загружаться из-за ошибки метаданных. Дайте агенту безопасный диагностический запрос: «Какие навыки применимы к задаче ревью, тестов и документации? Назови их, ничего не меняя». В режиме B должны появиться три установленных имени. В режиме A их быть не должно.

Сохраните диагностический ответ. Если агент не видит навык, не продолжайте сравнение: вы будете измерять два одинаковых режима.

Запуск режима A: универсальный агент

Перейдите в baseline-копию, убедитесь в чистом состоянии и сохраните идентификатор commit:

cd ../skills-exp-baseline
git status --short
git rev-parse HEAD
python -m pytest

Начальный тестовый набор должен проходить. Если он уже красный, зафиксируйте известные падения либо выберите другой commit. Нельзя приписывать агенту ошибку, существовавшую до эксперимента.

Сохраните формулировку задачи в отдельном файле и передайте её без дополнительных подсказок:

Проведи ревью функции резервирования, исправь обнаруженные проблемы,
добавь необходимые тесты и обнови документацию публичного поведения.
Не меняй внешний формат успешного ответа без необходимости.
Запусти подходящие проверки и сообщи, что было подтверждено.

Не помогайте агенту во время запуска. Если он задаёт вопрос, ответ должен предоставлять только действительно отсутствующий факт и затем дословно повторяться в режиме B. Все такие сообщения добавьте в журнал.

После завершения сохраните:

git status --short > experiment-status.txt
git diff --stat    > experiment-diff-stat.txt
git diff           > experiment.patch
git rev-parse HEAD > experiment-base-sha.txt

Сохраните также полный финальный ответ агента и сырой журнал среды. Не коммитьте исправление до завершения оценки: патч должен оставаться напрямую сравнимым с исходным состоянием.

Запуск режима B: агент с навыками

Повторите начальную проверку в skilled-копии. Commit, тесты и формулировка задачи должны совпадать с режимом A.

cd ../skills-exp-skilled
git status --short
git rev-parse HEAD
python -m pytest

Разрешите загрузку трёх навыков, но не объясняйте агенту, какой именно дефект он должен найти. Навыки должны выбрать метод, а не раскрыть ответ.

После завершения сохраните те же артефакты:

git status --short > experiment-status.txt
git diff --stat    > experiment-diff-stat.txt
git diff           > experiment.patch
git rev-parse HEAD > experiment-base-sha.txt

В журнале отметьте, какие навыки агент фактически открыл. Наличие навыка в каталоге ещё не означает его применения. Если среда записывает события чтения файлов или активации навыков, используйте эти события. Если нет, опирайтесь на явное сообщение агента, но пометьте доказательство как косвенное.

Сбор времени и расхода контекста

Для времени используйте монотонный таймер среды или системную утилиту. Внешняя команда агента различается, поэтому задайте её переменной:

AGENT_CMD="команда-запуска-вашего-агента"

/usr/bin/time \
  -f '{"elapsed_seconds":%e,"max_rss_kb":%M,"exit_code":%x}' \
  -o timing.json \
  sh -c "$AGENT_CMD" \
  > agent-output.txt \
  2> agent-events.txt

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

Что считать расходом контекста

Сохраните раздельно:

• input tokens total — сумма входных токенов всех обращений к модели;
• output tokens total — сумма выходных токенов;
• cached input tokens — кэшированная часть, если провайдер её сообщает;
• peak context tokens — максимальный размер одного запроса, если доступен;
• model calls — число обращений к модели;
• tool calls — число вызовов инструментов;
• files read — число уникальных прочитанных файлов, если это видно в трассе.

Не оценивайте токены по размеру текстового журнала: системные инструкции, схемы инструментов, кэш и скрытая служебная часть могут не попадать в экспорт. Если среда не сообщает usage, укажите недоступно. Честное пустое поле полезнее выдуманной точности.

Единая таблица сырых измерений:

mode,run_id,base_sha,model,input_tokens,output_tokens,cached_input_tokens,peak_context_tokens,model_calls,tool_calls,elapsed_seconds
baseline,A1,<sha>,<model>,,,,,,,
skills,B1,<sha>,<model>,,,,,,,

Оценка полноты ревью

Сначала скройте обозначение режима. Попросите оценщика читать ответы и патчи как «вариант X» и «вариант Y». Для каждого пункта рубрики присвойте один из статусов:

• found — риск назван, привязан к коду и объяснён через сценарий отказа;
• partial — тема упомянута, но нет доказательства или наблюдаемого последствия;
• missed — риск отсутствует;
• not_applicable — требование оказалось неприменимо после проверки кода.

Для расчёта используйте:

review_completeness =
  Σ(weight × score) / Σ(applicable_weight)

где:
found   = 1
partial = 0.5
missed  = 0

Не ставьте полный балл за фразу «нужно добавить обработку ошибок». Полноценное замечание должно объяснять, что произойдёт: например, первая позиция останется зарезервированной, когда резервирование второй завершится исключением.

Ложные замечания

Отдельно считайте утверждения о дефекте, которые опровергаются кодом или тестом. Полнота без точности бесполезна: агент может перечислить все типовые риски, но заставить разработчика вручную проверять каждый.

review_precision =
  confirmed_findings / all_defect_findings

Рекомендации по стилю не включайте в знаменатель, если агент честно пометил их как необязательные улучшения.

Оценка качества тестов

Простого зелёного запуска недостаточно. Тест может проходить и ничего не доказывать. Проверьте четыре уровня.

1. Исполняемость

python -m pytest -q

Запишите фактический код выхода и сводку. Не переносите число пройденных тестов из финального сообщения агента без сверки с выводом команды.

2. Способность поймать исходный дефект

Скопируйте только новые тесты в чистую исходную версию либо временно примените обратную часть исправления. Новые тесты на дефект должны падать по ожидаемой причине.

git diff -- tests/ > new-tests.patch

git worktree add ../skills-exp-mutation "$(cat experiment/base-sha.txt)"
cd ../skills-exp-mutation
git apply ../skills-exp-skilled/new-tests.patch
python -m pytest -q

Если тесты не отделяются от производственного кода чистым патчем, примените изменения тестовых файлов вручную и зафиксируйте это в отчёте. Не используйте непроверенную автоматическую мутацию, способную изменить смысл теста.

3. Проверка наблюдаемого эффекта

При позднем сбое тест должен проверять не только исключение, но и состояние тестового склада:

with pytest.raises(InventoryUnavailable):
    reserve_order(inventory, order)

assert inventory.reserved_quantity("SKU-1") == 0
assert inventory.reserved_quantity("SKU-2") == 0

Если реализация использует компенсацию, полезна также проверка порядка вызовов. Но не проверяйте частные имена локальных переменных или число внутренних функций, если это не часть контракта.

4. Стабильность

Повторите новый набор несколько раз только для обнаружения нестабильности, а не для искусственного увеличения числа тестов:

for run in 1 2 3 4 5
do
  python -m pytest -q tests/test_reservation.py || exit 1
done

Пять успешных запусков не доказывают отсутствие нестабильности, но один непоследовательный провал уже показывает проблему. Для конкурентного кода нужен отдельный стресс-тест и более длинная серия.

Оценка документации

Сравните текст с фактическим публичным контрактом. Для каждого утверждения найдите подтверждение в реализации или тесте.

Если документация обещает «операция всегда атомарна», а откат сам может завершиться ошибкой, формулировка слишком сильная. Корректнее описать гарантии и известные границы компенсации.

Соберите сравнительный отчёт

Не заполняйте таблицу по памяти. Каждая ячейка должна ссылаться на ответ, diff, трассу или вывод команды.

Как написать вывод

Используйте структуру из четырёх частей:

1. Наблюдение. Какие метрики фактически различаются.
2. Доказательство. Где находятся исходные данные.
3. Интерпретация. Какой навык мог повлиять на различие.
4. Решение. Где набор стоит применять, а где цена слишком высока.

Корректный шаблон вывода:

В этой задаче режим B обнаружил [число] из [число] применимых рисков, а режим A — [число]. Дополнительные находки подтверждены тестами [идентификаторы]. Режим B потребовал [значение] входных токенов и [значение] секунд против [значения] у режима A. Поэтому набор принимается для [тип задач], но пока не распространяется на [непроверенный класс задач].

Если разницы нет, так и напишите. Возможные объяснения: исходный промпт уже задавал тот же процесс, задача слишком проста, навыки не активировались или модель и без них стабильно выполняет контракт.

Проверка честности эксперимента

Перед публикацией результата выполните контрольный список:

1. Оба каталога созданы из одного SHA.
2. Формулировки задач совпадают посимвольно.
3. Модель и параметры не менялись.
4. Режим A не видел содержимое навыков.
5. Режим B действительно обнаружил и применил навыки.
6. Эталонные требования записаны до запуска.
7. Баллы не менялись после просмотра ответов.
8. Все числа взяты из сохранённых журналов.
9. Новые тесты проверены на исходной реализации.
10. Полный доступный набор тестов запущен для обоих вариантов.
11. Документация сверена с кодом, а не только прочитана на естественность.
12. Неизмеримые данные обозначены как недоступные.

Повторный запуск

Один парный запуск показывает конкретный случай, но плохо измеряет стабильность. Если бюджет позволяет, повторите оба режима три раза из чистого состояния. Не выбирайте лучший ответ из трёх: покажите медиану времени и токенов, диапазон качества и долю запусков, в которых найден каждый критический риск.

finding_consistency =
  runs_where_finding_was_confirmed / total_runs

Именно согласованность по запускам отвечает на исходную проблему непоследовательного поведения.

Типичные провалы

Навыки установлены, но не активируются

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

Агент читает все навыки на каждой задаче

Это увеличивает контекст и размывает приоритеты. Уточните описания: навык тестирования нужен при работе с тестами, а документационный — при изменении публичного контракта. Не делайте каждый навык «обязательным всегда».

Навык содержит ответ конкретного кейса

Если в инструкции прямо сказано проверить повторяющийся SKU и откат резерва, сравнение становится утечкой эталона. Навык должен перечислять общие классы риска: границы, повторы, частичные побочные эффекты и ошибки зависимостей.

Режим B получает более подробную задачу

Дополнительная фраза «обязательно проверь атомарность» способна объяснить весь выигрыш. Храните запрос в одном файле и передавайте его обоим агентам без ручного редактирования.

Качество измеряется количеством строк

Большой diff не равен хорошему исправлению. Агент может переписать модуль, добавить хрупкие моки и создать новые риски. Оценивайте наблюдаемое поведение и минимальность изменения отдельно.

Зелёные тесты принимаются без отрицательного контроля

Новый тест может проходить до исправления. Обязательная проверка на исходной реализации отделяет регрессионный тест от декоративного.

Финальный ответ считается доказательством

Фраза агента «все тесты проходят» не заменяет сохранённый вывод команды. Такая наблюдаемость особенно важна, если выполнение прервалось по лимиту или часть вывода была скрыта.

Время сравнивается при разном состоянии среды

Первый запуск может устанавливать зависимости или прогревать кэш. Подготовьте окружение заранее либо учитывайте подготовку одинаково для обоих режимов.

Ограничения метода

Один кейс не доказывает универсальную пользу набора. Навыки могут хорошо работать на небольшом Python-сервисе и мешать в монорепозитории, мобильном приложении или инфраструктурной миграции.

Ручная оценка ревью содержит субъективность. Снизить её помогают заранее записанная рубрика, слепые обозначения вариантов и второй оценщик для спорных замечаний.

Потребление токенов зависит не только от навыков. На него влияют реализация агента, схема инструментов, повторное чтение файлов, кэширование, сжатие истории и скрытые системные инструкции. Сравнение действительно только внутри закреплённой среды.

Тест на откат показывает поведение учебного адаптера, но не доказывает транзакционность реального распределённого склада. Внешние системы могут требовать идемпотентных команд, очередей или отдельного процесса компенсации.

Наконец, навык устаревает вместе с кодовой базой. Если команда меняет тестовый фреймворк, формат документации или правила ревью, инструкции необходимо обновить и снова прогнать сравнительный набор.

Перенос в рабочий проект

После эксперимента оформите использование навыков как версионируемый рабочий процесс:

1. Храните исходники навыков рядом с кодом или в контролируемом общем репозитории.
2. Назначьте владельца каждого навыка.
3. Добавьте номер версии или SHA набора в журналы запусков.
4. Подключайте только навыки, соответствующие задаче.
5. Проверяйте метаданные и обнаружение в CI.
6. Держите небольшой eval-набор из реальных обезличенных задач.
7. После изменения навыка повторяйте режимы A и B на закреплённых задачах.
8. Не принимайте обновление, если полнота растёт ценой неприемлемого числа ложных замечаний.
9. Следите за временем и некэшированными входными токенами.
10. Удаляйте правила, которые не влияют на наблюдаемое поведение.

Практический критерий принятия

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

Если навык улучшает тесты, но заметно удорожает простое исправление опечатки, используйте маршрутизацию. Небольшие локальные задачи могут выполняться без полного набора, тогда как изменения побочных эффектов, публичных интерфейсов и обработки ошибок должны активировать соответствующие инструкции.

Короткий чек-лист повторения

1. Выберите задачу, затрагивающую код, тесты и документацию.
2. Запишите эталонные риски до запуска агента.
3. Зафиксируйте модель, параметры, SHA и окружение.
4. Создайте независимые рабочие каталоги A и B.
5. Установите три навыка и проверьте их обнаружение.
6. Убедитесь, что в режиме A навыки недоступны.
7. Передайте обоим режимам идентичную задачу.
8. Сохраните ответы, патчи, команды и сырые журналы.
9. Проверьте новые тесты на исходной реализации.
10. Оцените ревью, тесты и документацию по заранее заданной рубрике.
11. Заполните время и usage только фактическими данными.
12. Повторите пару запусков для оценки согласованности.
13. Примите, ограничьте или отклоните набор по измеренному результату.