ワンクリックでManusで任意のスキルを実行

code-review

スター3

フォーク1

更新日2026年6月10日 15:04

Project-specific review checklist for this repository (DDD + Event Sourcing + Axon Framework 5 invariants). Use when: (1) reviewing code changes, a diff, or a pull request in this repository, (2) user says 'review', 'code review', 'check this change', (3) any automated review action runs for this repo.

インストール

Codex または Claude でインストールこの Prompt をコピーして Codex、Claude、または他のアシスタントに貼り付けると、Skill ページを確認してインストールできます。

Manusで実行

ソース

MateuszNaKodach

MateuszNaKodach/HeroesOfDomainDrivenDesign.EventSourcing.DCB.Kotlin.Axon5.Spring

GitHub リポジトリを開く Creator のリポジトリを見る

ダウンロード

Manusで実行

Code Review Checklist

Project-specific invariants to verify when reviewing changes in this repository. These complement (not replace) general review practice: correctness, security, performance, and missing tests.

Event Sourcing invariants

Exhaustive when (event) in evolve() — must switch over the sealed interface with an explicit branch per subtype. No else -> branch, ever. No-op branches (is SomeEvent -> state) are required and intentional — they document a conscious "this event doesn't affect my state here" decision.
@EventSourcingHandler only on state-mutating events — branches that return state unchanged must NOT have a corresponding handler.
Every state-mutating branch has a test for that state transition.
decide() and evolve() stay pure — no side effects, no infrastructure dependencies in the Domain section.

Testing invariants

gameMetadata passed to every event() and command() call in tests — events without metadata break MetadataSequencingPolicy and cause processor failures with shared Testcontainers.
Integration tests use @HeroesAxonSpringBootTest, never bare @AxonSpringBootTest.
Prefer constructor injection over field injection, also in tests.

Domain modeling invariants

Value classes validate invariants in init blocks — domain concepts (Day, Gold, Quantity, …) must reject invalid values at construction.
All domain events implement HeroesEvent; module events extend their own sealed interface (e.g. DwellingEvent).
State classes are internal; commands are public.

Slice structure invariants

One slice per file (FeatureName.Slice.kt) with Domain / Application / Presentation sections.
Feature flags — every new slice needs @ConditionalOnProperty plus entries in application.yaml and Spring configuration metadata.
REST endpoints follow games/{gameId}/...; player ID via X-Player-ID header; game-scoped singletons use a fixed path segment, not a path variable.

Verification

Prefer the narrowest check: run the affected slice's test class (./mvnw test -Dtest=FeatureNameTest), not the whole suite.

このリポジトリの他の Skills

同じリポジトリ

dcb-expert

MateuszNaKodach/HeroesOfDomainDrivenDesign.EventSourcing.DCB.Kotlin.Axon5.Spring

Subject matter expert on Dynamic Consistency Boundary (DCB) — a technique for enforcing consistency in event-driven systems without rigid transactional boundaries. Use when the user asks about DCB concepts, specification, patterns, examples, or compares DCB with traditional Event Sourcing approaches (aggregates, event streams, sagas). Covers topics including tags, projections, decision models, append conditions, queries, and the DCB-compliant Event Store interface. Implementation-agnostic — explains concepts without adhering to any specific library or language.

2026-05-283

em-proophboard-spec

MateuszNaKodach/HeroesOfDomainDrivenDesign.EventSourcing.DCB.Kotlin.Axon5.Spring

Work with proophboard Event Modeling boards via MCP. Read, create, and modify event models — chapters, lanes, slices, and elements (commands, events, information, automations, UI, hotspots). Use when: (1) user asks to read, explore, or understand an event model on proophboard, (2) user asks to create or modify chapters, slices, or elements on the board, (3) user asks to model a feature, flow, or bounded context using Event Modeling, (4) user says 'proophboard', 'event model', 'board', 'add slice to board', 'model this on proophboard', 'update the board', (5) translating between code and event model (syncing implementation status with board slices).

2026-05-283

em2code-write-slice-axon5kotlin

MateuszNaKodach/HeroesOfDomainDrivenDesign.EventSourcing.DCB.Kotlin.Axon5.Spring

Implement Event Sourcing write slices using Axon Framework 5, Vertical Slice Architecture, and Event Modeling patterns. A write slice is: Command to decide to Events to evolve to State. Use when: (1) implementing a new write slice / command handler in an AF5 project, (2) migrating/porting a write slice from Axon Framework 4 (Java or Kotlin) to AF5, (3) user provides a specification, Event Modeling artifact, existing tests, or natural language description of a command and asks to implement it, (4) user says "implement", "create", "add", "migrate", "port" a write slice, command handler, or aggregate behavior in an Axon Framework 5 / Vertical Slice Architecture project. Understands AF4 aggregate-based input as one possible source format.

