I Trained Claude to Run My Admin.
Here's the Full Playbook.

If you're a PM leader, a founder, or anyone whose calendar is basically a wall of back-to-back meetings, you know the real work doesn't happen in the meetings. It happens in the hour after.

The meeting ends. Five product docs need updating. The merchant you just spoke to needs a follow-up email with action items. Two people pinged you in Slack during the call about something you already answered in the meeting. And your inbox has twelve new emails, three of which are partners asking for status updates that require context from three past threads.

Do that for 40 meetings a week. Multiply it across 50 weeks a year. That's where the admin tax lives.

This is the story of how I stopped paying that tax. I built three skills in Claude that run on a schedule, talk to each other through a shared set of product docs, and handle the boring-but-critical admin work that was eating my days.

You can build the same setup. The rest of this post is the playbook.

The core idea: skills that share a brain

Most people think about AI agents one task at a time. "An email drafter." "A meeting summarizer." "A Slack bot." Each one runs in isolation, does its narrow job, and moves on.

That's fine, but it leaves value on the table. The real leverage shows up when multiple skills read from the same source of truth.

Here's the setup.

I have a folder of "product packs" in Google Drive. One doc per active workstream. Every pack contains the current scope, open questions, decisions, risks, and action items for that project. These aren't PRDs, they're living operational docs.

I also have a project index, one master doc that maps keywords and aliases to product pack Doc IDs. When someone says "PO Automation" or "the purchase order flow thing," the index tells my skills "that's the PO Automation pack, here's the Doc ID."

And I have a Meeting Intelligence folder, where the meeting analyzer creates a new dated doc per run with the full structured analysis.

Three skills run against this shared brain:

1. A Meeting Notes Analyzer that reads my calendar transcripts, matches them to product packs, generates structured update proposals (in the Cowork task output and a fresh Intelligence Doc), and drafts follow-up emails to attendees.
2. A Slack Responder that reads my DMs and @mentions and drafts replies in my voice.
3. A Scheduled Email Responder that reads my inbox, drafts replies in my voice, and flags the ones that need real attention.

They each do useful things individually. But because they all read from the same product packs, something more interesting happens.

A call happens at 10am. By 10:45, the meeting analyzer has matched the transcript to the right pack, output the new decisions as structured proposals, and drafted the follow-up email. I paste the approved proposals into the pack over coffee.

At 11, someone Slacks me about that same decision. The Slack responder reads the (now updated) pack and already knows.

At 2pm, a partner emails asking for a status update. The email drafter pulls context from the same pack and writes a reply that's actually accurate.

The product docs are the shared brain. The skills are the hands. I'm the one doing the paste, but the thinking is done.

One important detail before the setup: all three skill prompts in this playbook ask you to paste the same [YOUR INDEX DOC ID]. Use the same value in all three. That single Doc ID is what wires the shared brain together. Different Doc IDs in different skills = three assistants that do not know about each other.

An honest note on what Claude can and can't do with Google Docs

I want to address something upfront because it shapes how this whole system works.

Claude's Google Drive integration can:

• Read existing Google Docs (transcripts, project index, product packs)
• Create new Google Docs (for the Meeting Intelligence archive)
• Read calendar events and their attached files
• Create Gmail drafts and Slack drafts

Claude's Google Drive integration cannot:

• Edit existing Google Docs
• Append text to existing Google Docs
• Add comments or suggestions to existing Google Docs

This is a current limitation of the integration, not a Claude limitation. The earlier draft of this post claimed the meeting analyzer would "append a Suggested Updates section to each product pack." That doesn't actually work today. I had to redesign the skill around it.

Here's how it works in practice:

After each run, the analyzer outputs structured update proposals in two places: (1) the Cowork task log itself, organized by product pack with copy-paste-ready bullet lists, and (2) a new dated Google Doc in your Meeting Intelligence folder containing the full analysis. You review, then paste the approved changes into your product packs manually. It's about 2 minutes of clicking per meeting. The skill does everything else: the listening, the matching, the framing, the email drafting.

