domain-centric-development
OrganizationA Claude Code plugin marketplace that packages Domain-Driven Design, Hexagonal Architecture, and Clean Architecture as ready-to-use skills and agents.
Categories
Indexed Skills (23)
context-map
Maintains a strategic DDD Context Map (`docs/context-map.md` with Mermaid diagram) showing relationships between bounded contexts (Customer/Supplier, Anti-Corruption Layer, Open Host Service, Shared Kernel, Published Language, Conformist, Separate Ways, Partnership) and each context's subdomain type (Core/Supporting/Generic — drives pattern choice and rule-set strictness). Use when introducing a new context, changing cross-context communication, classifying subdomains, or onboarding to understand the system.
dca-bootstrap
Installs Domain-Centric Architecture (DCA) into a Java or .NET project by adding the published packages — `dev.domaincentric:dca-building-blocks` + `dca-spring` and `dca-archunit` (+ `dca-archunit-spring-modulith` with Modulith), or `DomainCentric.BuildingBlocks` + `DomainCentric.ArchRules.Xunit` — and generating one thin architecture test that runs the DCA rule catalog. Use when the user wants to introduce DCA conventions into a new or existing codebase — e.g. "set up DCA governance", "add the DCA architecture rules", "bootstrap DCA in this project". Inspects the project first, maps its layout onto `DcaLayout`, migrates or aliases existing marker-like interfaces, and never overwrites existing files.
dca-discipline
Applies Domain-Centric Architecture invariants while writing or editing Java/Spring or .NET/C# code: framework-free domain, dependency inversion (interfaces in app/domain, impls in adapters), bounded-context isolation (no raw cross-context imports), domain-event hygiene (publish + clear), named failure types with one translation site. Use during edits to domain/, application/, or adapter/ folders.
dca-knowledge
Answers Domain-Centric Architecture questions grounded in the generated OKF knowledge catalog (`dca-knowledge-catalog/bundle/`) — the full implementation-guide text anchored to marker contracts and ArchUnit rules as one cross-linked graph. Loads `index.md`, traverses typed links (governed-by / applies-to / discussed-in), and cites the node path for every claim. Use when the user asks "what does DCA say about X", "which rule governs this marker", "explain <DCA concept>", "/dca-knowledge", or wants an answer grounded in the canonical catalog rather than the model's own recollection.
dca-scaffold
Scaffolds new Domain-Centric Architecture (DCA) code into Java/Spring or .NET/C# projects: bounded contexts, use cases (Command/Query + InputPort + Result + Impl), and aggregate roots (with Id, Repository, and Created event). Use when the user asks to "create a new bounded context", "scaffold a use case", "add an aggregate root", "generate DCA structure for feature X", or "/dca-scaffold". Adapts to existing project conventions: reads the project's DcaLayout (architecture test) and the conventions overlay, plus existing code style. Never overwrites files.
ubiquitous-language
Maintains a per-bounded-context Ubiquitous Language glossary (`glossary.md` per context) and checks code naming for consistency. Use when adding a new domain concept, renaming an existing one, or auditing naming drift. Updates the glossary, finds outdated terms in code, and proposes consistent renames.
adr
Creates and manages Architecture Decision Records (ADRs) in Michael Nygard format. Use when making a non-trivial architectural decision (choice of framework, pattern, integration style, deprecation), superseding an old decision, or auditing past decisions. Maintains numbered, immutable records with cross-references and a regenerated index.
clean-code
Applies Clean Code, Pragmatic Programmer, and Refactoring principles during code edits: meaningful names, small functions, no comment smell, SLAP (Single Level of Abstraction), DRY with judgment, Boy-Scout-Rule. Complements language-specific style guides; does not replace formatters.
tdd
Enforces Red-Green-Refactor when implementing new behavior. Claude writes a failing test first, confirms it fails for the right reason, implements the minimum to pass, then refactors. Use when adding new functionality — especially in domain or application layers of a DCA project.
dca-review
Reviews Java/Spring or .NET/C# code against Domain-Centric Architecture (DCA) conventions. Complements ArchUnit by checking semantic aspects that static rules can't: aggregate-design quality, use-case granularity, port semantics, domain-event hygiene, failure types and their translation, cross-context boundaries, naming consistency. Use when the user asks to "review my DCA code", "is this DCA-compliant", "audit the changes for DCA", or "/dca-review". Default scope is the git diff against main; the user can pass explicit paths instead.
ddd-modelling
The craft of building tactical DDD types — aggregates, entities, value objects, ids, domain and integration events, domain services, factories, specifications, repositories, stores and named failures. Use when designing or implementing a new domain concept, or when a delivery stage needs the project's implementation craft. Reads the project's conventions and existing types first and adapts to them; it builds, it does not review.
factory-backlog
Writes and checks the backlog a delivery run reads — an epic with its outcome event, or one story small enough for a single run, in the markdown-with-front-matter contract. Use when a story or an epic is to be added, split or repaired, when the plan gate refused a story as incomplete, or on "/factory-backlog". Never invents an intent, a goal, a metric or a domain contact.
factory-decisions
The decision inbox of a delivery run — lists the questions stages could not answer, explains one from its record and the story it blocks, and writes the human's answer into the record on their explicit confirmation. Use when a run stopped with needs-human, when someone asks what is waiting on them, to answer a question from a second session, or on "/factory-decisions". Answers nothing itself and implements nothing.
factory-scope
Writes the product scope before a project's first story — what is built, for whom, through which surfaces, how it works, how it looks — and handles the one question a delivery run may not answer for itself — a story that would need a new bounded context, a new relationship between contexts, or a surface its actor does not have yet. Use when the backlog skill reported the product scope missing, when a plan stopped with needs-human for one of those questions, when the backlog skill refused a story for a context that is not on the map, or on "/factory-scope". Produces a product scope, a decision and a map, never code.
factory-status
Shows where the delivery pipeline stands in this project — which stage is running, which decisions wait for a human, every story's state and what comes next, and what the stories cost in tokens — read from the project's files alone. Use when someone asks how a run is going, what the factory is doing, what is waiting, how far the backlog is, what a story cost, or on "/factory-status". Works from any session in the project, beside a running pipeline; it changes nothing and starts nothing.
factory-verify
Checks that the delivery pipeline works. Two modes — observe one real story that was just delivered and report the facts about whatever did not hold (the stages' claims against the repository, the gate and the run journal), or check the pipeline's own machinery against throwaway fixtures. Use after a run to see whether it really did what it says, before trusting the pipeline in a new project, after changing a stage, a gate check or the runner, or on "/factory-verify".
stage-build
Build stage of a factory run — writes the production code that turns the story's red tests green, with the smallest change that works. Use after the test stage of a story, when the orchestrator hands over the failing tests or a gate report, or on "/stage-build". Keeps the domain framework-free and the architecture suite green.
stage-judge
Judge stage of a factory run — reviews the story's change from three perspectives (domain, boundaries, craft), keeps only defects it can confirm in the code, and returns one verdict. Use after the build stage of a story, when the orchestrator asks for the review, or on "/stage-judge". Reports defects; it does not fix them.
stage-plan
Plan stage of a factory run — turns one backlog story into an implementation plan with numbered acceptance criteria and names the architecture elements that change. Use when a story is to be planned before any test or code is written, when the orchestrator hands over a story, or on "/stage-plan". Reads only the story and the project's own glossary and context map.
stage-test
Test stage of a factory run — writes one end-user test per acceptance criterion plus unit tests for the invariants, and records the criterion-to-test table the story gate reads. Use after the plan stage of a story, when the orchestrator hands over a plan, or on "/stage-test". The tests must compile and be red before any production code is written.
stage-tidy
Tidy stage of a factory run — the refactor step the build stage deliberately skips, taken with every test green and without changing behaviour. Use after the build gate passed for a story, when the orchestrator hands over a green build, or on "/stage-tidy". Touches only what this story touched.
e2e-testing
The craft of end-user browser tests — Page Object Pattern, stable data-test selectors, one flow per test, explicit waits instead of sleeps, and a diagnosis-first protocol when a test breaks. Use when adding or extending an end-user test, when fixing a flaky one, or when a delivery stage needs the project's end-user testing craft. Library-agnostic discipline; Playwright as the default when the project has no runner yet.
factory-update
Brings this project's copy of the delivery pipeline — gate, runner, commit hook and, where the project keeps them, its skill copies — up to the newest pipeline installed on this machine, for the tools the project already uses, keeping links as links and copies as copies. Use when the factory reports that the project was installed from an older pipeline, after the plugin or marketplace was updated, or on "/factory-update". It commits nothing and never rewrites the stack profile.
Bio shown is the top-scored skill's repo description as a fallback — real GitHub bios land in a future update.