Lesson 4.1: Sharing Your Automation, Toolkits and Team Deployment

🎯 What You'll Learn: How to package your automation so your team can install it in minutes, not rebuild it over weeks
⏱️ Time Required: 35 minutes

---

The Sharing Problem

Riley's automation is working. Her margin report runs every Monday, her audit log captures every change, and her validation chain fires automatically. Her colleagues David and Lisa have noticed.

"David asked me three times last week to help him set up the same thing for EMEA. I could spend two hours walking him through each step, or I could package it once and let him install it in ten minutes. The second option respects both our time."
— Riley Harper

This is what a toolkit solves.

---

What Is an Automation Toolkit?

A toolkit is a folder containing your skills, agents, hooks, and configuration, organised so that anyone can install it with a single command and have your automation working immediately.

Think of it as packaging the recipe, not just the meal.

Toolkits are also how you share work across your organisation, or with colleagues who use the same workflows.

---

Toolkit Structure

An automation toolkit is a directory with a specific layout:

my-automation-toolkit/
├── README.md            ← Required: how to install and use it
│
├── skills/              ← Your skill files
│   ├── weekly-margin-report/
│   │   └── SKILL.md
│   └── data-validator/
│       └── SKILL.md
│
├── agents/              ← Your agent definitions
│   └── risk-analyzer.md
│
├── hooks/               ← Hook configuration
│   └── settings-snippet.json
│
└── templates/           ← Starter files for new users
    └── CLAUDE.md.template

The README.md at the root explains what's inside and how to install it. That's the only required file at the root, everything else is your automation assets.

---

Exercise: Inventory and Plan Your Toolkit

⏱️ Total Time: 35 minutes

Step 1: Take Inventory (15 min)

List everything you've built across this course that belongs in your toolkit:

## My Toolkit Inventory

### Skills
| Name | What it does | File location |
|------|-------------|---------------|
| | | |

### Agents
| Name | What it does | File location |
|------|-------------|---------------|
| | | |

### Hooks
| Hook type | What it does | Current location |
|-----------|-------------|-----------------|
| | | |

### Templates / starter files
| File | Purpose |
|------|---------|
| | |

### Configuration needed from the user
| Setting | Why they need it |
|---------|-----------------|
| | |

Riley's inventory:

Step 2: Define Your Toolkit (10 min)

Answer these five questions:

Name: What's a clear, descriptive name? (lowercase, hyphens, no spaces)

One-line description: What does it do and for whom?

Who is it for? Be specific, "risk operations managers doing weekly margin reporting", not "finance teams"

What do they need to configure? Slack token? A folder path? API credentials?

What does success look like for the installer? What should work within 10 minutes?

Riley's answers:

margin-operations-toolkit

Automates weekly margin reporting with risk analysis for Operations Directors

Operations Directors at financial services firms using Prime Broker portal

Slack webhook URL, Prime Broker portal export folder path

Monday 8am: report in Slack without Riley doing anything

Step 3: Create Your Toolkit Structure (10 min)

mkdir -p ~/toolkits/my-toolkit/{skills,agents,hooks,templates}
touch ~/toolkits/my-toolkit/README.md

Copy your skill and agent files into the appropriate folders. In the next lesson (4.2) you'll organise the files and write the README.

✅ Success Criteria:

---

What Changes When You Package for Others

The hardest part of making a toolkit isn't the technical structure, it's the perspective shift.

When you built your automation, you knew your context. You knew your Prime Broker portal folder, your Slack channel, your data format. The person installing your toolkit knows none of that.

Three rules for toolkit authors:

Never hardcode your paths. Everything that's specific to your machine should be a configuration variable.

Assume zero context. Write the README as if the reader has never heard of your work.

Test the install fresh. Ask a colleague to follow your README on a clean machine. Watch silently. Everywhere they get confused is a documentation gap.

---

Next Up

Lesson 4.2: Build Your Toolkit Structure

You've done the inventory and planning. Now you'll organise your files into the toolkit structure and create a README that makes the whole thing installable.