Skip to main content
Skill Trees V2 has not been officially launched yet. We are preparing the final rollout and expect to release it in the coming weeks.
LabEx Skill Trees V2 is a major iteration of how we model technical learning. The goal is not simply to add more topics or make longer learning paths. The goal is to make skills more precise, more measurable, and more useful across hands-on labs, challenge-based assessment, progress tracking, and learning recommendations. In V2, a Skill Tree is treated as a domain skill map: a structured representation of what a learner can understand, practice, and prove in a technical area. Skill Trees V2 skill map model

From Course Lists to Skill Maps

Traditional learning platforms often organize content around courses, chapters, or tutorials. That structure is useful for delivery, but it is not always a good model for measuring capability. A course answers:
  • What should I study next?
  • Which lessons are grouped together?
  • What is the recommended learning sequence?
A Skill Tree answers a different question:
  • What abilities exist in this technical domain?
  • Which abilities has the learner already demonstrated?
  • Which abilities still need practice or assessment?
  • Which labs and challenges provide evidence for each skill?
This distinction matters. LabEx learning is hands-on. A learner does not just read about Docker networking or Linux permissions; they work inside a real environment, complete tasks, and pass verification. Skill Trees V2 gives that activity a more accurate capability model.

What Changed in V2

V2 keeps the same high-level product idea, but redesigns the underlying skill model. Across the current canonical set, V2 includes:
  • 25 Skill Trees
  • 1,129 concept-level skills
  • Up from 783 skills in V1
  • A broader and more balanced coverage across programming, infrastructure, frontend, data systems, security, and automation
The increase is not uniform, and that is intentional. Some Skill Trees expanded significantly because V1 under-modeled their real capability space. For example, Cybersecurity moved from a minimal placeholder to a structured security knowledge model. React, Git, Jenkins, Kubernetes, JavaScript, Redis, Wireshark, and CSS also gained much more complete coverage. Other Skill Trees were reduced or tightened. Linux, for example, went from 118 skills in V1 to 86 in V2. That reduction reflects a design correction: Linux should model Linux system usage and administration, not absorb every adjacent shell, Git, container, or scripting capability that happens to run in a Linux terminal. V2 is therefore not just a larger dataset. It is a cleaner model.

Clearer Domain Boundaries

One of the most important changes in V2 is boundary design. Many technical domains overlap in practice. Docker runs on Linux. Kubernetes uses container images. Jenkins pipelines invoke shell commands. Database labs run in Linux environments. Frontend work often combines HTML, CSS, JavaScript, and React. If every Skill Tree absorbs every related tool, the model becomes noisy. A lab may appear to teach too many unrelated skills, progress becomes harder to interpret, and recommendations become less precise. V2 handles this by separating adjacent domains more deliberately:
  • Linux focuses on using and managing Linux systems.
  • Shell focuses on shell semantics as a command language and scripting language.
  • Docker focuses on local containers, images, Dockerfiles, volumes, networks, registries, and Compose.
  • Kubernetes focuses on orchestration objects, workloads, services, configuration, scheduling, rollout, observability, and access control.
  • Jenkins focuses on CI/CD platform concepts, jobs, pipelines, agents, credentials, artifacts, and automation workflows.
  • HTML, CSS, JavaScript, and React are modeled as related but distinct frontend capability spaces.
  • Cybersecurity, Nmap, Hydra, and Wireshark separate security concepts from tool-specific operational skills.
When a lab crosses boundaries, LabEx can bind it to multiple skills across multiple Skill Trees. The skill model does not need to duplicate concepts just because real work is interdisciplinary. Skill Trees V2 domain boundaries

More Consistent Skill Granularity

V2 also improves skill granularity. A good skill should be specific enough to teach and assess, but not so narrow that it only represents one command flag, one API parameter, or one lab step. For example:
  • File Permissions is a useful skill.
  • Run chmod +x is too narrow.
  • Linux Administration is too broad.
V2 aims for skills that are close to exam-style capability points: stable, explainable, teachable, and assessable. This makes each skill more useful as a progress signal. The result is a better relationship between content and evidence:
  • A guided lab can teach one or more skills.
  • A challenge lab can assess one or more skills.
  • A skill can be supported by multiple labs and challenges.
  • Learner progress can be inferred from repeated evidence, not just content completion.

Designed for Hands-On Assessment

LabEx has two complementary learning modes:
  • Guided Labs help learners understand and practice concepts step by step.
  • Challenge Labs verify whether learners can apply those concepts independently.
