메뉴
Google-native REST APIs (Gmail, Google Calendar) for users who bring their own Google Cloud OAuth client (~/.google/credentials.json required). For everyday email and calendar prefer the email-client skill, which needs no Google Cloud project. Requires daemon.
Codex 또는 Claude로 설치 이 Prompt를 복사해 Codex, Claude 또는 다른 어시스턴트에 붙여 넣으면 Skill 페이지를 검토하고 설치를 진행할 수 있습니다.
SOC 직업 분류 기준
| name | |
| description | Google-native REST APIs (Gmail, Google Calendar) for users who bring their own Google Cloud OAuth client (~/.google/credentials.json required). For everyday email and calendar prefer the email-client skill, which needs no Google Cloud project. Requires daemon. |
Official Google REST APIs (Gmail + Calendar v3), authenticated with your own
Google Cloud OAuth client: a ~/.google/credentials.json is required, there is
no shared sign-in. Only reach for this skill when the user genuinely needs
Google-native APIs; for ordinary Gmail mail and calendar, the email-client
skill is the right choice (zero-setup sign-in, no Google Cloud project). Every
command prints JSON to stdout.
Setup: See SETUP.md
Background: screen -dmS google google serve --notifications-dir ~/agent/notifications
google email list
google email get --id <message_id>
google email send --to bob@example.com --subject "Hello" --body "Message"
google email reply --id <message_id> --body "Thanks!"
google email search --query "project update"
google calendar list --days-ahead 30 --limit 20 # upcoming events
google calendar list --days-back 14 --days-ahead 0 # recent past
google calendar calendars # list calendars
google calendar get --id <event_id>
google calendar create --subject "Standup" --start "2025-11-15T10:00:00" --end "2025-11-15T10:30:00" --timezone "Europe/London"
google calendar update --id <event_id> --start "2025-11-15T11:00:00" --timezone "Europe/London"
google calendar delete --id <event_id>
google calendar respond --id <event_id> --response accept
Event ids are Calendar API event ids (the id field the API returns, e.g.
abc123def456), not iCalendar UIDs; ids from before the REST switch do not
resolve, re-list to get current ones. Recurring events are expanded into
concrete occurrences in the query window (singleEvents), returned sorted by
start time. update and delete on an occurrence id apply to the whole
series (the id resolves to the series master). respond never emails the
guest list; only create/update/delete send attendee notifications.
Not implemented: there is no meet command and calendar create does not attach
a Meet link (no conferenceData support). Because the OAuth client is your own,
nothing blocks adding it: enable the Calendar API (and any Meet scopes) on your
Google Cloud project and wire it up if the user asks.
Sign-in requires your own Google Cloud Desktop app OAuth client JSON at
~/.google/credentials.json; without it sign-in fails with a pointer at
SETUP.md. The flow is loopback OAuth (prints a consent URL,
listens on 127.0.0.1, does not auto-open a browser). One consent grants
https://mail.google.com/ (Gmail) + .../auth/calendar (Calendar). A stored
token stays tied to the client that minted it: a token from another client (e.g.
the old shared Thunderbird client) keeps refreshing and Gmail keeps working, but
calendar 403s until you re-run google auth login under your own client.
Set EMAIL_DRAFT_ONLY=1 (truthy: 1/true/yes, case-insensitive) to hard-disable sending. In this mode email send/reply (and forward, when present) are refused before any Gmail API call (non-zero exit with a clear message); only email draft works. Default off: unset/empty means today's behavior, no change.
--account needed. Google CLI uses a single authenticated account--label (INBOX, SENT, DRAFT, etc.) instead of folders--calendar (defaults to "primary") for calendar selection--timezone required for calendar create/update (IANA names like "Europe/London")--response choices: accept / decline / tentative--to/--cc/--attendees accept multiple space-separated values--limit on calendar list caps the number of events returned--no-details on calendar list returns compact output (no body/attendees)--user-timezone on calendar list returns times in the given IANA timezone--no-notification on calendar delete skips attendee cancellation emails (sendUpdates=none)--no-attachments on email get skips attachment metadataemail get saves the readable body to ~/.google/emails/<subject>_<id>.txt (idempotent: re-fetching overwrites, HTML is flattened to text with links preserved)--save-to on email get writes the body file to a chosen path instead[How to communicate with different contacts. Fill in after data gathering: who are the key contacts, what tone/formality for each, language preferences]
[User's email patterns. Fill in after data gathering: greeting style, sign-offs, capitalization, punctuation habits, typical length, tone]
[User's scheduling patterns. Fill in after data gathering: preferred meeting times, timezone, how they reschedule, buffer preferences]
[Recurring meetings and commitments. Fill in after data gathering: weekly/monthly recurring events, who with]
Use for any Microsoft account, personal or work (Outlook.com, Hotmail, Live, Microsoft 365); preferred over email-client for Microsoft accounts. Graph-based mail (read/send/reply/forward, drafts, flag/categorize, move/archive, folders, attachments, block senders), calendar and meetings, Microsoft Teams (chats, channels, presence), and new-mail/Teams notifications. Requires daemon.
Browse, navigate, click, fill forms, screenshot, or scrape web pages with a stealth (Camoufox) browser.
Design judgment and UI copy for building Vesta dashboard widgets that feel considered rather than templated, within the fixed design system.
Use before building or modifying the user's dashboard: widgets, pages, layouts, custom UI. Understand what the user wants, design it, write a spec, then dispatch the dashboard-builder to build it.
Use when someone who doesn't have their own vesta asks what vesta is, how to get one, or hints they want in. Vesta is invite-only: you gatekeep and build desire through scarcity, draw out what they want, then sell vesta as indispensable to their goals and set them up end-to-end in chat. Not for the owner, who already has one.
Talk to vestad, the host daemon that runs this container. Register a background service to get a port, build public URLs, update vestad to the latest release, check its version, and read gateway logs. Use when a skill needs an inbound port or a shareable link, when the user asks to update Vesta, or when debugging gateway/container issues.