domain-modeling

Build and maintain a project domain glossary and architectural decision records.

Updated Aug 2, 2026
One-click install
npx skills add https://github.com/mikalv/pi-extensions --skill domain-modeling-mikalv
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/mikalv/pi-extensions/tree/main/packages/pi-atelier/.agents/skills/domain-modeling
Command: npx skills add https://github.com/mikalv/pi-extensions --skill domain-modeling-mikalv

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and architectural decisions get forgotten, leaving future readers guessing why the code looks the way it does. This Skill actively sharpens a project's domain model during design sessions by challenging fuzzy terms, stress-testing concepts with concrete scenarios, and recording decisions the moment they crystallize. ## Core Features & Use Cases - Ubiquitous Language Management: Maintains a CONTEXT.md glossary with opinionated canonical terms and explicit _Avoid_ lists, supporting both single-context repos and multi-context setups via CONTEXT-MAP.md. - Active Terminology Challenge: Detects when your language conflicts with the existing glossary or the actual code, and surfaces the contradiction immediately. - Disciplined ADR Recording: Offers Architecture Decision Records in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Use Case: While designing a billing feature, you say "account" loosely; the Skill asks whether you mean Customer or User, updates CONTEXT.md with the resolved term, and records an ADR when you decide Billing communicates with Ordering via domain events instead of synchronous HTTP. ## Quick Start Ask the agent to help pin down the domain terminology for your project and record any significant architectural decisions as ADRs.

Frequently Asked Questions about domain-modeling

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

FAQPage Schema
How do I create a ubiquitous language glossary for my project?▼

Create a CONTEXT.md file at the repo root listing domain terms with one-to-two sentence definitions and an _Avoid_ list of rejected synonyms. Update it inline whenever a term is resolved during design discussions rather than batching changes.

When should I write an architecture decision record?▼

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a genuine trade-off between alternatives. If any of these three conditions is missing, skip the ADR to avoid documentation noise.

How do I handle multiple bounded contexts in one repository?▼

Place a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships, then give each context its own CONTEXT.md and docs/adr/ directory. System-wide decisions stay in the root docs/adr/ folder.

What belongs in a domain glossary versus a spec?▼

A glossary contains only definitions of domain-specific terms, never implementation details, general programming concepts, or design decisions. Implementation rationale belongs in ADRs, and general technical concepts should be excluded entirely.

What format should an ADR follow?▼

An ADR is a sequentially numbered Markdown file in docs/adr/ with a short title and one to three sentences covering context, decision, and rationale. Optional sections like Status, Considered Options, and Consequences are added only when they add genuine value.