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.
中文简介正在准备中。当前显示原文说明。
查看安装方法安装前可以查看交给 AI 代理的指令内容。
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.
还没有评价。欢迎分享你的使用感受。
无需登录即可发表。欢迎分享使用感受、提问，或说明在哪些环境下无法运行。
还没有评论。来写第一条吧。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。
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.
中文简介正在准备中。当前显示原文说明。