A method — and a Claude Skill — for getting oriented in an unfamiliar field before you understand any of it.
The hardest moment in a new field isn't difficulty. It's not knowing what you don't know.
You read chapter 9, then chapter 16, and have no idea the two are describing the same concept at different levels. Similar terms blur together. Nothing has a home. You can't tell whether you're missing something because you can't see the shape of the whole.
Build a flat, exhaustive inventory of every enumerable group in one bounded source — "the seven principles of X", "the four classifications of Y", "the three layers of Z" — organized by nothing but chapter, with all sub-numbering flattened away.
This is not a table of contents. A TOC tells you a section exists. A point tree tells you what is inside every section, at the grain the field itself uses.
Five steps:
- Lock a bounded source. One canonical text with edges. Boundedness is what makes "exhaustive" meaningful.
- Extract from the full body, never the TOC — and identify what form this source uses to carry enumeration first (lists? tables? numbered articles?). Guessing wrong fails silently.
- Write the tree. Flat. Counts in the group names. The source's own wording, unimproved.
- Measure the gap, out loud. Classify a real assessment set against the tree and report the coverage number.
- Fill in details, gap-driven. The misses from step 4 are the work queue.
"Point tree" is a misnomer, and the flattening is the honest response to it.
Real knowledge structures are graphs with cycles, not trees. A tree forces every concept under exactly one parent, and fields routinely violate that — the same term appears at three levels in three chapters meaning something different each time. That collision is usually the learner's single biggest source of confusion. Imposing nesting invents a hierarchy the field doesn't have, and the invented hierarchy is precisely what makes similar terms blur.
So the output is always two files: the flat tree, plus a disambiguation map carrying the lateral edges the tree can't hold. The second one is where "I keep mixing these up" actually gets solved.
Learning a field is not a sapling growing into a tree — trunk first, then branches, then leaves. Everything comes up faintly at once, like a progressively-loaded image that appears whole at low resolution and then sharpens all over. The point tree is that low-resolution first pass.
Two supporting lines of evidence: Ausubel's advance organizer work (a coarse framework given beforehand improves retention of subsequent detail), and Bransford & Johnson (1972), where a passage is nearly unrecallable without its title and recall jumps when the title comes first — same sentences, same reader, different blurry whole to attach them to.
One correction to the intuition: stray details don't wait patiently for the trunk to arrive. Information with nothing to attach to is simply lost. So the tree's function isn't retroactive collection — it's hanging hooks in advance, densely enough that anything arriving later lands on at least one. (This is why counts belong in group names: a count is a hook, and an empty slot in a known-size set is a hook with a shape.)
And the benefit is front-loaded. Bjork's work on desirable difficulties runs the other way: past the early phase, frictionless scaffolding becomes a crutch and produces fluency illusions. Step 4's coverage number is also the retirement signal.
This method has a ceiling, and pretending otherwise is the main way it hurts people.
On a systems-architecture certification textbook (292 pages), a carefully built point tree was classified against a full 75-question mock exam:
| Class | Share | What it is |
|---|---|---|
| A — answerable directly from the tree | 48% | Enumerable groups |
| B — needs body prose | 32% | Definitions, comparisons, "which statement is false" |
| C — calculation / reasoning | 13% | |
| D — outside scope | 7% |
48% is genuinely useful and nowhere near sufficient. Saying that number plainly is more valuable to a learner than the tree itself.
- Skill domains where knowing ≠ doing — programming, writing, design, clinical practice
- Derivation-based fields where the value is in the chain, not the list
- Fields with no bounded canonical source, where "exhaustive" is a lie
- Judgment-heavy fields where the content is in the trade-offs between items
For these, a concept map or a worked-example progression is the honest alternative. The skill is written to say so rather than produce a tree that misleads.
As a Claude Skill — download the packaged .skill from Releases, or build it yourself:
zip -r knowledge-point-tree.skill knowledge-point-tree/Then upload it in Claude's skill settings. It triggers on phrases like "I'm just starting to learn X and don't know where to begin", "help me build a framework for this subject", or when you hand over a textbook and ask what's in it.
As a plain method — read knowledge-point-tree/SKILL.md. It's written for a model but reads fine as a human procedure.
scripts/extract_points.py cuts a long source down to something you can read end to end.
python extract_points.py textbook.pdf -o points.txt --verify 50
python extract_points.py spec.md -o points.txt # auto-detects tables
python extract_points.py doc.md -o points.txt --form tables
python extract_points.py book.pdf --stage body -o body.txtHandles PDF (via pdftotext), Markdown, and plain text. Detects whether the source carries enumeration as lists, tables, or both, and reports the yield — a yield under ~3% means the form guess was wrong, not that the source is thin.
Its output is a draft to read and correct, not a finished tree.
The script started out working on exactly one Chinese textbook and quietly failing everywhere else. Each of these was found by testing against a genuinely different source:
| Failure | Symptom | Cause |
|---|---|---|
| Markdown TOC | 47 extracted "points", all section names | Anchor-link lists look identical to point lists |
| PDF TOC | 82 contents lines mixed into the tree | Dot leaders (1.1 Overview ..... 12) parse as numbered points |
| Spec tables invisible | 8% yield on OpenAPI 3.1 | Enumeration lived in pipe tables, not list markers |
| Tables split mid-way | Same table emitted twice, header lost | An escaped pipe | inside one cell |
| Every table decapitated | Header row shown as first data row | Repeated Field Name | Type | Description was eaten by the running-header filter |
| Legal articles missing | 0 of 87 clauses captured | CJK sources number clauses （一）（二）, not (1)(2) |
| PDF tables invisible | "0 table rows" on a book with 46 tables | pdftotext renders tables as space-aligned columns |
| Minority form discarded | Comparison tables dropped from a textbook | Auto-detect was winner-take-all — but the minority form held the densest groups |
Current coverage after fixes:
| Source | Before | After |
|---|---|---|
| Chinese textbook (PDF, 292pp) | 37% of body, legal chapter empty | 43%, 86 clauses + 377 table rows recovered |
| OpenAPI 3.1 (Markdown spec) | 8%, all of it TOC | 39%, 0 TOC residue |
| Plain prose | silent zero | warns explicitly |
Verification sampling passes 40/40 to 60/60 on every source.
Tables extracted from PDFs need manual repair. pdftotext renders them as space-aligned columns; wrapped cells split across rows and merged headers collapse. The heuristic finds the blocks but can't reliably reconstruct them. Treat PDF table output as a pointer — "there's a table here, go look at it" — and rebuild the important ones by reading the page. Markdown and HTML tables extract cleanly.
The method — the flat point tree, chapter-level hierarchy only, panorama before detail, and the underlying model of everything coming up faintly at once rather than growing branch by branch — is [https://github.com/SYQ1001]'s.
It was formalized into a skill, instrumented with the verification and coverage-measurement steps, and stress-tested against multiple source forms in collaboration with Claude.
MIT — see LICENSE.