agentsclimarketplace

Domain modeling

Skill sainzs/santiagosainz-skills/skills/core/domain-modeling

Auditable, portable agent skills that turn open-source maintenance - review, debugging, verification, handoff - into repeatable workflows for Codex, OpenCode, and Pi

Install
npx -y skills add sainzs/santiagosainz-skills --skill domain-modeling

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

One thing to look at

  • 0 stars0 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Model the domain language, entities, states, aliases, and naming rules from code, docs, ADRs, tests, and user vocabulary. Use when the user asks for glossary work, naming cleanup, project vocabulary, system concepts, or project-language.

SKILL.md

1.9 KB, as published. Nobody here has run it

domain-modeling

Make the agent speak the project language instead of inventing one.

Unix/Pi Contract

  • Do one job: normalize project vocabulary from evidence.
  • Consume source, tests, docs, ADRs, and user words; emit a glossary or glossary patch.
  • Prefer plain text tables or bullets that can be pasted into CONTEXT.md, issues, or prompts.
  • Keep the surface honest: mark uncertain terms instead of laundering guesses into canon.
  • Stop when the current task's vocabulary is resolved.

Use

Use when onboarding to a repo, reducing vague terminology, naming modules, creating CONTEXT.md, refreshing a glossary, or preparing a plan that depends on domain concepts.

Research Budget

Inspect, in order:

  1. Existing CONTEXT.md, AGENTS.md, README, ADRs, and issue templates.
  2. Public interfaces, route names, schemas, state enums, event names, tests, and docs.
  3. Repeated user vocabulary from the current task.

Stop when the terms needed for the current work are clear.

Glossary Rules

  • Prefer names already present in source and tests.
  • Include aliases only when they prevent confusion.
  • Define states by observable behavior, not implementation guesses.
  • Record disputed or weak terms as "avoid" or "needs decision".
  • Keep definitions short enough to reuse in prompts and issue titles.

Output

Return or write, depending on the user's request:

  1. Canonical term.
  2. One-line meaning.
  3. Aliases or forbidden synonyms.
  4. Source evidence.
  5. Where the term should appear in code, docs, tests, or issues.

If editing a repo glossary, preserve existing useful terms and mark uncertainty instead of deleting aggressively.

Keep looking

Skills are one crate of 328,083. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.