Use this skill when planning to create new ontology terms or modify existing ones to ensure proper design pattern compliance. This skill should be used proactively during issue planning to identify appropriate design patterns before term creation begins. No intersection_of tags should be added without using this skill.
Scanned 9/12/2026
Install to Claude Code
npx -y skills add geneontology/go-ontology --skill design-pattern --agent claude-codeInstalls into .claude/skills of the current project.
Are you the author of Design Pattern?
Add the live security badge to your README — it updates automatically with every re-scan.
[](https://www.skillsdirectory.com/skills/geneontology-design-pattern)More formats (shields.io, HTML) on the badges page.
---
name: design-pattern
description: Use this skill when planning to create new ontology terms or modify existing ones to ensure proper design pattern compliance. This skill should be used proactively during issue planning to identify appropriate design patterns before term creation begins. No intersection_of tags should be added without using this skill.
---
Design Patterns (DPs) are designed to ensure that labels, text definitions (def tags), logical definitions (intersection_of tags) are consistent *within* a term, and *across* terms. i.e. a term "X development" uses "X" in the label, definition, and logical definition (but prioritizing human readability over robotic conformance); and that "X development" terms look similar in form to "X development" terms.
Design patterns are documented here, using the DOSDP system:
`src/patterns/*.yaml`
This skill should provide documentation in the form of a DESIGN_PATTERNS.md doc (not committed) that document relevant DPs for the task at hand.
DP documentation may be incomplete or out of date, so always check for similar terms / precedent using `obo-grep.pl`.
Side Note: CHEBI has particular rules. Always use the /chemical-entity skill for anything involving chemical entities.
## Example: cell fate commitment
Consider this GO term:
```obo
id: GO:0001710
name: mesodermal cell fate commitment
namespace: biological_process
def: "The cell differentiation process that results in commitment of a cell to become part of the mesoderm." [GOC:go_curators, ISBN:0878932437]
synonym: "mesoderm cell fate commitment" EXACT []
is_a: GO:0060795 ! cell fate commitment involved in formation of primary germ layer
intersection_of: GO:0045165 ! cell fate commitment
intersection_of: results_in_commitment_to CL:0000222 ! mesodermal cell
relationship: part_of GO:0048333 ! mesodermal cell differentiation
```
This corresponds to this DP: `src/design_patterns/cell_fate_commitment.yaml`, which defines a variable 'target' that must be a type of cell:
```
vars:
target: "'cell'"
classes:
cell: "CL:0000000" # Should ensure plant cells are subclasses
```
It also defines lexical patterns:
```
name:
text: "%s cell fate commitment"
```
=> the `name` tag is consistent with this
```
def:
text: "The process involved in the commitment of %s cell identity."
```
=> the GO definition varies a little from this but is still essentially consistent
And a logical definition pattern:
```
equivalentTo:
text: "'cell fate commitment' and 'results in commitment of' some %s"
vars:
- target
```
The OWL expression `equivalentTo G and R some D` maps to
```
intersection_of: G
intersection_of: R D
```
## General guidelines
You should not add logical definitions unless the term truly corresponds to a DP (or if a user really wants you to). A common anti-pattern is over-specifying logical definition (intersection_of), not realizing these are necessary *and sufficient* conditions. If in doubt, it is better to specify necessary only (is_a and intersection_of).
## Inference of is_a
When intersection_of is specified, it's generally not necessary to specify an is_a parent because this can be inferred.
This can be checked via:
`cd src/ontology && robot reason -i go-edit.obo -o go-edit.entailed.obo` and checking the is_a parent
## Creation of DESIGN_PATTERNS.md doc
The output of this skill can be a document DESIGN_PATTERNS.md that lists and gives examples from the DP docs and existing ontology precedent, this doc will be used to guide term creation and updates, and to provide justification.
Note this document is temporary, it should not be committed, and do not waste time documenting DPs in *general*, this doc is for specifyng relevant DPs to the *task in hand*
Is this your skill, or is something wrong with this listing? Request removal or report an issue. Author removals are honored within 72 hours.
No comments yet. Be the first to comment!