Patterns

Claude at Work

How Claude became my work operating system - from email to invoicing to client projects.

The setup

I use Claude for most of my work - not just coding. Email, invoicing, project management, client research, meeting prep, documentation. The pattern: I decide what needs to happen, Claude does it.

Skills that call APIs

The way I integrate Claude with my work tools is through skills - instruction files that teach Claude how to talk to specific APIs. Not through plugins or middleware. Just skills that make HTTP requests.

Here’s the general pattern:

# Google Calendar

View and manage my calendar.

## Authentication

Use this API key: (stored in env)
Base URL: https://www.googleapis.com/calendar/v3

## What you can do

- List today's events: GET /calendars/primary/events?timeMin=...
- Search events: GET /calendars/primary/events?q=...
- Create events: POST /calendars/primary/events

## Notes

- Always show times in Europe/Berlin timezone
- When creating meetings, default to 30 minutes
- Ask before creating or modifying events

Claude reads the skill, knows the API, manages my calendar. Instructions and an API key. That’s it.

Why not MCP?

MCP (Model Context Protocol) is Anthropic’s official way to give Claude access to external tools. It works. I don’t use it.

Same idea as “build your own tools.” Most MCP servers are someone else’s abstraction between Claude and an API. You’re installing a dependency, trusting their implementation, and hoping it keeps working when the API changes. Claude already understands REST. It can read API docs and figure out the right request.

When I want Claude to talk to a new service, I don’t go looking for an MCP server. I tell Claude: “go find the API docs for this service and build me a skill.” Five minutes later I have a skill file that does exactly what I need, nothing I don’t, and I can read every line of it.

MCP has real advantages - type safety, structured tool definitions, community servers. For my workflow, having Claude build its own integrations has just been simpler.

What I’ve integrated

These are real integrations I use daily, all through skills:

ServiceWhat Claude does
GmailSearch, read, draft replies
Google CalendarCheck schedule, find free slots, create events
JiraSearch issues, create tickets, update status, add comments
ConfluenceSearch pages, read content, create and update documentation
HubSpotSearch contacts, view deal pipelines, check company info
InvoicingCreate offers and invoices, manage client data
Google ChatRead conversations, send messages
Google DocsCreate docs from local files, share them
Vertex AI SearchSearch company knowledge base and internal docs
Time trackingBook time entries, view timesheets

Each one is a skill file. Some are simple (HubSpot is mostly read-only lookups). Some are more involved (invoicing needs to handle line items, tax rates, and document completion workflows).

Work folders

I organize client work in Obsidian with one folder per client:

Work/
├── .claude/
│   └── settings.local.json    # Permissions for work APIs
├── clientname/
│   ├── plan.md                # Project plan
│   ├── workshop-notes.md      # Meeting notes
│   └── deliverables.md        # What we're building
└── another-client/
    └── ...

When I open Claude in the Work/ folder, it has the right API permissions and knows about all my clients. When I’m working on a specific client project, it reads their plan and knows the context.

This is just CLAUDE.md and file structure. No special tooling.

The daily flow

A typical workday looks like this:

Morning:

  • “What’s on my calendar today?”
  • “Check my inbox for anything urgent from [client]”
  • “What Jira tickets are assigned to me?”

During work:

  • “Create a Jira ticket for [thing we discussed]”
  • “Draft a reply to [email] - tell them we’ll have the proposal ready Thursday”
  • “Search Confluence for [topic] - I need the architecture diagram”

End of day:

  • “Create an invoice for [client] -8 hours consulting, reference project [name]”
  • “Update the Jira ticket status to Done”
  • “Send [colleague] a message that the review is ready”

No more switching between seven browser tabs. One conversation, Claude does the rest.

The real unlock

“Check my calendar, draft a reply to that email, and create a Jira ticket for the follow-up” - three tools, one sentence, zero context switches. That’s the point.

Getting started

You don’t need to integrate everything at once. Start with the tool you use most:

  1. Tell Claude to build it - “Find the API docs for [service] and create a skill that lets you [do the thing]”
  2. Set up auth - Add your API key to the environment
  3. Test it - “search my emails for [thing]”
  4. Iterate - “also add the ability to [other thing]”

Claude finds the API docs, figures out the endpoints, writes the skill. You just set up the API key.

Start with read-only operations. Searching and viewing is safe. Creating and modifying comes after you trust the integration.


Official Documentation

  • Skills - Creating custom slash commands and reusable workflows