A user extracts value once and moves on. A practitioner builds capability over time.
We’ve been naming AI skills like tools. That’s the wrong frame — and it’s quietly limiting how much value teams get from them.
When someone names a skill thesis-generator or review-helper, they’re making a framing decision that affects every person who ever uses it. They’re saying: this is a vending machine. Insert task, receive output, move on. Nobody expects to grow from using a vending machine.
But watch what actually happens when a skilled practitioner runs a well-designed AI workflow repeatedly. They watch the agent work through a customer thesis — asking about the customer’s business model first, then the technical constraint, then the competitive risk, then the opportunity window. They see the logic. They internalize the sequence. Over weeks, they start asking those questions themselves in meetings, before they even open the tool. The skill didn’t just automate a workflow. It taught them the workflow.
The skill is the teacher. And if that’s true, the name is the first lesson.
What Learning Science Already Knows
There’s a concept in learning theory called artifact-mediated learning: humans acquire mental models by interacting with artifacts, not by reading instructions. The artifact — its design, its behavior, its name — teaches the mental model implicitly, through use.
This has a direct implication for AI skills. The skill’s name and description are often the only “interface” a user ever reads before running it. The name shapes their expectation. It tells them what to bring to the interaction and what to take away. Name it thesis-generator and they bring a task and take away a document. Name it thesis-thinking and they bring a question and take away a way of thinking.
Same tool. Different frame. Different trajectory of internalization.
The Five Naming Frames
Not all names are created equal. There are five distinct ways to name a skill, and each one produces a different user behavior.
Tool (thesis-generator) — “This is something I use.” The framing is transactional. The user runs it when they need an output, gets what they came for, and moves on. Nothing accumulates over time. The skill remains external.
Behavior (think-in-theses) — “This is something I do.” The framing is active. The verb signals a repeatable action, not a one-time task. Users begin to associate the skill with a way of working rather than a particular output.
Practice (thesis-thinking) — “This is something I’m learning.” The gerund form is doing real work here. It signals ongoing development, not a completed action. This is the most underused frame in skills design, and arguably the most powerful for team knowledge transfer.
Ritual (thesis-before-calls) — “This is something we do, together, at a specific moment.” Ritual framing attaches the skill to a trigger — a meeting, a proposal, a weekly review. It creates shared cadence. Teams that adopt a ritual aren’t using a tool; they’re building a practice into their operating rhythm.
Role (thesis-thinker) — “This is who I am.” Role framing is the most ambitious. It embeds the skill into professional identity. When someone thinks of themselves as a person who thinks in theses, they apply the frame even in conversations where no AI is present.
Most skills libraries today are full of tools. The opportunity is to build practices, rituals, and eventually roles.
Why Gerunds Work
BJ Fogg’s research on habit formation shows that behaviors become automatic when they’re paired with consistent triggers and framed as ongoing practices rather than discrete tasks. The linguistic marker for an ongoing practice in English is the gerund — the -ing form.
Thesis-thinking feels like something you do repeatedly and get better at. Thesis-generator feels like a button you push.
This isn’t a minor stylistic choice. It changes what users expect to get from repeated use. A tool delivers a consistent output. A practice delivers compound returns — you get better, you internalize more, the cognitive scaffold gradually becomes part of how you think.
When naming skills that you want teams to internalize, default to gerunds: thinking, reviewing, analyzing, reasoning. The form signals the intent.
The Design System Analogy
The best design systems use a three-tier naming hierarchy worth borrowing for skills.
Primitive tier — the foundational concept, named for what it is: thesis-thinking, working-backwards, commitment-verification. These are the core mental models. The name alone signals the practice.
Semantic tier — the concept applied in context: thesis-before-calls, rigor-in-proposals, architecture-in-security-reviews. These add a trigger or domain to the core practice, making the skill habit-ready by attaching it to an existing workflow moment.
Component tier — the concept applied to a specific artifact: review-proposal-with-rigor, audit-page-for-freshness. These are the most task-specific. They belong in a skills library but shouldn’t crowd out the practices above them.
Most teams build only component-tier skills. They’re useful, but they don’t scale into culture. The primitive and semantic tiers are where behavior change lives.
Working Backwards as the Gold Standard
Amazon’s Working Backwards process is the best example of a practice-named mental model that actually changed organizational behavior at scale. The name isn’t customer-requirements-generator or prfaq-template. It’s Working Backwards — a description of the cognitive operation, not the output.
Because the name describes the thinking pattern (start from the customer outcome, work backward to the solution), it can be applied anywhere. You can work backwards from a product decision, a hiring decision, a pricing decision. The practice generalizes because the name names the practice, not the artifact.
This is exactly the model for a mature skills library. Skills named after mental models and practices generalize. Skills named after outputs don’t.
The Homebrew Tap Analogy
A skills library is a tap — a curated collection of installable practices. The Homebrew tap model is instructive here not architecturally but culturally: taps are collections of maintained, versioned, trustworthy tools. When you install from a tap, you’re implicitly trusting the maintainer’s curation decisions.
The difference between a skills tap and a prompt dump is naming and intent. A prompt dump is a vending machine: functional, transactional, unmemorable. A skills tap is a practice library: curated, versioned, designed to transfer knowledge over time.
The install-and-forget pattern happens when skills are named as tools. The return-and-internalize pattern happens when skills are named as practices.
An Audit You Can Do Today
If you have a shared skills or prompt library — for Claude Code, Cursor, Kiro, Copilot, or any other AI tool — take five minutes and audit the names.
For each skill, ask one question: does this name make someone a practitioner, or a user?
A user extracts value once and moves on. A practitioner builds capability over time, internalizes the mental model, and eventually applies the frame even without the tool.
Your skills library is either building practitioners or building dependency. The name is where that choice gets made.