Skill Trees V2 is designed around that distinction. The model does not treat a skill as “learned” simply because it appears in a course. Instead, skills are connected to hands-on evidence. Completing labs, passing checks, solving challenges, and practicing related tasks all become part of a more meaningful progress model. This is especially important for infrastructure, security, and programming topics, where real ability depends on applying concepts in working environments. Skill Trees V2 evidence loop

Better Support for Recommendations and Progress

A cleaner skill model improves more than the Skill Tree page itself. It gives LabEx a better foundation for:
  • Skill-based lab recommendations
  • Challenge selection
  • Progress visualization
  • Skill Tree badges
  • Certificates
  • Team learning analytics
  • Future adaptive learning features
Because V2 skills are more stable and better scoped, LabEx can recommend practice based on actual capability gaps instead of only course position or content popularity.

Migration and User Progress

Skill Trees V2 also changes how some historical progress is represented. When V2 rolls out, LabEx will migrate existing user learning records to the new skill model. We will not simply copy old skill counts into the new trees. Instead, historical lab completions, challenge completions, and related learning evidence will be reinterpreted against the V2 skill definitions. This matters because V2 is not a one-to-one rename of V1. Some V1 skills were merged into broader, more stable skills. Some were split into clearer concept-level skills. Some were moved to a more appropriate Skill Tree because V2 has stricter domain boundaries. Some overly narrow or duplicated skills were removed from the canonical model. As a result, a learner may see a change in the number of acquired skills after migration. In many cases, the number may decrease. That does not mean the learner has lost completed labs, challenge history, or learning work. It means the same historical evidence is being measured against a cleaner and more rigorous skill model. For example:
  • Several small V1 skills may map to one stronger V2 skill.
  • A skill previously counted under Linux may now belong under Shell, Git, Docker, or another more precise Skill Tree.
  • A completed lab may continue to contribute progress, but to a different set of V2 skills.
  • Some progress may require additional challenge evidence if V2 defines the skill at a deeper or more assessable level.
We are designing the migration to preserve learning evidence while improving how that evidence is interpreted. The main visible change is that skill counts may become more conservative. The benefit is that unlocked skills should better represent durable, demonstrable capability.

A Canonical Model for Technical Domains

V2 also introduces a stronger canonical structure behind the data. Each Skill Tree has a stable key and ordered skill list. Each skill has a stable slug, a user-facing name, and a description that explains the capability itself. The ordering is canonical, but it is not meant to force every learner into a single linear path. This is important because technical growth is rarely linear. A learner may be strong in Git branching but weak in rebasing. They may know Python functions but need more practice with packaging or testing. They may understand Kubernetes Pods but not RBAC. Skill Trees V2 makes those partial strengths and gaps easier to represent.

An Open Skill Assessment Model

Skill Trees V2 is also designed to become an open technical skill assessment model led by LabEx. The canonical Skill Tree data is maintained in the labex-labs/labex-skilltrees repository. This repository defines the skill taxonomy behind LabEx: the technical domains, stable skill identifiers, user-facing skill names, descriptions, and the canonical ordering of skills within each tree. By opening this model, we want Skill Trees to be useful beyond LabEx itself. Individuals can use it as a structured map for self-assessment. Educators can use it as a reference framework when designing practical courses, labs, and challenges. Teams can use it to discuss technical competency in a more concrete way. Contributors can propose improvements when a skill is missing, too broad, too narrow, duplicated across domains, or no longer aligned with modern practice. Our goal is to promote a LabEx-led skill assessment standard for hands-on technical learning: open enough to be inspected and improved by the community, but rigorous enough to remain useful for measurement, recommendations, badges, certificates, and team analytics.

What This Means for Learners

For learners, V2 should make Skill Trees feel more practical:
  • Skills are easier to understand.
  • Progress is tied more directly to real practice.
  • Related topics are separated more clearly.
  • Learning paths can become more flexible.
  • Challenges can better test whether a skill has actually been acquired.
You can still follow courses from start to finish. But Skill Trees V2 gives you another layer: a map of what you are building toward.

What This Means for Teams and Educators

For teams and educators, V2 provides a more useful competency framework. Instead of only asking whether a learner completed a course, teams can inspect which skill areas are covered, which areas are improving, and which areas may need more practice. This is especially useful for Linux, DevOps, cloud-native infrastructure, security, programming languages, and database training. The more precise the skill model, the more useful progress analytics become.

Explore Skill Trees V2

Skill Trees V2 is now the default model behind LabEx Skill Trees. You can explore the learner-facing Skill Trees at labex.io/learn, or read the support overview here: LabEx Skill Trees This iteration is a foundation for more accurate hands-on learning: clearer domains, better skill granularity, stronger lab bindings, and more meaningful progress.