القائمة
Act on behalf of your user in any third-party software that supports OAuth 2.0
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Read, search, send, and manage messages across Gmail, Outlook, Telegram, and other platforms
An on-demand personal daily briefing — weather, headlines, the shape of your day, and one thing worth your attention — in a sharp executive-assistant voice. The general-purpose morning brief; richer work or admin digests compose it as their general layer.
One-time migration of an existing memory-v2 concept corpus into the memory-v3 section-grain "wiki" — topical articles with a stand-alone lead and queryable sections — with loss-proof staging, assistant-reviewed authoring, and a retrieval-eval gate before cutover.
Delegate a big or high-stakes job to a fleet of parallel subagents, orchestrated deterministically; runs unattended and reports back
Manage contacts, communication channels, access control, and invite links
Build and edit small, personal visual tools and artifacts — dashboards, trackers, calculators, data visualizations, charts, simple landing pages, and slide decks the user wants for THEMSELVES. This is the right skill whenever the user asks to "visualize this," "make a chart," or "build an artifact" for their own use, or to edit an app they already built here. Do NOT reach for a ui_show dynamic_page to fake an artifact — build a real persistent app here. NOT for complex, multi-user, or shippable products — those go to a real project folder with a coding agent (see Scope below).
| name | vellum-oauth-integrations |
| description | Act on behalf of your user in any third-party software that supports OAuth 2.0 |
| compatibility | Designed for Vellum personal assistants |
| metadata | {"emoji":"🔌","vellum":{"category":"integrations","display-name":"Vellum OAuth Integrations"}} |
Integrating with a third-party software via OAuth is typically used to perform actions on behalf of the user. It involves having the user log in using their own credentials, specifying the scopes that they want to provide, and then afterwards, API requests can be made on their behalf.
Important: Avoid reaching for an OAuth integration if your intent is to act as yourself rather than as your user.
You are provided with the assistant oauth CLI for performing all necessary oauth-related actions.
Important: When in doubt how a command works or how to do something, read the references at the bottom. Never guess at how the CLI works. Read references and use the --help flag for any command you're about to run.
Vellum assistants can natively integrate with any application that supports OAuth 2.0. Many OAuth providers come pre-configured and ready to use. You can view them by running:
assistant oauth providers list
You can also search for specific providers. Here's an example that searches for the "google" provider:
assistant oauth providers list --provider-key google
All providers support "your-own" mode and some support "managed" mode.
"managed" mode relies on a first-class integration with the Vellum Platform. Managed mode is typically easier to set up and get going, often only requiring the user to log in with no additional configuration needed before they can begin using the integration. Managed mode is the recommended method for most users, especially those that are less technical or newer to their Vellum assistant.
When a task needs a managed OAuth connection, present it in chat with ui_show using surface_type: "oauth_connect" instead of sending the user to Settings or trying to open the OAuth flow from shell. See Connecting Accounts for the exact surface shape.
Note that using managed mode:
"your-own" mode requires that the user creates their own OAuth application directly with the third-party and then enter the application's Client ID and Client Secret into Vellum.
Your-own mode is typically best if:
Default to managed mode whenever the provider supports it. Check support with:
assistant oauth providers get <provider-key> --json | jq -r '.managedServiceConfigKey'
If this returns a non-null value, managed mode is supported and should be your starting recommendation. Only fall back to your-own mode if:
managedServiceConfigKey is null), ORDo not present managed and your-own as equivalent choices to a fresh user. Lead with managed, then offer your-own as an alternative if they push back.
You can determine whether a given provider supports managed mode based on the details returned by:
# Find the provider of interest in the list response
assistant oauth providers list
# Or, return just the provider of interest with their details
assistant oauth providers get <provider-key>
You can determine what mode the provider is currently set to use with:
assistant oauth mode <provider-key>
You can update which mode a given provider should use with:
assistant oauth mode <provider-key> --set "managed"|"your-own"
If an API request returns a 403 Forbidden, 401 Unauthorized, or a message about missing scopes, the connection likely doesn't have the scopes needed for that action. See Updating Scopes for how to disconnect and reconnect with the required scopes.
For detailed information on the following topics, see the reference files: