Build a reviewable software domain model with bounded contexts, shared language, identities, invariants, lifecycle transitions, contracts, and code-to-model contradictions.
A class diagram can look tidy while two teams use the same word for different things, three services claim the same fact, and no component can enforce the rule everyone assumes is safe. This skill makes those disagreements explicit before they turn into migration work.
It starts from real scenarios and supplied evidence. It defines context boundaries, local language, identities, aggregate rules, lifecycle transitions, cross-context contracts, consistency expectations, and failure behavior. Then it checks the proposed model against code, schemas, APIs, events, and tests. Conflicts stay visible until the right owner resolves them.
Use it before a new domain-heavy feature, during architecture discovery, or when an existing model no longer matches the product. The package includes a JSON record schema and an offline checker for stable IDs and cross-references. The checker validates structure. It cannot decide whether a business rule is true or replace the people who own that decision.
Input
Model subscription changes for organizations with several workspaces. Billing owns invoices and payment attempts. Product currently uses account, customer, organization, and workspace inconsistently. Upgrades are immediate, downgrades wait until renewal, and a failed renewal starts a grace period. Show the boundaries, terms, authority, invariants, transitions, events, and unresolved decisions.
Output
A scoped context map for identity, subscription, billing, and entitlement; a term register that separates organization, billing customer, workspace, and user; identity and authority rules; upgrade, renewal, grace, recovery, downgrade, and cancellation transitions; cross-context contracts with consistency and retry behavior; conflict notes for unresolved proration and entitlement timing; test scenarios; and a bounded readiness verdict.
Provide the product decision, representative scenarios, domain language, requirements, code or schema evidence, APIs, events, known rules, and the people who can resolve open questions. The skill returns the narrowest supportable model, keeps assumptions and contradictions visible, and gives a ready, ready-with-limits, or blocked verdict.
Requirements, scenarios, stakeholder notes, code, schemas, APIs, events, tests, or existing diagrams for the slice being modeled.
A named role or team that can resolve controlling terms, ownership, invariants, and lifecycle questions.
Optional. Required only to run the bundled JSON record checker.
SKILL.md; domain modeling review rubric; machine-checkable model record guide; JSON record schema; offline domain-model consistency checker; Agent Skills interface metadata
No reviews yet.
Input
Requirements say a seller can withdraw an unpaid listing, but the database uses listing.status for draft, review, sale, payout, and refund. Payment webhooks can arrive twice or out of order. The API lets admins set any status. Review the domain model before we split the service. Cite the supplied evidence and do not assume the requirement or code is automatically correct.
Output
Separate listing, moderation, order, payment, and payout responsibilities; one authority per mutable fact; explicit identities and contracts; invariants for publication and money movement; idempotent lifecycle transitions for duplicate and late webhooks; contradictions between requirements, schema, and admin API; migration impact; acceptance scenarios; and blocked decisions assigned to the right owners.
Input
Return the package's standard JSON record for an order reservation flow. Requirements say inventory is reserved at checkout, code reserves after payment, and an event consumer treats OrderSubmitted as proof of payment. Include contexts, terms, concepts, invariants, transitions, relationships, contradictions, decisions, implementation mappings, tests, and a verdict without inventing which source is correct.
Output
One checker-ready JSON object with stable lowercase IDs, valid context and concept references, conflicted evidence states, separate ordering, payment, and inventory authority, explicit reservation and payment invariants, allowed and rejected transitions, integration failure behavior, unresolved contradictions and owners, test scenarios tied to invariants, and a blocked verdict that lists every controlling open item.
Creator
Vvelnix78
