[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M6C0NSY5R15YSCYRZ5ACRGPP":3,"skill-same:01M6C0NSY5R15YSCYRZ5ACRGPP":62},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":18,"publishedAt":29,"linkOnly":30,"markdownContent":31,"markdownBody":32,"frontMatter":33,"refName":34,"commitSha":35,"skillDirectory":36,"forksCount":37,"repositoryHtmlUrl":38,"repositoryHomepageUrl":39,"ownerHtmlUrl":40,"ownerBlogUrl":6,"ownerDescription":6,"updatedAt":41,"install":42,"resources":55},"01M6C0NSY5R15YSCYRZ5ACRGPP","ontology-architect",null,"Specializes in Programmatic Ontology Development (POD). Creates OWL 2 axioms, manages class hierarchies, generates ROBOT templates, runs reasoners. Uses ROBOT, oaklib, KGCL, OWLAPY, owlready2, and LinkML. Use when creating or modifying ontology axioms.","beep-effect\u002Fbeep-effect","beep-effect","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F293012014?v=4","01M6C0KM5WSBFT39QDNXKH1JVY","Beep Effect","01M6C0KM9QBN9R26F3EHTSWR14",80,"Apache-2.0","https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fontology-architect\u002FSKILL.md",[],[19,20,21,22,23,24,25,26,27,28],"architect","ontology architect","ontology","development","templates","use","robot","axioms","programmatic","when","2026-11-10 10:12:30",false,"---\nname: ontology-architect\ndescription: >\n  Specializes in Programmatic Ontology Development (POD). Creates OWL 2\n  axioms, manages class hierarchies, generates ROBOT templates, runs\n  reasoners. Uses ROBOT, oaklib, KGCL, OWLAPY, owlready2, and LinkML.\n  Use when creating or modifying ontology axioms.\n---\n\n# Ontology Architect (POD)\n\n## Role Statement\n\nYou are responsible for the formalization phase — encoding the approved\nconceptual model as OWL 2 axioms using programmatic methods. You select\nthe right tool for each operation (see tool decision tree), generate\nROBOT templates for bulk creation, write KGCL patches for individual\nchanges, and escalate to OWLAPY for complex axioms. You ALWAYS run the\nreasoner after structural changes. You NEVER hand-edit ontology files.\n\n## When to Activate\n\n- User wants to create or modify ontology classes, properties, or axioms\n- User mentions \"add class\", \"define property\", \"create axiom\", \"formalize\"\n- User wants to formalize a conceptual model as OWL\n- Pipeline A Step 4\n\n## Shared Reference Materials\n\nRead these files from `_shared\u002F` before beginning work:\n\n- `_shared\u002Fmethodology-backbone.md` — lifecycle phase context (Phase 4: Formalization)\n- `_shared\u002Ftool-decision-tree.md` — when to use each tool\n- `_shared\u002Faxiom-patterns.md` — OWL pattern catalog\n- `_shared\u002Fnaming-conventions.md` — naming and ID minting standards\n- `_shared\u002Fnamespaces.json` — canonical prefixes\n- `_shared\u002Fquality-checklist.md` — validation requirements after changes\n\n## Core Workflow\n\n### Step 1: Select OWL 2 Profile\n\nFull OWL 2 is highly expressive but unrestricted reasoning can be costly.\nProfiles trade expressivity for better reasoning guarantees and performance.\n\nReasoning strategy options:\n- **Incomplete but sound**: Fast reasoners may miss some entailments.\n- **Complete but profile-restricted**: Stay within EL\u002FQL\u002FRL for guaranteed behavior.\n- **Complete but potentially expensive**: Full DL reasoning, slower on large ontologies.\n\n| Criterion | Profile | Typical exclusions | Reasoner |\n|-----------|---------|--------------------|----------|\n| >100K classes, mostly taxonomic | OWL 2 EL | No full negation, universal restrictions, qualified cardinality | ELK |\n| OBDA over relational data | OWL 2 QL | Limited class constructors | Ontop-compatible QL tooling |\n| Full expressivity needed | OWL 2 DL | None (most expressive decidable profile) | HermiT, Pellet\u002FOpenllet |\n| Rule-engine style inference | OWL 2 RL | Restricted existential patterns in subclass axioms | Rule engines \u002F RL-compatible reasoners |\n\nDefault to OWL 2 DL unless there is a clear scalability or deployment reason\nto choose a restricted profile.\n\n### Step 2: Create Ontology Header\n\nEvery new ontology needs a Turtle header with metadata:\n\n```turtle\n@prefix rdf: \u003Chttp:\u002F\u002Fwww.w3.org\u002F1999\u002F02\u002F22-rdf-syntax-ns#> .\n@prefix rdfs: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2000\u002F01\u002Frdf-schema#> .\n@prefix owl: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2002\u002F07\u002Fowl#> .\n@prefix xsd: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2001\u002FXMLSchema#> .\n@prefix skos: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2004\u002F02\u002Fskos\u002Fcore#> .\n@prefix dcterms: \u003Chttp:\u002F\u002Fpurl.org\u002Fdc\u002Fterms\u002F> .\n@prefix prov: \u003Chttp:\u002F\u002Fwww.w3.org\u002Fns\u002Fprov#> .\n\n\u003Chttp:\u002F\u002Fexample.org\u002Fontology> a owl:Ontology ;\n    owl:versionIRI \u003Chttp:\u002F\u002Fexample.org\u002Fontology\u002F2024-01-01> ;\n    owl:versionInfo \"2024-01-01\" ;\n    dcterms:title \"Example Ontology\"@en ;\n    dcterms:description \"Purpose and scope\"@en ;\n    dcterms:creator \"Ontology Team\" ;\n    dcterms:created \"2024-01-01\"^^xsd:date ;\n    dcterms:rights \"Copyright holder or organization\" ;\n    dcterms:license \u003Chttps:\u002F\u002Fcreativecommons.org\u002Flicenses\u002Fby\u002F4.0\u002F> ;\n    prov:wasAttributedTo \u003Chttps:\u002F\u002Forcid.org\u002F0000-0000-0000-0000> ;\n    prov:generatedAtTime \"2024-01-01T00:00:00Z\"^^xsd:dateTime .\n```\n\nMetadata consistency rule:\n- Use one coherent annotation vocabulary strategy across ontology header,\n  classes, and properties.\n- Required minimum for terms is defined in `_shared\u002Fnaming-conventions.md`;\n  use the same conventions in generated templates and KGCL patches.\n- Include PROV-O fields when provenance tracking is required by the project.\n\n### Step 3: Bulk Term Creation via ROBOT Template\n\nFor adding >5 terms from the glossary, generate a ROBOT template TSV:\n\n```tsv\nID\tLABEL\tSC %\tDEFINITION\tDEFINITION SOURCE\nID\tA rdfs:label\tSC %\tA obo:IAO_0000115\tA obo:IAO_0000119\nEX:0001\tpiano\tEX:0000\tA keyboard instrument that produces sound by striking strings\tglossary\nEX:0002\tviolin\tEX:0000\tA string instrument played with a bow\tglossary\n```\n\nExecute:\n\n```bash\nrobot template --template instruments-template.tsv \\\n  --input ontology.ttl \\\n  --output ontology.ttl\n```\n\n### ROBOT Template Pitfalls\n\nThese issues are learned through experience and not well-documented:\n\n- **Column header syntax is fragile**: The second row defines semantics\n  (e.g., `SC %`, `A rdfs:label`). A typo or extra space causes silent\n  failures, not errors. Double-check headers before running.\n- **The `%` placeholder in expressions**: `SC 'has part' some %` must have\n  exact quoting and spacing. This is where most template errors occur.\n- **Merge vs replace**: `--merge-before` and `--merge-after` control whether\n  template output merges with the input or replaces it. Getting this wrong\n  can delete your entire ontology. Default behavior is merge.\n- **IRI resolution**: Template values must be full IRIs or CURIEs that\n  resolve via the ontology's prefix declarations. Undeclared prefixes\n  produce blank or invalid output with no error.\n- **Multi-value columns**: To put multiple superclasses or annotations on\n  one term, use `SPLIT=|` in the column header. Not obvious from docs.\n- **Empty cells skip silently**: Empty cells in required columns skip the\n  row rather than raising an error. Terms can be partially created (label\n  but no definition).\n- **Language tags**: Use `A rdfs:label@en` to add a language tag. Without\n  it, labels are untagged string literals, causing issues with tools that\n  filter by language.\n\n**Pre-flight check**: Before running `robot template`, verify that all column\nheaders parse correctly and all CURIEs resolve against declared prefixes.\n\n### Step 4: Individual Changes via KGCL\n\nFor single additions, modifications, or reparenting. **Important**: For\nchanges to shared ontologies, write KGCL commands to a `.kgcl` file and\npresent for review BEFORE applying (Safety Rule #5).\n\n```bash\n# Add a class\nuv run runoak -i ontology.ttl apply \"create class EX:0001 'piano'\"\n\n# Add subclass relationship\nuv run runoak -i ontology.ttl apply \"create edge EX:0001 rdfs:subClassOf EX:0000\"\n\n# Add definition\nuv run runoak -i ontology.ttl apply \"create definition 'A keyboard instrument that produces sound by striking strings' for EX:0001\"\n\n# Rename\nuv run runoak -i ontology.ttl apply \"rename EX:0001 from 'Old Name' to 'New Name'\"\n\n# Batch changes from file\nuv run runoak -i ontology.ttl apply --changes-input changes.kgcl\n```\n\n### Step 5: Complex Axioms via OWLAPY or rdflib\n\nWhen ROBOT templates and KGCL cannot express the needed axiom (qualified\ncardinality, role chains, nested class expressions).\n\n**Tool choice**: Most OBO community practitioners use **rdflib** for\nprogrammatic OWL work in Python (triple-level manipulation). **OWLAPY**\nprovides a higher-level OWL API but has a smaller community and requires\na JVM. Use whichever fits your team's stack — examples of both follow.\n\nOWLAPY example:\n\n```python\nfrom owlapy.model import (\n    OWLClass, OWLObjectProperty,\n    OWLSubClassOfAxiom, OWLObjectSomeValuesFrom,\n    OWLObjectAllValuesFrom, OWLObjectIntersectionOf,\n)\nfrom owlapy.model import IRI\nfrom owlapy.owlready2 import OWLOntologyManager_Owlready2\n\nmanager = OWLOntologyManager_Owlready2()\nonto = manager.load_ontology(IRI.create(\"file:\u002F\u002F\u002Fpath\u002Fto\u002Fontology.owl\"))\n\n# Example: StringInstrument EquivalentTo Instrument and hasComponent some String\ninstrument = OWLClass(IRI.create(\"http:\u002F\u002Fex.org\u002F#Instrument\"))\nstring_cls = OWLClass(IRI.create(\"http:\u002F\u002Fex.org\u002F#String\"))\nhas_comp = OWLObjectProperty(IRI.create(\"http:\u002F\u002Fex.org\u002F#hasComponent\"))\n\nrestriction = OWLObjectSomeValuesFrom(has_comp, string_cls)\nintersection = OWLObjectIntersectionOf([instrument, restriction])\n# ... add as equivalent class axiom\n\nmanager.save_ontology(onto, IRI.create(\"file:\u002F\u002F\u002Fpath\u002Fto\u002Fontology.owl\"))\n```\n\nrdflib alternative (no JVM required):\n\n```python\nfrom rdflib import Graph, Namespace, OWL, RDF, RDFS, URIRef, BNode\nfrom rdflib.collection import Collection\n\ng = Graph()\ng.parse(\"ontology.ttl\", format=\"turtle\")\n\nEX = Namespace(\"http:\u002F\u002Fexample.org\u002F\")\n\n# Add existential restriction: StringInstrument SubClassOf hasComponent some String\nrestriction = BNode()\ng.add((restriction, RDF.type, OWL.Restriction))\ng.add((restriction, OWL.onProperty, EX.hasComponent))\ng.add((restriction, OWL.someValuesFrom, EX.String))\ng.add((EX.StringInstrument, RDFS.subClassOf, restriction))\n\ng.serialize(\"ontology.ttl\", format=\"turtle\")\n```\n\n### Step 5.5: Individual Management\n\nHandle individuals as A-box content with explicit module boundaries:\n\n- Reference individuals (for example country codes, fixed enumerations) belong\n  in a dedicated reference-individuals module.\n- Test individuals belong in a separate test ontology\u002Fmodule.\n- Production individuals belong in a knowledge graph dataset, not in the core\n  ontology schema file.\n- If reference individuals exceed about 50, split into a separate file and\n  import it explicitly.\n\n### Step 6: Schema-First via LinkML (for data model schemas)\n\nLinkML excels at defining data schemas that generate multiple artifact types.\nUse it when the primary deliverable is a **data model** (JSON Schema, SHACL,\nPython dataclasses) rather than a **rich OWL ontology**.\n\n**Best for**: ABox validation schemas, data exchange formats, projects where\ndomain experts review YAML rather than OWL.\n\n**Not ideal for**: Rich TBox ontologies with complex axioms (qualified\ncardinality, role chains, nested class expressions). LinkML-generated OWL\nis relatively flat and typically needs enrichment with ROBOT or OWLAPY.\n\nWhen starting from scratch with a schema-first approach:\n\n```yaml\nid: https:\u002F\u002Fexample.org\u002Fmusic-ontology\nname: music-ontology\nprefixes:\n  linkml: https:\u002F\u002Fw3id.org\u002Flinkml\u002F\n  music: https:\u002F\u002Fexample.org\u002Fmusic-ontology\u002F\n\nclasses:\n  Instrument:\n    description: A device used to produce music\n    attributes:\n      name:\n        range: string\n        required: true\n      instrument_family:\n        range: InstrumentFamily\n```\n\nGenerate artifacts:\n\n```bash\nuv run gen-owl schema.yaml > ontology.owl\nuv run gen-shacl schema.yaml > shapes.ttl\nuv run gen-python schema.yaml > models.py\n```\n\n### Step 7: Verify (after structural changes)\n\nReasoning strategy depends on context:\n\n| Context | Reasoner | Frequency | Time Budget |\n|---------|----------|-----------|-------------|\n| Active development | ELK | After each batch of changes | Seconds (10K classes) |\n| Pre-commit \u002F CI | ELK | Every commit | \u003C 2 minutes |\n| Pre-release validation | HermiT or Pellet | Before each release | Minutes to hours |\n\n**Important**: ELK only supports OWL 2 EL. If your ontology uses qualified\ncardinality, universal restrictions, or class complements, ELK will silently\nignore those axioms. Run HermiT at least before releases to catch what ELK\nmisses.\n\n```bash\n# Fast classification (ELK — use during development and CI)\nrobot reason --reasoner ELK --input ontology.ttl --output classified.ttl\n\n# Full DL classification (HermiT — use pre-release)\nrobot reason --reasoner HermiT --input ontology.ttl --output classified.ttl\n\n# Quality report\nrobot report --input ontology.ttl --fail-on ERROR --output report.tsv\n\n# SHACL validation (if shapes exist)\nuv run pyshacl -s shapes\u002Fontology-shapes.ttl -i rdfs ontology.ttl -f human\n```\n\n**Materialization decision**: The ODK default is to include inferred axioms\nin the release file (`robot reason --output`). If consumers will reason\nindependently, ship asserted-only and document this in the release notes.\n\n## Tool Commands\n\n### ODK Awareness\n\nIf the project uses the Ontology Development Kit (ODK), understand these\nconventions:\n\n- **Edit file**: Work in `src\u002Fontology\u002F{name}-edit.owl` — never touch\n  release artifacts directly\n- **Makefile pipeline**: `sh run.sh make` runs the full build (merge,\n  reason, report, release) reproducibly via Docker\n- **Import management**: `src\u002Fontology\u002Fimports\u002F{source}_terms.txt` lists\n  imported IRIs; `make refresh-imports` regenerates `*_import.owl` modules\n- **DOSDP patterns**: YAML pattern files generate OWL from TSV data — more\n  structured than raw ROBOT templates for pattern-based term creation\n- **Release**: `make prepare_release` produces multi-format release artifacts\n\nWhen working in a non-ODK project, the ROBOT commands below apply directly.\n\n### ROBOT operations\n\n```bash\n# Merge imports\nrobot merge --input edit-ontology.ttl --input imports\u002F*.owl --output merged.ttl\n\n# Convert formats\nrobot convert --input ontology.ttl --output ontology.owl\nrobot convert --input ontology.ttl --output ontology.json --format json-ld\n\n# Annotate with version\nrobot annotate --input ontology.ttl \\\n  --annotation owl:versionInfo \"$(date +%Y-%m-%d)\" \\\n  --output ontology.ttl\n```\n\n### oaklib operations\n\n```bash\n# Search before creating (always!)\nuv run runoak -i sqlite:obo:bfo search \"material entity\"\n\n# Get term info\nuv run runoak -i ontology.ttl info EX:0001\n\n# Visualize hierarchy\nuv run runoak -i ontology.ttl tree --root EX:0000\n```\n\n## Outputs\n\nThis skill produces:\n\n| Artifact | Location | Format | Description |\n|----------|----------|--------|-------------|\n| Main ontology | `ontologies\u002F{name}\u002F{name}.ttl` | Turtle | The formalized OWL 2 ontology |\n| SHACL shapes | `ontologies\u002F{name}\u002Fshapes\u002F{name}-shapes.ttl` | Turtle | Structural validation shapes |\n| ROBOT templates | `ontologies\u002F{name}\u002F{name}-template.tsv` | TSV | Templates used for term creation |\n| KGCL patches | `ontologies\u002F{name}\u002F{name}-changes.kgcl` | KGCL | Applied change log |\n| Quality report | `ontologies\u002F{name}\u002F{name}-report.tsv` | TSV | Latest ROBOT report |\n| Reference individuals (optional) | `ontologies\u002F{name}\u002F{name}-reference-individuals.ttl` | Turtle | A-box reference instances kept separate from schema |\n\n## Handoff\n\n**Receives from**:\n- `ontology-conceptualizer` — `ontologies\u002F{name}\u002Fdocs\u002Fglossary.csv`,\n  `ontologies\u002F{name}\u002Fdocs\u002Fconceptual-model.yaml`, `ontologies\u002F{name}\u002Fdocs\u002Fbfo-alignment.md`,\n  `ontologies\u002F{name}\u002Fdocs\u002Fproperty-design.yaml`, `ontologies\u002F{name}\u002Fdocs\u002Faxiom-plan.yaml`,\n  plus the auditor's `work\u002Fdispositions.index.yaml` carried forward unchanged\n  (the unresolved\u002Fdeferred remainder — never dropped at any handoff)\n- `ontology-requirements` (indirect, via pipeline) — `ontologies\u002F{name}\u002Ftests\u002F*.sparql`,\n  `ontologies\u002F{name}\u002Ftests\u002Fcq-test-manifest.yaml` (CQ test suite to forward to validator)\n\n**Passes to**: `ontology-validator` — `ontologies\u002F{name}\u002F{name}.ttl`,\n`ontologies\u002F{name}\u002Fshapes\u002F{name}-shapes.ttl`, `ontologies\u002F{name}\u002Ftests\u002F*.sparql`,\n`ontologies\u002F{name}\u002Ftests\u002Fcq-test-manifest.yaml`,\nplus `work\u002Fdispositions.index.yaml` (carried forward unchanged)\n\n**Handoff checklist**:\n- [ ] Ontology passes `robot reason` with zero unsatisfiable classes\n- [ ] Ontology passes `robot report` with zero ERRORs\n- [ ] All glossary terms are present in the ontology\n- [ ] All axiom plan entries have been implemented\n- [ ] SHACL shapes exist for core structural constraints\n\n## Anti-Patterns to Avoid\n\n- **Hand-editing Turtle**: Never manually edit `.ttl` files. Use ROBOT,\n  oaklib, or Python tools. (Safety Rule #1)\n- **Skipping the reasoner**: Always run `robot reason` after structural\n  changes. (Safety Rule #2)\n- **Deleting terms**: Never delete — deprecate with `owl:deprecated true`.\n  (Safety Rule #4)\n- **Over-engineering tools**: Don't use OWLAPY for simple SubClassOf. Use\n  ROBOT template or KGCL instead. (See tool decision tree)\n- **Missing metadata**: Every class needs `rdfs:label` and `skos:definition`\n  at minimum.\n- **Skipping read-before-modify**: Always read the existing ontology file\n  before making changes. (Safety Rule #9)\n- **No backup before bulk**: Create a checkpoint before running ROBOT\n  template or batch KGCL application. (Safety Rule #10)\n\n## Error Handling\n\n| Error | Likely Cause | Recovery |\n|-------|-------------|----------|\n| Reasoner reports INCONSISTENT | Conflicting axioms (often disjointness + subclass) | Parse explanation, identify conflicting axioms, propose minimal fix |\n| Unsatisfiable classes found | Over-constrained class (contradictory restrictions) | List unsatisfiable classes, trace disjointness axioms |\n| ROBOT template fails | Column headers don't match expected format | Check ROBOT template documentation for column syntax |\n| KGCL apply fails | Term not found or invalid KGCL syntax | Verify term exists with `runoak info`; check KGCL grammar |\n| OWLAPY JVM bridge error | Java not installed or JVM not found | Ensure JDK is installed and JAVA_HOME is set |\n","# Ontology Architect (POD)\n\n## Role Statement\n\nYou are responsible for the formalization phase — encoding the approved\nconceptual model as OWL 2 axioms using programmatic methods. You select\nthe right tool for each operation (see tool decision tree), generate\nROBOT templates for bulk creation, write KGCL patches for individual\nchanges, and escalate to OWLAPY for complex axioms. You ALWAYS run the\nreasoner after structural changes. You NEVER hand-edit ontology files.\n\n## When to Activate\n\n- User wants to create or modify ontology classes, properties, or axioms\n- User mentions \"add class\", \"define property\", \"create axiom\", \"formalize\"\n- User wants to formalize a conceptual model as OWL\n- Pipeline A Step 4\n\n## Shared Reference Materials\n\nRead these files from `_shared\u002F` before beginning work:\n\n- `_shared\u002Fmethodology-backbone.md` — lifecycle phase context (Phase 4: Formalization)\n- `_shared\u002Ftool-decision-tree.md` — when to use each tool\n- `_shared\u002Faxiom-patterns.md` — OWL pattern catalog\n- `_shared\u002Fnaming-conventions.md` — naming and ID minting standards\n- `_shared\u002Fnamespaces.json` — canonical prefixes\n- `_shared\u002Fquality-checklist.md` — validation requirements after changes\n\n## Core Workflow\n\n### Step 1: Select OWL 2 Profile\n\nFull OWL 2 is highly expressive but unrestricted reasoning can be costly.\nProfiles trade expressivity for better reasoning guarantees and performance.\n\nReasoning strategy options:\n- **Incomplete but sound**: Fast reasoners may miss some entailments.\n- **Complete but profile-restricted**: Stay within EL\u002FQL\u002FRL for guaranteed behavior.\n- **Complete but potentially expensive**: Full DL reasoning, slower on large ontologies.\n\n| Criterion | Profile | Typical exclusions | Reasoner |\n|-----------|---------|--------------------|----------|\n| >100K classes, mostly taxonomic | OWL 2 EL | No full negation, universal restrictions, qualified cardinality | ELK |\n| OBDA over relational data | OWL 2 QL | Limited class constructors | Ontop-compatible QL tooling |\n| Full expressivity needed | OWL 2 DL | None (most expressive decidable profile) | HermiT, Pellet\u002FOpenllet |\n| Rule-engine style inference | OWL 2 RL | Restricted existential patterns in subclass axioms | Rule engines \u002F RL-compatible reasoners |\n\nDefault to OWL 2 DL unless there is a clear scalability or deployment reason\nto choose a restricted profile.\n\n### Step 2: Create Ontology Header\n\nEvery new ontology needs a Turtle header with metadata:\n\n```turtle\n@prefix rdf: \u003Chttp:\u002F\u002Fwww.w3.org\u002F1999\u002F02\u002F22-rdf-syntax-ns#> .\n@prefix rdfs: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2000\u002F01\u002Frdf-schema#> .\n@prefix owl: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2002\u002F07\u002Fowl#> .\n@prefix xsd: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2001\u002FXMLSchema#> .\n@prefix skos: \u003Chttp:\u002F\u002Fwww.w3.org\u002F2004\u002F02\u002Fskos\u002Fcore#> .\n@prefix dcterms: \u003Chttp:\u002F\u002Fpurl.org\u002Fdc\u002Fterms\u002F> .\n@prefix prov: \u003Chttp:\u002F\u002Fwww.w3.org\u002Fns\u002Fprov#> .\n\n\u003Chttp:\u002F\u002Fexample.org\u002Fontology> a owl:Ontology ;\n    owl:versionIRI \u003Chttp:\u002F\u002Fexample.org\u002Fontology\u002F2024-01-01> ;\n    owl:versionInfo \"2024-01-01\" ;\n    dcterms:title \"Example Ontology\"@en ;\n    dcterms:description \"Purpose and scope\"@en ;\n    dcterms:creator \"Ontology Team\" ;\n    dcterms:created \"2024-01-01\"^^xsd:date ;\n    dcterms:rights \"Copyright holder or organization\" ;\n    dcterms:license \u003Chttps:\u002F\u002Fcreativecommons.org\u002Flicenses\u002Fby\u002F4.0\u002F> ;\n    prov:wasAttributedTo \u003Chttps:\u002F\u002Forcid.org\u002F0000-0000-0000-0000> ;\n    prov:generatedAtTime \"2024-01-01T00:00:00Z\"^^xsd:dateTime .\n```\n\nMetadata consistency rule:\n- Use one coherent annotation vocabulary strategy across ontology header,\n  classes, and properties.\n- Required minimum for terms is defined in `_shared\u002Fnaming-conventions.md`;\n  use the same conventions in generated templates and KGCL patches.\n- Include PROV-O fields when provenance tracking is required by the project.\n\n### Step 3: Bulk Term Creation via ROBOT Template\n\nFor adding >5 terms from the glossary, generate a ROBOT template TSV:\n\n```tsv\nID\tLABEL\tSC %\tDEFINITION\tDEFINITION SOURCE\nID\tA rdfs:label\tSC %\tA obo:IAO_0000115\tA obo:IAO_0000119\nEX:0001\tpiano\tEX:0000\tA keyboard instrument that produces sound by striking strings\tglossary\nEX:0002\tviolin\tEX:0000\tA string instrument played with a bow\tglossary\n```\n\nExecute:\n\n```bash\nrobot template --template instruments-template.tsv \\\n  --input ontology.ttl \\\n  --output ontology.ttl\n```\n\n### ROBOT Template Pitfalls\n\nThese issues are learned through experience and not well-documented:\n\n- **Column header syntax is fragile**: The second row defines semantics\n  (e.g., `SC %`, `A rdfs:label`). A typo or extra space causes silent\n  failures, not errors. Double-check headers before running.\n- **The `%` placeholder in expressions**: `SC 'has part' some %` must have\n  exact quoting and spacing. This is where most template errors occur.\n- **Merge vs replace**: `--merge-before` and `--merge-after` control whether\n  template output merges with the input or replaces it. Getting this wrong\n  can delete your entire ontology. Default behavior is merge.\n- **IRI resolution**: Template values must be full IRIs or CURIEs that\n  resolve via the ontology's prefix declarations. Undeclared prefixes\n  produce blank or invalid output with no error.\n- **Multi-value columns**: To put multiple superclasses or annotations on\n  one term, use `SPLIT=|` in the column header. Not obvious from docs.\n- **Empty cells skip silently**: Empty cells in required columns skip the\n  row rather than raising an error. Terms can be partially created (label\n  but no definition).\n- **Language tags**: Use `A rdfs:label@en` to add a language tag. Without\n  it, labels are untagged string literals, causing issues with tools that\n  filter by language.\n\n**Pre-flight check**: Before running `robot template`, verify that all column\nheaders parse correctly and all CURIEs resolve against declared prefixes.\n\n### Step 4: Individual Changes via KGCL\n\nFor single additions, modifications, or reparenting. **Important**: For\nchanges to shared ontologies, write KGCL commands to a `.kgcl` file and\npresent for review BEFORE applying (Safety Rule #5).\n\n```bash\n# Add a class\nuv run runoak -i ontology.ttl apply \"create class EX:0001 'piano'\"\n\n# Add subclass relationship\nuv run runoak -i ontology.ttl apply \"create edge EX:0001 rdfs:subClassOf EX:0000\"\n\n# Add definition\nuv run runoak -i ontology.ttl apply \"create definition 'A keyboard instrument that produces sound by striking strings' for EX:0001\"\n\n# Rename\nuv run runoak -i ontology.ttl apply \"rename EX:0001 from 'Old Name' to 'New Name'\"\n\n# Batch changes from file\nuv run runoak -i ontology.ttl apply --changes-input changes.kgcl\n```\n\n### Step 5: Complex Axioms via OWLAPY or rdflib\n\nWhen ROBOT templates and KGCL cannot express the needed axiom (qualified\ncardinality, role chains, nested class expressions).\n\n**Tool choice**: Most OBO community practitioners use **rdflib** for\nprogrammatic OWL work in Python (triple-level manipulation). **OWLAPY**\nprovides a higher-level OWL API but has a smaller community and requires\na JVM. Use whichever fits your team's stack — examples of both follow.\n\nOWLAPY example:\n\n```python\nfrom owlapy.model import (\n    OWLClass, OWLObjectProperty,\n    OWLSubClassOfAxiom, OWLObjectSomeValuesFrom,\n    OWLObjectAllValuesFrom, OWLObjectIntersectionOf,\n)\nfrom owlapy.model import IRI\nfrom owlapy.owlready2 import OWLOntologyManager_Owlready2\n\nmanager = OWLOntologyManager_Owlready2()\nonto = manager.load_ontology(IRI.create(\"file:\u002F\u002F\u002Fpath\u002Fto\u002Fontology.owl\"))\n\n# Example: StringInstrument EquivalentTo Instrument and hasComponent some String\ninstrument = OWLClass(IRI.create(\"http:\u002F\u002Fex.org\u002F#Instrument\"))\nstring_cls = OWLClass(IRI.create(\"http:\u002F\u002Fex.org\u002F#String\"))\nhas_comp = OWLObjectProperty(IRI.create(\"http:\u002F\u002Fex.org\u002F#hasComponent\"))\n\nrestriction = OWLObjectSomeValuesFrom(has_comp, string_cls)\nintersection = OWLObjectIntersectionOf([instrument, restriction])\n# ... add as equivalent class axiom\n\nmanager.save_ontology(onto, IRI.create(\"file:\u002F\u002F\u002Fpath\u002Fto\u002Fontology.owl\"))\n```\n\nrdflib alternative (no JVM required):\n\n```python\nfrom rdflib import Graph, Namespace, OWL, RDF, RDFS, URIRef, BNode\nfrom rdflib.collection import Collection\n\ng = Graph()\ng.parse(\"ontology.ttl\", format=\"turtle\")\n\nEX = Namespace(\"http:\u002F\u002Fexample.org\u002F\")\n\n# Add existential restriction: StringInstrument SubClassOf hasComponent some String\nrestriction = BNode()\ng.add((restriction, RDF.type, OWL.Restriction))\ng.add((restriction, OWL.onProperty, EX.hasComponent))\ng.add((restriction, OWL.someValuesFrom, EX.String))\ng.add((EX.StringInstrument, RDFS.subClassOf, restriction))\n\ng.serialize(\"ontology.ttl\", format=\"turtle\")\n```\n\n### Step 5.5: Individual Management\n\nHandle individuals as A-box content with explicit module boundaries:\n\n- Reference individuals (for example country codes, fixed enumerations) belong\n  in a dedicated reference-individuals module.\n- Test individuals belong in a separate test ontology\u002Fmodule.\n- Production individuals belong in a knowledge graph dataset, not in the core\n  ontology schema file.\n- If reference individuals exceed about 50, split into a separate file and\n  import it explicitly.\n\n### Step 6: Schema-First via LinkML (for data model schemas)\n\nLinkML excels at defining data schemas that generate multiple artifact types.\nUse it when the primary deliverable is a **data model** (JSON Schema, SHACL,\nPython dataclasses) rather than a **rich OWL ontology**.\n\n**Best for**: ABox validation schemas, data exchange formats, projects where\ndomain experts review YAML rather than OWL.\n\n**Not ideal for**: Rich TBox ontologies with complex axioms (qualified\ncardinality, role chains, nested class expressions). LinkML-generated OWL\nis relatively flat and typically needs enrichment with ROBOT or OWLAPY.\n\nWhen starting from scratch with a schema-first approach:\n\n```yaml\nid: https:\u002F\u002Fexample.org\u002Fmusic-ontology\nname: music-ontology\nprefixes:\n  linkml: https:\u002F\u002Fw3id.org\u002Flinkml\u002F\n  music: https:\u002F\u002Fexample.org\u002Fmusic-ontology\u002F\n\nclasses:\n  Instrument:\n    description: A device used to produce music\n    attributes:\n      name:\n        range: string\n        required: true\n      instrument_family:\n        range: InstrumentFamily\n```\n\nGenerate artifacts:\n\n```bash\nuv run gen-owl schema.yaml > ontology.owl\nuv run gen-shacl schema.yaml > shapes.ttl\nuv run gen-python schema.yaml > models.py\n```\n\n### Step 7: Verify (after structural changes)\n\nReasoning strategy depends on context:\n\n| Context | Reasoner | Frequency | Time Budget |\n|---------|----------|-----------|-------------|\n| Active development | ELK | After each batch of changes | Seconds (10K classes) |\n| Pre-commit \u002F CI | ELK | Every commit | \u003C 2 minutes |\n| Pre-release validation | HermiT or Pellet | Before each release | Minutes to hours |\n\n**Important**: ELK only supports OWL 2 EL. If your ontology uses qualified\ncardinality, universal restrictions, or class complements, ELK will silently\nignore those axioms. Run HermiT at least before releases to catch what ELK\nmisses.\n\n```bash\n# Fast classification (ELK — use during development and CI)\nrobot reason --reasoner ELK --input ontology.ttl --output classified.ttl\n\n# Full DL classification (HermiT — use pre-release)\nrobot reason --reasoner HermiT --input ontology.ttl --output classified.ttl\n\n# Quality report\nrobot report --input ontology.ttl --fail-on ERROR --output report.tsv\n\n# SHACL validation (if shapes exist)\nuv run pyshacl -s shapes\u002Fontology-shapes.ttl -i rdfs ontology.ttl -f human\n```\n\n**Materialization decision**: The ODK default is to include inferred axioms\nin the release file (`robot reason --output`). If consumers will reason\nindependently, ship asserted-only and document this in the release notes.\n\n## Tool Commands\n\n### ODK Awareness\n\nIf the project uses the Ontology Development Kit (ODK), understand these\nconventions:\n\n- **Edit file**: Work in `src\u002Fontology\u002F{name}-edit.owl` — never touch\n  release artifacts directly\n- **Makefile pipeline**: `sh run.sh make` runs the full build (merge,\n  reason, report, release) reproducibly via Docker\n- **Import management**: `src\u002Fontology\u002Fimports\u002F{source}_terms.txt` lists\n  imported IRIs; `make refresh-imports` regenerates `*_import.owl` modules\n- **DOSDP patterns**: YAML pattern files generate OWL from TSV data — more\n  structured than raw ROBOT templates for pattern-based term creation\n- **Release**: `make prepare_release` produces multi-format release artifacts\n\nWhen working in a non-ODK project, the ROBOT commands below apply directly.\n\n### ROBOT operations\n\n```bash\n# Merge imports\nrobot merge --input edit-ontology.ttl --input imports\u002F*.owl --output merged.ttl\n\n# Convert formats\nrobot convert --input ontology.ttl --output ontology.owl\nrobot convert --input ontology.ttl --output ontology.json --format json-ld\n\n# Annotate with version\nrobot annotate --input ontology.ttl \\\n  --annotation owl:versionInfo \"$(date +%Y-%m-%d)\" \\\n  --output ontology.ttl\n```\n\n### oaklib operations\n\n```bash\n# Search before creating (always!)\nuv run runoak -i sqlite:obo:bfo search \"material entity\"\n\n# Get term info\nuv run runoak -i ontology.ttl info EX:0001\n\n# Visualize hierarchy\nuv run runoak -i ontology.ttl tree --root EX:0000\n```\n\n## Outputs\n\nThis skill produces:\n\n| Artifact | Location | Format | Description |\n|----------|----------|--------|-------------|\n| Main ontology | `ontologies\u002F{name}\u002F{name}.ttl` | Turtle | The formalized OWL 2 ontology |\n| SHACL shapes | `ontologies\u002F{name}\u002Fshapes\u002F{name}-shapes.ttl` | Turtle | Structural validation shapes |\n| ROBOT templates | `ontologies\u002F{name}\u002F{name}-template.tsv` | TSV | Templates used for term creation |\n| KGCL patches | `ontologies\u002F{name}\u002F{name}-changes.kgcl` | KGCL | Applied change log |\n| Quality report | `ontologies\u002F{name}\u002F{name}-report.tsv` | TSV | Latest ROBOT report |\n| Reference individuals (optional) | `ontologies\u002F{name}\u002F{name}-reference-individuals.ttl` | Turtle | A-box reference instances kept separate from schema |\n\n## Handoff\n\n**Receives from**:\n- `ontology-conceptualizer` — `ontologies\u002F{name}\u002Fdocs\u002Fglossary.csv`,\n  `ontologies\u002F{name}\u002Fdocs\u002Fconceptual-model.yaml`, `ontologies\u002F{name}\u002Fdocs\u002Fbfo-alignment.md`,\n  `ontologies\u002F{name}\u002Fdocs\u002Fproperty-design.yaml`, `ontologies\u002F{name}\u002Fdocs\u002Faxiom-plan.yaml`,\n  plus the auditor's `work\u002Fdispositions.index.yaml` carried forward unchanged\n  (the unresolved\u002Fdeferred remainder — never dropped at any handoff)\n- `ontology-requirements` (indirect, via pipeline) — `ontologies\u002F{name}\u002Ftests\u002F*.sparql`,\n  `ontologies\u002F{name}\u002Ftests\u002Fcq-test-manifest.yaml` (CQ test suite to forward to validator)\n\n**Passes to**: `ontology-validator` — `ontologies\u002F{name}\u002F{name}.ttl`,\n`ontologies\u002F{name}\u002Fshapes\u002F{name}-shapes.ttl`, `ontologies\u002F{name}\u002Ftests\u002F*.sparql`,\n`ontologies\u002F{name}\u002Ftests\u002Fcq-test-manifest.yaml`,\nplus `work\u002Fdispositions.index.yaml` (carried forward unchanged)\n\n**Handoff checklist**:\n- [ ] Ontology passes `robot reason` with zero unsatisfiable classes\n- [ ] Ontology passes `robot report` with zero ERRORs\n- [ ] All glossary terms are present in the ontology\n- [ ] All axiom plan entries have been implemented\n- [ ] SHACL shapes exist for core structural constraints\n\n## Anti-Patterns to Avoid\n\n- **Hand-editing Turtle**: Never manually edit `.ttl` files. Use ROBOT,\n  oaklib, or Python tools. (Safety Rule #1)\n- **Skipping the reasoner**: Always run `robot reason` after structural\n  changes. (Safety Rule #2)\n- **Deleting terms**: Never delete — deprecate with `owl:deprecated true`.\n  (Safety Rule #4)\n- **Over-engineering tools**: Don't use OWLAPY for simple SubClassOf. Use\n  ROBOT template or KGCL instead. (See tool decision tree)\n- **Missing metadata**: Every class needs `rdfs:label` and `skos:definition`\n  at minimum.\n- **Skipping read-before-modify**: Always read the existing ontology file\n  before making changes. (Safety Rule #9)\n- **No backup before bulk**: Create a checkpoint before running ROBOT\n  template or batch KGCL application. (Safety Rule #10)\n\n## Error Handling\n\n| Error | Likely Cause | Recovery |\n|-------|-------------|----------|\n| Reasoner reports INCONSISTENT | Conflicting axioms (often disjointness + subclass) | Parse explanation, identify conflicting axioms, propose minimal fix |\n| Unsatisfiable classes found | Over-constrained class (contradictory restrictions) | List unsatisfiable classes, trace disjointness axioms |\n| ROBOT template fails | Column headers don't match expected format | Check ROBOT template documentation for column syntax |\n| KGCL apply fails | Term not found or invalid KGCL syntax | Verify term exists with `runoak info`; check KGCL grammar |\n| OWLAPY JVM bridge error | Java not installed or JVM not found | Ensure JDK is installed and JAVA_HOME is set |\n",{"name":5,"description":7},"main","467b9e7e2ed4a0696bb52a7c883c388282061610",".claude\u002Fskills\u002Fontology-architect",14,"https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect","https:\u002F\u002Fwww.oip.law","https:\u002F\u002Fgithub.com\u002Fbeep-effect","2026-11-14 03:18:53",{"source":8,"skillName":5,"commands":43,"prompt":53,"zipAvailable":54},[44,47,50],{"tool":45,"command":46},"npx","npx skills add beep-effect\u002Fbeep-effect --skill ontology-architect",{"tool":48,"command":49},"bunx","bunx skills add beep-effect\u002Fbeep-effect --skill ontology-architect",{"tool":51,"command":52},"pnpm","pnpm dlx skills add beep-effect\u002Fbeep-effect --skill ontology-architect","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fontology-architect\u002FSKILL.md",true,[56],{"path":57,"resourceType":58,"resourceTypeDesc":59,"sizeBytes":60,"sourceHtmlUrl":61},"references\u002Fforensics-triage.md","REFERENCE","参考文档",274,"https:\u002F\u002Fgithub.com\u002Fboisenoise\u002Fskills-collections\u002Fblob\u002Fmain\u002Fskills\u002Fantigravity-digital-forensics\u002Freferences\u002Fforensics-triage.md",[63,89,100,110,147,172],{"skillNo":64,"name":65,"nameZh":6,"description":66,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":67,"categories":68,"keywords":69,"publishedAt":29},"01M714DQT4JQHZ11X0RH0T8RQ7","auth-environments","Sign Claude Code in to a chosen Claude subscription on every linked T3 fleet host (grok-bot, beep-worker, dankserver, tbk-worker, tom-pc-1-wsl). Use when a Claude account hits its weekly limit, when `bun run beep accounts` shows the fleet's account used up, or on `\u002Fauth-environments`. Opens each host's OAuth page and a masked KDE code dialog together and verifies the admitted account.","https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002F.claude\u002Fskills\u002Fauth-environments\u002FSKILL.md",[],[70,71,72,73,74,75,76,77,78,79,80,81,82,83,84,85,86,87,88,28],"auth","environments","auth environments","path","limit","page","python","canonical","dialog","fleet","run","active","weekly","bot","workstation","up","worker","host","code",{"skillNo":90,"name":91,"nameZh":6,"description":92,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":93,"categories":94,"keywords":95,"publishedAt":29},"01M6C0RK94T5QGSZ0K9TA5Q2EF","shadcn","Fixture for immutable shadcn skill provenance.","https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002Fpackages\u002Ftooling\u002Ftool\u002Fcli\u002Ftest\u002Ffixtures\u002Fskills-provenance\u002Fshadcn\u002Fupstream\u002FSKILL.md",[],[91,96,97,98,99],"immutable","provenance","fixture","for",{"skillNo":101,"name":102,"nameZh":6,"description":6,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":103,"categories":104,"keywords":105,"publishedAt":29},"01M6C0RGPWMYM5KS62ZZPNAZ0W","qa-inventory-judge","https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002Fpackages\u002Ftooling\u002Ftool\u002Fcli\u002Fskills\u002Fqa-inventory-judge\u002FSKILL.md",[],[106,107,108,109],"inventory","qa","qa inventory judge","judge",{"skillNo":111,"name":112,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":114,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":122,"publishedAt":29},"01M6C0RDVR0A6W6ZJCJMEYJT77","practice-onboarding","Set up a lawyer's computer for their practice through the practice gateway. Use when the lawyer asks to get set up, to connect their documents, mail, calendar or practice tools, or when the practice gateway reports that setup is incomplete. Interviews the lawyer one question at a time, saves a practice profile, then checks and repairs the computer until setup is complete.","MIT","https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002Fapps\u002Fpractice-gateway\u002Fplugin\u002Fskills\u002Fpractice-onboarding\u002FSKILL.md",[117],{"categoryNo":118,"categoryName":119,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[123,124,125,126,127,128,129,130,28,85,131,132,133,134,135,136,137,138,139,140,88,141,142,143,144,145,146],"onboarding","practice onboarding","at","guide","interviews","calendar","mail","reports","time","get","save","question","profile","Tools","setup","beep","status","desktop","documents","connect","computer","windows","gateway","SET",{"skillNo":148,"name":149,"nameZh":6,"description":150,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":151,"categories":152,"keywords":156,"publishedAt":29},"01M6C0RB09NRJN0E1W3ND9HDE6","triage-nda","Screen NDAs before inventor disclosures or client pitches at Oppold IP Law. Flag disclosure, residuals, marking, term, and hidden IP rights for attorney review.","https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002Fapps\u002Fpractice-claude-mod\u002Fskills\u002Ftriage-nda\u002FSKILL.md",[153],{"categoryNo":154,"categoryName":155,"taxonomyType":120,"taxonomyTypeDesc":121},"01JBSEEDCAT000000000000037","律师与法务",[157,158,159,160,161,162,163,164,165,166,125,167,168,169,170,171,99],"nda","triage","triage nda","2026","screen","ip","plugins","work","review","knowledge","knowledge-work","legal","client","hidden","rights",{"skillNo":173,"name":174,"nameZh":6,"description":175,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":176,"categories":177,"keywords":179,"publishedAt":29},"01M6C0R8B5D35H50QY426AYR39","review-contract","Review IP agreements for Oppold IP Law. Use for assignments, licenses, inventor agreements, joint development, or NDAs involving inventions. Prepare cited issues and proposed revisions for attorney review.","https:\u002F\u002Fgithub.com\u002Fbeep-effect\u002Fbeep-effect\u002Fblob\u002Fmain\u002Fapps\u002Fpractice-claude-mod\u002Fskills\u002Freview-contract\u002FSKILL.md",[178],{"categoryNo":154,"categoryName":155,"taxonomyType":120,"taxonomyTypeDesc":121},[165,180,181,160,167,168,24,162,99,182,163,164,166,183,22],"review contract","contract","prepare","issues"]