Record a Skill Across Gmail, Drive, Telegram — 3 Tools

By Lazar Milicevic · Published September 7, 2026 · 7 min read

Every Record a Skill demo you've seen runs one task inside Claude. That's not real work. Real work crosses three tools, and the skill silently dies on the second run when a Gmail label gets renamed by one character. Here's the recording pattern I use for agency clients that actually holds up on a Friday when nobody's watching.

The Friday job that broke on run three

The actual task: every Friday, generate a client status report for three agency clients. For each one — pull the week's Gmail thread with that client, summarize what was decided and what's blocking, export the summary as a PDF, drop it into that client's Google Drive folder, and send a Telegram message to the account manager with the link. Manual time is 22 minutes across three clients when nothing goes wrong. Something always goes wrong because I context-switch and paste the wrong client name into the wrong report.

First automation attempt with Record a Skill looked textbook. Hit record. Walk through client A end to end. Open Gmail, find the thread labeled Client-A-Weekly, summarize, generate PDF, save to Drive, send Telegram. 3 minutes 40 seconds. Stop recording. Test on client B — works. Ship it.

Next Friday, run on all three. A clean. B clean. C — Claude says done, Telegram ping arrives, link is in place. I open the Drive folder. Empty. The Telegram message links to a file that doesn't exist. The skill didn't throw an error. It just quietly skipped the Drive save because client C's label had been renamed from Client-C-Weekly to ClientC-Weekly-2024. One dash. The skill couldn't find the thread, generated an empty summary, saved nothing, and confidently reported success.

That's the failure mode. Record a Skill is not lying on purpose — it's just blind past the tool boundary.

Why Record a Skill lies when it crosses a tool boundary

Record a Skill treats your entire recording as one opaque action once execution leaves Claude. Inside Claude, the model can reason about the state of a conversation, a summary, a document — it sees what it just did and what came back. The moment control hands off to Gmail, Drive, or Telegram through a connector, that reasoning loop breaks. The connector returns "call completed" and the skill takes that at face value.

Concretely, here's what the skill sees on a normal run vs a broken run:

Notice there is no red flag at any step. Every tool call returns 200. The skill has no built-in notion of "this result is semantically wrong." That's your job as the person recording — you have to inject the semantic checks yourself, at every handoff, before the next tool is called.

This is the same lesson anyone who's built agent workflows over connectors has learned. Anthropic's own skills documentation is explicit that skills work best when the model can verify intermediate state. Cross-tool skills need you to make that verification explicit.

The four-sentence checkpoint pattern

The fix takes five minutes. Re-record the skill, but before every tool handoff, type the guard condition into the chat out loud. Not in your head — in the message stream that Claude is recording. Those sentences become part of the skill's logic.

Here are the four checkpoints I use for the Friday report, verbatim:

1. Now switching to Gmail to find the thread labeled
   Client-{X}-Weekly. If no thread is found, stop and
   report which label is missing. Do not continue.

2. Now generating the PDF from the summary above.
   Confirm the summary is not empty first. If the
   summary is under 200 characters, stop and report.

3. Now saving the PDF to the Client-{X} folder in Drive.
   Confirm the file uploaded and a shareable link was
   returned. If no link, stop and report.

4. Now sending the Telegram message to the account
   manager with the Drive link. Do not send if the
   link is missing or empty.

When Claude records the skill, those narrations become explicit guard conditions in the generated skill logic. On the next broken Friday — and there was one, a client's VA reorganized labels — the skill stopped at checkpoint 1 and told me exactly which client and which label was missing. Rename the label back, re-run, done. Elapsed fix time: 90 seconds.

What each checkpoint actually protects against

• Checkpoint 1 — label drift, thread archived, wrong client selected
• Checkpoint 2 — empty summary (thread found but no new messages this week)
• Checkpoint 3 — Drive quota, wrong folder permissions, silent upload failure
• Checkpoint 4 — the cardinal sin: pinging a client with a dead link