It's not as magical as "the docs update themselves." But it's honest about what's possible today, and the cognitive load is still 95% lifted.

What you need before you start

Three things.

Claude Desktop with Cowork enabled. This is what lets you create scheduled tasks. Regular Claude chat can run any of these skills on demand, but scheduling is where the real leverage comes from.

Google Workspace connected. Gmail, Google Calendar, and Google Drive all need to be connected as integrations in Claude. The meeting analyzer needs all three. The email responder needs Gmail. The Slack responder needs the Slack integration.

A Claude Pro, Team, or Enterprise account. Scheduled tasks are a paid feature.

None of this requires code. Everything below is configuration and prompts.

Skill 1: Meeting Notes Analyzer

This is the most involved of the three skills, and also the one that pays back the most.

What it does

Every 30 minutes during business hours, the skill:

1. Checks my Google Calendar for meetings that ended in the last 4 hours
2. Looks for meetings that have Google Meet transcripts or attached notes
3. Skips any meeting it's already processed (deduped against the Processed Meetings Log in the project index)
4. For each new meeting, reads the transcript and matches it to one or more product packs via the project index
5. Generates structured "Update Proposal" blocks for each matched pack, with what to add/change/remove, what section, what source, what rationale, all formatted as copy-paste-ready text
6. Creates a new dated Google Doc in my Meeting Intelligence folder containing the full analysis (matched projects, all update proposals, action items by owner, cross-project impact, risks, unmatched discussions)
7. Drafts a recap email to the attendees (only for meetings with 8 or fewer people)

Step 5 happens in the Cowork task output itself. Step 6 is the archive, which lets me search back through every meeting analysis ever generated. Step 7 lands as a draft in Gmail.

The doc and folder you need to create first

Before the skill runs, you need one Google Doc and one folder.

The Project Index doc. Three parts:

INTELLIGENCE_FOLDER_ID: [paste your Meeting Intelligence folder ID here]
LOOKBACK_HOURS: 4

The Aliases column is doing real work. When the skill reads a transcript and someone says "the PO flow thing," it needs to know that maps to PO Automation. Put every nickname, acronym, and shorthand you use in there.

The Meeting Intelligence folder. A folder in your Google Drive where the skill will create one new doc per run. Create it, copy its folder ID, paste it into the Configuration section of the index. Build Parts 2 and 3 of the Project Index as real Google Docs tables (Insert > Table), not as plain text — the skills look for table rows.

Product pack template (one per workstream)

Create one Google Doc per active project. The meeting analyzer's Update Proposals reference specific sections by name, so use these section headings verbatim so proposals slot in cleanly:

PRODUCT PACK: [Project Name]
Last updated: [YYYY-MM-DD]

SCOPE
One paragraph: what we are building and for whom.

STATUS
Current state, target launch date, blockers.

OPEN QUESTIONS
- Bullet list of unresolved decisions

DECISIONS
- YYYY-MM-DD: short statement of the decision
- YYYY-MM-DD: another decision

METRICS
- Test set accuracy: X%
- Pilot volume: Y

RISKS
- Bullet list of known risks

ACTION ITEMS
- Owner to do X by YYYY-MM-DD
- Owner to do Y by YYYY-MM-DD

PILOT CUSTOMER (or KEY STAKEHOLDERS)
Names, companies, contact emails.

Keep the pack short, under one page is ideal. The skills read every active pack on every run, so length costs latency and token budget.

How to find a Google Doc ID or Folder ID

Open the doc or folder in Drive. The ID is the long alphanumeric string in the URL between /d/ (for Docs) or /folders/ (for folders) and the next /:

