You can put everything in one Skill. You'll regret it.
After Sprouts, most kids try to write a single huge Skill that knows about everything they care about. That works — for about a month. Then it becomes impossible to update, impossible to share, and impossible to remember what's in it.
Look at the difference:
my-everything.skill.yaml
name: "Everything I Know" facts: - "My dog Buddy is a golden retriever..." - "Buddy only barks at one neighbor..." - "My favorite Pokemon is Eevee..." - "Eevee evolves into eight forms..." - "Eevee's HP is 55..." - "The library on Oak Street has..." - "...the radiator clanks every 40s..." - "My grandma uses cold water for..." - "She adds orange peel to soups..." - "My brother Jonas plays soccer..." - "He hates the goalkeeper position..." - "..." - "...30 more facts..."
three small files
my-dog-buddy.skill.yaml 5 facts about Buddy eevee.skill.yaml 5 facts about Eevee grandma-cooking.skill.yaml 5 facts about grandma's cooking + a parent file that knows when to use which one ↓
The mega-Skill is one file with 30 facts about 6 unrelated things. The focused approach is 4 files (3 specialists + 1 organizer). When you want to fix a fact about Buddy, the mega-Skill makes you scroll past Eevee. The focused approach lets you open one tiny file and fix the thing.
Pick a domain to organize around.
A "domain" is a chunk of your life that's big enough to need several Skills, but small enough to fit under one umbrella. Pick one. Don't overthink it — you'll do this for other domains later.
"Family" can mean one parent's side. "School" can mean one teacher. "A video game" can mean one specific update of one specific game. Smaller is better at this stage.
One parent. Several children.
Composition is the grown-up word for "one Skill that knows about other Skills." The parent doesn't have facts itself — it's a router. It just knows which child to call when.
↑ each child knows about exactly one person ↑
Each box is one file. The parent file at the top is small — maybe 10 lines. Its only job is to know "if the user asks about Mom, use mom.skill.yaml; if they ask about Dad, use dad.skill.yaml..." and so on. The child files do the actual work.
This is the same pattern that real software uses. Big systems are made of small pieces. Each piece does one thing well. Something on top knows how to combine them. Engineers call this "composition." You just learned it.
This is what composition looks like in code.
Here's the parent file. Notice how short it is — it has zero facts. It only has rules for which child to call when.
# A parent Skill — knows about my family # Doesn't have facts itself; just routes to specialists name: "My Family" description: "Routes any family question to the right specialist Skill" uses: - mom.skill.yaml - dad.skill.yaml - grandma.skill.yaml routing_rules: - if: "the user asks about Mom or my mother" use: mom.skill.yaml - if: "the user asks about Dad or my father" use: dad.skill.yaml - if: "the user asks about Grandma or cooking" use: grandma.skill.yaml when_to_use: "Any time the user asks anything about my family"
And here's one of the child files. Same exact format as a Sprouts Skill — facts + personality + a rule. It has no idea it's part of a larger system. That's what makes it reusable.
# A child Skill — knows about Grandma's cooking # Same shape as any Sprouts Skill name: "Grandma's Cooking" description: "How my grandmother actually cooks" facts: - "Always uses cold water for dough — never warm" - "Three pinches of salt, not four" - "Adds a small piece of orange peel to almost everything" - "Refuses store-bought wrappers" - "Says cookbooks are 'for tourists'" personality: "Strong opinions about technique, dismissive of cookbooks" when_to_use: "Any time the user asks about cooking or Grandma"
Notice the trick: the child file is exactly like a Sprouts
Skill. You don't have to rewrite anything. The parent just
wraps the children. If you already have grandma.skill.yaml from Module 03,
you can plug it in unchanged.
Sketch your own composition.
For your domain (—), pick a parent Skill name and 3 children. Don't worry about facts yet — just the structure. As you fill in the form, the YAML builds itself underneath.
# Fill in the form above and watch this update. name: ... uses: - ...
You don't need to write the actual children right now. The point of this step is to plan the structure — you can fill in the children's facts later, one at a time.
The name is half the engineering.
Two Skills with the same content but different names will give you completely different results. Good names tell future-you (and Claude) when to use the file. Two judging rounds.
Round 1. Which file name is better for a child Skill about your dog?
Round 2. Which set of children is better organized?
Two laws: Specific enough that nothing else could share the name. And consistent enough across siblings that you could guess any one of them. If you follow both, you'll never have to remember a filename again.
You just learned composition.
This is the same pattern professional engineers use. Today you used it on a Skill about your family. Tomorrow you can use it on anything.
What you just learned
- One mega-Skill is hard to maintain. Many small Skills are easy.
- Composition means a parent Skill that calls children Skills.
- The parent has zero facts. It's just a router.
- A child Skill is exactly like a Sprouts Skill — same shape, same rules.
- Good names are specific + consistent across siblings.
- This is the first real engineering pattern in Kindling. There are more.
In Module 02 (still in Makers tier), you'll learn the next pattern: Skills that change behavior based on who's asking. Your homework Skill will sound different to Mom than to your friend Aiko. Same facts, different voice.
★ Before you call it done
Three questions. Same three. Every time.
These are the same three questions for every module in Kindling. They are how you check whether AI did the part it should and you did the part only you could. Tap each one to mark it true.
★ ★ ★