create-message-contract

Scaffolds cross-bounded-context IMessage event records with naming and property conventions.

Updated Nov 19, 2020
One-click install
npx skills add https://github.com/kwojtasinski-repo/ECommerceApp --skill create-message-contract-kwojtasinski-repo
Or copy as Structured Prompt for Agent
Please help me install this Agent Skill.
Skill: create-message-contract
Source: https://github.com/kwojtasinski-repo/ECommerceApp/tree/main/.github/skills/create-message-contract
Command: npx skills add https://github.com/kwojtasinski-repo/ECommerceApp --skill create-message-contract-kwojtasinski-repo

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Defining events that cross bounded-context boundaries in a modular .NET application is error-prone: wrong naming, leaking domain types into contracts, or publishing before persistence. This Skill scaffolds a consistent, publisher-owned IMessage event record following the project's conventions. ## Core Features & Use Cases - Event Record Scaffolding: Generates a public C# record implementing IMessage in the publisher BC's Messages folder, with templates for simple and nested-payload events. - Convention Enforcement: Applies naming rules (past-tense, no Event suffix), property rules (primitives only, int IDs, DateTimeOffset timestamps), and placement rules. - Architecture Hygiene: Reminds you to update the bounded-context map, consider ADR amendments, and add consumer handlers separately via /create-domain-event. - Use Case: When the Orders BC must notify other contexts that an order was placed, generate an OrderPlaced record in Application/Sales/Orders/Messages and wire the PublishAsync call after SaveChangesAsync. ## Quick Start Ask the assistant to create a message contract named OrderPlaced published by the Sales/Orders bounded context.

Frequently Asked Questions about create-message-contract

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I create a cross-bounded-context event contract in .NET?

Define a public record implementing IMessage in the publisher bounded context's Messages folder, using only primitive property types. Publish it with PublishAsync after SaveChangesAsync, and add consumer handlers separately in the consuming context.

How should domain event records be named?

Use past-tense names describing what happened, such as OrderPlaced or PaymentConfirmed. Never append an Event suffix, since the IMessage base interface already implies the type is an event.

Can message contracts reference domain entities or typed IDs?

No. Contracts must use primitives and built-in types only, with int for IDs instead of TypedId value objects. This keeps consumers independent of the publisher's domain model and avoids cross-context coupling.

When should I publish a domain event relative to saving changes?

Always publish after SaveChangesAsync succeeds, never before. If persistence fails, the event must not fire, otherwise consumers react to state that was never actually committed.

Where does the event handler live when an event crosses bounded contexts?

The publisher BC owns only the contract record; handlers live in the consumer BC and are added separately, for example via the create-domain-event skill in handler-only mode. The publisher should never know its consumers.