Routines + Skills + MCPs

By now you've built a skill (Module 9), connected an MCP (Module 8), and shipped a Routine (this module). They look similar. They're not. Using the wrong one for the job wastes time and tokens.

This lesson is the decision tree. Save it and refer back when you're about to automate anything.

What each one is, in one line

MCP - a connection

A bridge between Claude and a platform (Google Ads, Meta, Supabase, GitHub). It lets Claude read data and, depending on the MCP, write it. On its own, an MCP does nothing - you still have to ask Claude to use it.

Skill - a saved workflow

A reusable set of instructions packaged as a slash command. You invoke it in a session. The skill tells Claude how to do a task using whatever MCPs and files it needs.

Managed Agent (Routine) - a scheduled run

Claude running remotely on a schedule, without you. Uses MCPs and skills like any session, but fir es itself.

How they stack together

They're not alternatives. They compose

1. MCPs are the foundation - they're how Claude touches the outside world
2. Skills sit on top - they're workflows that use MCPs to do something useful
3. Routines sit on top of that - they fir e skills on a schedule without you

A typical weekly report Routine looks like this

Routine (fires every Monday 7am)

-> invokes the /weekly-report skill -> which uses the Google Ads MCP (pull data) -> and the Supabase MCP (pull historicals) -> and the GitHub MCP (commit the HTML) -> and the Slack MCP (post the preview link)

If the skill changes, every Routine using it gets the new behaviour automatically. If an MCP credential expires, every Routine and every skill breaks at the same time. That's the coupling you're buying.

When to use which

Use an MCP alone when

• You're exploring a platform for the first time
• The task is one-off and ad hoc
• You want to poke at data, not build a workflow

Build a skill when

• You've done the same task manually 3+ times
• You want consistent output across runs
• You want to share the workflow with teammates
• You'd rather type a slash command than re-explain yourself

Build a Routine when

• You've built the skill and it works reliably
• The job runs on a clock (not when you think of it)
• The output is valuable even without you in the room
• You want the result waiting for you when you start work

The progression: try manually in a session -> skill it when it repeats -> routine it when it runs on a schedule.

The common mistake

Skipping the skill layer. Writing the entire workflow inside the Routine prompt.

Why it's worse

• Harder to test - you can't invoke the Routine prompt in a session without firing a Routine run
• Harder to reuse - other Routines can't share the logic
• Harder to update - every change means re-opening the Routine editor
• More expensive - long prompts cost tokens every run, a skill file loads only when needed The fix: always build the skill first, get it working in sessions, then wrap a Routine around it.

A working example - weekly report automation

Layer 1: MCPs connected

Google Ads (read), Meta Ads (read), Supabase (read/write), GitHub (write), Slack (write). Each has credentials stored.

Layer 2: Skill built and tested

/weekly-report skill - pulls data, generates HTML following the report template, commits to GitHub, posts the preview link to Slack. Tested in sessions until the output is consistent.

Layer 3: Routine wraps the skill

weekly-report-clientname Routine - fir es every Monday 6am AEST, invokes the /weekly-report skill with the client-specific inputs, logs the run to Supabase, notifies Slack on failure.

Now: the client report lands in your inbox every Monday morning. A broken credential pings Slack. You review and send. Total weekly time: 10 minutes of review instead of 2 hours of build.

The minimum sustainable stack

You don't need every MCP, every skill, or every Routine from day one. Build in this order:

1. Connect the 3-5 MCPs you touch most often (usually an ad platform, a DB, GitHub)
2. Build skills for the 3 workflows you repeat weekly
3. Wrap the highest-value skill in a Routine
4. Add one Routine a month after that, only if the previous one is working

5 working Routines beat 20 broken ones. Keep the stack small and reliable.

Power-user tips

• Skills are the unit of reuse - write clean, focused skills and the Routines on top stay simple
• MCP audit quarterly - list all connected MCPs, prune ones no Routine or skill actually uses. Smaller attack surface, cheaper loads.
• Routine naming convention - {cadence}-{job}-{target} keeps the list sortable and self-documenting
• Document the stack for each client - a simple table in the project CLAUDE.md: MCPs connected, skills built, Routines running. When something breaks, you know where to look.

Action items

☐ Write the stack for your first Routine: which MCPs does it call, which skill does it invoke

☐ Check: is the workflow in a skill, or buried in the Routine prompt? If buried, extract it.

☐ Add a "managed stack" section to your project CLAUDE.md listing MCPs, skills, Routines

☐ Plan your next 2 Routines - one per month is a sustainable pace

Module complete. You're ready for Module 11: Plan and structure complex projects.

Exercises

1. Review the concepts covered in this lesson: Routines + Skills + MCPs.
2. Write down your key takeaway from this lesson.
3. Practice running any commands or prompts mentioned above inside your terminal.