Build and sharpen a project's domain model. Use only when actively changing glossary or ubiquitous-language terms, or recording a durable architectural decision; merely reading a glossary is not a trigger.
The English summary is being prepared. Showing the original description.
See how to installReview the instructions the agent will receive before you install.
Actively build and sharpen the project's domain model as you design. This is the active discipline: challenging terms, inventing edge-case scenarios, and writing the glossary and decisions down the moment they crystallise. (Merely reading GLOSSARY.md for vocabulary is not this skill: that's a one-line habit any skill can do. This skill is for when you're changing the model, not just consuming it.)
Most repos have a single context:
/
├── GLOSSARY.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
If GLOSSARY-MAP.md or CONTEXT-MAP.md exists at the root, read its pointers to find the existing contexts:
/
├── GLOSSARY-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
├── src/
│ ├── ordering/
│ │ ├── GLOSSARY.md
│ │ └── docs/adr/ ← context-specific decisions
│ └── billing/
│ ├── GLOSSARY.md
│ └── docs/adr/
Use existing GLOSSARY.md or CONTEXT.md files and their map pointers; do not migrate or duplicate them. When authorized to write and no glossary exists, create GLOSSARY.md for the first resolved term. Create docs/adr/ only for the first accepted ADR. Otherwise render the exact proposed change in chat.
When a term conflicts with the existing GLOSSARY.md or CONTEXT.md language, surface the conflict. "Your glossary defines 'cancellation' as X, but you seem to mean Y. Which is it?"
When the user uses vague or overloaded terms, propose a precise canonical term. "You're saying 'account': do you mean the Customer or the User? Those are different things."
When domain relationships are being discussed, stress-test them with specific scenarios. Invent scenarios that probe edge cases and force the user to be precise about the boundaries between concepts.
When the user states how something works, check whether the code agrees. If you find a contradiction, surface it: "Your code cancels entire Orders, but you just said partial cancellation is possible. Which is right?"
When a term is resolved and writing is authorized, update the existing glossary, or GLOSSARY.md for a new one. Otherwise render the exact proposed update in chat. Don't batch these up: capture them as they happen. Use the format in GLOSSARY-FORMAT.md.
Keep the existing GLOSSARY.md or CONTEXT.md focused on domain terms, without implementation details or decisions. Use ADRs for durable decisions.
Only offer to create an ADR when all three are true:
If any of the three is missing, skip the ADR. Use the format in ADR-FORMAT.md.
No reviews yet. Tell others what you thought.
No login needed. Share how it worked for you, ask a question, or note where it did not run.
No comments yet. Be the first to write one.
Read public X/Twitter post URLs as structured evidence through the ADHX API. Use for relevant user-provided or research-discovered x.com, twitter.com, or adhx.com links. ADHX does not search X, and long-form Article content may be incomplete.
The English summary is being prepared. Showing the original description.
Design, review, or report a measured performance comparison. Use for benchmark methodology, speedup or regression claims, and performance-based choices; not generic performance discussion, ordinary dependency bumps, local renames, or prose edits.
The English summary is being prepared. Showing the original description.
Trace what an actual code change could break beyond its diff when interfaces, serialized data, database schemas, configuration, caches, lifecycle ordering, or cross-language consumers are involved. Use for explicit impact analysis; not local renames, prose edits, ordinary dependency bumps, or generic architecture discussion.
The English summary is being prepared. Showing the original description.
Shared vocabulary for designing deep modules, interfaces, seams, adapters, leverage, and locality. Use when designing or reshaping module boundaries, making code more testable, or evaluating interface depth.
The English summary is being prepared. Showing the original description.
Plan or implement retirement of a system, API, feature, persisted configuration, or database shape. Use for compatibility cutovers, explicit deprecation review, or an explicit unreleased replacement decision, including determining whether consumers or data exist; not ordinary dependency bumps, local renames, prose edits, or generic architecture discussion.
The English summary is being prepared. Showing the original description.
Disciplined diagnosis loop for hard bugs, regressions, flaky failures, and performance problems with unclear cause. Use for root-cause debugging after a concrete symptom exists; do not use for routine implementation or speculative cleanup.
The English summary is being prepared. Showing the original description.