Best workplace app skills for AI agents

An agent holding a valid Gmail token will send. That is the whole problem. Nothing in a model's general knowledge tells it that replying to a thread needs a wider permission than composing a fresh message, that a Notion integration stays blind to a page until a human shares it from the Share menu, or that a Telegram bot token proves the bot exists and says nothing whatsoever about who is on the other end of the chat. The request shapes it can already guess. The operating rules it cannot.

So the sorting question for anything that wires an agent into your mail, your calendar and your team chat is simple: how much of this document is not the API? Read enough of them and the answer separates them cleanly. The thin ones are a formatted endpoint list with the word "productivity" in the front matter. The good ones spend most of their length on identity, scope, confirmation, and the specific ways a request succeeds while doing the wrong thing. The best one I read opens by trying to talk you out of installing it.

Top picks

skill	publisher	license	verdict	updated
google-gmail	Open-Curiosity	MIT	Top pick — a send/don't-send decision procedure	2026-07-18
google-workspace	NousResearch	MIT	Top pick — triages scopes before OAuth	2026-07-28
lark-im	larksuite	MIT	Top pick — identity and scope, per method	2026-07-28
gws-shared	googleworkspace	Apache-2.0	Top pick — the file the others lean on	2026-07-22
Notion	graniet	Apache-2.0 *	Top pick — pins the newer API version	2026-07-26
add-telegram	nanocoai	MIT	Top pick — proves you own the chat	2026-07-27
google-workspace	moltis-org	MIT	Rival — declared fork, smaller surface	2026-07-27
notion	vellum-ai	MIT	Rival — richest error table, older pin	2026-07-28
notion	moltis-org	MIT	Also read — same text, names its source	2026-07-27
gws-calendar-insert	googleworkspace	Apache-2.0	Also read — the write caution, inline	2026-07-22
gws-gmail-reply-all	googleworkspace	Apache-2.0	Also read — sends mail, caution lives elsewhere	2026-07-22
add-telegram	sbusso	MIT	Rival — trusts a pasted chat ID	2026-07-26
add-telegram	b1rdmania	MIT	Rival — same flow, different host project	2026-05-03
Google Gmail	AceDataCloud	NOASSERTION	Also read — careful rules, licence disagreement	2026-07-27

Verdicts: Top pick is what to install; Rival is a direct alternative I read and argue against below; Also read is worth opening for its own reason, not competing for the same slot.

* Notion declares MIT in its own front matter while the repository it ships from resolves to Apache-2.0 — as does the same publisher's google-workspace. Both are permissive, but see the last section.

Gmail: Open-Curiosity's writes the decision procedure, not the warning

A rule that says confirm before sending is easy to write, and plenty of these have one. google-gmail writes the procedure that rule leaves out. Sending is "an irreversible, third-party-facing action", so it splits cases: if the user dictated the message, execute; if you composed it yourself or they only delegated the outcome, get an explicit confirmation first — and if they named a recipient but not what to say, ask before drafting rather than inventing a position and attributing it to them.

It also treats Gmail permissions as "four separate trust boundaries", spelling out why a reply needs a wider one than a fresh send: the reply helper must fetch the original message to thread it. Caveat: it assumes a working gws install and a specific host app's confirmation primitive.

Whole-Workspace setup: take the upstream, not the fork

google-workspace is the rare skill that starts by asking whether you need it. Before touching OAuth it asks two questions, and for anyone who only wants email the answer is that "They don't need this skill at all." — go use a lighter mail skill with an app password. It asks whether the account is on Advanced Protection, because that needs an admin to allowlist the client before the flow will ever complete. Its delete rule prefers the reversible trash over a permanent wipe.

google-workspace is an honest fork — its front matter names hermes-agent as the source — but it is a smaller snapshot: Drive search only, no upload, share or delete, and its confirmation rule stops at mail and events.

Lark and Feishu: take the lark-cli skill for the identity rules

If you want your agent posting into Feishu or Lark, install lark-im, because it is about identity before it is about messages — it is the one that explains why the same call works for you and fails for your bot. It maps the two identities to two token types and states the consequence plainly: "The same API can succeed with one identity and fail with the other", because membership, ownership and tenant boundaries are all evaluated against whoever is calling.

Then it does the unglamorous work — a per-method scope table, which operations are bot-only versus user-only, the per-call ceilings, chunked downloads for large files, and an instruction never to hand-write an interactive card payload. Caveat: much of the surrounding prose is in Chinese, and the deep detail lives in reference files this page doesn't contain.

The gws CLI's generated skills: install the boring shared one first

The gws CLI generates its own agent skills, and the per-command ones each carry the --help invocation they were rendered from. The interesting one is the plumbing. gws-shared holds the auth options, the global flags, the dry-run and response-sanitising switches, a note about zsh mangling a sheet range because of the exclamation mark — and the security rules, including "confirm with user before executing write/delete commands".

