Connecting your tools to Claude is step one. Most teams stop there

Most teams that adopt an AI agent go through the same first month. Someone connects the CRM. Someone else connects analytics, the CMS and the shared drive. There is a burst of impressive one-off demos: “summarise every deal that slipped last quarter”, “which blog posts drove sign-ups in August”. Then usage quietly flattens. The connectors are still there, but the work people actually do every week looks much as it did before.

The connectors are not the problem. They are the first of three steps, and most teams never take the other two. We see the progression often enough in the libraries on shareskills that it is worth writing down.

Step 1: connect, then stack

A connector, usually an MCP server, lets an agent read and write inside a tool you already pay for. On its own that fixes three familiar complaints about AI output:

• It stops being generic. An agent that can read your positioning doc, your brand guidelines and last quarter’s winning proposals writes like your company, not like the average of the internet.
• It stops making numbers up. Asked for pipeline or traffic, it reads the real figures from the system of record instead of producing plausible-sounding ones.
• It respects who you are. A connector acts with the permissions of the person who connected it. The intern’s agent sees what the intern sees; the finance lead’s sees more. Nobody has to build a second permission model for the AI.

The real jump comes when you stack them: several connectors live in the same session, so one request can join data that has never sat in one place. Closed-won deals from the CRM, matched against the pages those accounts read on the website, matched against the call transcripts where they raised objections. No single tool in the stack can answer that question. The agent in the middle can.

The shape every good workflow takes

Look at the stacked requests that people keep coming back to, and nearly all of them have the same five beats:

• Gather context from the connected tools: records, documents, metrics.
• Reason over it with specific instructions: what good looks like, what to ignore, what to flag.
• Combine it with a second source, if the question needs one.
• Write back to where the result belongs: a CRM note, a CMS draft, a row in a tracker, rather than a chat reply that scrolls away.
• Save the whole procedure so nobody has to type it again.

That last beat is step two, and it is where most of the value is hiding.

Step 2: wrap it in a skill

A connector gives the agent access. A skill gives it your way of doing the job: which records matter, which framework to judge against, what the output should look like, where it goes when it is finished. It is a folder of markdown, and the instructions in it can name the tools it expects to find:

---
name: weekly-pipeline-review
description: Monday pipeline review. Use when asked for the weekly
  pipeline, deal risks, or "what slipped".
---

1. From the CRM, pull every open deal over $20k whose close date
   moved in the last 7 days.
2. For each, read the most recent call notes. Flag: no next step
   booked, a new stakeholder, or pricing raised as an objection.
3. From analytics, check whether the account visited the pricing
   or security pages this week.
4. Write one line per deal to the "Pipeline review" note in the
   CRM, worst risk first. Never change a deal stage.

Notice what is not in there: no API keys, no tokens, no account IDs. The skill describes the procedure; each person’s own connectors supply the access, with their own permissions. That is what makes a skill safe to hand to a colleague, and it is why we scan every save for credentials that should never have been pasted in.

The workflows that earn a skill tend to be the ones that already have a named owner and a recurring slot in the calendar. From the libraries we see, the common ones are:

• Brief builders. Pull the scattered inputs for a campaign or project — strategy doc, last results, stakeholder notes — into one structured brief that every later task reads from.
• Reporting roll-ups. Numbers from three tools, reconciled into one view, written to the place leadership already looks.
• Quality audits. Check finished work against the team’s own framework before it ships: the brand rules, the messaging hierarchy, the compliance checklist.
• Evidence finders. Search call transcripts or support tickets for customer language on a given theme, with sources attached.
• Bulk editors. Apply the same SEO or copy fix across fifty CMS pages, as drafts for a human to publish.

We wrote a longer piece on when a skill beats a prompt. The short test: if you have pasted roughly the same instructions three times, it is a skill.

Step 3: put it on a schedule

Once a workflow is a skill, it no longer needs a person to start it. The Monday pipeline review can run at 7am on Monday and be waiting when the sales lead opens the CRM. The monthly reporting roll-up can land on the first of the month. Claude Code, Cowork and most agent platforms can now run a skill on a schedule.

Scheduling raises the stakes in one specific way. A skill you run by hand gets looked at every time you run it; a scheduled one runs unattended, week after week, on whatever version it was last given. If the team improves the skill in March and the scheduled copy is a file someone saved in January, the routine is quietly doing last quarter’s job. A scheduled skill should read the current version each time it runs, from one place. (Unattended jobs also have no person present to approve a sign-in, so they connect to shareskills with an API token rather than the browser flow.)

The part nobody plans for: doing it as a team

Here is where the progression usually breaks. Connectors are per-person, and that is correct: everyone brings their own access. But skills, by default, are per-person too. They live in one laptop’s skills folder, or one person’s account. So five people on a marketing team connect the same four tools and then each write their own brief builder, slightly differently, and none of them knows the others exist.

Step one scales on its own. Steps two and three do not, unless the skills themselves have somewhere shared to live: one copy that belongs to the team, that anyone can improve under review, that updates everywhere when it changes, and that works from whichever tool each person prefers — the chat window, Cowork, a terminal. That is the job shareskills exists to do. Connect it once as an MCP server alongside the rest of your stack, and the library of team skills becomes one more thing every agent session can reach.

Your tools get more valuable, not less

One last observation, because it comes up in every budget conversation. None of this replaces the CRM, the analytics suite or the CMS. It makes each of them more useful by letting their data meet in ways the products cannot manage alone. The expensive subscriptions stay; what changes is that the know-how for using them together stops living in one person’s head and starts living in a skill the whole team runs.

If you want a place to start: pick one task you already do every week that touches two tools. Do it once with both connected. Save it as a skill. Share it with the one colleague who does the same task. Then, when it has survived a few weeks of real use, give it a schedule.