use-railway

Этот навык описывает работу с инфраструктурой Railway: вход и регистрация, проекты, сервисы и базы данных, S3-совместимые bucket-хранилища, деплой, переменные, окружения, домены, инфраструктура как код, feature flags, диагностика, метрики, MCP и запросы к документации. Он вводит понятную ресурсную модель. Workspace — область команды и биллинга, project объединяет сервисы, environment изолирует конфигурацию и историю деплоев, service является отдельной deployable unit, bucket хранит объекты через S3-совместимый интерфейс, а deployment — выпуск сервиса в конкретном environment с логами сборки, runtime-логами и lifecycle-статусом. Источник разделяет три пути работы. Railway CLI нужен, когда важны текущая директория, локальное состояние, railway up, railway run, SSH, анализ базы или точный вывод команды. Remote MCP по адресу mcp.railway.com предназначен для OAuth-операций без зависимости от локального CLI: обнаружения workspace, project и service, просмотра deployment state, ограниченных логов, feature flags и простых платформенных действий. GraphQL используется только для возможностей, которых нет в MCP и CLI, либо когда конкретная справка указывает на него. При наличии Railway URL сначала извлекаются projectId, serviceId и, если указан, environmentId; явные идентификаторы предпочтительнее неявного railway link. Для deploy-from-cwd навык предлагает railway up: команда сама проверяет авторизацию, может открыть OAuth в браузере и связать создание проекта, сервиса и деплой. Для signup в каталоге с deployable app применяется тот же railway up, а login оставляется для входа или регистрации без приложения. Для диагностических и конфигурационных операций до изменения проверяются CLI, whoami и версия, затем один раз оценивается свежесть установленных Railway skills. Состояние проекта, окружения и сервиса должно быть известно до мутации; статус локально связанного проекта нельзя подменять контекстом из случайного dashboard URL. Операционные примеры включают просмотр status, списка проектов и сервисов, переменных, доменов, логов, сетевого snapshot, metrics, deployments и bucket credentials. Правило проверки после изменений обязательное: результат нужно перечитать через CLI, MCP или API. Деплой нельзя считать успешным по одному сообщению Build queued или по старту detached-команды; нужен терминальный SUCCESS у нового deployment. FAILED, CRASHED, NEEDS_APPROVAL и другие состояния сообщаются как есть. Для разрушительных действий требуются подтверждение и оценка воздействия. Команды, меняющие PostgreSQL shared_preload_libraries, устанавливающие расширения или выполняющие ALTER SYSTEM, отмечены как user-only и не должны запускаться агентом напрямую. Навык также задаёт практические детали безопасной диагностики: передавать project, environment и service явно, использовать JSON-вывод там, где он доступен, и подбирать справку по намерению — setup, deploy, configure, operate, feature-flags, iac, sandbox или request. Если CLI устарел, сначала используется railway upgrade; если CLI отсутствует, источник перечисляет официальные способы установки. При headless OAuth устройство-код нужно показать пользователю сразу, пока команда продолжает ждать вход. Эти инструкции описывают маршрутизацию и контроль операций Railway, но не дают разрешения на конкретный production-деплой: проект, окружение, scope токена, diff конфигурации и итоговый deployment должны быть проверены отдельно.