Teaches an agent graph engineering — both halves. Knowledge graphs (ontology design, entity/relation/event extraction, fusion, GraphRAG/memory serving; distilled and translated from Southeast University's graduate Knowledge Graph course, npubird/KnowledgeGraphCourse, 4.4K stars) and task graphs (agent orchestration — parallel fan-out, verifier separation, the stop rule, human gates). Use when asked to build a knowledge graph, extract entities/relations from text, design an ontology, dedupe/merge entities, add graph memory or GraphRAG to an agent, orchestrate multi-agent workflows as a graph, or LEARN graph engineering — in teaching mode the agent explains each stage with worked examples and generates visual diagram artifacts.
73
90%
Does it follow best practices?
Run evals on this skill
Adds up to 20 points to the overall score
View guide
Passed
No findings from the security scan
Graph engineering is the discipline of designing the structures agents work through — not the prompts. It has two halves:
Core mental model: a knowledge graph is a product with a schema, not a pile of triples. Quality comes from the pipeline order — model the domain BEFORE extracting, fuse BEFORE storing, evaluate at every stage.
When the user wants to LEARN graph engineering (rather than build something), teach it — do not just execute. Rules:
graph LR for example ontologies and
subgraphs) or a single self-contained HTML page when interactivity helps. At minimum:
the 9-stage pipeline, a 3-type ontology drawn from the user's domain, one extracted
subgraph (5-10 nodes) from a real sample, and the diamond pattern with the user's own jobs
as nodes.ontology.yaml and a
drawn task graph for the user's first real build.Run stages in order. For small projects stages 4-6 collapse into one extraction pass, but never skip stages 3 (ontology) or 8 (fusion) — they are where real-world graphs fail.
Scope & value test — Confirm a graph beats a simpler structure. A graph pays off when queries are multi-hop ("who worked with X on projects using Y"), when entities recur across documents, or when relationships ARE the data. If lookups are single-hop, use a table and stop.
Knowledge representation choice — Pick how facts are encoded: property graph (Neo4j-style, pragmatic default), RDF triples (interop/standards), or plain typed edges in JSON/SQLite (small scale). Decide now how time and provenance attach to every fact.
Ontology modeling — Define entity types, relation types (with domain/range), and
attributes BEFORE extraction. Start minimal: 5-15 entity types, 10-30 relation types.
Two rules from the course: every relation gets a precise verb name (ACQUIRED, not
RELATED_TO), and if two types are always queried together, merge them.
Details and worked examples: references/modeling.md
Entity extraction (NER) — Extract typed entities from sources. Method ladder: exact rules/dictionaries for closed vocabularies → LLM extraction with the ontology in the prompt for open text. Always extract with span + source pointer for provenance.
Relation extraction — Extract typed edges between recognized entities. Constrain the LLM to the ontology's relation list with domain/range checks; reject edges whose endpoints have incompatible types. This one validation step removes most hallucinated structure.
Event extraction — For dynamic domains (news, logs, transactions), extract events as first-class nodes (trigger + typed arguments + time), not just static edges. Extraction methods, prompt patterns, and failure modes for stages 4-6: references/extraction.md
Quality gate — Before fusion, sample and score: entity precision (are extracted entities real and correctly typed?), relation precision (does the source sentence actually assert the edge?). Fix the prompt/rules, not the output, then re-run. Target ≥90% precision on a 50-item sample before proceeding — recall improves with more passes; bad precision poisons the graph permanently.
Knowledge fusion — Merge duplicates within and across sources: same real-world entity, different surface forms ("SEU" = "Southeast University" = "东南大学"). Blocking + matching + merge policy. Skipping this is the #1 cause of useless graphs. Matching strategies: references/fusion-and-llm.md
Serve to LLMs (KG × LLM) — Make the graph useful to agents: GraphRAG retrieval (subgraph → context), graph-as-memory (agent writes facts back through stages 4-8), and LLM-as-reasoner over paths. Patterns and pitfalls: references/fusion-and-llm.md
source, extracted_at, and confidence.
Non-negotiable — fusion (stage 8) and trust both depend on it.Distilled and translated from 东南大学《知识图谱》研究生课程 (Southeast University graduate course on Knowledge Graphs), Prof. Peng Wang — https://github.com/npubird/KnowledgeGraphCourse. All original lecture PDFs are in Chinese; this skill is an independent English distillation adapted for AI-agent workflows.
4e1e73b
If you maintain this skill, you can claim it as your own. Once claimed, you can manage eval scenarios, bundle related skills, attach documentation or rules, and ensure cross-agent compatibility.