🧩 Domain skill vs. process skill
There are two skill families. The domain encodes knowledge about one thing: vercel-react-best-practices, supabase-postgres, stripe-best-practices. The one from process encodes HOW the agent thinks and works—regardless of the subject. It's the difference between "what to know about React" and "how to debug anything."
📚 Domain skill
- ›Answers "what I know about X"
- ›Triggers when topic X comes up
- ›Ages with the domain (framework version)
- ›E.g.:
frontend-design,neon-postgres
🧠 Process skill
- ›Answers "HOW to work/think"
- ›Triggers based on task type, not by topic
- ›Timeless — applies to any language/project
- ›E.g.:
test-driven-development,systematic-debugging
💡 Why process scales better
A domain skill helps people who work in that domain. A process skill helps anyone who codes. That’s why test-driven-development reaches 107k installs (obra/superpowers): TDD applies just as well in Python, Go, Rust, or TypeScript. Process has a larger total market—and it's what's missing from the agent by default.
🧪 test-driven-development (107k)
The most installed process skill in the Testing niche: test-driven-development, 107k installs, from the repo obra/superpowers. It doesn't teach a testing library — it enforces a work order: write the failing test BEFORE writing the implementation. This radically changes the agent’s behavior.
What changes in the agent’s behavior
- →Without the skill, the agent writes the implementation and maybe tests afterward, overly optimistic.
- →With the skill: it first writes a test that real failure, confirm the red, only then implement the minimum needed to pass.
- →Result: every feature is born with real coverage, and "passing the tests" stops being theater.
When to use
Whenever you’re implementing a feature or fixing a bug with clear acceptance criteria. Don’t use it for throwaway prototypes or exploration ("I’ll just see if the API responds"). The benefit shows up when the output needs to be verifiable.
🦸 The superpowers family
The repo obra/superpowers popularized the idea of packaging engineering processes as triggerable skills. It’s a constellation of process skills that invoke one another. The four pillars:
brainstorming
Changes: before creating anything, the agent explores intent, requirements, and design instead of jumping into code. When: new features, components, behavior changes—before touching a file.
systematic-debugging
Changes: Instead of guessing at fixes, the agent reproduces the issue, isolates it, forms a hypothesis, and tests one thing at a time. When: any bug, test failure, or unexpected behavior, BEFORE proposing the fix.
writing-plans
Changes: turns a spec into a plan of verifiable steps before implementation. When: a multi-step task with defined requirements — becomes the playbook another session follows.
verification-before-completion
Changes: prohibits declaring "ready/working" without running the verification command and checking the output. When: before stating a conclusion, committing, or opening a PR—evidence before assertion.
💡 Skills that call skills
The magic of superpowers is in the composition: writing-plans points to brainstorming, which points to verification-before-completion. Each one is atomic (one responsibility), but together they form a disciplined workflow. It's the opposite of the 800-line "everything-about-X" skill.
⚖️ Process skill: rigid vs. flexible
Not every process skill is written the same way. There’s a spectrum between the rigid (an exact, step-by-step procedure that allows no deviation) and the flexible (principles and heuristics the agent adapts to the context). Choosing the wrong point on the spectrum is a subtle anti-pattern.
🔒 Strict (Procedure)
A fixed sequence that must be followed exactly. E.g., the TDD red-green-refactor cycle or a deploy checklist.
- ✓Good when skipping a step is costly or dangerous
- ✓Reproducible and auditable result
- ✗Bad if the context varies a lot
🌊 Flexible (heuristic)
Principles the agent weighs. E.g., the brainstorming ("explore intent first"), design guidelines.
- ✓Good when every case is different
- ✓Generalizes beyond the examples
- ✗Bad if you need guaranteed execution
the signal in the skill text:
# RIGID — sequential imperative verbs; order matters 1. Write the test. 2. Confirm it fails. 3. Implement the minimum. # FLEXIBLE — principle + why; the agent decides how "Before creating anything, explore the real intent: does the user want X or want to solve Y? Ask what’s missing before assuming."
💡 The practical rule
If a mistake in the step causes damage (broken deploy, lost data), go with rigid. If the value is in the judgment (design, prioritization, exploratory debugging), go with flexible and explain why — remembering that uppercase MUSTs in a flexible skill cause overfitting.
❤️ Why these are loved
Process skills appear disproportionately often among the top installs because they solve a pain point everyone who uses an agent has, every day, on every project. Three concrete reasons:
Correct the lazy default behavior
Without guidance, the agent tends to skip tests, guess at fixes, and declare "done" too soon. These skills enforce rigor where it’s missing by default.
Huge total market
They work with any language and any project. A Postgres skill matters only to people who use Postgres; “how to debug” matters to everyone.
A compounding, reliable effect
Applied across all your work, the gains add up: less rework, fewer “I thought it worked” moments. You’ll feel the difference in the first week.
The contrast with Testing&QA as a group
Curious: the Testing&QA group has 1,339 skills but only 0.60M installs combined — a low average. Even so test-driven-development alone gets 107k. The lesson: within a lukewarm group, a skill process a well-made one rises above the average because it targets behavior, not just the tool.
🧠 Steal these patterns for your skill
You don’t need to publish the next superpowers — just apply its patterns to your process skill. The checklist for what makes a process skill loved:
✗ Weak process skill
- ✗Mixes process with domain knowledge
- ✗Trigger tied to a specific technology
- ✗List of MUSTs without explaining why
- ✗Tries to cover 5 processes in a single skill
✓ Beloved process skill
- ✓One process, one responsibility (atomic)
- ✓Triggers based on task type, stack-agnostic
- ✓Explain why; be strict only where needed
- ✓Composes with other process skills
💡 Bridge to the next module
Now you know what type of whether a skill is worth creating. In 5.4, we'll go from concept to concrete steps: the decision checklist before creating one, how to structure the repo, and the exact commands to publish it and make it appear on skills.sh.
✅ Module Summary
Next:
Module 5.4 — 🛠️ How to Create: From Decision to Publish. The decision checklist, repository structure, and exact commands to go live.