The rule: fail loudly at the boundary, not silently three steps later. A loud failure at checkpoint 1 is a 90-second fix. A silent success that ends in a broken Telegram link to a client is an email you have to write on Saturday.

One skill, one variable — not three skills

The second mistake I made was almost worse than the first. After the checkpoint fix worked, I was about to record three separate skills — one per client. Don't do that. You'll end up maintaining three near-identical recordings, and when the checkpoint pattern evolves you'll update it in one and forget the other two.

Record one skill with the client name as a single input variable. At the very start of the recording, before you open anything, type:

This skill takes one input: client_name.
It uses client_name to resolve three things:
  - Gmail label:       Client-{client_name}-Weekly
  - Drive folder:      /Clients/{client_name}/Reports
  - Telegram chat ID:  from a lookup table keyed on client_name
Walk through client A as the example.

Then walk through client A once as the concrete example. Claude generalizes the pattern from that single recording. Now I invoke the same skill three times per Friday — client_name=A, client_name=B, client_name=C — same skill, three different folders, zero re-work when the checkpoint logic needs updating.

The naming convention matters here. Whatever pattern you commit to at recording time (Client-{X}-Weekly, /Clients/{X}/Reports) is now a contract. If somebody renames the folder to /Client-A/Reports/2026 it will break, and it should — checkpoint 3 catches it, and you either rename the folder back or re-record the skill with the new pattern. Pick one.

The 90-second recovery loop

The whole point of checkpoint discipline is that failures become boring. Before checkpoints, a broken Friday looked like this:

• 4:15 PM — run skill, get Telegram ping, close laptop
• Monday 9:00 AM — account manager asks where the report is
• Monday 9:15 AM — I dig through Drive, find nothing
• Monday 9:30 AM — I dig through Gmail, find the renamed label
• Monday 9:45 AM — I re-run manually for one client, another 12 minutes
• Monday 10:00 AM — apologetic email to the client

With checkpoints, the same failure looks like this:

• 4:15 PM — run skill, checkpoint 1 stops on client C: "Label Client-C-Weekly not found on mail@myagency.com"
• 4:15:30 PM — open Gmail, find the renamed label, rename it back
• 4:16:30 PM — re-run skill on client C only
• 4:20 PM — done

Total recovery: 90 seconds of active work. The skill did not lie. It did not send a broken link. The account manager never noticed anything happened.

That's the only kind of failure worth building for. Silent success is worse than loud failure every single time — especially in client-facing workflows where the cost of one broken link is a trust hit you don't get back cheaply.

The one rule

Record a Skill works when the task lives inside Claude. The moment it crosses into an external tool — Gmail, Drive, Telegram, Notion, Slack, HubSpot, anything — the skill loses the ability to notice a partial failure. You have to narrate the handoffs and force the guard conditions into the recording. Otherwise it treats the whole thing as one opaque action and reports success on run two when the world has drifted underneath it.

Narrate the handoffs. State the guard condition before the tool call. Use one skill with a variable, not N skills per client. That's the difference between a demo and something you can leave running on a Friday afternoon.

Where bizflowai.io fits

The Friday report workflow above is one of the more common patterns we build for agency and consultancy clients at bizflowai.io — a cross-tool skill or agent that pulls from Gmail or Slack, transforms into a client-ready artifact, drops it in Drive or Notion, and pings the right person on Telegram or Slack. The checkpoint pattern is baked in from the first recording, plus a small lookup table for per-client variables (labels, folder IDs, chat IDs) so onboarding a fourth client is a one-row change, not a re-recording.

Want more like this?

I publish practical AI automation, GenAI engineering, and faceless content workflows on YouTube every week.

Subscribe to bizflowai.io on YouTube — never miss a new tutorial.

Planning an AI automation project or need a second opinion on your architecture?

Connect with me on LinkedIn — Lazar Milicevic, GenAI Engineer & bizflowai.io Founder.

Visit bizflowai.io for our services, case studies, and AI consulting.