deploy-to-vercel

deploy-to-vercel — навык для управляемого развёртывания приложений и сайтов в Vercel. Его основная задача — сначала собрать состояние проекта, а затем выбрать подходящий путь публикации. В описанном workflow проверяются git remote, локальная связь проекта с Vercel через .vercel/project.json или .vercel/repo.json, доступность CLI и текущая учётная запись через vercel whoami, а также список команд через vercel teams list. Такая последовательность помогает понять, к какому проекту и команде относится рабочая копия, прежде чем запускать операцию. По умолчанию навык ориентирован на preview deployment. Production-вариант рассматривается только тогда, когда его явно запросили. Если каталог уже связан с Vercel и у репозитория есть git remote, рекомендуемый долгосрочный путь — Git-интеграция: перед push нужно получить явное разрешение, после чего изменения можно закоммитить и отправить в удалённый репозиторий. Ветки, отличные от production-ветки, получают preview deployment; push в production-ветку может запустить production-развёртывание согласно настройке проекта. Ссылку на последний preview навык предлагает искать через vercel ls. Когда связь с Vercel есть, но git remote отсутствует, используется vercel deploy с ключом --no-wait, чтобы команда быстро вернула URL, а состояние сборки затем проверялось через vercel inspect. Production-флаг --prod не является значением по умолчанию. Если проект не связан, но CLI авторизован, навык предлагает выбрать команду, передать её slug через --scope и связать проект через vercel link. Для репозитория с remote предусмотрен repo-based link; без remote используется обычная интерактивная привязка. Это разделяет обнаружение состояния, выбор владельца и сам deploy. В среде без авторизации предусмотрен запасной сценарий с deploy-скриптом. Он определяет фреймворк по package.json, упаковывает проект без node_modules, .git и .env, загружает архив, ждёт завершения сборки и возвращает preview URL вместе с claim URL. Такой режим удобен для временной проверки, но передаёт управление проектом через отдельное предъявление claim-ссылки. Навык также прямо ограничивает автоматизацию: нельзя молча публиковать production, нельзя делать push без разрешения пользователя и нельзя заменять проверку состояния неявным выбором команды. Поэтому он подходит для повторяемой процедуры публикации, когда важны team scope, разделение preview и production, а также понятный результат операции; он не отменяет требования Vercel к авторизации, связи проекта, сборке и правам доступа.