eliteforge-java-uml

EliteForge Java UML

Goals

• Generate implementable Java 25 UML class designs that are clearly structured, have well-defined boundaries, and accurate relationships.
• Prioritize correctness and implementability; better to draw less than to draw incorrectly.

Environment Variables

• ELITEFORGE_SKILL_JAVA_UML_PLANTUML_ASL_JAR [required] Absolute path to the ASL PlantUML jar used to render and validate generated UML SVG output.

Execution order (do every time)

1. Identify the aggregate roots, core objects, rule objects, persistence objects, query responsibility components, and operation responsibility components in the business.
2. Distinguish layers: the foundation layer uses Controller、Service、Repository、Domain、Enums、External；Service downstream can be split into sub-blocks by functional type (such as storage/rules/cache/gateway), not limited to a fixed single layer.
3. Identify closed-set concepts and prioritize modeling them as enums (status, type, stage, source, etc.).
4. Assign a color to each business module; the same module uses a consistent color family, and different modules are distinguished by different color families.
5. Determine which objects require audit fields, and complete the fixed 6 fields (see reference rules).
6. Verify whether each relationship has an anchor point: a field or method signature (parameter/return value).
7. Remove technical noise nodes: POJO conversion classes (*Converter/*Assembler/*MapperStruct) and MyBatis technical classes (*Mapper/*Example/*Criteria/SqlSession) are not included in the diagram.
8. Verify whether query responsibility components satisfy the pagination constraint (queryPage or queryByCursor）。
9. Verify table ownership descriptions: for relational persistence models, the Entity node must explicitly state 表: xxx(for reuse of the same table, may write 复用表: xxx）；Repository nodes do not write table ownership comments.
10. Verify Controller node descriptions: the interface prefix must be annotated with 接口前缀: /api/.../; Controllers split by responsibility must each annotate their own prefix.
11. First generate and write the .puml file; when information is insufficient, first write the determinable parts, then annotate uncertain items in comments within the diagram.
12. Check generic syntax: generics in method signatures and field types must directly use <>; prohibited from appearing: ~ generics and </> entities.
13. Check item by item according to the self-check list before giving the final result.

Mandatory output constraints

• Generate only PlantUML class diagram files; the source file extension is fixed as .puml。
• The UML file must be written first, then necessary explanations (path/rendering result) added.
• It is prohibited to fabricate classes, fields, methods, relationships, or enums just to "look complete".
• It is prohibited to draw Dto / Vo / ResVo nodes; they are only allowed to appear in method signatures.
• It is prohibited to draw Page / PageResult / PageResponse and other pagination container nodes.
• It is prohibited to reflect the POJO conversion chain; it is prohibited to draw *Converter/*Assembler/*MapperStruct nodes and toXxx/fromXxx conversion methods.
• It is prohibited to draw MyBatis technical classes (*Mapper/*Example/*Criteria/SqlSession) and XML mapping details.
• It is prohibited to have connection lines without anchor points, connection line labels, or unnecessary noise connection lines.
• List queries must be paginated; prohibited findAll / selectAll / queryAll / listAll / loadAll。
• For relational persistence models, the Entity node description must annotate table ownership:表: xxx(may write 复用表: xxx）；Repository nodes are prohibited from annotating 表: / 复用表: / 无表:。
• The Controller node description must indicate the interface prefix:接口前缀: /api/.../。
• All nodes (classes/interfaces/enums) must have an in-class description:<<说明标题>> + at least 1 line of description.
• Enums only display instances (constants), not member variables or internal methods.
• Generics in method signatures and field types must directly use <>; ~ generics and </> entities are prohibited.
• Colors must be divided by module; it is prohibited to color solely by technical layer while ignoring module boundaries.
• Do not draw the Persistence layer separately;Entity is grouped into the functional sub-blocks of Repository to avoid technical implementation details appearing in the diagram.
• The skill runtime must first detect the ELITEFORGE_SKILL_JAVA_UML_PLANTUML_ASL_JAR environment variable; if it is not set, end directly and remind the user to configure it first.
• Whenever UML content is added or modified, it must be re-rendered successfully using ELITEFORGE_SKILL_JAVA_UML_PLANTUML_ASL_JAR , otherwise do not output the final result.
• The final artifact may only output one *.puml source file and a sibling *.svg; generating extra *.plantuml。
• Do not echo the UML body in the conversation; only return the output file path, rendering result, and necessary error information.

Reference File Reading Strategy

• When handling a normal UML design request, first read references/uml-core-rules.md。
• When the user emphasizes layout, color, readability, or in-class descriptions, then read references/plantuml-template.md。
• When the user requests "give me a template/example that can be modified directly", read references/plantuml-example-template.md。
• When the user is worried about rendering failure or version compatibility, read references/plantuml-validation.md。

Output Style Baseline

• Use top to bottom direction + skinparam linetype ortho。
• by default: first color by module, then organize layered nodes within the module; unless the user explicitly requests it, avoid using external note。
• Enums are not connected by lines by default, to reduce noise.

Output Template

@startuml
top to bottom direction
skinparam linetype ortho

' 先放分层包，再放类定义与关系
' 信息不足时，用注释列出不确定项，仍保持 PlantUML 输出

@enduml

Reference Materials

• General UML Rules and Self-Check
• PlantUML Output Template
• PlantUML Example Template
• PlantUML Version and Validation