Maintains project glossaries and architectural decision records during domain design sessions.
npx skills add https://github.com/j172/bid --skill domain-modeling-j172
Please help me install this Agent Skill. Skill: domain-modeling Source: https://github.com/j172/bid/tree/main/agent/skills/domain-modeling Command: npx skills add https://github.com/j172/bid --skill domain-modeling-j172
CONTEXT.md glossary with opinionated canonical terms and explicit _Avoid_ lists, supporting single-context repos and multi-context setups via CONTEXT-MAP.md. - Architectural decision records: Creates sequentially numbered ADRs in docs/adr/ only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. - Live model challenging: Flags conflicts between user language and the existing glossary, cross-references claims against actual code, and updates files inline rather than batching. - Use Case: While designing an ordering system, a user says "account" ambiguously; the Skill asks whether they mean Customer or User, records the resolved term in CONTEXT.md, and offers an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Help me pin down the domain terminology for my ordering system and record any significant architectural decisions we make along the way.High-intent search queries and answers about installing and using this skill.
Create a CONTEXT.md file at the repo root listing canonical domain terms with one or two sentence definitions and an _Avoid_ list of rejected synonyms. Add terms inline as they are resolved during design discussions, keeping the file free of implementation details.
Write an ADR only when all three conditions hold: the decision is hard to reverse, it is surprising without context, and it resulted from a genuine trade-off between alternatives. If any condition is missing, skip the record to avoid noise.
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.
An ADR is a sequentially numbered Markdown file in docs/adr containing 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.
CONTEXT.md is a glossary only and must not contain implementation details, specs, or scratch notes. It should only include terms specific to the project's domain, not general programming concepts like timeouts or error types.
redpanda-dataExtract domain terminology from conversations and propose a canonical glossary.
100Thieves-teamDesign Bounded Contexts and Ubiquitous Language glossaries from subdomain classifications.
ethan-rioStress-test project plans against domain glossaries, ADRs, and codebase context.
JaviMontanoPlan and run collaborative discovery workshops with structured facilitation guides.