Domain model
My personal Agent Skills for coding agents: engineering workflows plus a few personal-use tools. Personalized forks, with every upstream author credited.
npx -y skills add martonpaulo/skills --skill domain-modelAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 14 days oldThe repository was created 14 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Clarify ambiguous domain terminology, states, rules, entities, and relationships when code, documentation, or requested behavior use inconsistent or overloaded language.
SKILL.md
2.1 KB, as published. Nobody here has run it
Domain Model
Use this skill only when domain language or rules are ambiguous, contradictory, or consequential. Merely reading existing terminology does not require this skill.
Workflow
- Inspect repository guidance and existing glossaries, diagrams, decisions, code, tests, and public behavior relevant to the terms in question.
- Compare requested behavior and documentation with the actual code. Surface contradictions instead of silently choosing one source.
- Distinguish entities, value concepts, states, transitions, rules, ownership, and relationships only as far as the current ambiguity requires.
- Prefer precise existing project terminology. When a term is overloaded, propose a canonical meaning and identify the concepts that need separate names.
- Validate the model with concrete scenarios and edge cases.
- If durable glossary changes are useful, update the path configured by repository guidance or default to
CONTEXT.md.
Glossary boundary
Create no glossary for a codebase without meaningful domain language. When one is useful, follow CONTEXT-FORMAT.md and keep it limited to canonical vocabulary, rules, states, and relationships. Exclude implementation plans, task lists, temporary notes, and specifications.
Assume one context unless the repository already shows clear, meaningful context boundaries. Preserve its existing multi-context structure when present.
Consequential decisions
Create or propose an ADR only when a decision is difficult to reverse, surprising without context, and based on a real tradeoff. Follow repository conventions or ADR-FORMAT.md. Most terminology clarifications do not need an ADR.
Completion
The work is complete when the material ambiguity is resolved or explicitly remains open, contradictions are visible, and any durable edits contain only canonical domain knowledge.