# Graph Engineering: A Claude Skill for Knowledge Graphs and Task Graphs > The repository packages Southeast University's nine-stage knowledge-graph pipeline and a set of task-graph orchestration rules as a Claude skill, with nine paste-ready workflow prompts. It is documentation and prompts, not a running service. **codejunkie99/graph-engineering** — 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 - Repository: https://github.com/codejunkie99/graph-engineering - Stars: 530 · Forks: 67 - Language: Unknown - License: MIT - Published: 2026-09-10 · Updated: 2026-09-10 · Language: en - Canonical page: https://hysenlabs.com/projects/codejunkie99-graph-engineering ## What graph-engineering actually ships The repository is not a library and not a service. It is a skill bundle plus written references. The README describes two halves: knowledge graphs, which cover what agents remember (nodes as entities and facts, edges as relationships carrying time and provenance), and task graphs, which cover how agents work (nodes as jobs, edges as execution dependencies). The framing sentence is that prompt engineers steered the model's words, loop engineers steered its iterations, and graph engineers steer its topology. The top level holds LICENSE, README.md, WORKFLOWS.md, dist/, and graph-engineering/. Inside graph-engineering/ sits the skill itself and a references/ directory with five distilled documents: curriculum.md, modeling.md, extraction.md, fusion-and-llm.md, and task-graphs.md. The README states these are an independent English distillation of Southeast University's graduate Knowledge Graph course taught by Prof. Peng Wang, with the original Chinese lecture PDFs remaining in the npubird/KnowledgeGraphCourse repository and none redistributed here. That distinction matters if you need the primary source: the decks are elsewhere, and this repository gives you a translated curriculum map with links back to them. Because there is nothing to execute, your evaluation should focus on whether the written pipeline matches how you already build retrieval systems. A reader looking for a package to import, a server to start, or a schema migration tool will not find one here. ## The nine-stage pipeline and why order is the argument The pipeline runs scope, representation, ontology, entities, relations, events, quality gate, fusion, then serving to LLMs. The README draws it as a left-to-right flow and states three rules alongside it: model the domain before extracting, fuse before storing, and verify at every stage. The closing line of that section is blunt: a knowledge graph is a product with a schema, not a pile of triples. The ordering is the substantive claim. Most retrieval projects start at extraction, pull triples out of documents, and only later discover that two entities from different sources should have been merged, or that an event and a relation were conflated. Putting ontology at stage three and fusion at stage eight forces those decisions earlier in the design, which is cheaper than reconciling them after storage. Events appear as their own stage, separate from relations, which implies the pipeline treats time-bound occurrences differently from standing facts. The README does not spell out the exact schema for either, so the modeling and extraction references are where that detail would live. The quality gate at stage seven is the least specified part in the README. It is placed before fusion, which suggests filtering happens on extracted material rather than on the merged store, but the README does not define the checks. Treat the gate as a design slot you fill yourself until you read the reference files. ## Task-graph rules: fake edges, the diamond, the stop rule, the human gate The second half is a short list of orchestration rules. Delete fake edges: an arrow is real only when work flows through it. The diamond pattern splits work, runs parallel workers, gives each a separate verifier context, and ends in one owned merge. The human gate places approval exactly where a mistake is expensive to undo. The stop rule is the only place the README cites a measurement. It attributes the finding to Google DeepMind and MIT across 180 configurations: teams win roughly 80% on work that splits, and every team configuration loses on sequential work. The stated conclusion is that the shape of the work decides, not the configuration. That is a narrower claim than multi-agent advocacy usually makes, and it is the most useful thing in the repository for someone deciding whether to parallelize at all. The separate verifier context in the diamond is a real constraint, not a stylistic preference: if the verifier shares context with the worker, it inherits the worker's assumptions and the check becomes ceremonial. The README states this in one phrase and does not elaborate on how to isolate contexts in any particular harness, so the task-graphs reference is the place to look for the mechanics. ## Installing the skill and running a first build The README gives exactly two commands for installation. The first clones the repository, the second copies the inner skill folder into the Claude skills directory. Note the doubled path segment: the repository contains graph-engineering/, and inside it another graph-engineering/ directory, which is the one that gets copied. ```bash git clone https://github.com/codejunkie99/graph-engineering.git cp -r graph-engineering/graph-engineering ~/.claude/skills/ ``` After the copy, the skill folder should appear alongside your other skills under ~/.claude/skills/. The README does not document an uninstall step or a way to verify the copy succeeded beyond checking that directory. With the skill in place, the README says to ask your agent either to build or to teach. A build request is phrased as building a knowledge graph from your docs; a teaching request is phrased as teaching you 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. The other entry point is WORKFLOWS.md, which the README describes as nine paste-ready prompt blocks. One is a /kg-tutor that teaches the whole course interactively, and eight are single-purpose tools running from /kg-scope through /kg-rag that chain into a full build. If you prefer to drive the pipeline manually rather than through the skill, that file is where the prompts live. ## Where this is the wrong tool Three cases stand out. First, if you need a running pipeline rather than instructions for one, this repository does not provide it. There is no extraction binary, no graph database configuration, no embedding service. The README describes stages and rules; it does not claim to execute them. Second, if your work is sequential, the stop rule tells you not to use the task-graph half. The README states plainly that every team configuration loses on sequential work. Applying the diamond pattern to a chain of dependent steps adds coordination cost with no parallel gain, and the repository's own cited result argues against it. Third, the knowledge-graph half is a distillation of a Chinese-language graduate course, and the README is explicit that the original lecture PDFs are not redistributed here. If your team needs the full academic treatment, the primary course repository is the source, and this one is a translation layer with its own editorial choices. The README also does not describe any evaluation of the pipeline against a labelled dataset, so there is no accuracy figure to weigh. A subtler limitation: the repository has no releases. The README's install path clones the default branch, so what you get is whatever is on master at the time you clone. There is no version to pin. ## How it differs from loop engineering and from a framework like LangGraph The README positions graph engineering against loop engineering directly: loop engineers steer the model's iterations, graph engineers steer its topology. The distinction is about where control lives. A loop repeats a single agent with feedback until some condition is met; a task graph declares the dependency structure up front, so parallelism and verification points are design decisions rather than emergent ones. The stop rule's finding supports that split: the shape of the work, not the tuning of the loop, determines whether teams help. Against a code-first orchestration framework, the difference is medium and audience. A framework gives you classes, a scheduler, and a runtime you import into an application. This repository gives you a Claude skill, five Markdown references, and nine prompt blocks. One is infrastructure; the other is a way of thinking that you apply through an agent conversation. If your team already writes orchestration code, the references here are reading material that may change your graph design, not a replacement for your scheduler. There is also a provenance difference worth noting. The task-graph rules are attributed to published work from Google DeepMind and MIT and to Anthropic's multi-agent engineering writing, while the knowledge-graph pipeline is attributed to a specific university course. Both halves name their sources, which makes it possible to go read the originals and judge the distillation. ## Licence, maintenance and upgrade cost The repository is MIT licensed, and the README repeats that at the bottom. The licence covers the repository's own text and skill files. It does not cover the Southeast University lecture PDFs, which the README says remain in the original repository and are not redistributed here. If you plan to reuse the distilled references in training material or a product, read the LICENSE file at the top level rather than relying on the README line, and treat the upstream course material as a separate question. This is not legal advice. The last push to the repository was on 2026-07-23. There are no releases, so upgrades mean pulling the default branch again and re-copying the skill folder. Because the install is a directory copy into ~/.claude/skills/, an upgrade overwrites whatever you had there; the README does not document rollback or a way to keep local edits alongside upstream changes. If you modify the skill files for your own domain, expect to reconcile those edits by hand on each pull. Maintenance cost after installation is low in the sense that there is no service to run and no dependency to patch. It is higher in the sense that the value depends on the agent harness reading the skill correctly, and the README does not describe compatibility beyond Claude Code and skill-compatible harnesses. ## Conclusion Adopt graph-engineering if you already run Claude Code or a skill-compatible harness and want the nine-stage pipeline and task-graph rules as teaching material and prompt blocks rather than as a service. Do not adopt it if you need an executable graph builder, a vector store, or a Python library to import; the repository ships Markdown references, a packaged skill file, and WORKFLOWS.md. Before relying on it, open graph-engineering/references/fusion-and-llm.md and WORKFLOWS.md and confirm that the fusion and serving guidance matches the stack you actually run, because the README does not name a database or a runtime beyond the skill file itself. ## FAQ ### What is graph engineering in Claude? It is the practice of designing the knowledge-graph and task-graph structures an agent works through, packaged here as a Claude skill. The README frames it as steering the model's topology rather than its prompts or its iterations. ### What are the key differences between graph engineering and loop engineering? The README states that loop engineers steer the model's iterations while graph engineers steer its topology. In practice that means a loop repeats one agent with feedback, whereas a task graph declares jobs, dependencies, parallel workers and verification points up front. ### What is a graph engineer? In this repository's framing, a graph engineer designs the structures agents work through: the knowledge graph they remember from and the task graph they execute. The README contrasts that role with prompt engineers and loop engineers. ### What is graph engineering in AI? The README describes it as the discipline of designing the structures AI agents work through, split into knowledge graphs for what agents remember and task graphs for how agents work. The repository packages that discipline as a skill and a set of workflow prompts. ### What is loop and graph engineering? Loop engineering steers an agent's iterations, while graph engineering steers its topology, according to the README's framing. The repository covers the graph side: a nine-stage knowledge-graph pipeline and task-graph rules such as the diamond and the stop rule. ## Sources - [codejunkie99/graph-engineering on GitHub](https://github.com/codejunkie99/graph-engineering) - [Issues](https://github.com/codejunkie99/graph-engineering/issues) - [License: MIT](https://github.com/codejunkie99/graph-engineering/blob/master/LICENSE) - [README](https://github.com/codejunkie99/graph-engineering/blob/master/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/codejunkie99-graph-engineering