domain-modeling

Build and maintain project glossaries and architecture decision records during design discussions.

Updated Sep 11, 2026
One-click install
npx skills add https://github.com/CYRUS-pinto/pi-bot --skill domain-modeling-cyrus-pinto
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/CYRUS-pinto/pi-bot/tree/main/.agents/skills/domain-modeling
Command: npx skills add https://github.com/CYRUS-pinto/pi-bot --skill domain-modeling-cyrus-pinto

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Domain terminology drifts and design decisions get forgotten as a codebase evolves, leaving future readers guessing why things were built a certain way. This Skill actively sharpens a project's domain model during design conversations by challenging vague terms, cross-checking claims against code, and recording glossaries and decisions the moment they crystallize. ## Core Features & Use Cases - Glossary management: Creates and updates CONTEXT.md files with opinionated, tightly-defined domain terms, including explicit "avoid" lists for ambiguous synonyms. - Architecture Decision Records: Writes lightweight ADRs in docs/adr/ with sequential numbering, but only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Multi-context support: Handles both single-context repos (one root CONTEXT.md) and multi-context repos via a CONTEXT-MAP.md that maps bounded contexts and their relationships. - Use Case: While discussing a billing feature, the user says "account" loosely; the Skill asks whether they mean Customer or User, updates CONTEXT.md with the resolved term, and offers an ADR when the team decides Billing communicates with Ordering via domain events instead of synchronous HTTP. ## Quick Start Help me sharpen the domain language for our ordering system and record any significant architectural decisions we make along the way.

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 domain glossary for my codebase?

Create a CONTEXT.md file at the repo root listing each domain term with a one-to-two sentence definition and an "Avoid" line for rejected synonyms. Keep it free of implementation details; it is a glossary only, not a spec or scratch pad.

When should I write an architecture decision record?

Write an ADR only when all three conditions hold: the decision is hard to reverse, it would surprise a future reader without context, and it resulted from a genuine trade-off between alternatives. Easy-to-reverse or obvious decisions should be skipped.

How do I handle multiple bounded contexts in one repository?

Create a CONTEXT-MAP.md at the repo root listing each context, where its CONTEXT.md lives, and how contexts relate to each other, such as event flows or shared types. Each context then keeps its own glossary and context-specific ADRs.

What format should an ADR follow?

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. The minimal template is a title plus one to three sentences covering context, decision, and rationale; optional sections like Status or Considered Options are added only when they add genuine value.

What are the limitations of a CONTEXT.md glossary?

CONTEXT.md is strictly a glossary and must not contain implementation details, specs, or design rationale. General programming concepts like timeouts or error types do not belong; only terms specific to the project's domain qualify.