Build rigorous structural entity-relationship models for any domain using category theory, dependent types, and algebraic structures. Use this skill whenever the user asks to model a domain, formalize an entity relationship model, create a structural specification, describe a system's architecture mathematically, or analyze the structure of a codebase/project/system. Also trigger when the user mentions domain modeling, entity relationships, formalisms, structural invariants, schema design, or asks 'what are the entities and relationships in X'. Works from natural language descriptions (requirements docs, design specs, META files, READMEs, user stories) and produces a complete structural model with sorts, arrows, constructions, axioms, and morphisms. Even if the user doesn't mention category theory explicitly — if they want a precise structural description of a domain, use this skill.
Instalar com Codex ou Claude Copie este prompt, cole no Codex, Claude ou outro assistente e deixe que ele revise a página da skill e instale para você.
Um comando direto ignora o prompt de revisão. Verifique a origem antes de executá-lo.
Instruções da origem · Visualização somente leitura
name
structural-domain-modeling
description
Build rigorous structural entity-relationship models for any domain using category theory, dependent types, and algebraic structures. Use this skill whenever the user asks to model a domain, formalize an entity relationship model, create a structural specification, describe a system's architecture mathematically, or analyze the structure of a codebase/project/system. Also trigger when the user mentions domain modeling, entity relationships, formalisms, structural invariants, schema design, or asks 'what are the entities and relationships in X'. Works from natural language descriptions (requirements docs, design specs, META files, READMEs, user stories) and produces a complete structural model with sorts, arrows, constructions, axioms, and morphisms. Even if the user doesn't mention category theory explicitly — if they want a precise structural description of a domain, use this skill.
Structural Domain Modeling
Build complete structural entity-relationship models for any domain using a six-step procedure grounded in category theory, dependent types, and algebraic structures. The output is a formal specification of objects, morphisms, and axioms — no behavioral semantics.
When to read reference files
Before Step 3 (Apply Constructions): read references/construction-reference.md for the full menu of 14 constructions with signatures, selection guidance, natural morphisms, typical axioms, and examples.
After completing all steps: optionally read references/psi-worked-example.md for a complete worked example showing how the framework was applied to a real Clojure-based AI development environment.
The Six Primitives
Every structural domain model is composed of exactly six kinds of entity:
Extend if your domain requires additional forms (probabilistic, metric, etc.) — but keep the grammar explicit.
Common Axiom Patterns
Pattern
Form
Example
Immutability
Invariance(f(x), t₁, t₂)
"once assigned, never changes"
Non-interference
Independence(f(x), g(y))
"changing A doesn't affect B"
Coverage
SubsetOf(needed(x), available(y))
"all required resources present"
Totality
∀ x, Equation(f(x), defined)
"classification is total"
Involution
Equation(f ∘ g, id)
"include and exclude are inverses"
Commutativity
Equation(f ∘ g, g ∘ f)
"order doesn't matter"
Membership
Membership(active, nodes(forest))
"pointer is valid"
Uniqueness
Implication(Eq(f(x), f(y)), Eq(x, y))
"identifiers are unique"
Construction Quick-Reference
For each construction's full documentation (signature, when-to-use, morphisms, axioms, examples), read references/construction-reference.md. Here is the summary grouped by structural question:
Output: morphism catalogue with domain, codomain, and preserved construction.
Step 6: Check for 2-Cells
For parallel morphisms (same source and target), ask: is there a meaningful relationship?
2-Cells arise when there are multiple strategies for the same transformation, multiple extension paths to the same enriched type, or comparable migration strategies.
If none exist, state: "The model is a 1-category." That's fine.
Output: 2-Cells, or their explicit absence.
Assembling the Sketch
Steps 1–6 produce a sketch (in the sense of Ehresmann):
A model is a structure-preserving functor M : DomainSketch → Set. The running system is one such model. Migrations between models are natural transformations α : M₁ ⟹ M₂.
Level Structure
Every model sits in four levels:
Level 0 — Runtime: concrete instances
Level 1 — Domain Model: sorts, arrows, constructions, axioms, morphisms (Steps 1–6 output)
Level 2 — Doctrine: the six primitives, construction vocabulary, proposition grammar (this skill)
Level 3 — Foundation: set theory / type theory / categorical logic (ambient)
Downward functors (instantiate, classify, ground) are structure-preserving. Upward recovery does not exist — each level is a lossy compression of the one below.
Quality Checklist
After completing Steps 1–6, verify:
Check
Question
Fix
Sort completeness
Every domain noun → sort or arrow?
Add missing sorts
Arrow coverage
Every relationship captured?
Add missing arrows
Totality correctness
Partial/total correctly declared?
Adjust
Construction fit
Each construction matches the pattern?
Swap
Axiom grounding
Every axiom in the proposition grammar?
Extend grammar or reformulate
Axiom independence
No redundant axioms?
Remove
Morphism completeness
All natural transformations accounted for?
Add
Morphism preservation
preserves sets correct?
Correct
2-Cell check
Parallel morphisms related or independent?
Add or note absence
Sketch well-formedness
All cones/cocones match constructions?
Reconcile
Output Format
Produce a markdown document structured as follows. Adapt section count and depth to the domain's complexity.
# [Domain Name] — Structural Formalism## Sorts
E = { ... }
## Value Sorts
V = { String, UUID, Instant, Int, ... }
## Arrows
[name] : [Sort] → [Sort] -- total
[name] : [Sort] →? [Sort] -- partial
## Constructions
[Sort] is structured as [Construction]([args])
-- one subsection per construction applied, with the formal definition
## Axioms
A1 [Name]: [Proposition]
A2 [Name]: ...
## Morphisms
[name] : [source] → [target]
preserves: [constructions]
-- one subsection per morphism family
## 2-Cells
[name] : [Morphism₁] ⟹ [Morphism₂]
-- or: "The model is a 1-category."
## Appendix: Axiom Summary Table## Appendix: Construction Summary Table## Appendix: Morphism Catalogue
When writing each section, use the formal notation from this skill (arrows, constructions, propositions) alongside natural language explanation. The document should be readable by someone familiar with basic category theory, but accessible enough that the notation is always explained on first use.
