pocock-domain-modeling

Build and maintain project domain glossaries and architectural decision records in Markdown.

Updated Dec 18, 2025
One-click install
npx skills add https://github.com/l0lxl0lw/dotfiles --skill pocock-domain-modeling-l0lxl0lw
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: pocock-domain-modeling
Source: https://github.com/l0lxl0lw/dotfiles/tree/main/ai/shared/skills/mattpocock/pocock-domain-modeling
Command: npx skills add https://github.com/l0lxl0lw/dotfiles --skill pocock-domain-modeling-l0lxl0lw

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 resolutions in CONTEXT.md glossaries and ADR files. ## Core Features & Use Cases - Ubiquitous language management: Maintains CONTEXT.md glossaries with canonical terms and explicitly avoided synonyms, updated inline the moment a term is resolved. - Architectural decision records: Creates numbered ADRs in docs/adr/ 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 designing a billing feature, the user says "account" ambiguously; the Skill challenges the term, resolves it to Customer versus User, updates CONTEXT.md immediately, and offers an ADR when the team picks event-based communication between Ordering and Billing. ## Quick Start Help me pin down the domain terminology for our ordering and billing flow and record any significant architectural decisions we make along the way.

Frequently Asked Questions about pocock-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 canonical domain terms with one-to-two sentence definitions and avoided synonyms. Update it inline whenever a term is resolved during design discussions, keeping it free of implementation details.

When should I write an architectural 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?

Create a CONTEXT-MAP.md at the repo root listing each context, its location, and how contexts relate to each other. Each context then gets its own CONTEXT.md and context-specific docs/adr directory for local decisions.

What format should an ADR follow?

ADRs live in docs/adr/ with sequential numbering like 0001-slug.md. The minimal format 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 belongs in CONTEXT.md versus implementation documentation?

CONTEXT.md is a glossary only: domain-specific terms with tight definitions and avoided synonyms. It must not contain implementation details, specs, or general programming concepts like timeouts or error types.