Doc:    https://docs.google.com/document/d/1AbCdEf_GhIjKlMnOpQrStUvWxYz0123456789AbCdE/edit
Folder: https://drive.google.com/drive/folders/1AbCdEf_GhIjKlMnOpQrStUvWxYz012345

Copy that string. Paste it into the highlighted placeholders in the setup prompts below.

The setup prompt

Open a new Claude conversation with Google Calendar, Google Drive, and Gmail connected. Paste this prompt, customizing the highlighted sections:

Create an automated meeting notes analysis skill that runs on a schedule. Here's what I need:

-- Calendar lookup --
Every time this runs, search my Google Calendar for events that ended within the last [LOOKBACK WINDOW, e.g., 4 hours]. For each event, check if it has attached Google Docs (notes or transcripts). Skip events with no attachments.

-- Deduplication --
I have a Project Index Google Doc at Doc ID [YOUR INDEX DOC ID]. In that doc is a "Processed Meetings Log" table with columns: Date, Title, Transcript Doc ID, Matched Project(s), Intelligence Doc ID. Read that table to identify already-processed meetings. Dedup by the Transcript Doc ID column (not by title) since titles can vary slightly. At the end of the run, output the newly-processed meetings as a copy-paste-ready row block so I can manually append them to the log table.

-- Project matching and memory lookup (REQUIRED) --
The Project Index contains a table mapping project names and aliases to product pack Doc IDs. For each meeting transcript:
1. Read every active project pack first to load full context. You must actually open each pack via its Doc ID and read it, not just glance at the title.
2. Scan the transcript against all active projects and tag every project that is meaningfully discussed (not just mentioned). A project qualifies if a decision was made about it, an action item was assigned, scope or timeline was discussed, or dependencies were raised.
3. When generating Update Proposals (next step), compare what was said in the meeting against what is already in the pack. Only propose NEW information or CHANGES. Do NOT propose adding anything the pack already documents. This is what makes the shared brain work.

-- Update proposals (IMPORTANT) --
The Google Drive integration cannot edit, append to, or comment on existing Google Docs. Do NOT attempt to modify product packs directly. Instead, for every matched project, generate a structured "Update Proposal" block in the task output AND in the new Meeting Intelligence Doc (see below). Each proposal should specify: (1) the product pack Doc ID and title, (2) the section of the pack it applies to, (3) the specific text to add/change/remove, (4) the source (meeting + speaker), and (5) the rationale. Format proposals so I can copy-paste them directly into the relevant pack section.

-- Meeting Intelligence Doc --
After analyzing each run's meetings, create a new Google Doc in folder ID [YOUR INTELLIGENCE FOLDER ID] titled "Meeting Intelligence: [YYYY-MM-DD HH:MM] [TIMEZONE]" using the current run time (e.g., "Meeting Intelligence: 2026-05-31 14:00 PT"). Content: (1) meetings processed, (2) matched projects per meeting, (3) all update proposals grouped by product pack, (4) action items grouped by owner with absolute YYYY-MM-DD due dates (interpret any relative dates from the transcript like "by Monday" as the closest future date), (5) cross-project impact notes, (6) new risks surfaced, (7) unmatched discussions.

-- Follow-up emails --
For meetings with 8 or fewer attendees, draft a Gmail recap email to all attendees. Subject line: "Follow up: [Meeting Title]". Write in my voice. Use my name [YOUR NAME] in the sign-off. Never send. Always create as a draft.

-- Voice profile --
Before drafting any emails, search my sent Gmail from [DATE RANGE] and study my writing patterns. Apply that voice to every draft.

-- Safety guardrails --
Never send emails automatically. Never attempt to edit existing Google Docs (the integration does not support it). If a meeting discusses a project not in my index, include it in the Intelligence Doc under "Unmatched Discussions" and flag that keywords might need to be added. Flag uncertain factual claims with [VERIFY] inline next to the claim. Flag drafts that touch sensitive topics (personnel, compensation, legal, budget commitments to customers) with [PLEASE REVIEW] at the top of the draft.

