A skill catalog is the shared vocabulary a company uses to describe what its people can do. Get it right, and it becomes the backbone of role definitions, skill matrices, development plans, and internal mobility, the core building blocks of any skill management software. Get it wrong, too broad, too granular, or full of tasks and personality traits instead of skills, and nobody trusts it, so nobody uses it.
This guide walks through how to build a skill catalog step by step, and explains two concepts that decide whether your catalog stays useful as it grows: skill taxonomy and skill ontology.
What Is a Skill Catalog?
A skill catalog is the centralized, structured list of skills an organization tracks: every skill its employees have or need, defined once, named consistently, and organized so it can be reused across role profiles, skill matrices, development plans, and internal mobility. Instead of every team inventing its own labels for the same skill, the catalog gives the company one common language for what people can do.
A skill catalog is not the same as a skill matrix, which applies the catalog to a specific team or role to track proficiency levels. The catalog is the dictionary; the matrix is one sentence written with it.
What Is a Skill Taxonomy?
A skill taxonomy is the classification system that organizes the skills in your catalog into categories and levels, the way a biological taxonomy sorts species into genus and family. It answers the question: where does this skill belong?
In practice, a skill taxonomy is built from:
- Categories: groupings such as “Data & Analytics,” “Communication,” or “Project Management” that reflect your company’s structure or industry.
- Skill types: hard skills, soft skills, and languages are the common ones, though you can define custom types.
- Hierarchy: broader and narrower skills, for example “JavaScript frameworks” as a parent of “Vue.js” and “React.”
A good taxonomy is what makes a catalog with hundreds of skills still feel navigable: employees browsing for a skill find it in a category that makes sense, and admins can spot duplicate or missing skills at a glance.
What Is a Skill Ontology?
A skill ontology goes a step further than a taxonomy. Where a taxonomy organizes skills into a tree of categories, an ontology maps the relationships between skills, regardless of which category they sit in. It answers a different question: how does this skill relate to that one, rather than just where it belongs?
Typical relationship types in a skill ontology include:
- Specialization / generalization: “Vue.js” is a specialization of “JavaScript frameworks.”
- Contains / is part of: “Vue.js” contains “Vue Router” as a component.
- Prerequisite: one skill must be learned before another can be effectively used.
- Similarity / transfer: how much proficiency in one skill carries over to another, for example “Vue.js” has strong similarity with “React” and “Angular” because the underlying concepts overlap.
This is what allows a platform to reason about skills instead of just listing them: recommending what to learn next, matching someone to a project even when their exact skill isn’t listed but a closely related one is, or spotting that two “duplicate” skills in the catalog are actually the same thing written differently.
Taxonomy vs. Ontology, in One Line
A taxonomy sorts skills into a hierarchy of categories. An ontology connects skills to each other through typed relationships, whether they sit in the same category. A taxonomy is usually part of an ontology, but an ontology carries more information than a taxonomy alone.
How to Create a Skill Catalog
1. Decide What Counts as a Skill
Before adding a single entry, agree on what belongs in the catalog. A skill describes what a person can do, not a task, a certificate, a personality trait, or a working condition.
- “Video editing” is a skill.
- “Edit the weekly recap video” is a task, not a skill; it belongs in a role’s list of tasks, not the skill catalog.
A simple test: can you say “she is an expert in [X]”? If yes, X is probably a skill. If the sentence sounds strange, you’re likely looking at a task, a deliverable, or a trait instead.
It also helps to separate skill from the neighboring terms people mix up: ability, competency, and qualification each mean something slightly different, and using them interchangeably is where most catalogs start to drift. We cover the distinction in detail in What Is the Difference Between Abilities and Skills?
2. Start From Roles, Not a Blank List
Trying to brainstorm “every skill in the company” from scratch produces a bloated, disorganized list. Start instead from the roles that already exist in your organization, and derive their skills from the job descriptions behind them. This naturally scopes the catalog to what your company actually needs, and gives every skill an obvious home from day one. See How to Create a Role in the Skill Catalog for the practical steps.
Our advice for anyone starting today: pick the roughly 10 to 20 skills that are actually relevant to the work at hand rather than trying to cover everything up front, then let real gaps in visibility tell you where to expand next.
3. Get the Granularity Right
Too broad (“Marketing”) and the catalog says nothing useful. Too narrow (“Instagram Reels captioning in Canva”) and it becomes unmanageable and intimidating to fill in.
A reliable benchmark: match the granularity already used in CVs and job postings. Both formats have spent decades converging on a level of detail that is specific enough to be meaningful and compact enough to stay readable. So before adding a skill, ask: could this appear, in this exact form, in a CV or in one of our job postings? If yes, the granularity is right.
A second, complementary test: stop splitting a skill further once you can no longer point to a specific training for it. “Programming languages” is too broad to act on; “C++” is specific enough that you can find or commission a course for exactly that. Once you’re below the level where a dedicated training could plausibly exist, you’ve gone one level too deep.
4. Reuse the Vocabulary Your Organization Already Understands
A shared skill language doesn’t start with the catalog, it usually already exists informally, wherever project staffing decisions get made. If your teams already fill in skill matrices to staff projects, those terms are already part of the company’s working vocabulary, understood and used by everyone. Keep them.
If that shared vocabulary doesn’t exist yet, don’t invent one from scratch: pull skill names from existing CVs and from your internal or external job postings. Both are already written in language candidates and employees recognize.
5. Organize Skills Into a Taxonomy
Once you have a working list of skills, group them into categories that mirror your company’s structure or industry, and tag each one with a type (hard skill, soft skill, language, or a custom type of your choosing). This is what turns a flat list into a taxonomy people can actually browse.
6. Add an Ontology Layer
Once the taxonomy is in place, connect related skills to each other: mark specializations, prerequisites, and skills with strong transfer between them. This layer is what turns a static list into something that can support smarter matching and personalized “what to learn next” recommendations, and it’s usually where AI-assisted tools save the most manual effort, since relationships between hundreds of skills are tedious to map by hand.
This isn’t just useful for recommendations, it also changes behavior at the exact moment duplicates get created. When catalog search only matches exact text, people whose wording doesn’t line up exactly tend to add a near-identical skill under different phrasing instead of finding the one that already exists. Once search also surfaces related skills through the ontology, not just exact matches, people recognize “that’s basically it” and reuse the existing entry instead, which cuts down on duplicates substantially.
7. Set Governance: Who Can Add Skills, and Who Approves Them
A decision to be made at the beginning: Will employees be allowed to add a skill that doesn’t exist yet, and should new skills sit in a review queue before moving into the public catalog? Turning on review keeps the public catalog clean at the cost of a bit of friction. Leaving it off lets the catalog grow faster but needs more cleanup later.
We have set up the following process with several customers to ensure a consistent and clear skill catalog over time:
- Creation. A user creates a new skill. It’s private by default, visible only within their own team.
- Adoption signal. Other, independent teams start selecting and reusing that same skill on their own.
- Threshold reached. Once enough independent teams have picked it up, that cross-team reuse is treated as a signal that the skill is relevant beyond one team.
- Routing. The skill is automatically moved out of private status and routed to a review queue.
- Review. A subject-matter reviewer, not HR, evaluates it. HR can govern the process, but usually can’t judge whether a technical skill is correctly named, categorized, or actually relevant. That judgment needs someone who knows the domain.
- Decision. The reviewer approves it into the public catalog, merges it with an existing near-duplicate, or rejects it.
A lesson learned from several rollouts: define the catalog’s structure and actually enforce that reviewer role from day one. Skipping it early caused most of the recurring friction later.
8. Keep the Catalog Alive
A skill catalog is never “done.” New tools, roles, and ways of working keep adding vocabulary. Revisit it periodically to merge duplicates, retire skills nobody uses, and add synonyms so that two ways of writing the same skill don’t end up as two different entries.
What matters most is clear responsibility and dedicated time, not everyone’s occasional attention. Someone needs to own the catalog, with time set aside to actually review it, the same way DB Systel’s catalog stewards do. Search only stays trustworthy if a query reliably turns up one entry instead of several near-identical ones.
The administrative work behind that, however, can be mostly automated. Teammeter’s Skill Catalog uses AI to surface near-duplicates and inconsistent naming, categorize new skills, generate relationships between them, and translate skill names for multilingual teams. That leaves the catalog administrators to focus on judgment calls on whether the catalog actually represents the common language in the organization.
FAQ
The skill catalog is the actual list of skills your organization tracks. The skill taxonomy is the classification system, categories, types, and hierarchy, that organizes that list so it stays navigable as it grows.
A taxonomy organizes skills into a hierarchy of categories. An ontology adds typed relationships between skills, specializations, prerequisites, and transfer between related skills, regardless of category. Most mature skill catalogs use a taxonomy for organization and an ontology for reasoning about relationships.
No. Tasks describe what someone does (“edit a video”); skills describe what someone can do (“video editing”). Keeping tasks in a separate field, tied to a role, keeps the skill catalog reusable across roles instead of duplicating skill names as tasks everywhere they’re needed.
Granular enough to be meaningful, broad enough to stay manageable. A practical benchmark is the level of detail already used in CVs and job postings: if a skill could realistically appear in one of those, in that exact form, the granularity is about right. Another good test: stop splitting once you can no longer find a specific training for the result.
Yes, and you should. If a skill matrix is already filled in and actively used to staff projects, its vocabulary is already part of the company’s shared language. Carrying those terms into the catalog is easier, and more accurate, than inventing new ones.
Usually HR or People Ops owns the governance (categories, review process, standards), while managers, employees, and subject-matter reviewers contribute and vet the actual skill content, since HR can rarely judge whether a technical skill is correctly named or categorized. A catalog that only HR touches tends to drift away from how work actually gets described on the ground.
AI is genuinely useful for the repetitive parts: suggesting skills from a role name, sorting new skills into the right category, generating relationships between skills, and translating skill names for multilingual teams. It’s less reliable for the upfront decisions, what counts as a skill, and at what granularity, which still benefit from a short human review pass.