Plantuml component diagram
Skill brunojaime/plantuml-diagram-toolkit/skills/plantuml-component-diagram
Skills y herramientas para generar, validar y renderizar diagramas PlantUML
npx -y skills add brunojaime/plantuml-diagram-toolkit --skill plantuml-component-diagramAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 10 days oldThe repository was created 10 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 0 stars0 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
Generate and refine logical UML component diagrams in PlantUML from architecture notes, requirements, or code. Use when the user asks for componentes, modules, services, hexagonal ports/adapters, provided and required interfaces, logical dependencies, or external systems. Exclude deployment location, servers, containers, regions, networks, and runtime topology; route those concerns to the architecture diagram skill.
SKILL.md
3.1 KB, as published. Nobody here has run it
PlantUML Component Diagram
Model what software parts exist, what each part is responsible for, and which functional interfaces connect them.
Boundary
Include:
- applications, modules, services, adapters, repositories, data stores as logical dependencies, and external systems;
- system boundaries and logical groupings;
- provided/required interfaces and generic dependencies.
Exclude:
- machines, devices, pods, containers, ECS tasks, regions, availability zones, subnets, load balancers, ports as deployment endpoints, replica counts, and where a component runs.
A database may appear as a logical dependency named Document Repository.
Do not show its managed instance, server, subnet, or region.
Workflow
- Extract only explicit logical elements and responsibilities.
- Define the system boundary; keep external systems outside.
- Identify the user-facing frontend/channel entry points. Show the user
starting through named frontends instead of a generic
Internetelement when channels are known. - Identify consumer, provider, functional interface, and known binding.
- Use
Consumer -(0- Provider : Interface name\nTechnical bindingwhen roles are known. Use an arrow only for a generic dependency. - Keep hexagonal ports as contracts, not runtime components, unless code structure is explicitly requested.
- Apply conventions.md and the shared semantic visual style. Apply LANG-001 and LANG-002 to every user-visible label and response field.
- Render and visually inspect the SVG.
- Return one
@startuml ... @endumlblock plus explicit assumptions.
Hard rules
- Never show where a component lives.
- Generate explanatory content in Spanish. Preserve official names, protocols, identifiers, and the controlled technical vocabulary allowed by LANG-002.
- Prefer named frontends/channels such as web, mobile, chat, or CLI over a generic Internet component when the user entry points are known.
- Name the interface by capability; HTTPS, REST, JSON, TCP/IP, and a port number are not interface names.
- Do not infer bindings, security, or infrastructure.
- Do not use deployment
node,cloud,artifact, or container notation. - Prefer 5–15 primary elements and split by logical concern when needed.
- Preserve semantic colors when the same element appears in an architecture view; color must never be the only semantic signal.
- Use unique aliases and no remote includes.
When user feedback is reusable, update references/conventions.md; otherwise
keep the decision local to the diagram.