-- Schedule --
Run every [FREQUENCY, e.g., 30 minutes] during business hours on weekdays.

-- Output --
Give me the final prompt as plain text that I can paste directly into a Cowork scheduled task. Do not generate code or an HTML file. Just the prompt.

Claude will generate a plain-text task prompt. Save that output.

Create the scheduled task

1. Open Claude Desktop and go to Cowork
2. Navigate to Scheduled Tasks
3. Create a new task, name it "Meeting Notes Analyzer"
4. Paste the prompt Claude generated as the instructions
5. Set the frequency and active hours (I recommend every 30 minutes, 8am-7pm, weekdays only)
6. Enable the task

What you'll see after each run

• Cowork task output. A summary of what was processed, structured update proposals per pack, action items by owner, and a list of drafts created.
• A new Meeting Intelligence Google Doc. Dated and saved in your folder, containing the full analysis.
• Gmail drafts. One per meeting with 8 or fewer attendees, ready for review.

Your 5-minute review workflow

Open the Intelligence Doc. Skim the update proposals. Copy the ones you agree with into the relevant product pack sections (in Google Docs, where you can paste, edit, and version-control properly). Delete the rest. Add the meeting to the Processed Meetings Log table in your index. Open Gmail drafts, review, send.

The first week, I spent about 15 minutes a day doing this. After two weeks, it was down to 5. The proposals get sharper the more the skill learns your voice and the structure of your packs.

Skill 2: Slack Responder

Simpler than the meeting analyzer, but just as useful.

What it does

Every hour during business hours, the skill:

1. Searches Slack for DMs and @mentions I haven't responded to
2. Reads the surrounding thread context
3. Drafts a reply in my voice
4. Saves the draft as an attached Slack draft in the relevant channel or DM

I open Slack, see the draft, review it, and send. Or edit and send. Or discard and write my own.

The setup prompt

Create an automated Slack responder skill that runs on a schedule. Here's what I need:

-- Message discovery --
Every time this runs, search Slack for DMs and @mentions directed at me that I haven't responded to. Focus on messages from the last [LOOKBACK WINDOW, e.g., 24 hours]. Skip messages I've already replied to, bot notifications, and channels where I'm a passive member.

-- Context loading --
For each message that needs a reply, read the full thread or recent channel history so the draft has proper context.

-- Memory lookup (REQUIRED before drafting) --
Before drafting any reply, do this in order:
1. Open my Project Index Google Doc at Doc ID [YOUR INDEX DOC ID]. This is the same Index Doc ID used by the meeting analyzer.
2. Read the Project Mappings table to get the full list of project names, aliases, and product pack Doc IDs.
3. Scan the message and thread for any project name, alias, or shorthand from the table (case-insensitive, partial match).
4. For every project mentioned (even in passing), open the matching product pack via its Doc ID and read it fully.
5. ALSO check the Meeting Intelligence folder ID [YOUR INTELLIGENCE FOLDER ID] for the most recent Intelligence Doc (sort by Modified date). If its timestamp is more recent than the matched pack's "Last updated" line, read its Update Proposals for the matched project. Those reflect decisions the user has not yet pasted into the pack. Prefer them over older pack content when they conflict, and append [VERIFY: from unapplied proposal] inline next to any number/date you draw from there.
6. Use the pack contents (current status, decisions, commitments, action items), augmented by any fresher proposals from step 5, to make the draft accurate and specific. Reference recent decisions by name where relevant. Do NOT ask "what is the status?" if the pack or proposals already answer it.
7. If a project mentioned in the thread is NOT in the index, flag the draft at the top with [NEW PROJECT: name] so I can add it to the index later.

If no project is mentioned in the thread, draft using thread context and voice profile alone.

-- Voice cloning --
Search my sent Slack messages from [DATE RANGE] to build a voice profile. Apply that voice to every draft. On Slack I'm more casual than email.

