Build and maintain a project domain glossary and architectural decision records.
npx skills add https://github.com/nseng-ai/ns --skill domain-modeling-nseng-ai
Please help me install this Agent Skill. Skill: domain-modeling Source: https://github.com/nseng-ai/ns/tree/main/.agents/skills/domain-modeling Command: npx skills add https://github.com/nseng-ai/ns --skill domain-modeling-nseng-ai
CONTEXT.md glossary of canonical domain terms, challenges conflicting usage, and sharpens vague language into precise definitions. - Architectural Decision Records: Offers to write lightweight 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 linking per-context glossaries. - Use Case: While designing an ordering system, the user says "account" loosely; the Skill asks whether they mean Customer or User, records the resolved term in CONTEXT.md once implemented, and drafts an ADR when the team picks event-sourced writes over a CRUD model. ## Quick Start Ask the agent to help pin down the domain terminology for your project and record the decisions in CONTEXT.md and docs/adr as the design solidifies.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-to-two sentence definitions and an _Avoid_ line for rejected synonyms. Update it only when the corresponding code or ground truth changes, keeping glossary and implementation in sync.
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 ADR to avoid documentation noise.
Create a CONTEXT-MAP.md at the repo root listing each context, where it lives, and how contexts relate, then give each context its own CONTEXT.md. System-wide ADRs go in the root docs/adr, while context-specific decisions live in each context's own docs/adr folder.
No. CONTEXT.md is strictly a glossary of resolved domain terms and must stay free of implementation details, specs, and future plans. Record proposed vocabulary in plans or discussions, and update CONTEXT.md only alongside the code change that establishes the term.
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.
NzettodessChallenges plans against domain glossaries and updates CONTEXT.md and ADR documentation inline.
yash-gargResolve ambiguous domain terminology and record architectural decisions in CONTEXT.md and ADR formats.
babuallyChallenge proposed plans against codebase terminology and documented ADR decisions.
taiyousan15Guide Event Storming workshops and generate Markdown domain reports.