Model or dataset
codejunkie99/graph-engineering avatar
codejunkie99/graph-engineering

graph-engineering: a Claude skill that turns Southeast University's knowledge-graph course into a 9-stage pipeline

Graph engineering for AI agents: the 9-stage knowledge-graph pipeline (translated from SEU's graduate course) + task-graph orchestration patterns, as a Claude skill with teaching mode and paste-ready workflows

503 stars66 forksUnknownMIT

At a glance

What is it?
The repository packages an English distillation of a Chinese graduate course plus task-graph orchestration patterns as a Claude skill. It is a teaching artifact and a set of prompt blocks, not a runtime library, and the README is explicit about what it does not redistribute.
Who is it for?
Adopt it if you want a structured walkthrough of knowledge-graph construction inside a skill-compatible harness, or if you need paste-ready prompt blocks for scoping, extraction, fusion and serving. Do not adopt it if you expect a runnable graph database, an extraction library, or a maintained Python package; the repository ships Markdown references and a packaged skill file.
Can I use it commercially?
Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
Is it still maintained?
Yes. The repository last received commits 54 days ago.
What is it written in?
GitHub does not report a main language for this repository.

Answers come from the project's GitHub data, last synced on September 15, 2026, and from our analysis. They are not legal advice.

DEEP OPEN-SOURCE ANALYSIS

The gap this fills: agents that remember nothing and pipelines nobody documents

Most agent work in 2026 is prompt-shaped. You write instructions, the model produces text, and the structure of the problem stays implicit. The README frames the project's premise bluntly: prompt engineers steered the model's words, loop engineers steered its iterations, graph engineers steer its topology. That is the claim. The repository is the argument for it. It splits the subject in two. Knowledge graphs are what agents remember: nodes are entities and facts, edges carry time and provenance. Task graphs are how agents work: nodes are jobs, edges are execution dependencies. The intended reader is someone who has an agent harness and wants to give it a vocabulary for structure rather than another prompt template. The secondary reader is a student or engineer who wants the Southeast University graduate course content in English without reading the original Chinese decks. The README credits npubird/KnowledgeGraphCourse, taught by Prof. Peng Wang since 2019, as the source of the knowledge-graph half, and states plainly that the original lecture PDFs remain in the original repository and are not redistributed here.

What actually ships in the repository

Four things, per the README's own table. First, graph-engineering/graph-engineering, described as the skill itself, intended to be handed to a skill-compatible harness. Second, graph-engineering/references/, which holds the distilled course: curriculum.md (a translated curriculum map with links back to the original Chinese decks), modeling.md, extraction.md, fusion-and-llm.md, and task-graphs.md. Third, WORKFLOWS.md, which the README describes as nine paste-ready prompt blocks: a /kg-tutor that teaches the whole course interactively, plus eight single-purpose tools running from /kg-scope to /kg-rag that chain into a full build. Fourth, dist/graph-engineering.skill, the packaged skill file. That inventory matters because it sets expectations. There is no server, no schema file, no database adapter, no Python package. If you were hoping to pip install something, the repository will disappoint you on the first command. What you get is prose, structure, and prompts.

The 9-stage pipeline and why the order is the point

The README gives the pipeline as a Mermaid flowchart: 1 scope, 2 representation, 3 ontology, 4 entities, 5 relations, 6 events, 7 quality gate, 8 fusion, 9 serve to LLMs. Two claims sit underneath that ordering. The first is that you model the domain before you extract from it. That is a direct rebuke of the common pattern where someone points an LLM at a document set, pulls triples, and only afterwards asks what the schema should have been. The second is that fusion happens before storage, not after. Anyone who has merged two entity lists post hoc knows the cost: duplicate nodes with slightly different surface forms, edges that point at the wrong variant, and a cleanup job that never quite finishes. The README's summary line is that a knowledge graph is a product with a schema, not a pile of triples. Stage 7, the quality gate, is placed between extraction and fusion, which means verification is meant to run on extracted material before it contaminates the merged store. The README also states the general rule as verify at every stage, though it does not specify what verification means at each of the nine steps. That detail presumably lives in the reference files.

Task graphs: fake edges, the diamond, the stop rule, the human gate

The orchestration half gives four rules. Delete fake edges: an arrow is real only when work flows through it. This targets the habit of drawing an architecture diagram with dependencies that no data or control actually traverses. The diamond pattern is split, then parallel workers, then separate verifier contexts, then one owned merge. The word separate is doing real work there; a verifier that shares context with the producer is not an independent check. The stop rule is attributed to Google DeepMind and MIT across 180 configurations, with the README's summary being that teams win roughly 80% on work that splits and that every team configuration loses on sequential work. The shape of the work decides. That is a conditional claim, not a general endorsement of multi-agent systems, and the README presents it that way. The human gate is placed where a mistake is expensive to undo. Note what is missing: the README does not give the 180 configurations, the specific tasks, or the loss margins for sequential work. The task-graphs.md reference is cited as holding the details.

Installation is two commands and one directory convention

The README gives these two commands verbatim. First, git clone https://github.com/codejunkie99/graph-engineering.git. Second, cp -r graph-engineering/graph-engineering ~/.claude/skills/. The doubled path segment is not a typo in the README; the repository directory and the skill directory inside it share a name, so the copy source is graph-engineering/graph-engineering and the destination is the Claude skills directory. After that, the README says you ask the agent to build (build a knowledge graph from my docs) or to teach (teach me graph engineering). Teaching mode is described as walking the pipeline stage by stage with worked examples and generated diagrams, using your own project as the running example. There is no configuration file, no environment variable, and no config key documented in the README. The dist/graph-engineering.skill file is mentioned as the packaged alternative but the README does not give an installation command for it, so if you prefer the packaged route you are on your own to work out where it goes.

Where it is the wrong tool

Three cases. First, if you need a running knowledge graph today. Nothing here executes. The skill teaches an agent how to reason about graph construction and supplies prompt blocks, but the actual extraction, fusion and serving are performed by whatever your agent does with those instructions. There is no bundled extractor, no storage layer, and no query interface. Second, if your domain is small and stable. A nine-stage pipeline with an ontology stage and a quality gate is overhead when you have forty documents and a schema you already know. The README's framing, that a knowledge graph is a product with a schema, implies ongoing maintenance of that schema, and that cost is not worth paying for a one-off retrieval task. Third, if your work is sequential. The stop rule as stated says every team configuration loses on sequential work, which means the task-graph half of this repository argues against applying itself to a linear pipeline. The README does not carve out an exception, so a reader who takes the claim seriously should not reach for the diamond pattern on work that cannot be split.

The alternative approach, and the real difference

The obvious comparison is to a code-first graph framework such as an LLM graph builder library, where you write a Python pipeline that calls an extractor, resolves entities, and writes into a graph store. The difference is not quality; it is where the logic lives. A code-first framework puts the pipeline in your repository as executable functions with tests and version pins. This project puts the pipeline in your agent's context as a skill and a set of Markdown references, with WORKFLOWS.md supplying prompt blocks that you paste. The code-first route gives you reproducibility and a diff history; it also gives you a dependency you must upgrade. The skill route gives you portability across harnesses and no runtime to maintain; it also gives you no test suite, no output schema enforcement, and behaviour that shifts when the underlying model shifts. A second comparison is to the source course itself. npubird/KnowledgeGraphCourse is the original graduate material in Chinese, with the full lecture decks intact. This repository is an independent English distillation, which means it is a translation and a compression, and any nuance lost in that compression is not recoverable from this repository because the PDFs are not redistributed here. If you read Chinese, the original is the more complete artifact.

Maintenance, licensing, and what to check before you commit

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the licence and copyright notice are retained. That covers the repository's own content. It does not automatically cover the underlying course material, and the README is careful on this point: the knowledge-graph half is described as an independent English distillation, all original lecture PDFs remain in the original repository, and none are redistributed here. If you plan to republish the reference files, read that sentence twice and confirm with the upstream course what its terms are. On maintenance, the material gives one signal: the last push is dated 2026-07-23 and no releases are listed. There is no changelog and no stated compatibility range for the Claude skill format, which means an upgrade to the harness could break the skill with no notice in this repository. The task-graph half cites Google DeepMind and MIT research plus Anthropic's published multi-agent engineering work, so if that research is revised, the task-graphs.md file would be the piece to re-check. Before adopting, open graph-engineering/references/curriculum.md and confirm the translated scope covers your domain, then open task-graphs.md and check whether the stop-rule numbers are cited to a specific paper or only summarised. If the citations are thin, treat the 80% figure as a pointer to the source research rather than as a number you can plan against.

Editorial conclusion

Adopt it if you want a structured walkthrough of knowledge-graph construction inside a skill-compatible harness, or if you need paste-ready prompt blocks for scoping, extraction, fusion and serving. Do not adopt it if you expect a runnable graph database, an extraction library, or a maintained Python package; the repository ships Markdown references and a packaged skill file. Before relying on it, read graph-engineering/references/curriculum.md to confirm the translated scope matches your domain, and check whether the task-graph claims in task-graphs.md cite the DeepMind and MIT material directly or only summarise it.

Official sources

  1. codejunkie99/graph-engineering on GitHub
  2. Issues
  3. License: MIT
  4. README
Community notes

Community notes