Run any Skill in Manus with one click

messaging-patterns

Stars5

Forks0

UpdatedMay 23, 2026 at 08:41

Inbox/Outbox implementation rules, MessageConstants usage, and partition assignment for CoreBankDemo. **When to use:** - When implementing or reviewing Inbox/Outbox processors in CoreBankDemo. - When you need to ensure correct usage of MessageConstants or partition assignment logic. **When NOT to use:** - Do NOT use for messaging patterns outside CoreBankDemo or for unrelated architectures. - Do NOT use for ad-hoc message handling that does not use the provided base classes.

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

loekd

loekd/CoreBankDemo

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name

messaging-patterns

description

Inbox and Outbox processors

Always inherit from the base classes in CoreBankDemo.Messaging:

InboxProcessorBase<TMessage, TDbContext>
OutboxProcessorBase<TMessage, TDbContext>

Override LockNamePrefix and ProcessMessageAsync. Reference implementation: CoreBankAPI/Inbox/InboxProcessor.cs.

Never bypass the base classes and reimplement polling or locking logic.

MessageConstants — no magic strings

MessageConstants.Status.Pending / Processing / Completed / Failed

MessageConstants.Defaults.MaxRetryCount       // 5
MessageConstants.Defaults.BatchSize           // 10
MessageConstants.Defaults.PollingInterval     // 5 s
MessageConstants.Defaults.ProcessingTimeout  // 5 min

Partition assignment

int partitionId = PartitionHelper.GetPartitionId(idempotencyKey, partitionCount);

Always use PartitionHelper — never write a second implementation.

Key files

File	Purpose
`CoreBankDemo.Messaging/MessageConstants.cs`	All status strings and defaults
`CoreBankDemo.Messaging/PartitionHelper.cs`	FNV-1a partition hashing
`CoreBankDemo.Messaging/Inbox/InboxProcessorBase.cs`	Base inbox service
`CoreBankDemo.Messaging/Outbox/OutboxProcessorBase.cs`	Base outbox service
`CoreBankDemo.CoreBankAPI/Inbox/InboxProcessor.cs`	Reference inbox implementation
`CoreBankDemo.PaymentsAPI/Outbox/OutboxProcessor.cs`	Reference outbox implementation

More from this repository

same repository

corebank-trace-analysis

loekd/CoreBankDemo

Analyze OpenTelemetry traces after a CoreBankDemo load test to identify performance issues and errors. **When to use:** - After a load test completes (or fails), to investigate what happened at the infrastructure level - When `get_assertion_results` returns failures and you need to understand why - When you want to find slow spans, high-latency payment flows, or exceptions during a test run - When asked to analyze Jaeger traces, spans, or distributed tracing data for CoreBank or Payments **When NOT to use:** - For business-level assertions (exactly-once, balance conservation) — use LoadTestSupport MCP tools instead - Before the load test has run — there will be no relevant traces - For general .NET debugging unrelated to load testing

2026-06-025

load-test

loekd/CoreBankDemo

Run a full CoreBankDemo load test, wait for drain, and assert results via the LoadTestSupport API. **When to use:** - When you want to run a complete end-to-end load test of CoreBankDemo, including reset, execution, drain, and assertion, via the LoadTestSupport MCP API. - When you need to validate system resilience, idempotency, and correctness under load. **When NOT to use:** - Do NOT use for unit testing, manual, ad-hoc, or partial testing of individual services. - Do NOT use if you only want to run k6 or inspect a single component—use the relevant skill or tool instead. - Do NOT use the Aspire MCP CLI for these endpoints (see warning below).

2026-06-025

aspire-launch

loekd/CoreBankDemo

Start and stop CoreBankDemo AppHosts using the Aspire CLI. **When to use:** - When you need to start, stop, or wait for health of CoreBankDemo AppHosts using the Aspire CLI. - When you want to ensure services are running and healthy before interacting with APIs or running tests. **When NOT to use:** - Do NOT use for starting individual services outside of AppHosts. - Do NOT use `dotnet run` or `sleep` for orchestration or health checks—always use the Aspire CLI commands as described. - Do NOT use for inspecting logs, traces, or resource state—use the aspire-mcp skill for those tasks.

2026-05-235

aspire-mcp

loekd/CoreBankDemo

Use Aspire MCP tools to inspect resource state, logs, and traces in CoreBankDemo. **When to use:** - When an AppHost is already running. - When you need to inspect the state, logs, or distributed traces of resources managed by an Aspire AppHost in CoreBankDemo. - When you want to use Aspire CLI or MCP tools to diagnose, monitor, or interact with running services. **When NOT to use:** - Do NOT use if no AppHost is running (start one with the aspire-launch skill first). - Do NOT use for direct database inspection, application-level debugging, or for actions outside the scope of Aspire-managed resources. - Do NOT use for running or stopping AppHosts themselves—use the aspire-launch skill for that purpose.

2026-05-235

conventions

loekd/CoreBankDemo

Coding conventions for CoreBankDemo: database, time, HTTP/business logic separation, validation, and logging. **When to use:** - When writing or reviewing code for CoreBankDemo to ensure consistency in database usage, time handling, controller/business logic separation, validation, and logging. - When you need to check or enforce project-wide coding standards. **When NOT to use:** - Do NOT use for framework-agnostic or non-CoreBankDemo projects. - Do NOT use for runtime troubleshooting or debugging—use the relevant skills for those tasks.

2026-05-235

observability

loekd/CoreBankDemo

OpenTelemetry tracing rules for CoreBankDemo: ActivitySource registration, span creation, and trace context propagation. **When to use:** - When adding or reviewing tracing, ActivitySource, or span logic in CoreBankDemo. - When ensuring trace context propagation and distributed tracing best practices are followed. **When NOT to use:** - Do NOT use for tracing unrelated to CoreBankDemo or for non-OpenTelemetry tracing systems. - Do NOT use for runtime log inspection or debugging—use the aspire-mcp skill for those tasks.

2026-05-235

name

messaging-patterns

description

Inbox and Outbox processors

Always inherit from the base classes in CoreBankDemo.Messaging:

InboxProcessorBase<TMessage, TDbContext>
OutboxProcessorBase<TMessage, TDbContext>

Override LockNamePrefix and ProcessMessageAsync. Reference implementation: CoreBankAPI/Inbox/InboxProcessor.cs.

Never bypass the base classes and reimplement polling or locking logic.

MessageConstants — no magic strings

MessageConstants.Status.Pending / Processing / Completed / Failed

MessageConstants.Defaults.MaxRetryCount       // 5
MessageConstants.Defaults.BatchSize           // 10
MessageConstants.Defaults.PollingInterval     // 5 s
MessageConstants.Defaults.ProcessingTimeout  // 5 min

Partition assignment

int partitionId = PartitionHelper.GetPartitionId(idempotencyKey, partitionCount);

Always use PartitionHelper — never write a second implementation.

Key files

File	Purpose
`CoreBankDemo.Messaging/MessageConstants.cs`	All status strings and defaults
`CoreBankDemo.Messaging/PartitionHelper.cs`	FNV-1a partition hashing
`CoreBankDemo.Messaging/Inbox/InboxProcessorBase.cs`	Base inbox service
`CoreBankDemo.Messaging/Outbox/OutboxProcessorBase.cs`	Base outbox service
`CoreBankDemo.CoreBankAPI/Inbox/InboxProcessor.cs`	Reference inbox implementation
`CoreBankDemo.PaymentsAPI/Outbox/OutboxProcessor.cs`	Reference outbox implementation