I'll be honest — I've never put real effort into writing tests. Embarrassing, but true. I was always so focused on implementation that testing got shoved to the back of the line. Then I heard someone say "write the tests first," and I figured I'd give it a shot. Claude Code happened to have this thing called Skills, so I picked a TDD Skill and tried it out.
To cut to the chase: I started pulling apart the Skill file and extracting the key points, then stopped halfway. The original was so well-written that summarizing it felt like a downgrade. So this post is exactly what the title says — half-dissected.
What Even Is a Skill?
If you've used Claude Code, you know there are times when you keep feeding the same instructions into every prompt. "Write tests first." "Format commit messages like this." "Refactor in this order." A Skill lets you save all of that in a markdown file ahead of time. Invoke it, and Claude follows those instructions automatically.
Set it up once, reuse it forever. Pretty convenient.
What I Picked
The obra/superpowers repo — 112k GitHub stars. I chose the test-driven-development Skill from there. Why? Because it has a lot of stars, obviously.
🔗 obra/superpowers - test-driven-development
TDD in 30 Seconds
For those unfamiliar with TDD, here's the short version. You write the test before the code.
Traditional approach: Write code → Error → Fix → Another error → Infinite loop
TDD: Define the passing criteria first → It naturally fails → Write just enough code to pass → Clean up
"Logging in with username admin and password 1234 should succeed"
You write that test first. It fails, obviously (🔴 Red). Then you write just enough code to make it pass (🟢 Green). Then you clean things up (🔵 Refactor). Because you set the direction before writing any code, the implementation doesn't wander off into the weeds.
What I Found Inside the Skill File
I opened the MD file. Here's the table of contents:
- Overview
- When to Use
- The Iron Law
- Red-Green-Refactor
- Good Tests
- Why Order Matters
- Common Rationalizations
- Red Flags - Stop and Start Over
- Example: Bug Fix
- Verification Checklist
- When Stuck
- Debugging Integration
- Testing Anti-Patterns
- Final Rule
Fourteen sections. Imagine typing all of that into a prompt by hand every time. That alone makes you appreciate why the Skill feature exists.
Breaking Down the Structure
At a high level, the file splits into three chunks.
First — Laying down the fundamentals. When to Use, The Iron Law, Red-Green-Refactor, Why Order Matters. This is the skeleton of TDD — when to use it, how it works, what to do, and why the order matters.
Second — Blocking the traps Claude tends to fall into. Good Tests, Common Rationalizations, When Stuck. Why is this necessary? Because Claude has a tendency to rationalize its way out of TDD — "this is too simple, I probably don't need a test for it..." — or to skip steps entirely. These sections are preemptive guardrails.
Third — Reinforcing everything with examples and checklists. Example: Bug Fix, Verification Checklist, Testing Anti-Patterns. These nail down the earlier principles with concrete cases and checklists you can actually reference.
Principles → Trap prevention → Concrete reinforcement. That flow really stuck with me.
Honestly, in my experience, Claude is one of the more stubborn large language models out there. If it decides something is unproductive, it won't comply no matter how hard you push. The flip side is that you need to convince it why your approach is logical — then it follows along properly. The Skill author clearly understood this. The file reads like a naturally persuasive argument even to a human, which made me think it would be a great reference when I eventually write my own Skills.
The Key Takeaways
- New features, bug fixes, refactoring — always TDD
- If the human says "skip it this once," then skip it (Claude does listen)
- Iron Law: See a failing test first, then write the code. This sequence rule exists to prevent the "all tests pass so it must be fine" trap
- Strict Red-Green-Refactor
- 🔴 Red: Write a failing test first
- 🟢 Green: Write the bare minimum code to pass
- 🔵 Refactor: Clean up (remove duplication, fix naming)
Why I Stopped Dissecting
I'll be straight with you — I was going to keep summarizing, but I stopped. The original is just too well-written. Anything I rephrase would only dilute it.
After actually using the Skill, I can say that the single rule of "tests first" genuinely changed my development flow. You define what you're building before you start building it. And watching Claude diligently follow Red → Green → Refactor when this Skill is active was honestly impressive.
Go read the rest yourself. The real substance starts right where I left off.