-- Tone by relationship --
Different audiences get different tones. With direct reports, be short and direct. With peers, be direct but collaborative. With senior leaders or external partners, be slightly more formal but still direct.

-- Smart filtering --
Only draft replies for messages that actually need a response. Skip FYI messages, automated notifications, channel-wide announcements, and messages where someone else has already answered. If a message is asking for a meeting, include my scheduling link: [YOUR SCHEDULING LINK].

-- Safety guardrails --
Never send messages automatically. Always use the Slack draft tool to create drafts. If the Slack draft tool is not available in this run, output the draft as plain text in the task log with a clear "DRAFT FOR [channel/DM]:" header so I can paste it manually. Flag uncertain factual claims with [VERIFY] inline next to the claim. Flag drafts that touch sensitive topics (personnel, compensation, legal, budget commitments) with [PLEASE REVIEW] at the top of the draft.

-- Schedule --
Run every [FREQUENCY, e.g., hour] during business hours on weekdays.

-- Output --
Give me the final prompt as plain text I can paste into a Cowork scheduled task. Not code, not HTML. Just the prompt.

Same flow as before. Generate the prompt, paste it into a Cowork scheduled task, set the frequency, enable it. Critical: when you paste the prompt, replace [YOUR INDEX DOC ID] with the same Doc ID you used for the meeting analyzer. All three skills must point at the same Project Index for the shared brain to work.

Skill 3: Scheduled Email Responder

What it does

Every hour, the skill:

1. Checks my inbox for new threads
2. Skips newsletters, marketing, automated notifications, and calendar invites
3. For everything else, reads the thread and drafts a reply in my voice
4. Flags sensitive or complex threads with [PLEASE REVIEW]
5. Marks uncertain factual claims with [VERIFY]

This skill works very similarly to the Slack responder but operates on email threads. Voice cloning from sent mail, tone adaptation by audience, scheduling-link auto-insertion for meeting requests, and the Gmail draft creation tool for safe drafting. And critically: the same required memory-lookup step the Slack responder uses, including the freshness check against the most recent Intelligence Doc in case you have not yet pasted in the latest meeting analyzer proposals. Before drafting any reply, the skill opens the Project Index, finds which projects are referenced in the email, opens those product packs, checks the Intelligence folder for fresher proposals, and uses all of that to make the draft accurate. Use the same [YOUR INDEX DOC ID] and [YOUR INTELLIGENCE FOLDER ID] here that you used for the other two skills.

Two hard-won rules

After running this skill for a few weeks, I discovered two failure modes that needed explicit instruction to fix. Both are baked into the setup prompt above, but they're worth calling out because they're not obvious until you've seen them go wrong.

Rule 1: Always reply-all. Out of the box, the skill will quietly reply only to the sender, dropping everyone else on the thread. The fix is a step-by-step recipient extraction in the prompt: read the most recent message, take the From into to, take the To header into to, take the Cc header into cc, remove your own address, deduplicate. If the resulting to list is empty (the only other participant was you), skip the thread. Reply-only-to-sender is never acceptable unless the thread has one other participant and no Cc field.

Rule 2: The draft must thread into the original conversation. Gmail stitches drafts into the right thread by matching the subject line. If the subject is even slightly off (extra "Re:" prefix, normalized casing, trimmed whitespace, "cleaned up" punctuation), the draft lands as a standalone message and you have to manually fix it. The fix: copy the subject of the most recent message in the thread byte-for-byte. If it already starts with "Re:", use it as-is. If it doesn't, prepend exactly Re: and append the rest unchanged. Don't trim, don't normalize, don't translate, don't shorten. Also don't include any quoted body from the original.

If your version of the Gmail draft tool also supports a replyToMessageId parameter, pass it as a belt-and-braces backup. But subject-matching is the primary mechanism and you should not rely on replyToMessageId alone.

