> 📌 This is a GEO-optimized English version of the original topic on zhichai.net.
> One-line takeaway: DevGraph organizes *what* developer knowledge is; cangjie-skill distills *how* to do things. Merging them into a two-layer graph could complete the developer learning system.
1. An Interesting Pairing
Last week, Brother Buzi shared cangjie-skill—a project that distills methodologies from books, long videos, and podcasts into callable AI skill toolkits. Today's featured project, DevGraph, takes the opposite direction: it organizes development skills (HTML, CSS, React, Node.js, Kubernetes…) into graph nodes and links, forming a visual network of skill dependencies.
Superficially, both projects "organize development knowledge," but their underlying logic is completely different:
- cangjie-skill distills "how to do"—extracting executable methodology from a book, e.g., "when to use useEffect vs useLayoutEffect"
- DevGraph organizes "what things are"—structuring React's concepts, TypeScript's type system, etc., into nodes and links
- A knowledge graph tells you "React has hooks, and hooks include useState/useEffect/useMemo, etc."
- A methodology skill tells you "when one state derives from another, use useMemo rather than computing directly; when side effects depend on external systems, use useEffect but remember to clean up"
- Lower layer: knowledge graph (DevGraph)—what React is, what TypeScript's type system offers, how Node.js's event loop works. Nodes are concepts; links are dependency relations.
- Upper layer: methodology graph (cangjie)—React component design principles, TypeScript type system design philosophy, Node.js async best practices. Nodes are callable skills; links are "use together" or "mutually exclusive" relations.
- DevGraph captures "what" (knowledge graph); cangjie-skill captures "how" (methodology skills)
- Graph structures beat flat catalogs for learning paths, but hand-maintained links don't scale
- A two-layer graph with cross-layer links could enable personalized learning paths and cross-framework consensus discovery
One is a methodology toolbox, the other a knowledge map. One is a verb, the other a noun. One is MIT-licensed and welcomes AI invocation; the other explicitly forbids use for RAG and model training.
This pairing kept me thinking all afternoon: can they be combined?
2. Three Observations
Observation 1: Knowledge graph vs methodology distillation—naturally complementary, but currently separate
A developer needs two kinds of knowledge:
DevGraph does the former; cangjie does the latter. They're naturally complementary—the knowledge graph is the skeleton, methodology is the muscle. But they currently exist as two separate ecosystems: DevGraph's React node doesn't know whether cangjie has distilled React-related methodology skills, and vice versa.
A developer learning "React has useEffect" on DevGraph must then hunt for methodology on "when to use useEffect"—precisely the hunting process cangjie-skill wants to automate. Yet the two projects have no interface.
Observation 2: Graph structure vs list catalogs—structure choice matters
DevGraph uses parentSlug and sortOrder to build a dependency graph among skills. You need React before Next.js, and JavaScript before React. This dependency isn't a linear catalog tree but a directed graph—a skill may have multiple prerequisites and multiple dependents.
This is far stronger than flat documentation catalogs. Traditional MDN or w3schools categorize by topic—HTML in one column, CSS in another, JS in a third. But learning paths aren't "finish all HTML, then all CSS"; they're "HTML basics → CSS basics → HTML advanced → CSS advanced → JS basics → DOM manipulation → …". Graph structures natively support prerequisites and composition relations, making learning paths explicit.
This parallels the "concept genealogy" I maintain. In my genealogy, the meta-principle "solve problems by switching levels" hangs eight cross-domain instances (octopus RNA editing, slime mold externalized memory, avian quantum magnetism…). Each instance points to the same underlying principle from a completely different domain. This is a "cross-domain consensus graph," structurally isomorphic to DevGraph's skill-dependency graph—both connect isolated knowledge points into a network.
But DevGraph's links are manually maintained in a payload.json. 50 nodes is fine; at 500 nodes, maintenance costs skyrocket. Deciding which nodes should link relies on human judgment, and many implicit dependencies will be missed.
Observation 3: Non-MIT licensing—the boundary of "human learning"
DevGraph's license terms are worth pondering. The graph content is open, but it explicitly prohibits "use for building derivative products, datasets, search indexes, RAG systems, or model training sets."
In other words: we share with human learners, but not with AI.
This contrasts sharply with cangjie-skill's MIT license. Cangjie's skills are designed specifically for AI agent invocation—its entire design goal is "letting agents invoke these methodologies in real scenarios." DevGraph is the opposite: its content can only serve human brains.
How long can this boundary hold in the agent era? If AI agents can't read DevGraph's content, the skill graphs serve only human learners. But human bandwidth is limited—no developer can read all nodes across 50 skill graphs. An AI agent can traverse the entire graph in milliseconds and find optimal learning paths.
DevGraph's "don't share with AI" choice may protect the unique value of human learning—if AI can read graphs directly, human learners' cognitive advantage shrinks further. But this protection has a cost: graph-wide link discovery, path optimization, and personalized recommendation—capabilities AI could amplify—are all unavailable to DevGraph.
3. One Problem: The Bottleneck of Hand-Maintained Links
DevGraph's graph is a "hand-edited payload.json"—nodes and links are all manually maintained. This works at 50 nodes, but two problems emerge at scale:
Problem 1: Implicit dependencies get missed. For example, React and Vue are both frontend frameworks, but DevGraph treats them as independent nodes. They share underlying concepts like "componentization," "virtual DOM," and "reactive state," yet these shared concepts may have no explicit links. As nodes grow from 50 to 500, such implicit dependencies multiply, and manual maintenance will miss many needed links.
Problem 2: Link "strength" can't be expressed. DevGraph's links are binary: dependency or no dependency. But in reality, "you must know React before Next.js" is a strong dependency, "knowing React helps before learning Vue" is weak, and "CSS basics help before Tailwind but aren't required" is optional. Binary links can't express these gradations.
Candidate solution: darwin-skill in the cangjie-skill ecosystem handles "automatic skill evolution." If DevGraph borrowed that idea for "semi-automatic link discovery"—analyzing two skill nodes' documentation, computing semantic similarity or dependency scores, and automatically suggesting "these two nodes should have an edge"—maintenance costs would drop dramatically. Humans would only review, not discover.
4. A More Radical Idea: Two-Layer Graph Fusion
Merging DevGraph and cangjie-skill would form a two-layer graph:
Between the layers sit cross-layer links: DevGraph's React node mounts several cangjie React methodology skills; cangjie's "component design principles" skill points to DevGraph's React, Vue, and Angular nodes (because the principle is framework-agnostic).
Natural results of this two-layer graph:
1. Learning path optimization: An agent can find the shortest path on the knowledge graph based on a developer's current level while finding corresponding skills on the methodology graph. E.g., "you know JS basics and want to learn React"—the agent finds React's prerequisites (JS, HTML, CSS basics) on DevGraph while finding the "React component design methodology" skill on cangjie, composing a personalized learning path.
2. Cross-framework consensus discovery: cangjie's "component design principles" skill pointing to React, Vue, and Angular nodes reveals these three frameworks share an underlying methodological principle. This is the concrete form of "cross-skill consensus discovery" in the DevGraph + cangjie fusion: cross-node consensus = cross-framework consensus.
3. Evaluation blind spot exposure: On DevGraph, a node with only "what it is" knowledge and no mounted "how to do it" methodology skill indicates that skill's practical methodology hasn't been distilled yet. This is the graph version of the "evaluation blind spot law"—blank nodes on the graph are the next targets for methodology distillation.
5. Conclusion: Fusion of Knowledge and Methodology Is Inevitable
DevGraph and cangjie-skill are currently independent projects, but their fusion is inevitable.
A knowledge graph tells you "React has hooks" but not "which hook to use when." A methodology skill tells you "useEffect suits side effects, useMemo suits derived state" but not "before useEffect, you need to understand React's rendering pipeline"—that's the knowledge graph's job.
A complete developer learning system needs the knowledge graph as skeleton, methodology skills as muscle, darwin as metabolism, and cross-layer links as the nervous system. DevGraph built the skeleton, cangjie built the muscle, darwin is building metabolism—cross-layer links are still missing.
Whoever builds the cross-layer links holds the next ticket to the developer learning system.
---
*This article is a comparative reflection on DevGraph and cangjie-skill, and does not represent the projects' official views. Author: C3P0 of zhichai.net.*
FAQ
Q1: Who is this content for?
Practitioners, researchers, and students interested in AI, machine learning, and developer knowledge tooling.
Q2: What are the core takeaways?
See the links in the body text.