Перейти к содержимому

Ревью обновленного perf-audit: сильный скилл с парой опасных мест

skills perf-audit performance seo llms-txt

Эта статья - результат рабочей сессии с AI-агентом. Агент фиксирует процесс, я редактирую и дополняю.

Я разобрал обновленный perf-audit не только по SKILL.md, но и по связанным references/, скриптам seo-audit.sh и seo-audit.ps1, а также по плану обновления внутри пакета. Итог короткий: это уже зрелый скилл, у которого появился хороший входной workflow, нормальная развязка между performance-аудитом и llms.txt, и заметно более вменяемая React-часть. Но до состояния “безопасно запускать без оглядки” он пока не дошел.

Если формулировать вердикт в одном абзаце, то perf-audit v1.2.0 хорошо решает задачу оркестрации аудита, но у него есть три места, которые могут дать пользователю неверный сигнал: устаревший пример budget’ов для Lighthouse CI, слишком агрессивные дефолтные маршруты в audit-скриптах и слабая переносимость bash-версии.

Автор скила - Илья Гиндин.

Скачать архив со скилом можно здесь: perf-audit-v1.2.0.zip.

Что в обновлении действительно стало лучше

Первое сильное решение - вынести переписывание текста в отдельный осознанный шаг. Скилл больше не пытается молча “улучшать” copy в процессе технического аудита. Вместо этого он требует явного решения пользователя и ограничивает scope через $humanizer. Это хороший сдвиг, потому что технический аудит и редактура текста часто смешиваются, а потом невозможно понять, что было performance-замечанием, а что просто вкусовой правкой.

Второе сильное решение - перестать трактовать llms.txt как “ещё один SEO-файл”. В версии 1.2.0 это уже отдельная capability со своим reference-документом и отдельными правилами. Это правильная архитектура. llms.txt и llms-full.txt не заменяют robots.txt и sitemap.xml, а решают другую задачу: дают агенту сжатую карту сайта для inference-time retrieval. В самом скилле это объяснено достаточно трезво, без обещаний несуществующего ranking boost.

Третье улучшение - более адекватная React-оптика. В тексте появилась привязка к startTransition, useDeferredValue, useEffectEvent и React Compiler. Это уже похоже на 2026 год, а не на набор универсальных советов из эпохи “заверни всё в useMemo”.

Главные замечания

1. В budget-примере остался interactive, хотя TTI давно убран из Lighthouse

Самое неприятное замечание находится не в prose, а в примере конфигурации. В секции Performance Budgets скилл предлагает такой фрагмент:

{
  "timings": [
    { "metric": "interactive", "budget": 3000 },
    { "metric": "first-contentful-paint", "budget": 1500 }
  ]
}

Проблема в том, что interactive опирается на Time to Interactive. В документации Chrome для Lighthouse прямо сказано, что TTI был удалён как метрика из Lighthouse 10, а вместо него рекомендуют смотреть на LCP, TBT и INP. То есть пример выглядит свежо, но уже тащит устаревшую метрику в CI-конфиг. Для скилла такого уровня это не мелочь: пользователь легко воспримет JSON-блок как готовый шаблон и протащит устаревший budget в пайплайн.

Что бы я сделал: убрал бы interactive совсем и заменил пример на набор budget’ов, который не конфликтует с текущей документацией Chrome. Если нужен lab-oriented fallback, лучше явно писать про LCP и TBT, а не про TTI.

2. Дефолтные маршруты в audit-скриптах конфликтуют с логикой самого скилла

В SKILL.md входной workflow начинается правильно: сначала определить стек и важные public routes. Но оба скрипта сразу подсовывают дефолтные пути "/", "/pricing", "/about". Это плохой компромисс.

Почему это опасно:

То есть сама автоматизация противоречит собственной методологии скилла. Если workflow требует сначала определить важные маршруты, скрипт не должен жёстко навязывать три англоязычных path’а из SaaS-шаблона.

Что бы я сделал: либо требовал бы список путей явно, либо пробовал бы читать sitemap.xml и работать от него, либо хотя бы оставлял по умолчанию только /.

3. Bash-скрипт заявлен как универсальный, но на деле хрупкий

PowerShell-версия выглядит заметно надёжнее, чем seo-audit.sh. В shell-варианте сразу несколько проблем.

Первая - переносимость. Скрипт активно использует grep -P, а это GNU-специфичная история, которая часто ломается на macOS и других средах с BSD grep. Для скилла, который позиционируется как рабочий инструмент для “bash-like environments”, это плохая ставка.

Вторая - подозрительная сборка массива путей:

PATHS=("${@:-/ /pricing /about}")

В Bash такая запись не даёт три отдельных fallback-маршрута. Без пользовательских аргументов она разворачивается как одна строка "/ /pricing /about", а не как три элемента массива. То есть дефолтный запуск shell-скрипта может пойти вообще не по тем URL, по которым автор ожидал.

Третья - сам HTML parsing в shell-версии заметно более хрупкий, чем в PowerShell. Для быстрой диагностики это терпимо, но если уже есть более аккуратная PS-реализация, shell-вариант стоит либо ужесточить и переписать, либо честно сузить обещание по поддерживаемым окружениям.

Что я бы исправил в v1.2.1

Итог

Обновленный perf-audit уже выглядит как полезный production-skill, а не как заметка из личного архива. У него хороший procedural backbone, трезвое отношение к llms.txt, адекватная развязка с копирайтом и современная React-часть. Это сильная база.

Но в ревью я бы поставил акцент не на prose, а на том, что скилл обещает через automation layer. Именно там сейчас основные риски. Если поправить budget-блок и привести скрипты к более честному поведению по маршрутам и окружениям, следующая версия будет заметно надёжнее текущей.

Перед упаковкой я отдельно проверил содержимое архива на явные конфиденциальные данные: пароли, ключи, токены, FTP-реквизиты и приватные ключи. Совпадение нашлось только по слову password внутри документационного примера Vercel Password Protection, без реальных секретов. В архиве нет .env, хостинговых учётных данных или приватных ключей.

Источники

Автор скила

Илья Гиндин

Все записи