The per-command files are uneven about repeating it, and the unevenness runs the wrong way. gws-calendar-insert restates it inline, in a [!CAUTION] block: this is a write command, confirm before executing. gws-gmail-reply-all, which puts your words in front of a whole thread, says nothing about confirmation in its own text — its tips are about attachments and HTML quoting. Nothing here is unrecoverable: both files open with the same prerequisite line pointing at the shared reference, and that line tells you to run gws generate-skills if it is missing. But an agent reading one command file sees what that file says, and the caution went to the calendar command rather than the one whose mistakes are public.

Notion: choose by the API version it pins, not the name

Notion's API makes you pin a version in a header, and the skills wrapping it disagree about which one to send. That disagreement is the whole decision. Notion pins 2025-09-03 and explains what changes: databases become data sources, each one carries two ids, and you use one to create pages and the other to query. It also notes the rate ceiling and that "The API cannot set database view filters" — that stays a UI job. The same text ships under two names; notion is the copy that tells you where it came from, and if you are on that host project it is the one to take.

notion pins 2022-06-28 instead, but has the richest failure guidance and a blunt rule: "Never reveal credential values or echo token values into the shell." Whichever you pick, hold on to the thing both are clear about: a valid key still sees nothing until a human shares the page with the integration.

Telegram: nanoclaw's handshake beats a pasted chat ID

A skill called add-telegram can be any of several different documents, and they diverge exactly where it counts. add-telegram refuses to ask you for a chat id, because "Telegram tokens carry no user binding" — instead it issues a short numeric code, you send those digits from the chat you actually want registered, and the running adapter matches them. It also pins its adapter dependency to an exact version, noting that "the supply-chain policy rejects ranges and latest".

add-telegram and add-telegram instead have you run a command in the bot and paste back whatever id it prints. Fine when you are the only operator; weaker when you are not. Caveat: all three modify a specific host project, so your codebase may make the choice for you — and if it lands you on the pasted-id flow, know which half of the check you are skipping.

How do you tell two skills with the same name apart?

Skill names are not namespaced. Anyone can publish notion or add-telegram, so the name tells you the topic and nothing else — the publisher and the body are the identity. A skill called google-workspace can be a thin wrapper around a CLI, a full guided OAuth onboarding, or a copy of someone else's document with the tool names swapped out.

Start with the front matter, where a copy sometimes admits it is one. moltis's Notion skill carries an origin block naming an upstream project and the commit it was taken at. graniet's presents itself as community-authored with no lineage at all — and yet, read side by side, the two are the same instructions: the same pinned version, the same data-sources explanation, the same property table, the same rate note. What differs is a credential storage path, two sample strings, and the compatibility preamble graniet's carries at the top, mapping one host project's tool names onto another's. Neither is doing anything wrong; permissive licences exist precisely so this can happen. But only one of them tells you where the thinking came from, and therefore where to look when it goes stale. Next, find the version or endpoint the body pins, because two documents that pin different API versions will behave differently against the same workspace. Then go looking for the sentence about acting on your behalf. If a skill sends mail, writes a calendar entry or removes a file and never says a word about confirming first, that silence is the finding.

What to check before you hand one your credentials

These skills receive real tokens and act on real accounts, so read the licence line twice — and read it in both places, because the file and the project do not always agree. Google Gmail is the sharp case: the instructions themselves are careful — narrow-scope discipline, a confirm-before-destructive-write rule — but its own front matter declares Apache-2.0 while the repository it ships from resolves to no recognised licence at all. The permission you would be relying on is a line someone typed in a file, not a licence attached to the project. That is worth knowing before it lands in a work repo, and it applies to every skill that publisher ships.

Two of the picks above have a milder version of the same thing, and it would be dishonest to print the table without saying so: graniet's Notion and Workspace skills declare MIT in their own front matter while the repository resolves to Apache-2.0. That is a disagreement between two permissive licences, not between a permissive licence and nothing, so the practical exposure is different in kind — but the habit that catches one catches the other.

Then check where the credential goes and how long it lives. The good ones are specific about it: nanocoai's Telegram setup writes the bot token into the bridge's .env only if it is not already set, so a re-run cannot quietly overwrite a working one; sbusso's tells you to copy .env into data/env/env, because the container reads the copy and not the original — exactly the sort of detail you would never guess and would debug for an hour. That is the level of specificity to look for. If a setup flow asks you for a secret and never says which file it lands in, you have no way to answer the only question that matters later: what do I rotate, and where.

What you have now avoided

The opening problem was an agent that can act on your accounts and has no idea which actions are irreversible. Every recommendation above closes part of that gap in a different place: Open-Curiosity's Gmail skill decides when a message needs your sign-off; NousResearch's asks for the narrowest scope that does the job and prefers a recoverable delete; larksuite's tells your agent which identity a call runs as before it fires; the shared googleworkspace file carries the confirmation rule the per-command files only point at; graniet's Notion skill pins an API version that matches what your workspace actually returns; and nanocoai's Telegram setup binds the channel to a chat you proved you were sitting in.

Install those and the failure you have avoided is the quiet one — the agent that sends the right words to the wrong thread, or trashes a file it cannot restore, and reports success either way.