Session 2

Session 2: Skills to Agents

Turning the work you repeat into something reusable. From spotting the pattern, to writing the skill, to knowing when it's safe to hand off.

Find the Repeatable Work

Audit your own week for the tasks worth turning into a skill.

Prompt

I'm going to describe how I spend my week. Help me find what's worth turning into a reusable skill.

My role: <role>
Things I do every week: <list them, however roughly>
Things I do every show cycle: <list>
The task I most dread: <one>

For each candidate, score it on:
- FREQUENCY — how often it actually happens
- SAMENESS — how much the process is identical each time vs. genuinely different
- JUDGMENT — how much of it needs a human decision
- COST OF ERROR — what happens if it's wrong and nobody catches it

Then rank them. Tell me which one to build first and, just as importantly, which ones I should NOT automate and why.

What it is

A structured triage of your own recurring work against the four factors that decide whether a skill will actually pay off.

So what

The usual failure is building a skill for something you do twice a year, or for something that looked repetitive but needs a judgment call every time. Those get abandoned. This finds the boring high-frequency work where the process really is the same each time — that's where the hours are.

How to use it

Be honest in the "most dread" line; it's usually the right answer. Take the do-not-automate list seriously — anything high-judgment or high-cost-of-error is better served by a prompt you run manually than a skill that runs on its own.

The Practice Brief

A ready-made task to build a Claude skill against.

Prompt

Build me a marketing campaign for <brand>'s Black Friday and Cyber Monday deal.

Theme the whole thing around <my favorite TV show>. Carry it through the concept, the headlines, and the channel plan.

Then tell me where the theme should stop, so the offer stays clear.

What it is

A stand-in task for when you do not have one of your own ready.

So what

What you keep is a skill that turns a brief into a campaign the same way every time: concept, headlines, channel plan. The next brief that lands starts as a structured draft instead of a blank page. The theme question is where your judgment gets written in, so the skill knows when to stop an idea running away with the offer.

How to use it

Only if you need it. Swap in your brand and your show, then run it through the skill-creator the same way you would your own task.

Turn This Thread Into a Skill

Capture a process you just worked out, while it's still fresh.

Prompt

We just worked through <the thing> together in this conversation. I want to be able to repeat it without re-explaining everything.

Before you write anything, audit this thread:
1. What did I actually ask for, underneath what I literally typed?
2. Where did you get it wrong, and what did I correct? Those corrections are the important part.
3. What context did I supply that you'd need again next time?
4. What was specific to this one case and should NOT be baked in?

Show me that audit first. Once I confirm it, write the skill.

What it is

A capture step that mines a working conversation for the rules you arrived at — especially the corrections.

So what

The corrections are the whole value. If you write a skill from scratch you'll describe the process as you imagine it; if you write it from a real thread you encode what actually went wrong and how you fixed it. Step 4 is what stops you hard-coding one client's details into a skill you meant to reuse.

How to use it

Run it at the end of a session where something finally worked — not at the start of a new one. Read the audit carefully before you approve it; if it misread what you were after, the skill will inherit that.

Write the SKILL.md

Get the structure and the description right — the description is what makes it fire.

Prompt

Write a SKILL.md for <what it does>.

Frontmatter:
- name: kebab-case, matches the folder name
- description: what it does, THEN the literal phrases I'd say to trigger it, THEN an explicit "Do NOT use for X (use Y instead)" clause

Body:
- What this skill is for, in two sentences
- The inputs it needs, and what to do when one is missing
- The procedure, as numbered steps
- The output format, shown as a filled-in example rather than described
- The mistakes to avoid — specific ones you'd expect on this task, not generic advice

Rules: no file paths from my machine, no tool or connector names unless the skill genuinely can't work without them, and keep it under 500 lines. Anything longer than that belongs in a separate reference file.

What it is

The house structure for a skill file, with the frontmatter conventions that determine whether it gets invoked at the right moment.

So what

A skill that never triggers is worth nothing, and triggering is decided almost entirely by the description. Naming the literal phrases you'd say — and the cases where it should stay out of the way — is the difference between a skill that fires when you need it and one you have to invoke by name every time.

How to use it

Write the description last, once the body has settled and you know what it actually does. The no-local-paths rule is what makes a skill portable to a teammate; that's the most common reason a shared skill breaks on someone else's machine.

Test It Before You Trust It

Three cases: the easy one, the edge case, and the one it should refuse.

Prompt

Here is a skill I just wrote. Before I use it on anything real, stress-test it.

1. Write three test cases: an obvious one it should handle cleanly, an edge case with something missing or contradictory, and one it should decline because it's outside what the skill is for.
2. Run each one and show me the output.
3. For each, tell me where the skill file was ambiguous enough that you had to guess.
4. Give me the specific edits that would close those gaps.

<paste the skill>

What it is

A rehearsal on invented cases, including one the skill is supposed to refuse.

So what

Skills fail on the inputs you didn't picture, and the refusal case is the one nobody tests — a skill that cheerfully handles work it shouldn't is worse than one that doesn't exist. Step 3 is the payoff: the ambiguities are exactly the places a teammate will use it differently than you intended.

How to use it

Run this before you share a skill with anyone, every time. When you apply the fixes from step 4, run the whole thing again — edits reliably introduce fresh ambiguity somewhere else.

From Skill to Agent

Decide what can run unattended — and what should never run without you.

Prompt

I have these skills: <list them>.

I want to understand what could run as an agent — chained together, on a schedule or a trigger, without me watching each step.

For each skill, tell me:
- Could it run unattended? What would have to be true first?
- What does it need that I'd have to connect (calendar, email, a document store, a project tool)?
- What's the blast radius if it runs and gets it wrong?
- Should a human approve before it acts, or is reviewing after good enough?

Then propose one chain worth building, and be explicit about where the human checkpoint goes.

What it is

The bridge from skills you invoke to workflows that run on their own, framed around what can go wrong.

So what

The gap between a good skill and a safe agent is entirely about blast radius. Anything that only reads and drafts is low risk. Anything that sends, posts, books, or bills needs a human in front of it. Deciding that deliberately — before you wire it up — is what keeps automation from becoming something you have to clean up after.

How to use it

Start with a chain that produces a draft for you to approve, not one that acts. Run it that way for a few cycles; if you're approving unchanged every time, that's real evidence you can loosen the checkpoint. If you're editing every time, the skill underneath isn't ready.

Materials

Netflix House × Sparks transcriptMD Netflix House × Sparks transcriptPDF