Architecture Diagrams Skill

Goal

Turn infrastructure source files or a declared DS_CATALOG_V1 data model into a readable architecture diagram for reviews, ADRs, and design discussions. Preserve the caller's selected output format and the source's authority boundaries.

Infrastructure inputs include Terraform, Bicep, ARM templates, shell scripts, Kubernetes manifests, and Docker or Compose files. Catalog input uses declared entities and relationships from data-catalog, the durable data-catalog skill. It does not infer a data model from SQL or ORM files.

This skill documents infrastructure topology and data models. To document a software system, meaning its containers, its components, and the people and systems around it, use the c4-architecture skill instead.

Success criteria

• The diagram includes only the confirmed source scope.
• Infrastructure sources retain their existing parsing and relationship behavior.
• Catalog diagrams preserve declared entity IDs, endpoints, cardinality, endpoint minimums, join keys, confidence, and evidence basis without inventing relationships.
• Caller preference controls ASCII or Mermaid output.
• Inferred and assumed catalog relationships remain visibly distinct from confirmed relationships.

Constraints

• Treat a diagram as a view over source authority, not a semantic authority of its own.
• Read catalog-erd.md for DS_CATALOG_V1 input, multiplicity mapping, confidence rendering, the catalog output contract, and the Functional Planner compatibility boundary.
• Do not parse SQL DDL, Prisma, SQLAlchemy, or another ORM as catalog input.
• Do not render primary-key, foreign-key, or uniqueness markers for catalog join keys; the catalog declares field names, not database key roles.
• Keep the Feasibility Study Interchange Profile and downstream requirement mappings in their owning workstreams.

Stop rules