2026-05-283

em2code-automation-slice-axon5kotlin

MateuszNaKodach/HeroesOfDomainDrivenDesign.EventSourcing.DCB.Kotlin.Axon5.Spring

Implement automation slices (Event to Command) using Axon Framework 5, Vertical Slice Architecture, and Event Modeling patterns. An automation is: an Event Handler that reacts to an event by dispatching a command via CommandDispatcher. Automations can be stateless (direct event-to-command mapping) or with a private read model (to look up data needed for command construction). Use when: (1) implementing a new automation / event-to-command reactor in an AF5 project, (2) migrating/porting an automation from Axon Framework 4 (Java or Kotlin) to AF5, (3) user provides a specification, Event Modeling artifact, or natural language description of an event-to-command reaction and asks to implement it, (4) user says "implement", "create", "add", "migrate", "port" an automation, event handler, reactor, or event-to-command flow in an Axon Framework 5 / Vertical Slice Architecture project. Understands AF4 @EventHandler/@ProcessingGroup input as one possible source format.

2026-03-143

em2code-read-slice-axon5kotlin

MateuszNaKodach/HeroesOfDomainDrivenDesign.EventSourcing.DCB.Kotlin.Axon5.Spring

Implement read slices (projections + query handlers + REST API + tests) using Axon Framework 5 AxonTestFixture with Spring Boot integration tests. A read slice is: Events projected into a Read Model, queried via QueryGateway. Use when: (1) implementing a new read slice / projection in an AF5 project, (2) migrating/porting a read slice from Axon Framework 4 (Java or Kotlin) to AF5, (3) user provides a read slice specification or Event Modeling artifact and asks to implement it, (4) user says "implement", "create", "add" a read slice, projection, query handler, or read model in an Axon Framework 5 / Vertical Slice Architecture project.

2026-03-143

em-proophboard-code

MateuszNaKodach/HeroesOfDomainDrivenDesign.EventSourcing.DCB.Kotlin.Axon5.Spring

Implement a single Event Modeling slice from proophboard — discover slices via MCP, let the user choose which one, delegate to the matching implementation skill (write/read/automation), run quality gates, handle git branching, and ask the user how to finalize (merge or PR). Use when: (1) user says "implement slice", "implement next slice", "/em-proophboard-code", (2) user wants to pick and implement a slice from the event model board, (3) user provides a slice ID or name and asks to implement it, (4) user says "what slices are planned" and wants to implement one.

2026-03-113

name	code-review
description	Project-specific review checklist for this repository (DDD + Event Sourcing + Axon Framework 5 invariants). Use when: (1) reviewing code changes, a diff, or a pull request in this repository, (2) user says 'review', 'code review', 'check this change', (3) any automated review action runs for this repo.

Code Review Checklist

Project-specific invariants to verify when reviewing changes in this repository. These complement (not replace) general review practice: correctness, security, performance, and missing tests.

Event Sourcing invariants

Exhaustive when (event) in evolve() — must switch over the sealed interface with an explicit branch per subtype. No else -> branch, ever. No-op branches (is SomeEvent -> state) are required and intentional — they document a conscious "this event doesn't affect my state here" decision.
@EventSourcingHandler only on state-mutating events — branches that return state unchanged must NOT have a corresponding handler.
Every state-mutating branch has a test for that state transition.
decide() and evolve() stay pure — no side effects, no infrastructure dependencies in the Domain section.

Testing invariants

gameMetadata passed to every event() and command() call in tests — events without metadata break MetadataSequencingPolicy and cause processor failures with shared Testcontainers.
Integration tests use @HeroesAxonSpringBootTest, never bare @AxonSpringBootTest.
Prefer constructor injection over field injection, also in tests.

Domain modeling invariants

Value classes validate invariants in init blocks — domain concepts (Day, Gold, Quantity, …) must reject invalid values at construction.
All domain events implement HeroesEvent; module events extend their own sealed interface (e.g. DwellingEvent).
State classes are internal; commands are public.

Slice structure invariants

One slice per file (FeatureName.Slice.kt) with Domain / Application / Presentation sections.
Feature flags — every new slice needs @ConditionalOnProperty plus entries in application.yaml and Spring configuration metadata.
REST endpoints follow games/{gameId}/...; player ID via X-Player-ID header; game-scoped singletons use a fixed path segment, not a path variable.

Verification

Prefer the narrowest check: run the affected slice's test class (./mvnw test -Dtest=FeatureNameTest), not the whole suite.