| name | shu-li-cheng-zhang |
| description | Build collapsible HTML review trees from concept-heavy slides, lecture decks, PDFs, DOCX notes, or course materials. Use when the source material is dense, abstract, parallel, or terminology-heavy and the goal is to clarify hierarchy, inclusion, contrast, repeated frameworks, or case-to-theory relationships for study and review. Especially useful for business, ethics, law, policy, humanities, social science, and other concept-first courses where linear summaries are less helpful than a structured concept map. |
树理成章 / Concept Arbor
Overview
Turn concept-heavy teaching materials into a collapsible HTML review tree that helps the reader move from macro structure to micro terms.
Prefer this skill when the source is visually dense or conceptually tangled and the reader needs structure more than prose.
Core Outcome
Produce a single HTML file with:
- clear nested hierarchy
- collapsible branches
- visually distinct levels
- bilingual labels when the source uses both languages
- concept-first phrasing instead of paragraph summaries
- short review-oriented explanations under nodes
- leaf nodes that are revision-ready without requiring a follow-up question
The output should feel like a study map, not like lecture notes pasted into HTML.
Workflow
1. Read for structure, not just text
Inspect the material visually whenever possible.
Prioritize:
- slide titles
- section breaks
- matrices
- pyramids
- concentric models
- compare/contrast layouts
- numbered frameworks
- bullet nesting
- arrows, stages, rings, and process diagrams
Do not flatten everything into a list just because OCR text is available.
2. Identify the course logic
Before drafting the tree, infer the organizing logic used by the material.
Common patterns:
topic -> framework -> sub-principlescase -> issue -> stakeholders -> consequencesdefinition -> dimensions -> applicationslevel -> stage -> indicatortheory A vs theory Bglobal principle -> local variation -> case example
If the deck repeats a concept later, decide whether it is:
- genuine new detail that should attach back to the earlier concept
- simple recap that should not become a second parallel branch
Prefer one concept node with deeper children over repeated sibling nodes.
3. Normalize concepts
Extract terms as review units.
Prefer:
- concept names
- principle names
- model names
- stage names
- actor groups
- case names
- strategic categories
- exam steps
Avoid turning full teaching sentences into labels unless the sentence itself is the named framework.
When the source uses both Chinese and English, keep both in the label if useful for study.
Read references/concept-rules.md before writing labels.
4. Build the hierarchy carefully
Use the smallest number of levels that preserves meaning.
Good hierarchy:
- top level = session or major lecture part
- second level = core framework or major theme
- deeper levels = principles, stages, dimensions, cases, or applications
Do not create fake structure.
If two items are parallel, keep them parallel.
If one item explains another, nest it.
If one slide only revisits an earlier concept, merge it back into that branch.
Watch for the common failure mode where a slide first lists subcomponents and later expands them.
In that case:
- keep the list-introducing node as the parent
- hang later expanded detail under those listed subcomponents
- do not leave a shallow preview version and a second parallel expanded version side by side
5. Write node explanations as review content
Every meaningful node should include short, content-focused review text.
Leaf nodes are not optional here.
If a node has no children, it should normally include a desc that helps the user revise directly from the HTML.
The explanation must teach the concept itself.
Never waste explanation on meta commentary like “this node belongs to the previous branch.”
When writing node explanations, read references/detailed-mode.md.
6. Generate stable HTML
Prefer a custom collapsible tree implementation over fragile default browser widgets if the layout needs precise control.
Use assets/collapsible-tree-template.html as the default scaffold unless the user already has a better in-project template to preserve.
Read references/output-spec.md before finalizing the HTML so the data model, button behavior, and detailed-mode expectations stay consistent.
Requirements:
Expand all and Collapse all must behave predictably- collapsing should truly hide lower levels
- no phantom reserved height for closed branches
- mobile and desktop should both remain readable
- indentation and color should reveal depth at a glance
If a similar HTML tree already exists, preserve working interaction patterns and patch the logic instead of rewriting unnecessarily.
Output Rules
Labels
Write labels so they are scannable in review mode.
Good:
Stakeholder Analysis 利益相关者分析Utilitarianism 功利主义Mixed Blessing 好坏参半型 -> Collaborate 协作
Bad:
- long paraphrase sentences
- unlabeled paragraphs copied from slides
- commentary disguised as labels
Node explanations
Each explanation should help answer at least one of these:
- what is it
- what problem does it solve
- how is it used in analysis
- how is it different from nearby concepts
- why does it matter in the course
For leaf nodes, prefer covering two or three of these at once:
- the working definition
- the nearest contrast or confusion point
- the role in case analysis, argument, or exam use
Explanations must be:
- short
- concept-focused
- exam-useful
- free of meta narration about tree nodes or UI structure
Cases
Treat cases as containers for application.
Under a case, prefer branches like:
- facts
- ethical issue
- stakeholders
- consequence categories
- theory/application links
Do not let cases swallow the theory tree unless the user explicitly wants a case-first review structure.
Repetition handling
If a concept appears in Session 1 and is revisited in Session 4:
- keep repetition if the user wants session-by-session fidelity
- merge it into one branch if the user wants a global synthesis tree
When uncertain, preserve session structure first.
Quality Checks
Before finishing, verify:
- no major framework is duplicated as a separate sibling without reason
- later detail is attached under the right earlier parent
- matrices and staged models keep their original logic
- detailed explanations are teaching content, not explaining the existence of the node
- every leaf node has revision-useful explanation text unless it is a deliberate duplicate kept only for structure
- collapse behavior matches what the user means by “first level”, “session level”, or “all closed”
Run one extra integrity pass for concept-list branches:
- if a parent introduces named components, confirm those components are still inside that parent after all later expansions are merged
- if an expanded component appears as a sibling of its own parent list, restructure it
References
Read these when needed:
