domain-context

Standardize domain terminology across projects using CONTEXT.md and ADRs.

15|5|Updated May 17, 2026
One-click install
npx skills add https://github.com/cropsgg/skills --skill domain-context-cropsgg
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: domain-context
Source: https://github.com/cropsgg/skills/tree/main/skills/planning/domain-context
Command: npx skills add https://github.com/cropsgg/skills --skill domain-context-cropsgg

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve?

Inconsistent terminology and undocumented design decisions across repositories create confusion and slow collaboration. This Skill helps teams establish a shared domain language and capture decisions in CONTEXT.md and ADRs for clear, auditable communication.

Core Features & Use Cases

  • Inventory terms by scanning READMEs, modules, and PR titles to surface repeated nouns/verbs and ambiguous terminology.
  • Draft CONTEXT.md to house a glossary (term → definition → example) and core concepts, plus ADRs to record reversible decisions.
  • Identify decision gaps by proposing ADRs in docs/adr/NNNN-title.md with context, decision, and consequences.
  • Align references in code with glossary terms, and propose aliases during transitions to avoid breaking changes.
  • Validate terminology by re-reading a complex module using CONTEXT.md as the mapping reference to verify consistency.

Quick Start

Create a CONTEXT.md glossary at the repo root, document terms, and start capturing ADRs for major decisions.

Frequently Asked Questions about domain-context

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

FAQPage Schema
How do I standardize domain terminology across documentation and code?

You can standardize domain terminology by scanning READMEs, modules, and PR titles to inventory recurring terms, then drafting a CONTEXT.md glossary that maps each term to a definition and example to align code references across repositories.

What is the best way to document architecture decisions for a software project?

Document architecture decisions by creating ADRs in docs/adr/NNNN-title.md files, capturing context, decision, and consequences to establish a shared domain language and maintain auditable communication across software engineering teams.

How do I identify gaps in my project's architecture decision records?

Identify ADR gaps by reviewing your CONTEXT.md glossary and complex modules to propose new ADRs for undocumented design decisions, ensuring major reversible choices are recorded with their context and consequences.

How do I align code references when changing domain language in a glossary?

Align code references by mapping glossary terms to actual module implementations and proposing aliases during terminology transitions, which avoids breaking changes while updating the domain language across your codebase.

Can I use a CONTEXT.md glossary to validate terminology consistency in complex modules?

Yes, you can validate terminology consistency by re-reading a complex module using CONTEXT.md as the mapping reference, verifying that the domain language in the code aligns with the documented glossary terms.