Domain Modeling

Make the domain model precise enough that later specifications, interfaces, and tests can use the same concepts without silently choosing another meaning. Treat examples and edge cases as tests of the model, not as accepted requirements.

Authority and composition

Inspect authorized repository material and actively analyze the model in the conversation. Classify every changed term, rule, or boundary as established, proposed, or unresolved; mark it established only when repository authority or an authorized decision maker settles it.

• Read the existing domain document as a routine prerequisite when another skill only needs its vocabulary. That consumption alone does not invoke this skill.
• Use codebase-design for module interfaces and architectural seams. A domain boundary may constrain a module seam, but this skill does not design the module.
• Pass established behavior and domain decisions to to-spec. Do not turn a plausible scenario into a requirement merely because it makes the model cleaner.
• Use documenting-work before persisting a domain-model change. Let it resolve authority, path, identity, metadata, index, lifecycle, and write authorization; keep ownership of domain content here.
• Leave implementation to tdd, issue and tracker lifecycle to work-github-issue, and completed-change assessment to code-review.

A request to inspect, discuss, challenge, or draft is read-only: return proposed domain-model changes in the response and create no file. When the user or repository explicitly authorizes repository persistence, update only the destination and locally required index or reciprocal links selected by documenting-work, with destination fingerprint and dirty-worktree protection. Do not edit code, mutate a tracker, commit, push, publish, or delete an existing document from this skill.

Frame the model change