Clarify project terminology and the relationships between business concepts. Check definitions against concrete scenarios and code, update GLOSSARY.md as terms are agreed, and record significant design decisions with their trade-offs when the stated criteria are met.
构建并打磨项目的领域模型。适用于讨论 codebase 术语、编写或编辑 GLOSSARY.md，或记录或编辑 ADR。
Run score Not tested
See how to installReview the instructions the agent will receive before you install.
在设计过程中主动构建并打磨项目的 domain model。这是 active discipline：挑战术语、发明 edge-case scenarios，并在概念成形的当下写入 glossary 和 decisions。
多数 repos 只有一个 context：
/
|- GLOSSARY.md
|- docs/
| `- adr/
| |- 0001-event-sourced-orders.md
| `- 0002-postgres-for-write-model.md
`- src/
如果 root 有 GLOSSARY-MAP.md，说明 repo 有多个 contexts。map 指向每个 context 的位置：
/
|- GLOSSARY-MAP.md
|- docs/
| `- adr/ -> system-wide decisions
`- src/
|- ordering/
| |- GLOSSARY.md
| `- docs/adr/ -> context-specific decisions
`- billing/
|- GLOSSARY.md
`- docs/adr/
按需懒创建文件：只有在有内容要写时才创建。如果没有 GLOSSARY.md，当第一个 term 被解决时创建它。如果没有 docs/adr/，当第一个 ADR 需要出现时创建它。
当用户使用的术语与 GLOSSARY.md 中既有语言冲突时，立即指出。"Your glossary defines 'cancellation' as X, but you seem to mean Y - which is it?"
当用户使用模糊或过载术语时，提出一个精确的 canonical term。"You're saying 'account' - do you mean the Customer or the User? Those are different things."
讨论 domain relationships 时，用具体场景做压力测试。发明能探测 edge cases 的场景，迫使用户精确定义概念之间的 boundaries。
当用户描述某事如何工作时，检查代码是否同意。如果发现矛盾，要指出："Your code cancels entire Orders, but you just said partial cancellation is possible - which is right?"
当一个 term 被解决时，立刻更新 GLOSSARY.md。不要批量攒到最后；随着概念出现就捕获。使用 GLOSSARY-FORMAT.md 中的格式。
GLOSSARY.md 必须完全不包含 implementation details。不要把 GLOSSARY.md 当 spec、scratch pad 或 implementation decisions 的仓库。它只是一份 glossary。
只有以下三项都成立时，才提出创建 ADR：
缺少任一项就跳过 ADR。使用 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.
Find the right skill and sequence for your current development task, from shaping an idea to implementation, debugging, and review. The guide also explains when to prototype, prepare specifications, or move work into a fresh session.
Summarize the current conversation and launch a fresh background agent to continue the work. The handoff includes references to existing artifacts and suggested skills, removes sensitive information, and can emphasize the next session’s intended focus.
Review changes from a chosen Git reference against both project coding standards and issue or specification requirements. Separate parallel reviews report rule violations, possible design problems, missing requirements, and changes beyond the intended scope.
Design modules that expose simple interfaces while hiding substantial behavior. Use shared terms and principles to assess interface complexity, decide where behavior can be swapped, and organize code so callers and tests use the same interface.
Diagnose difficult bugs and performance regressions by first building a repeatable check for the exact symptom. Minimize the reproduction, test ranked hypotheses, apply a fix, and verify the original scenario with regression tests where suitable.
Set up Claude Code hooks that block specified Git commands before they run, including push and destructive cleanup operations. Choose project or global installation, adjust the blocked commands, and test that the hook rejects a sample command.