# Trees

# Trees as areas of knowledge

A **tree** is a scope of view over a connected group of skills — an *area of knowledge* that forms a logical part of a larger whole.

Take a front-end developer. Their full role covers a lot of ground, but the ground has natural regions: **Testing**, **Frameworks**, **JavaScript/TypeScript**, **Styling/CSS**. Each of those regions becomes a tree. Inside each tree sit the skills of that area, connected by their prerequisites — and because most skills in an area depend on other skills in the same area, the whole thing naturally reads as a tree shape in a diagram: broad foundations at the bottom, specialised skills branching above.

Three things to know about trees:

- **The slicing is yours.** How a role divides into areas is up to the team. There's no canonical set of trees for "front-end developer" — there's the set that matches how *your* team thinks about its work. If the names feel obvious to the team, the slicing is right.
- **Every tree gets a clear name.** The name describes the area it covers — a person glancing at the forest should know what lives in each tree without opening it.
- **A skill is defined only once, anywhere.** Trees show skills; they don't own them. The same skill is never defined in two trees. (It may still *appear* under another tree as a root — that's the subject of the roots page.)

A tree is deliberately human-sized: big enough to represent a real area of expertise, small enough to take in at a glance and reason about in a conversation.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-03-06.png)

# How trees connect inside

Inside a tree, the prerequisite chains from the skills page become visible paths. Arrows run from each prerequisite up to the skill it unlocks, so the tree isn't just a grouping — it's a route map. Reading one is mostly instinct once you know two conventions:

**The path is the prerequisite chain.** You start at the bottom of the tree and work up. You can't take a skill before the skills beneath it, the same way you can't take the third rung of a ladder first. If a skill high in the tree looks impossibly hard, the explanation is almost always a missing skill somewhere below it.

**Chains stay clean — no double-linking.** The rule from the skills chapter does its real work here. If B depends on A and C depends on B, then C connects only through B; there is never an extra arrow from A straight to C. Every dependency is expressed exactly once, at the closest link. This is what keeps even a large tree readable instead of becoming a plate of spaghetti.

Because prerequisites live on the skills themselves (defined once, organisation-wide), a tree never invents connections. It reveals the ones that already exist among the skills it chose to show. Pull "React I" and "React II" into any tree, and they arrive connected — the tree didn't link them, the skills were always linked.

A well-formed tree ends up with a recognisable anatomy: a few foundational skills near the bottom that much of the area rests on, branches where specialisations diverge, and the most advanced skills at the tips. The skills at the very top aren't special — there's no notion of "exit skills," they're just the current ends of the branches. Trees keep growing.

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-03-02.png)

# Roots are derived, not added

Every tree has **roots** — the skills you must already hold *before* you can enter the tree. And here's the elegant part: you never place roots by hand. The tree grows its own.

The derivation is mechanical. Look at the lowest skills in the tree — the ones whose prerequisites are *not* themselves in the tree. Those external prerequisites are the tree's roots, surfaced one level deep beneath it. In one line:

**Roots = prerequisites of the tree's skills that aren't in the tree.**

Say a "Frameworks" tree starts at "React I," and React I requires "JavaScript fundamentals" — a skill that lives in the JavaScript tree, not this one. Then JavaScript fundamentals appears *as a root* under the Frameworks tree. It isn't defined there (skills are defined only once); it's shown there, below the ground line, telling every reader: *hold this before you climb here.*

Why derive instead of declare?

- **Roots can't go stale.** Change a prerequisite on a skill, and every tree's roots update themselves. Hand-placed entry requirements drift; derived ones can't.
- **Roots can't be wishful.** Nobody can decorate a tree with aspirational entry bars that no skill inside actually demands. If it's a root, some skill in the tree genuinely requires it.
- **It keeps the mental model whole.** There is exactly one kind of connection in the method — the prerequisite. Roots aren't a second system; they're the same connections viewed from the other side of the tree's boundary.

Roots are the tree's honest answer to "am I ready to start this?" — and later, at the forest level, the same idea becomes the honest answer to "am I ready for this role?"

![](https://docs.skillforests.com/uploads/images/gallery/2026-07/method-03-03.png)