stripe-projects

Stripe Projects — официальный workflow для поиска и подключения сторонних сервисов через Stripe Projects CLI. Источник охватывает базы данных, authentication, hosting, аналитику, caching, AI, observability, vector DB, email, search, очереди, object storage и feature flags. Он также применяется, когда нужно посмотреть каталог провайдеров, проверить состояние проекта, получить список подключённых ресурсов или увидеть переменные окружения. Если пользователь спрашивает, где получить API key или credentials для внешнего сервиса, навык сначала направляет поиск в Projects catalog, а не предлагает обходной ручной маршрут. Работа начинается с проверки локального Stripe CLI командами which stripe и stripe --version. Источник требует версию не ниже 1.40.0; если CLI отсутствует или старее, для macOS указан Homebrew-путь stripe/stripe-cli/stripe, а на других платформах — официальная инструкция установки. После этого нужно установить Projects plugin командой stripe plugin install projects. Навык не описывает собственный API-клиент и не предлагает вручную редактировать внутреннее состояние CLI: каталогом и проектом управляет сам Stripe Projects. Запрос провайдера выполняется через stripe projects search <query> --json. Если result_count равен нулю, workflow останавливается с сообщением, что сервис не найден. Когда запрос слишком общий, вместо угадывания провайдера используется stripe projects catalog --json, а рекомендации строятся только по реально возвращённым элементам каталога. Текущий проект проверяется через stripe projects status --json. Если проект ещё не инициализирован, сначала запускается stripe projects init --preflight --json, чтобы увидеть все блокеры до изменения состояния. При успешном preflight допускается stripe projects init --accept-tos --yes. Источник отдельно предупреждает, что init устанавливает локальный skill stripe-projects-cli в .claude/skills/stripe-projects-cli. После инициализации нужно проверить наличие этого файла и передать дальнейшее добавление сервисов, управление credentials и настройку окружения локальному skill. Если файл отсутствует, workflow предлагает повторить init, а не продолжать по непроверенной схеме. Ошибки BROWSER_AUTH_REQUIRED, ACCOUNT_NOT_ELIGIBLE, TOS_ACCEPTANCE_REQUIRED, PROVIDER_NOT_LINKED и PLAN_REQUIRED имеют разные причины и соответствующие действия; неизвестную ошибку следует показать полностью и при необходимости повторить с --debug. После успешного подключения результат удобно фиксировать по полям Provider, Service и Tier, а для окружения перечислять только имена env vars без их значений. Состояние, переменные и health проверяются через status, env или variables-команды CLI. Навык не обещает конкретного провайдера без ответа каталога, не заменяет пользовательскую авторизацию и не раскрывает секреты в отчёте; подключение, OAuth-linking, принятие условий и выбор плана остаются отдельными контролируемыми шагами.