domain-modeler

Models business domains from prose, code, and tests before implementation begins.

2|Updated Jul 6, 2026
One-click install
npx skills add https://github.com/nguyenpv1980-wq/Project-Aegis --skill domain-modeler-nguyenpv1980-wq
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeler
Source: https://github.com/nguyenpv1980-wq/Project-Aegis/tree/main/.claude/skills/domain-modeler
Command: npx skills add https://github.com/nguyenpv1980-wq/Project-Aegis --skill domain-modeler-nguyenpv1980-wq

SYSTEM DOCUMENTATION & REQUIREMENTS

💡 This Skill includes references (resource) components.

What problem does it solve?

This Skill prevents costly implementation mistakes by turning vague requirements, conflicting terminology, and scattered code into an explicit business domain model before any schema or code is written.

Core Features & Use Cases

  • Ubiquitous Language Extraction: Identifies the business nouns and verbs already used in requirements, docs, code, and tests, then resolves naming collisions into a canonical vocabulary.
  • Domain Structure Mapping: Defines actors, workflows, subdomains, bounded contexts, entities, value objects, aggregates, domain services, domain events, and context relationships.
  • Decision Gatekeeping: Stops at a hard do-not-code-yet boundary and returns assumptions and open questions instead of silently implementing.
  • Use Case: When a new feature is described in prose and the team is unsure what the core entities or boundaries should be, this Skill produces a reviewable domain model that aligns everyone before build work begins.

Quick Start

Ask the skill to model the domain for your feature or system using the requirements, docs, and code you already have.

Frequently Asked Questions about domain-modeler

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

FAQPage Schema
How do I extract ubiquitous language from business requirements before coding?

Domain modeling extracts ubiquitous language by identifying business nouns and verbs from prose requirements, existing code, and tests, then resolves naming collisions into a canonical vocabulary before implementation begins.

What is the best way to define bounded contexts and aggregates from vague feature descriptions?

Defining bounded contexts and aggregates involves mapping domain structure from scattered requirements to explicitly identify actors, workflows, subdomains, entities, value objects, and context relationships before system design.

How do I model a business domain from existing code and tests?

You can model a business domain from existing code and tests by analyzing them to extract the ubiquitous language, workflows, and aggregates, clarifying terminology collisions to produce a reviewable domain model.

Can domain modeling help identify invariants and open questions during early system design?

Yes, domain modeling identifies invariants, assumptions, and open questions during early system design by enforcing a decision gatekeeping boundary that stops at a hard do-not-code-yet limit and returns open questions instead of silently implementing.

When should I not use domain modeling for feature discovery?

You should avoid domain modeling when your team needs immediate code implementation, because this approach enforces a no-code review gate, intentionally halting development to produce assumptions and open questions first.