domain-modeling

Maintains project domain vocabulary in a glossary and records architectural decisions as ADRs.

Updated Aug 13, 2026
One-click install
npx skills add https://github.com/Evolutionary-Leadership/harness --skill domain-modeling-evolutionary-leadership
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-modeling
Source: https://github.com/Evolutionary-Leadership/harness/tree/main/.claude/skills/domain-modeling
Command: npx skills add https://github.com/Evolutionary-Leadership/harness --skill domain-modeling-evolutionary-leadership

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Teams lose shared understanding as projects grow: terms drift, decisions get forgotten, and code contradicts what stakeholders say. This Skill keeps the project's domain model sharp by capturing vocabulary and decisions the moment they crystallise during design conversations. ## Core Features & Use Cases - Glossary Maintenance: Challenges conflicting or fuzzy terminology and updates docs/GLOSSARY.md inline, moving replaced terms to a Deprecated table instead of deleting them. - Decision Recording: Applies a three-part test (hard to reverse, surprising without context, real trade-off) to decide when a decision deserves an ADR, then scaffolds it with /document adr. - Code Cross-Referencing: Checks whether stated domain behavior matches the actual code and surfaces contradictions. - Use Case: During a feature discussion, a user says "cancel the account." The Skill flags that the glossary distinguishes Customer from User, proposes a precise term, updates the glossary row, and offers an ADR when the cancellation policy decision settles. ## Quick Start Ask the assistant to help pin down the domain terminology for a new feature and record any architectural decisions that come out of the discussion.

Frequently Asked Questions about domain-modeling

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I maintain a domain glossary for my project?

Add one row per domain term to docs/GLOSSARY.md in that file's table format, pointing each term at its canonical home. Update rows inline as terms are resolved during discussions, and move replaced terms to a Deprecated table rather than deleting them.

When should I write an architecture decision record?

Write an ADR only when a decision is hard to reverse, surprising without context, and the result of a real trade-off. Easy-to-reverse or obvious decisions do not need one; the WHEN-TO-ADR.md reference lists qualifying cases like technology lock-in and subsystem boundaries.

How do I handle conflicting domain terminology in a team?

Call out the conflict immediately by comparing the user's usage against the existing glossary definition, then propose a precise canonical term. Once resolved, update the glossary row right away instead of batching changes.

Should decisions made during brainstorming become ADRs immediately?

No. During brainstorming, record decisions in the idea issue on the tracker, not as ADR files. The ADR ships later with the feature that implements the decision, written when the decision settles during feature work.

What terms belong in a project domain glossary?

Only concepts unique to the project's domain belong in the glossary. General programming concepts like timeouts, error types, or utility patterns should be excluded no matter how often the project uses them.