Build and maintain project domain glossaries and architectural decision records.
npx skills add https://github.com/mmnavarr/harness --skill domain-modeling-mmnavarr
Please help me install this Agent Skill. Skill: domain-modeling Source: https://github.com/mmnavarr/harness/tree/main/skills/domain-modeling Command: npx skills add https://github.com/mmnavarr/harness --skill domain-modeling-mmnavarr
CONTEXT.md glossary with opinionated canonical terms and explicit "avoid" lists, updated inline as terms are resolved. - Architectural Decision Records: Creates 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 linking per-context glossaries and ADRs. - Use Case: While designing an ordering system, the 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 decides Billing and Ordering will communicate via domain events instead of synchronous HTTP. ## 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 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, and keep it free of implementation details.
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. Skip ADRs for easily reversed or obvious decisions.
Place a CONTEXT-MAP.md at the repo root listing each context, its location, and its relationships with other contexts. Each context then gets its own CONTEXT.md glossary and context-specific docs/adr/ directory, while system-wide decisions stay in the root docs/adr/.
CONTEXT.md is purely a glossary of domain terms and their canonical definitions, with no implementation details. An ADR records a specific architectural decision and its rationale, capturing why a trade-off was made rather than defining vocabulary.
Skip the ADR if the decision is easy to reverse, unsurprising to a future reader, or had no real alternatives. Recording obvious or reversible choices adds noise without preserving useful context.
redpanda-dataExtract domain terminology from conversations and propose a canonical glossary.
a35506322Stress-test project plans against domain documentation, codebase, and ADRs.
taiyousan15Guide Event Storming workshops and generate Markdown domain reports.
coreweaveApply tolerations to GKE system pods for the SUNK lock taint.