modelagem-dominio

Resolves ambiguous product terms and records canonical domain definitions, relations, and decisions.

Updated May 31, 2026
One-click install
npx skills add https://github.com/ithaloazevedo/pm-loadout --skill modelagem-dominio-ithaloazevedo
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: modelagem-dominio
Source: https://github.com/ithaloazevedo/pm-loadout/tree/main/.agents/skills/modelagem-dominio
Command: npx skills add https://github.com/ithaloazevedo/pm-loadout --skill modelagem-dominio-ithaloazevedo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Product teams accumulate ambiguous terminology, conflicting domain relationships, and undocumented structural decisions that cause misalignment. This Skill provides a disciplined process to resolve term ambiguity, update domain relations, and register hard-to-reverse decisions with canonical language. ## Core Features & Use Cases - Canonical Term Resolution: Detects vague, overlapping, or contradictory terms and proposes canonical definitions tested against concrete scenarios and boundary cases. - Domain Relation Updates: Proposes synchronized updates to relations documentation (Markdown and YAML) when domain relationships change. - Decision Logging: Registers structural decisions in a decisions directory only when they are hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: When a team debates whether "assinante" and "cliente" mean the same thing, use this Skill to define the canonical term, test it against edge cases, and propose its entry in the glossary. ## Quick Start Ask the assistant to resolve the ambiguity between two product terms and propose the canonical definition for the domain glossary.

Frequently Asked Questions about modelagem-dominio

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I resolve ambiguous product terminology in a team?▼

Identify the vague or contradictory term, propose a canonical definition in plain language, and test it against concrete scenarios including at least one boundary case. Once resolved, register the term in a shared glossary so the definition stays consistent.

What is a domain glossary and when should I create one?▼

A domain glossary holds canonical language and definitions for product terms. Create it when the first term genuinely deserves to be preserved, and keep it limited to language and definitions rather than specs or implementation history.

When should a product decision be recorded in a decision log?▼

Record a decision only when it is hard to reverse, surprising without context, and the result of a real trade-off. Routine or easily changed choices do not belong in the decision log.

Can domain relations be documented in both Markdown and YAML?▼

Yes, and they should be updated together to stay synchronized. Markdown serves human readers while YAML supports structured consumption, so a resolved or changed relation must be proposed in both formats at once.

What are the limitations of glossary-based domain modeling?▼

A glossary captures language and definitions but is not a spec or implementation history. It also should not record unconfirmed hypotheses, since entries must be backed by cited sources and confirmed evidence.