Kickoff
For most of this series I’ve been alone in a room with git repos, answerable to nobody but the commit history. This post is about the opposite: nearly forty colleagues, four consecutive weeks, one room, and a shared library that every cohort inherited from the one before.
By April 2026 I’d spent months proving things at home — everything this series has covered so far, on my own repos, on my own time, unwitnessed. AI Week was the bet that it could transfer anyway. Not the frontier versions; the adoptable versions. Every exercise traced back to something I’d already broken and fixed on my own time, stepped down to the rung a busy team could actually stand on.
The Run
The shape
Four back-to-back cohorts, early April into May, nine or ten people each, same room, Monday to Friday. The first plan ran Wednesday to Wednesday; by the time the participant briefing went out it was Monday to Friday. Plans meet calendars.
Every week had the same skeleton. Monday morning: a shared introduction, then a split by experience. Monday afternoon: an ideas session where project leads brought short briefs — here’s the project, here’s what hurts, here’s the skill we wish existed. Tuesday to Thursday: building, with a short standup each morning. Friday afternoon: the outgoing cohort demoed to the incoming one and left two artefacts behind — a golden ticket (each person’s proudest skill, one sentence, no elaboration) and a wish list (what they wanted to build and didn’t).
The cohorts had different jobs. The first built for its own projects. The second used those skills on other projects and built more. The third pushed the cross-pollination further. The fourth was hand-picked for cross-cutting work: tools that had to function in any team’s repository, not just their author’s.
What I taught first
Not prompts. The first hour was mostly about trust.
Supervised, on purpose. A human stays in the loop, and that’s a strategy rather than a limitation. The rhythm I asked for all week was Plan → Review → Implement: the agent proposes, you review as the domain expert rather than rubber-stamp, then it executes while you watch. A skill, I said, is a codified version of a plan you’ve reviewed and trusted enough times to stop re-reading.
Skills are knowledge, plugins are packaging, the marketplace is where it compounds. Progressive disclosure from Post 8 got its own slide: about a hundred tokens loaded at startup, the full body on activation, references on demand.
Where things live. If a skill knows about your service’s APIs, data or deployment process, it belongs in the project repo, not your home directory. Personal shortcuts are fine; project knowledge travels with the project.
What you can’t install. A skill runs with your credentials and your filesystem. “Does it do what it says?” is the wrong question; “can I see who wrote it and what it touches?” is the right one.
And the setup happened before Monday: three steps, emailed in advance, so the morning wasn’t a setup queue.
Two on-ramps
I had originally imagined the split as engineers versus managers. The split that mattered was experience.
The first track was for people new to skills. One prompt opened it — what’s the most tedious, repeatable thing you do in your project? — and the goal was a working skill by lunch. Not polished. Working.
The second track was for people who’d already been building. They inventoried what they had, decided what was personal and what belonged to a project, what was a skill and what was really an agent, and packaged one thing properly.
Both tracks reconvened before lunch and one person from each showed what they’d made. The ideas session started with everybody already holding something.
And it was never only engineers. Programme, project and engineering managers were in the room too, and they turned out to be some of the most influential people in it. They didn’t come to watch. They brought their own problems: backlog hygiene, standup prep, status reporting, delivery estimates, requirements and design review. Those problems set the agenda as much as any codebase did. Several of the earliest and most-reused skills were aimed squarely at them: sprint-hygiene checks, not code generators. Bringing managers in as builders, with their own problems, rather than as an audience for a separate track was one of the better accidents of the design.
What resistance actually looked like
I braced for scepticism. What I got was plumbing.
Repository write access that arrived mid-week instead of on Monday. Secrets and identity permissions that ate half a day — in more than one cohort. A data source that couldn’t be opened up in time. A token limit hit on a Thursday afternoon. A vendor outage on a Wednesday, which the command-line tools sailed through and the chat app did not.
Not one of these was about whether AI was a good idea. Every one of them was about whether the organisation was ready for someone to use it on a Monday.
And the blocked weeks still shipped. In one cohort, a blocked data source cost the first half of a week; the builder switched to a data-quality check on data they could reach and shipped it within two days. A blocked data source cost the plan, but not the week.
What compounded
Across the four weeks, the cohorts raised around eighty pull requests, and roughly four in five people shipped at least one skill during their week. Nine of those PRs weren’t written by a person at all; more on that below. Every handover passed forward at least three skills that the next cohort used on real work.
The part I didn’t plan was the chains. An anomaly-detection prototype from week two became a scheduled production job in week three, and in week four a version that reasoned about why a metric moved, grounded in a structured model of the domain rather than left to the LLM’s imagination. A set of documentation rules written in week one was reused by three different teams without anyone rebuilding them. A skill that taught the agent a component library in week one became, in week four, a server the agent could query for the live catalogue. Nobody scheduled any of those continuations. The handover notes carried them.
One more, from the first Friday: an agent built during week one opened nine documentation pull requests of its own against a production repository before the week was out.
What it didn’t prove
Honesty section, because the scorecard version of this post is easy to write. Demos weren’t recorded until someone asked why not, so some of the evidence lives only in the memories of the people in the room. Some of the best work was validated by a live demo and never became a pull request — convincing on the day, impossible for the next cohort to inherit. And week four’s first afternoon was spent discovering that inherited skills were carrying configuration the runtime silently ignored (more on that in Post 14). Whether the library is still in use months later is a question for a later post, not a claim for this one.
The Debrief
A blueprint you can adapt, assembled from four runs of the same week:
On The Training Ground
The Tedious-Task Handover. By the end you’ll have a skill that takes something boring off your plate, written so a colleague can pick it up without you in the room. It’s the smallest piece of a team practice that still compounds.
Info
You’ll need: an agentic CLI, the repo you work in most, one real task you do at least weekly, and one colleague willing to spend fifteen minutes trying your skill.
Before opening anything, list the repeatable things you did in the last fortnight that you resented. Pick the one with the clearest done: a report that exists, a ticket that’s tidy, a check that passes. Not the most important task. The most tedious one.
Fresh session, in the repo where the task lives:
I want a skill for this recurring task: <task>.
Here's a real example of a finished one: <paste or point at it>.
Draft a SKILL.md that describes what DONE looks like, the inputs it
needs, and where to find them in this repo. Don't script the steps —
describe the outcome and let the agent navigate. One job only; if
this is really two tasks, tell me and draft the first.
Keep the description short and specific enough to trigger reliably.Use it on this week’s instance of the task, not a toy one. Where it goes wrong, fix the skill rather than the session, then run it again. Two rounds is usually enough.
If the skill knows about this project, commit it to the project repo, not your home directory. Personal shortcuts can stay personal. Project knowledge travels with the project.
Give it to your colleague with exactly two things: a golden ticket (one sentence saying what it does and why they’d want it) and a wish list (what you’d build next if you had another day). Watch them run it without your help. Every question they ask is a gap in the skill. Write the wish list into the skill’s README.
Tip
What you just proved: adoption starts with somebody’s own tedium, not a showcase. And a handover note turns a personal shortcut into something the next person can build on. Do the same thing with three colleagues and you have a library. Do it every week and the library starts to compound.
I have taught precisely one class in my life before this one, at a friend’s request, on how to change a bicycle tyre. Four people came. One tyre was successfully changed, by me, while the other three watched and asked when the AI part started. I have chosen not to read anything into that.