agentsclimarketplace

Domain architecture workflow

Skill xfoundries/domain-architecture-skills/skills/domain-architecture-workflow

Source-aware architecture guidance for business-domain systems using Domain-Driven Design, Layered Architecture, Onion Architecture, Hexagonal Architecture / Ports and Adapters, and CQRS.

Install
npx -y skills add xfoundries/domain-architecture-skills --skill domain-architecture-workflow

Assembled from the repository path, not quoted from the project. Check it against their README if it does not work.

2 things to look at

  • no licenseNo license file was found in the repository. Code published without one is not open source by default, so using it at work is a question for whoever answers licensing questions where you are.
  • 1 stars1 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.

What its author says it does

Copied from the file, not written here

Use when a business software project needs an end-to-end domain and architecture workflow: understanding requirements, modeling domains, deciding DDD/Hexagonal/Onion/CQRS boundaries, planning implementation, or handing off to framework-specific guidance such as jfoundry. Does not require any external workflow skill.

SKILL.md

4.5 KB, 782 tokens by cl100k_base, as published. Nobody here has run it

Domain Architecture Workflow

Purpose

Use this skill as the entry point for business-domain software architecture work. It coordinates domain modeling, architecture guidance, and optional framework-specific landing without depending on any external workflow skill.

If another planning, TDD, or review workflow is already active, use this skill only for the domain and architecture decisions inside that workflow.

Workflow

  1. Understand the business goal, acceptance expectations, actors, workflows, constraints, and uncertainty; classify how much domain and architecture work the requested increment needs.
  2. Use domain-modeling for non-trivial business behavior and consume its Domain Modeling Result.
  3. Use domain-architecture-guidance to choose appropriate boundaries and consume its Architecture Guidance Result.
  4. Use using-jfoundry only when applicable and after domain and architecture assumptions are clear. If jfoundry use is undecided, continue framework-neutral phases without invoking it and defer the choice until a framework-specific next activity materially requires it.
  5. Produce a composite Domain Architecture Handoff that makes planning readiness, dependent blockers, and the next owner explicit.
  6. Persist workflow-owned artifacts under the default documentation directory, then route detailed planning to its plans subdirectory or to the user-selected process companion. The companion alone owns its plan files, tasks, and execution state.
  7. During implementation or review, revisit the modeling or architecture phase when changed business meaning, drift, or conflicts invalidate assumptions.

Skill Routing

  • Use domain-modeling for requirements-to-model work: ubiquitous language, business commands, events, bounded contexts, aggregates, invariants, value objects, domain services, repositories, and read needs/read models.
  • Use domain-architecture-guidance for architecture decisions and reviews: dependency direction, Layered/Onion/Hexagonal/CQRS boundaries, jMolecules-style annotations, architecture tests, and source-aware rule interpretation.
  • Use using-jfoundry only when the target project uses jfoundry or the user explicitly asks for jfoundry-specific dependencies, package layout, annotations, Repository/Port guidance, persistence adapters, Outbox/Inbox, or ArchUnit setup. Undecided alone does not make this specialist applicable.

Result And Handoff Routing

Read references/first-use.md when the user asks how to start an end-to-end project or combine this workflow with an optional process companion.

Read references/implementation-planning.md when handing a completed analysis to detailed planning, selecting the smallest independently verifiable increment, or later introducing a process companion to an existing handoff.

Read references/workflow-results.md before coordinating phases. Require each specialist to return its own phase-specific payload in the shared result envelope. Check phase status and combine results without rewriting specialist guidance. When a phase reports needs-input, pause only dependent progression, preserve completed results, produce an interim handoff with blockers, and ask the smallest blocking question. Treat process companions as optional and user-selected; never make this workflow depend on one.

Handoff Rules

  • Do not let framework choices drive the domain model.
  • Do not force DDD ceremony into low-complexity CRUD.
  • Keep open business questions visible before coding.
  • Attribute guidance to the right source: DDD concepts, architecture style constraints, framework conventions, heuristics, or project policies.
  • Keep this workflow independent. It can run alongside other process skills, but it must not require them.
  • Treat a Domain Architecture Handoff as planning input, not as a detailed implementation plan. Use the plugin's default documentation directory for workflow-owned artifacts and never reproduce a selected companion's process artifacts.

What ships with it: 5 files

29.6 KB alongside SKILL.md

agents/

references/

Gives 0 of the 12 instructions most architecture codebase skills give in 782 tokens

Counted across 811 of the 1,134 authors here whose files we hold, read 2026-08-07

  • Ask the user which candidate to explorein 45 of 811, across 15 files
  • Apply the deletion test to suspected shallow modulesin 43 of 811, across 15 files
  • Read any relevant architecture decision records firstin 31 of 811, across 8 files
  • Use exact glossary terms in every suggestionin 30 of 811, across 10 files
  • Accept dependencies instead of creating themin 24 of 811, across 5 files
  • Include before and after visualisations for each candidatein 24 of 811, across 5 files
  • Read the domain glossary before exploringin 24 of 811, across 6 files
  • Return results instead of producing side effectsin 23 of 811, across 4 files
  • Explore the codebase for shallow modules and frictionin 23 of 811, across 3 files
  • Introduce seams only where things varyin 22 of 811, across 3 files
  • Reduce the number of methodsin 21 of 811, across 2 files
  • Design deep modules with small interfacesin 21 of 811, across 3 files

Said here and by no other author read

  • understand business goals, actors, and constraints
  • classify required domain and architecture work
  • use domain-modeling for non-trivial business behavior
  • use domain-architecture-guidance to choose boundaries
  • defer framework choice until explicitly needed
  • produce a domain architecture handoff

Grouped from the skills themselves: near-identical wordings counted once, and counted by distinct author, so one author publishing three of these counts once. Length counted with cl100k_base; the agent that loads this file may tokenize it differently.

Keep looking

Skills are one crate of 327,069. Ordering is by how many stacks a row turns up in, so the top of any crate is what has actually been picked rather than what has the most stars.