Skip to content
Agentmart
Submit a tool

domain-modeling

Use to actively build and sharpen a project's domain model — pin down terminology / ubiquitous language, resolve fuzzy or overloaded terms, and record the…

Skill by KSriki

IndexedMIT
Write a review

Install

Works with Claude Code, Claude apps, Codex, Cursor, Gemini CLI, GitHub Copilot, VS Code, OpenCode, Goose, Windsurf. Read the repository before you give any tool access to your data.

npx agentmarket install skill/ksriki-domain-modeling

Asks which of your tools to add it to (Claude Code, Codex, Cursor, VS Code, Windsurf, Gemini CLI, Claude Desktop) and shows the change first. See https://agentmart.dev/cli.

Get the weekly diff

The weekly diff: one email a week with new agent tools, notable updates and grade changes, plus security alerts for tools you follow. Double opt-in, one-click unsubscribe.

We use your email only for this newsletter. Privacy

About

Use to actively build and sharpen a project's domain model — pin down terminology / ubiquitous language, resolve fuzzy or overloaded terms, and record the occasional architectural decision (ADR) — writing the glossary down the moment a term crystallizes. Triggers on "what do we call this", "'account' — is that the Customer or the User?", "pin down the terminology", "record this decision / ADR", "update the glossary / CONTEXT.md". Do NOT use for a full design doc on a big, expensive-to-reverse decision (`write-design-doc`), for module interface design (`codebase-design`), or for product requirements (`write-a-prd`). This skill is the glossary + light ADRs.

Use cases: documents, design, writing

No reviews yet. Installed it? Reviews come from verified installers only. How reviews work

Permissions

What this skill can do and what it asks for, from its SKILL.md. Checked Oct 25, 2026.

Tools
No tools found
Secrets
None asked for
Install scripts
None found

Network hosts it talks to 1

  • codeload.github.com · found in install command

Files it touches

  • ~/.claude/skills/domain-modeling

What's inside

Skill name
domain-modeling
Description
Use to actively build and sharpen a project's domain model — pin down terminology / ubiquitous language, resolve fuzzy or overloaded terms, and record the occasional architectural decision (ADR) — writing the glossary down the moment a term crystallizes. Triggers on "what do we call this", "'account' — is that the Customer or the User?", "pin down the terminology", "record this decision / ADR", "update the glossary / CONTEXT.md". Do NOT use for a full design doc on a big, expensive-to-reverse decision (`write-design-doc`), for module interface design (`codebase-design`), or for product requirements (`write-a-prd`). This skill is the glossary + light ADRs.
License
MIT
Instructions
47 lines in SKILL.md · view on GitHub

Files (1)

  • SKILL.md

SKILL.md (first lines)

# Domain modeling: the glossary as you go

> Adapted from `mattpocock/skills` (MIT) — reimplemented in this repo's style.

## When to use this

While designing or discussing — the *active* discipline of challenging terms,
inventing edge cases, and **writing the glossary and decisions down as they
crystallize**. (Merely *reading* the glossary is a one-line habit, not this skill;
this skill is for *changing* the model.)

**Not this skill if:** it's a big irreversible design decision needing a full doc →
`write-design-doc`. It's a module interface → `codebase-design`. It's product
requirements → `write-a-prd`.

## Where it lives

- **Single context:** a root `CONTEXT.md` (the glossary) + ADRs under 〈`docs/adr/` or `docs/design/`〉, numbered `0001-…md`.
- **Multi-context (monorepo):** a root `CONTEXT-MAP.md` pointing to a per-context `CONTEXT.md` + context-scoped ADRs.
- **Create files lazily** — only when there's something to write.

## Procedure (during the session)

1. **Challenge against the glossary.** When a term conflicts with `CONTEXT.md`, call
   it out immediately.
2. **Sharpen fuzzy language.** Propose a precise canonical term for a vague or
   overloaded word — *"'account' — do we mean Customer or User?"*
3. **Discuss concrete scenarios.** Invent edge-case scenarios that force precise
   boundaries between concepts.
4. **Cross-reference with code.** Check whether the code agrees with the stated
   behavior; surface contradictions.
5. **Update `CONTEXT.md` inline** the moment a term resolves — don't batch.
   > **`CONTEXT.md` is a glossary and nothing else — totally devoid of
   > implementation details.**
6. **Offer an ADR — sparingly.** Record one *only when all three hold:*
   **(1) hard to reverse, (2) surprising without context, (3) the result of a real
   trade-off.** Miss any one → skip it. (This is the steering doc's
   penalty-for-being-wrong test, applied to decisions.)

## Definition of done

- [ ] Conflicting/fuzzy terms resolved to canonical names
- [ ] `CONTEXT.md` updated inline — glossary only, no implementation detail
- [ ] ADR recorded **only** if hard-to-reverse **and** surprising **and** a real trade-off
- [ ] Code contradictions surfaced (not silently left)

From KSriki/agent-harness-template, MIT.

More from KSriki/agent-harness-template

Signals

Stars
0
Forks
0
Open issues
0
Last commit (this folder)
Jul 22, 2026 (3 months ago)

From GitHub (fetched Oct 24, 2026).

Details

License
MIT
First seen
Oct 24, 2026
Last checked
Oct 24, 2026

More from KSriki

Cite this page

domain-modeling skill. Agent Mart. https://agentmart.dev/skills/ksriki-domain-modeling (last updated 2026-10-24)