---
name: plantuml-component-diagram
description: 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.
---

# 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

1. Extract only explicit logical elements and responsibilities.
2. Define the system boundary; keep external systems outside.
3. Identify the user-facing frontend/channel entry points. Show the user
   starting through named frontends instead of a generic `Internet` element
   when channels are known.
4. Identify consumer, provider, functional interface, and known binding.
5. Use `Consumer -(0- Provider : Interface name\nTechnical binding` when roles
   are known. Use an arrow only for a generic dependency.
6. Keep hexagonal ports as contracts, not runtime components, unless code
   structure is explicitly requested.
7. Apply [conventions.md](references/conventions.md) and the shared
   [semantic visual style](references/visual-style.md).
   Apply [LANG-001 and LANG-002](references/language.md) to every user-visible
   label and response field.
8. Render and visually inspect the SVG.
9. Return one `@startuml ... @enduml` block 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.