Вместо этого поста я мог бы просто дать вот эту ссылку https://github.com/affaan-m/ECC/tree/main/skills
И порекомендовать медленно промотать содержимое страницы, обращая внимание на назначение скилов.

Но все же прокомментирую)

Первый набор скилов по ссылке выше:
- accessibility
- article-writing
- benchmark-methodology
- brand-discovery
- content-engine
- cost-tracking
- design-system
- healthcare-phi-compliance
- investor-materials
- scientific-thinking-literature-review
- seo

Что у них общего?
При чем тут разработка вообще?

А вот второй набор:
- android-clean-architecture
- angular-developer
- codebase-onboarding
- cpp-coding-standards
- django-tdd
- frontend-patterns
- golang-patterns
- java-coding-standards
- jpa-patterns
- kotlin-coroutines-flows
- kubernetes-patterns
- perl-patterns
- python-patterns
- quarkus-tdd
- rust-patterns
- springboot-patterns

Да, у skill есть прогрессивное раскрытие - вначале загружается frontmatter - заголовок, потом все остальное.
Но держать в контексте 250+ скилов - такое себе.
А еще там есть команды и субагенты)))
И хуки https://github.com/affaan-m/ECC/tree/main/hooks.

Тут проблема даже в другом - как выбрать необходимое среди 250 скилов?
Я вижу вариант - брать только то, что кто-то тестировал или по знакомым словам - java, kotlin, spring.
Вроде как в выборе должен помочь скил ecc-guide, но мне не помог(
Авторы в readme рекомендуют скопировать только нужное, да.
Но... зачем собирать такой "божественный репозиторий"?
Если ограничений на тематику нет - то сколько там будет скилов через год? 1000?

При этом судя по названию скилов, число звезд репозитория и по тому факту, что авторы выиграли в хакатоне Claude - полезные штуки там есть.
Та же /code-review команда мне понравилась.

Выглядят интересно хуки:
Strategic compact: Suggests manual /compact at logical intervals.
Git push reminder: Reminds to review changes before git push
Pre-commit quality check: linter (JS, Python, Go), validates commit message format, поиск секретов.
Quality Gate after file edit: автоформат, как в IDEA, тоже только для JS, Python, Go
Сonfig protection: запрет на редактирование конфига линтера.

И одна интересный, но спорный хук: Fact Forcing gate.
Не заметить его сложно, т.к. на каждое редактирование файла будет просьба к агенту предоставить факты:
- какие файлы проекта зависят от текущего (imports)
- какие публичные API меняются
- формат изменяемых файлом внешних данных
- исходный запрос пользователя
Идея в том, что собрав эту информацию агент должен сам себе задать вопрос - все ли правильно он делает?
Такая более продвинутая версия вопроса - "ты уверен?"
Срабатывает на первое редактирование файла в сессии, создание нового, а также на выполнение деструктивных команд.
Последнее так не решается, от деструктивных команд нужно защищаться на уровне репозитория git\прав доступа, но пусть будет.
Замедляет работу, очевидно, но возможно польза есть, наблюдаю.

Итого: интересная штука, но ребята, зачем вы плагин в помойку превратили??? Они не для этого.

P.S. Что-то не верится, что все это люди накодили)
P.P.S. Как они это поддерживать собираются?

#ai #harness

В AI разработке только и разговоров что об evals)

Что это за зверь такой?

По сути это приемочные тесты, наличие которых - базовое отличие разработки с AI от вайб-кодинга.
Что это на практике?

Если речь про архитектуру и аналитику:
1) проверки формата полученного артефакта - структура файлов, структура разделов внутри,
2) наличие обязательных элементов
3) единообразие терминов
4) ограничение по размеру
5) банально правильная нумерация разделов и ссылок

Если речь про разработку - сразу стоит подсветить важный нюанс.
Агент сам пишет тесты и даже следует TDD (см. предыдущие серии)
И поэтому рассматривать наличие тестов как eval - неправильно, мы их содержимым особо не управляем.
Но при этом тесты - лучшие eval.
Поэтому в самой постановке задачи должны быть проверяемые требования, которые превратятся в генерируемые агентом тесты.
unit или интеграционные - не критично, зависит от уровня, на котором можно проверить работу фичи.
И вот наличие таких приемочных тестов и их прохождение - это уже evals.

Также evals - это успешные проверки линтеров (Checkstyle к примеру) и внешних статических анализаторов кода (SonarQube, Checkmarx, ...).
Сюда же процент покрытия тестами нового кода из SonarQube.
С линтерами есть важный момент - агент в теории может поменять их настройки. Это запрещается через хуки, есть такой хук в ECC плагине https://t.me/javaKotlinDevOps/610
Можно втащить к себе в проект как часть плагина или просто позаимствовать адаптировав под свои файлы настроек.

Еще в качестве evals могут выступать:
- запрет на использование тех или иных библиотек\классов (по всему проекту или в отдельных модулях)
- запрет циклических ссылок (spring beans, ArchUnit)
- запрет на "ломающие" изменения в API или БД
- наличие JavaDoc в определенных местах
- требования к SQL скриптам, например, наличие CREATE INDEX CONCURRENTLY
- время выполнения вызова
...
В общем все, что выполняется достаточно быстро и без сложных интеграций, имеет смысл сделать evals и проверять пораньше.
Ну и один из самых важных evals - соответствие реализации постановке.
В целом все это уже должно было проверяться в CI pipeline с одним исключением, о котором ниже.

Как оформить evals? Как и все остальное - в виде скила.
И тут еще один важный нюанс.
Любую проверку можно выполнить 3 способами:
- запуск кода (тест или shell скрипт)
- просьба сделать проверку агенту
- запуск нового CLI агента в headless режиме

Всегда, когда это технически возможно, стоит использовать первый вариант.
Почему?
AI все-таки по природе своей ленив - любит быстро достигать результата.
Т.е. на явную просьбу что-то проверить в скиле он может сказать: "все ок"- ничего не проверяя. Или даже написать - проверь сам.
Да, он может "подшаманить" скрипт проверки, чтобы пройти дальше.
С последним нужно бороться хуками с запретом на редактирование.
А с первым как раз помогает "хардкод" проверки.
А еще вызов LLM всегда дороже по времени.

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

И вот как раз возможность проверки кода LLM моделью и есть важный бонус, которого ранее не было в CI pipeline.
Но, повторюсь, использовать с осторожностью)

У кого был опыт написания evals для агента - делитесь, что еще можно проверить?

#ai #harness #ai_agents