Skills: Encoding Your Judgment¶
From Process to Permanence¶
You just practiced decomposition — breaking a big feature into independently shippable pieces. That process worked. But what happens next time you need to decompose a feature? You'll explain the approach to AI again from scratch. And the time after that, you'll explain it again. Every new conversation starts from a blank slate.
This isn't just about decomposition. Think about any multi-step process you repeated during Run 1: adding a new page to the app, creating a form, updating documentation after a change. Each time, you explained the process from scratch. Each time, AI did it a little differently.
If you don't write it down, AI reinvents it every time. Your project context file tells AI what the project IS, but it doesn't tell AI HOW you want things done — the processes and procedures your team follows.
User stories solve the "what to build" problem. Skills solve the "how to build it" problem.
What Is a Skill?¶
A skill is a set of reusable instructions saved to a file that tells your AI coding assistant how to do a task YOUR way. Think of it as a recipe you write once and reuse in every conversation. When AI encounters a relevant task, it reads those instructions and follows them — without you having to re-explain your conventions.
A skill is a SKILL.md file in .claude/skills/ in your project. Claude reads it automatically when it determines the skill is relevant, or you can invoke it directly.
Skills map to custom instructions or prompt templates saved in your project. The concept is the same — reusable instructions that AI follows without re-explanation.
Skills map to prompt templates invoked with /name. Save them in your project and invoke them by name.
The key insight: skills encode YOUR judgment, not generic automation. The goal isn't to write a "perfect" prompt. It's to teach AI the specific way your team evaluates, decides, and produces work. When the skill runs, it should produce output that reflects YOUR team's conventions, not generic AI output.
The "We Do, You Do" Pattern¶
How do you build a skill? Not from scratch. You build it through iteration — the same way you'd onboard a new team member.
- We Do: Work through a task with AI, refining until the output matches what you'd produce yourself. Each "no, like this instead" encodes your judgment.
- You Do: Ask AI to capture what you just did as instructions it can follow independently. AI just went through the process with you, so it knows what to capture.
- Test: Start a fresh conversation and run the skill with different input. Does it reproduce the quality without your guidance?
- Refine: If not, identify what's missing and update the skill. Common failure modes: the skill assumes context from your original conversation (add it explicitly), it describes the what but not the how (add the steps), or it's too generic (add your team's specific conventions).
Remember from Lift 1: AI is stateless. When you build a skill in conversation, AI has all the context from your refinements. But when someone invokes that skill in a fresh session, AI only has what's written in the skill file. Testing with fresh context proves your skill is self-contained. If it only works in the session where you created it, you're relying on conversation context — not the skill itself.
Skill Candidates: Spot the Pattern¶
Pay attention to repeated friction — every time AI makes the same mistake twice, every time you re-explain the same convention, that's a signal.
Skills are for processes — repeatable, multi-step workflows where you want AI to follow the same approach every time. Good skill candidates for your observation network:
- Feature decomposition — You just practiced this. Capture how your team breaks big features into independently shippable story-sized pieces
- Adding a new page — When you add a new page to the app, you probably want AI to follow the same steps every time: check what pages already exist, match the existing navigation pattern, follow the same layout structure
- Creating a new form — Every time you need a new form (submission, filtering, editing), there's a process: what fields to include, how to handle validation, where to put the submit action
- Documentation cleanup — After building a feature, update the relevant docs in a consistent format
What about visual conventions? You might be wondering: should card layouts, color schemes, and form styles be skills too? Actually, no — those belong in your project context file from Lift 1. Here's the test: if a convention should apply every time whether you're thinking about it or not, it's a project context rule. If it's a process you invoke on demand, it's a skill. Your project context file says "observation cards always use this layout." A skill says "when decomposing a feature, follow these steps."
The signal: if you've explained the same thing to AI three times, it's time to write a skill.
Your Skill as a Story¶
Here's where Lift 1 pays off directly. The story format you learned for delegation contracts is the same format you use to define skills:
Intent for your skill:
As a [your role], I want [this process automated], so that [consistency / speed / never forget steps].
Acceptance criteria for your skill:
Given [this input or starting condition], when [the skill runs], then [this specific output is produced].
You're both the domain expert (you know your conventions) AND the developer (you're building something reusable). The story format forces the same clarity here that it forced when you wrote delegation contracts in Lift 1.
Team Discussion: What Would You Capture?¶
Format: Team Discussion Time: ~2 minutes
Look back at what you've done so far today — the decomposition you just practiced, the features you built in Run 1, the processes you found yourself repeating. If you could teach AI to follow ONE process your way every time, what would it be? Go around the table — each person names one candidate.
Team Activity: Build Your First Skill¶
Format: Mob Session Time: ~4 minutes Setup: One person drives, everyone else navigates. Do this in the same workspace where you built your Run 1 project — the skill you create will live alongside your code and be available for every future conversation.
You just practiced decomposition in Section 1. Now capture it as a skill — so your team does it the same way every time. This is the "We Do, You Do" pattern in action: you just did the process, now teach AI to reproduce it.
Ask your AI coding assistant:
Based on how we just decomposed our backlog, write a skill that captures our decomposition process. When we give AI a big feature, it should: break it into independently shippable pieces, ensure each piece delivers value on its own, write each piece as a user story with 2-4 acceptance criteria, and order pieces so the smallest valuable thing comes first. Group by user persona where relevant.
If your team wants to capture a different process instead — adding a new page, creating a form, or something else from your discussion — go for it. The pattern is the same: describe the process you want AI to follow, and ask it to write a skill file that captures it.
This creates a SKILL.md file in .claude/skills/. Claude reads it automatically when working on related tasks.
Save this as a custom instruction file in your project. Reference it when working on related tasks.
Save this as a prompt template. Invoke it by name when working on related tasks.
Save your progress:
Save my progress and sync it.
Discuss: You just experienced the "We Do, You Do" pattern firsthand — you did a process, then captured it as reusable instructions. How does having this skill change what happens when you start Run 2?
Key Insight¶
Skills are how you turn one-time refinement into permanent consistency. Instead of re-explaining conventions every session, you encode them once and they travel with the project. The "We Do, You Do" pattern — do it together, capture it, test with fresh context — ensures the skill works independently. If you've explained the same thing to AI three times, it's time to write a skill.