vercel-optimize

Vercel Optimize — это навык для наблюдаемого аудита стоимости, производительности и надёжности развёрнутых проектов. Его исходный SKILL.md требует начинать с production-сигналов Vercel, а не с общего поиска по репозиторию. Цель — связать измеряемую проблему с конкретным маршрутом, файлом или настройкой проекта и только после этого формировать ранжированные рекомендации. В README репозитория навык описан как средство анализа расходов и использования функций, медленных или дорогих маршрутов, кэширования, ISR, middleware, изображений и build minutes. Поддерживаемыми фреймворками названы Next.js App Router и Pages Router, SvelteKit и Nuxt; для Astro поддержка ограничена, а Hono, Remix и неизвестный фреймворк блокируются по умолчанию. Для route-level анализа нужны Vercel CLI версии 53 или новее с командами metrics, usage, contract и api, авторизованная сессия через vercel login, привязанный каталог приложения через vercel link и Node.js 20 или новее. Исходник также указывает на необходимость Observability Plus для маршрутных рекомендаций, основанных на метриках. Если проект, команда или аккаунт определены неоднозначно, навык требует остановиться и запросить точную область, а не смешивать данные разных Vercel-проектов. Рабочий процесс начинается со сбора сигналов Vercel, сканирования кода и объединения результатов в signals.json. До дальнейшего анализа проверяются блокеры: поддержка фреймворка, доступность Observability Plus, состояние проекта, трафик, квота и права. При отсутствии трафика результат можно продолжить только как ограниченный аудит; при исчерпанной дневной квоте нужно дождаться сброса. Нельзя молча подменять метрики кодовым аудитом: исходник разделяет полноценный metric-backed режим и явно согласованный limited code-only режим. Следующий этап — детерминированный gate. Он разделяет кандидатов для исследования, рекомендации уровня платформы и записи, которые были пропущены или уже покрыты. Для каждого запущенного кандидата сохраняются наблюдаемые метрики, затем выполняется глубокая проверка и reconciliation. В исходнике перечислены причины, по которым кандидат может быть преобразован в наблюдение без рекомендации: несовпадение метрик, поток ошибок, регрессия развёртывания или наличие только scanner-сигнала без подтверждённого трафика. После этого формируются короткие investigation briefs, а результаты проходят отдельную проверку файлов, ссылок и соответствия версии фреймворка. Навык не разрешает выводить экономию из неподтверждённых предположений. В рекомендациях должны быть конкретные performance-числа из signals.json или evidence.deepDive, проверяемые файлы с номерами строк при изменении кода и допустимая документация для обнаруженной версии фреймворка. Для кэширования нужно называть точную политику. Динамические, авторизованные, ошибочные, fallback-, невалидные, геозависимые и неверсированные ответы нельзя делать статически кэшируемыми без доказательства безопасности. Для streaming, SSE и других намеренно долгих маршрутов одно лишь wall-clock время не считается проблемой: сначала нужны признаки лишней работы до первого байта, высокой активности CPU, дублирующихся вызовов или работы после ответа. Отдельно задано ограничение для Workflow endpoint: нельзя рекомендовать уменьшать длительность `/.well-known/workflow/v1/*`, потому что это маршруты долговечного выполнения шагов. Если затрагиваются Workflow, рекомендация должна назвать изменяемую границу — например, постановку длительной работы в очередь с возвратом идентификатора запуска, исправление replay/closure/lock или сокращение доказанного избытка шагов и хранилища. Таким образом, Vercel Optimize полезен для узкого, доказательного аудита расходов и производительности, но требует корректно привязанного проекта, доступных сигналов и не превращает каждый результат сканера в совет к изменению.