These two rules are the difference between a skill that saves you time and a skill that creates more work cleaning up its mistakes.

How the three skills work together

Here's where it gets interesting.

The meeting analyzer proposes updates to product packs. I apply them. The Slack and email responders read the (now-updated) packs when drafting replies.

That means if you have a meeting in the morning where you decide to push a feature launch date from May 15 to June 1, the meeting analyzer outputs that as an update proposal. You paste the new date into the pack at 11am. Every Slack message and email drafted later that day that asks about the launch date will already know.

You don't have to tell the Slack responder about the meeting. You don't have to brief the email drafter on the decision. The pack updates (with your manual paste), and the whole system knows from that point forward.

This is the compounding part. Each skill on its own saves you maybe 30-60 minutes a day. Together, with a shared source of truth, they become a coherent operating system.

What I learned building this

A few things that weren't obvious at the start:

The hard part isn't the AI. It's the plumbing. Matching meetings to the right docs. Keeping the voice consistent across skills. Knowing when to draft versus when to escalate. Working around the limitations of the tools (like the Google Drive integration not supporting doc edits). The prompt is 20% of the work. The other 80% is the rules around the prompt.

Scheduled tasks beat chat. A skill that runs every 30 minutes without me asking is 10x more useful than one I have to summon. The friction of "open Claude, ask the question, wait for the answer" is what kills most assistant use cases. Remove the friction and the value shows up.

Always draft, never send. This one is non-negotiable. I review every output before anything goes out. The skill is my assistant, not my replacement. And I've caught enough tone misses in the first few weeks that I never want to remove the review step.

A project index is the unlock. One source of truth that tells the skills "this meeting = this doc" is worth more than any prompt tweak. Without the index, the skills have to guess. With the index, they're deterministic about which pack the analysis applies to.

Be honest about integration limits. When I first designed this, I assumed Claude could edit Google Docs directly. It can't. Reframing the skill around "structured proposals you manually apply" instead of "automatic updates" required a redesign, but the redesigned version actually works.

Start with one skill, then add. Don't try to build all three at once. Build the one that saves you the most time (for me, that's the meeting analyzer). Run it for two weeks. Refine the voice and the rules. Then add the next one.

Regenerate the voice profile every month. Your writing evolves. The projects you work on shift. Re-run the setup prompts every few weeks to refresh the voice and context.

A quick starter checklist

If you want to build this yourself, here's the order I'd go in:

1. Enable Claude Desktop with Cowork
2. Connect Gmail, Google Calendar, Google Drive, and Slack as integrations
3. Create your Project Index Google Doc with Configuration, Mappings, and Processed Log sections
4. Create your Meeting Intelligence folder in Google Drive
5. Paste the folder's ID into the Configuration section of the index
6. Create your first product pack Doc for one active workstream
7. Generate the Meeting Notes Analyzer prompt using the setup prompt above
8. Create a Cowork scheduled task, paste the prompt, set frequency to 30 minutes, weekdays only
9. Let it run for two weeks, refining the voice and rules as you go
10. Once the meeting analyzer is working, add the Slack responder
11. Once Slack is stable, add the email responder

Start small. Don't try to automate everything at once. The goal is to reclaim hours, not to build a complicated system that needs constant babysitting.

One final note on privacy

Everything I've described runs on your own accounts with your own data. The skills read your emails, meetings, and Slack messages because you're asking them to. They don't share that data with anyone. The drafts stay drafts until you send them. The update proposals stay as structured text in the Cowork output and the Intelligence Doc until you manually paste them into your product packs.

If you're doing this inside a regulated company, check with your IT and legal teams first. Some organizations restrict which AI tools can read corporate email. Some require specific data-handling agreements. Don't assume you can just turn this on without asking.

For everyone else, this is safer than the alternative, which is a dozen half-built tools from a dozen vendors, each with their own data handling policies.

Build one system. Review every output. Own the process.