菜单
Actively build and refine a project's domain model as you design. Use when the user wants to nail down domain terminology or a ubiquitous language, capture an architectural decision as an ADR, or when another skill needs to keep the domain model current.
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
基于 SOC 职业分类
| name | domain-modeling |
| description | Actively build and refine a project's domain model as you design. Use when the user wants to nail down domain terminology or a ubiquitous language, capture an architectural decision as an ADR, or when another skill needs to keep the domain model current. |
Shape the project's domain model while you design — this is the active craft, not passive reading. You challenge loose terms, invent scenarios that expose edge cases, and commit the glossary and decisions to disk the instant they firm up. (Simply consulting CONTEXT.md to reuse a word is not this skill; that's a habit any skill already has. Reach for this skill when you are changing the model, not merely reading it.)
Most repositories hold a single context:
/
├── CONTEXT.md
├── docs/
│ └── adr/
│ ├── 0001-event-sourced-orders.md
│ └── 0002-postgres-for-write-model.md
└── src/
A CONTEXT-MAP.md at the root signals multiple contexts. The map records where each one lives:
/
├── CONTEXT-MAP.md
├── docs/
│ └── adr/ ← system-wide decisions
├── src/
│ ├── ordering/
│ │ ├── CONTEXT.md
│ │ └── docs/adr/ ← context-specific decisions
│ └── billing/
│ ├── CONTEXT.md
│ └── docs/adr/
Create these files lazily, the moment you have something worth writing — not before. Write the first CONTEXT.md when you resolve the first term; create docs/adr/ when the first ADR earns its place.
The moment the user reaches for a word that clashes with the language already in CONTEXT.md, stop and name the clash: "Your glossary pins 'cancellation' to X, but you're describing Y — which do you mean?"
When a word is vague or carries two meanings at once, offer a single precise term to replace it: "You said 'account' — is that the Customer or the User? They're not the same thing."
As domain relationships come up, ground them in specific cases. Invent scenarios that push on the edges and force the user to state exactly where one concept ends and the next begins.
When the user explains how something behaves, check whether the code tells the same story. Surface any mismatch: "The code cancels a whole Order, but you just said a partial cancellation is allowed — which one holds?"
Resolve a term, write it down immediately. Never let these pile up for a later pass — capture each one in the moment. Follow the layout in CONTEXT-FORMAT.md.
Keep CONTEXT.md free of any implementation detail. It is not a spec, a scratch pad, or a home for design decisions — it is a glossary, and only that.
Propose an ADR only when all three hold:
Miss any one of the three and there's no ADR to write. Follow the layout in ADR-FORMAT.md.
Recurring maintenance pass over automated dependency-bump PRs (Dependabot, Renovate, or similar) — rebase, relock, verify, and report what's ready to merge. Meant to be handed to a time-based loop or schedule, not run once.
Post-deploy verification loop — poll a rollout until every instance is on the new version and healthy, then run one smoke check against a real user path. Meant to be handed to a time-based loop with a timeout, not polled by hand.
Reference for designing agent loops — cycles of work that repeat until a stop condition is met. Covers the four loop shapes, writing completion criteria, carrying state and isolating work across cycles, and what running unattended still leaves on you.
Recurring check-in on a stack of dependent PRs — rebase children onto updated parents, surface CI state, flag anything waiting on a human-only gate, and report only what changed since last time. Meant to be handed to a time-based loop, not run once.
Pick the skill or flow that fits your situation. A router over the skills in this repo.
Review the changes since a fixed point (commit, branch, tag, or merge-base) along two axes — Standards (does the code follow this repo's documented coding standards?) and Spec (does the code match what the originating issue/PRD asked for?). Runs both reviews in parallel sub-agents and reports them side by side. Use when the user wants to review a branch, a PR, work-in-progress changes, or asks to "review since X".