Add Provider
Extend a pluggable service with one entry point and the existing adapters.
Use $add-provider when you want to configure or add a payment, email, storage, AI, analytics, or authentication provider. Its full instructions live in .agents/skills/data-and-integrations/add-provider/SKILL.md.
Ask for the integration
Use $add-provider to integrate [service] for [area].
We need [required capabilities]. Check whether an existing adapter supports
it through configuration before adding code. Include provider selection,
credentials, documentation, and offline tests. Report any live checks
that still need test credentials. Do not deploy or send real transactions.S3-compatible storage, SMTP email, and OpenAI-compatible endpoints may already work through configuration. The skill checks that first, then routes new implementation work to the owning package.
Supported areas
| Area | Existing extension point | Focused skill |
|---|---|---|
| Payments | Typed adapters in packages/payments for checkout, catalog, portal, and signed webhooks | add-a-payment-provider |
Mail transports in packages/mail behind sendEmail | add-or-edit-an-email | |
| Storage | Signed upload and read URLs in packages/storage | storage-providers |
| AI | Provider and model resolution in packages/ai | ai-providers |
| Analytics | Browser scripts and event tracking in apps/web/modules/analytics | add-provider |
| Authentication | Existing Better Auth configuration and plugins in packages/auth | add-auth-flow-or-better-auth-plugin |
For another area, the agent first finds its actual extension point. The skill does not assume every integration uses the same registry.
What a complete provider change includes
The implementation connects the adapter to its runtime resolver and public API. Registered providers also need their ID and configuration guidance in packages/config/providers.ts. Payments, email, storage, and AI use the admin service settings, so saved selection, credential handling, and readiness must agree with runtime behavior. Analytics and authentication use their own configuration paths.
The agent documents environment variables and provider limits, then checks selection, missing credentials, provider errors, and the affected user workflow. Existing sandbox and authorization rules still apply. Passing offline tests proves the local integration; it does not prove live delivery, payment processing, or production configuration.
See the complete skill catalog for each focused skill's full file path.
vibekit-deploy proceeds through authentication, email, payments, storage, AI, and analytics categories. Each category loads on-demand reference guidance for the chosen provider. Existing adapters need configuration; add-provider handles any required extension. The skill catalog lists all active category hubs and focused skills.