Season 3, Episode 7 of Going Meta introduces the concept of formalised agent skills for ontology engineering. Rather than prompting an LLM ad hoc each time you need an ontology, a skill is a reusable, versioned instruction set stored alongside the codebase that any LLM agent or IDE assistant can pick up and execute consistently. The session walks through theDocumentation Index
Fetch the complete documentation index at: https://mintlify.com/jbarrasa/goingmeta/llms.txt
Use this file to discover all available pages before exploring further.
ontology-builder-assistant skill — a complete workflow that takes a purpose statement, competency questions, and sample data as inputs and delivers a minimal, evidence-backed OWL ontology as output.
Watch the Recording
Season 3, Episode 7 — April 2026
Session Code
Skill definition, ontology, and KG pipeline script
What Is an Agent Skill?
An agent skill is a Markdown file (SKILL.md) placed inside a .agent/skills/<skill-name>/ directory. Agents running inside tool-aware IDEs (such as Cursor or GitHub Copilot) or orchestration frameworks can discover, load, and execute these skills on demand. The skill file declares:
- Name and description (in YAML frontmatter) — used for skill selection by the agent
- A required workflow — an ordered sequence of steps the agent must follow
- An output contract — the exact structure the agent must return
- Style and decision rules — guardrails that prevent scope creep
The ontology-builder-assistant Skill
The skill is declared with a short description that helps the agent select it in the right context:
The Nine-Step Workflow
Normalize the Inputs
Organise all available inputs into five buckets: purpose (use cases, scope boundaries, competency questions, constraints), representative data (CSV, JSON, XML, or natural-language documents), existing ontologies or vocabularies to reuse, supporting semantic evidence (glossaries, SME notes, data catalog descriptions), and implementation constraints (naming rules, reasoning profile, test expectations, quality criteria).If a bucket is missing or thin, say so explicitly before proceeding. Do not invent requirements to fill gaps.
Build the Requirement Gate
Create a candidate list of classes, properties, and controlled values drawn from explicit use cases, scope statements, competency questions, and implementation constraints. An ontology element is eligible only if it is required to answer at least one competency question or explicit requirement. Competency questions are the strongest filter.
Build the Evidence Gate
Check each candidate against the representative data. Support can be direct or near-direct evidence: repeated entities, repeated attributes, events, roles, states, measures, identifiers, dates, places, relationships, or lexical patterns. Generalise beyond literal sample mentions only when the generalisation remains supported by the data.
Apply Strict Inclusion and Exclusion Rules
Include an ontology element only when both conditions hold: (1) it is required by at least one explicit requirement or competency question, and (2) it is supported by the sample data. Exclude everything else, even if it appears in a reused vocabulary or seems generally useful.
Choose a Top-Level Grounding Scheme
Create a small set of mutually disjoint top-level classes that reduces cross-category confusion. Example schemes:
person / object / location / event; party / event / clinicalFinding; asset_artifact / data_information / governance / location / measurement / party / process_event / state_condition / time. Keep the set small, declare the classes mutually disjoint, and explain why the chosen scheme fits the use case.Keep the Taxonomy Shallow and Extraction-Friendly
Maximum class depth is 3. Prefer properties over deeper subclass trees. Use potential subclasses beyond level 3 as
skos:example values on the parent class rather than adding new taxonomy levels. Keep names concrete and operational.Reuse External Vocabularies Carefully
Reuse classes or properties from existing ontologies only when reuse helps satisfy an included requirement. Do not import large fragments that violate the minimal-scope rule. Say explicitly what was reused and what was deliberately not reused.
Define Classes and Properties Clearly
Provide an Aristotelian definition for every class: “an X is a Y that Z.” Definitions must help distinguish nearby concepts that might be confused during extraction or mapping. Avoid circular definitions and vague labels.
The Modeling Checklist
The skill references a companion checklist atreferences/modeling-checklist.md that acts as a pre-flight verification before the final serialisation:
Output Contract
The skill mandates exactly five output sections, ensuring every ontology produced is self-documenting and traceable:- CQ-to-ontology mapping — for each competency question, the classes, properties, and controlled values required to answer it, with justification
- Top-level disjoint class scheme — the grounding classes, the rationale, the disjointness statement, and each included class mapped to one grounding branch
- Class definitions — preferred label, parent class, Aristotelian definition, inclusion justification (citing requirement + data signal), and key properties
- Final ontology serialisation — OWL Turtle using only the included elements, with prefixes, disjointness assertions, and domain/range axioms where stable
- Actionable artifacts — for unstructured source data, a
GraphSchemaJSON file produced by the bundledscripts/owl_to_graphrag_schema.pyconversion script; for structured source data, a mapping specification with column-to-class/property mappings, transformation rules, and examples
Translating the Ontology into Actionable Artifacts
Once the Turtle ontology is produced, the skill generates deployment artifacts automatically: For unstructured source data, the skill runsscripts/owl_to_graphrag_schema.py to produce a GraphSchema JSON file that a SimpleKGPipeline can consume directly:
A Worked Example: Clinical Case Sheet Ontology
The session demonstrates the skill applied to clinical case sheet documents. The resulting ontology uses a three-way top-level grounding scheme (Party, Event, ClinicalFinding) with mutually disjoint assertions: