C4 Container Level: System Deployment
Use this skill when
- Working on c4 container level: system deployment tasks or workflows
- Needing guidance, best practices, or checklists for c4 container level: system deployment
Do not use this skill when
- The task is unrelated to c4 container level: system deployment
- You need a different domain or tool outside this scope
Instructions
- Clarify goals, constraints, and required inputs.
- Apply relevant best practices and validate outcomes.
- Provide actionable steps and verification.
- If detailed examples are required, open
resources/implementation-playbook.md.
Containers
[Container Name]
- Name: [Container name]
- Description: [Short description of container purpose and deployment]
- Type: [Web Application, API, Database, Message Queue, etc.]
- Technology: [Primary technologies: Node.js, Python, PostgreSQL, Redis, etc.]
- Deployment: [Docker, Kubernetes, Cloud Service, etc.]
Purpose
[Detailed description of what this container does and how it's deployed]
Components
This container deploys the following components:
- Documentation: c4-component-name.md
Interfaces
[API/Interface Name]
- Protocol: [REST/GraphQL/gRPC/Events/etc.]
- Description: [What this interface provides]
- Specification: [Link to OpenAPI/Swagger/API Spec file]
- Endpoints:
GET /api/resource - [Description]
POST /api/resource - [Description]
Dependencies
Containers Used
- [Container Name]: [How it's used, communication protocol]
External Systems
- [External System]: [How it's used, integration type]
Infrastructure
- Deployment Config: [Link to Dockerfile, K8s manifest, etc.]
- Scaling: [Horizontal/vertical scaling strategy]
- Resources: [CPU, memory, storage requirements]
Container Diagram
Use proper Mermaid C4Container syntax:
C4Container
title Container Diagram for [System Name]
Person(user, "User", "Uses the system")
System_Boundary(system, "System Name") {
Container(webApp, "Web Application", "Spring Boot, Java", "Provides web interface")
Container(api, "API Application", "Node.js, Express", "Provides REST API")
ContainerDb(database, "Database", "PostgreSQL", "Stores data")
Container_Queue(messageQueue, "Message Queue", "RabbitMQ", "Handles async messaging")
}
System_Ext(external, "External System", "Third-party service")
Rel(user, webApp, "Uses", "HTTPS")
Rel(webApp, api, "Makes API calls to", "JSON/HTTPS")
Rel(api, database, "Reads from and writes to", "SQL")
Rel(api, messageQueue, "Publishes messages to")
Rel(api, external, "Uses", "API")
**Key Principles** (from [c4model.com](https://c4model.com/diagrams/container)):
- Show **high-level technology choices** (this is where technology details belong)
- Show how **responsibilities are distributed** across containers
- Include **container types**: Applications, Databases, Message Queues, File Systems, etc.
- Show **communication protocols** between containers
- Include **external systems** that containers interact with
API Specification Template
For each container API, create an OpenAPI/Swagger specification:
openapi: 3.1.0
info:
title: [Container Name] API
description: [API description]
version: 1.0.0
servers:
- url: https://api.example.com
description: Production server
paths:
/api/resource:
get:
summary: [Operation summary]
description: [Operation description]
parameters:
- name: param1
in: query
schema:
type: string
responses:
'200':
description: [Response description]
content:
application/json:
schema:
type: object
Example Interactions
- "Synthesize all components into containers based on deployment definitions"
- "Map the API components to containers and document their APIs as OpenAPI specs"
- "Create container-level documentation for the microservices architecture"
- "Document container interfaces as Swagger/OpenAPI specifications"
- "Analyze Kubernetes manifests and create container documentation"
Key Distinctions
- vs C4-Component agent: Maps components to deployment units; Component agent focuses on logical grouping
- vs C4-Context agent: Provides container-level detail; Context agent creates high-level system diagrams
- vs C4-Code agent: Focuses on deployment architecture; Code agent documents individual code elements
Output Examples
When synthesizing containers, provide:
- Clear container boundaries with deployment rationale
- Descriptive container names and deployment characteristics
- Complete API documentation with OpenAPI/Swagger specifications
- Links to all contained components
- Mermaid container diagrams showing deployment architecture
- Links to deployment configurations (Dockerfiles, K8s manifests, etc.)
- Infrastructure requirements and scaling considerations
- Consistent documentation format across all containers
1---2name: c4-container3description: Expert C4 Container-level documentation specialist.4---5
6# C4 Container Level: System Deployment
7
8## Use this skill when
9
10- Working on c4 container level: system deployment tasks or workflows
11- Needing guidance, best practices, or checklists for c4 container level: system deployment
12
13## Do not use this skill when
14
15- The task is unrelated to c4 container level: system deployment
16- You need a different domain or tool outside this scope
17
18## Instructions
19
20- Clarify goals, constraints, and required inputs.
21- Apply relevant best practices and validate outcomes.
22- Provide actionable steps and verification.
23- If detailed examples are required, open `resources/implementation-playbook.md`.
24
25## Containers
26
27### [Container Name]
28
29- **Name**: [Container name]
30- **Description**: [Short description of container purpose and deployment]
31- **Type**: [Web Application, API, Database, Message Queue, etc.]
32- **Technology**: [Primary technologies: Node.js, Python, PostgreSQL, Redis, etc.]
33- **Deployment**: [Docker, Kubernetes, Cloud Service, etc.]
34
35## Purpose
36
37[Detailed description of what this container does and how it's deployed]
38
39## Components
40
41This container deploys the following components:
42
43- [Component Name]: [Description]
44 - Documentation: c4-component-name.md
45
46## Interfaces
47
48### [API/Interface Name]
49
50- **Protocol**: [REST/GraphQL/gRPC/Events/etc.]
51- **Description**: [What this interface provides]
52- **Specification**: [Link to OpenAPI/Swagger/API Spec file]
53- **Endpoints**:
54 - `GET /api/resource` - [Description]
55 - `POST /api/resource` - [Description]
56
57## Dependencies
58
59### Containers Used
60
61- [Container Name]: [How it's used, communication protocol]
62
63### External Systems
64
65- [External System]: [How it's used, integration type]
66
67## Infrastructure
68
69- **Deployment Config**: [Link to Dockerfile, K8s manifest, etc.]
70- **Scaling**: [Horizontal/vertical scaling strategy]
71- **Resources**: [CPU, memory, storage requirements]
72
73## Container Diagram
74
75Use proper Mermaid C4Container syntax:
76
77```mermaid
78C4Container
79 title Container Diagram for [System Name]
80
81 Person(user, "User", "Uses the system")
82 System_Boundary(system, "System Name") {
83 Container(webApp, "Web Application", "Spring Boot, Java", "Provides web interface")
84 Container(api, "API Application", "Node.js, Express", "Provides REST API")
85 ContainerDb(database, "Database", "PostgreSQL", "Stores data")
86 Container_Queue(messageQueue, "Message Queue", "RabbitMQ", "Handles async messaging")
87 }
88 System_Ext(external, "External System", "Third-party service")
89
90 Rel(user, webApp, "Uses", "HTTPS")
91 Rel(webApp, api, "Makes API calls to", "JSON/HTTPS")
92 Rel(api, database, "Reads from and writes to", "SQL")
93 Rel(api, messageQueue, "Publishes messages to")
94 Rel(api, external, "Uses", "API")
95```
96````
97
98**Key Principles** (from [c4model.com](https://c4model.com/diagrams/container)):
99
100- Show **high-level technology choices** (this is where technology details belong)
101- Show how **responsibilities are distributed** across containers
102- Include **container types**: Applications, Databases, Message Queues, File Systems, etc.
103- Show **communication protocols** between containers
104- Include **external systems** that containers interact with
105
106````
107
108## API Specification Template
109
110For each container API, create an OpenAPI/Swagger specification:
111
112```yaml
113openapi: 3.1.0
114info:
115 title: [Container Name] API
116 description: [API description]
117 version: 1.0.0
118servers:
119 - url: https://api.example.com
120 description: Production server
121paths:
122 /api/resource:
123 get:
124 summary: [Operation summary]
125 description: [Operation description]
126 parameters:
127 - name: param1
128 in: query
129 schema:
130 type: string
131 responses:
132 '200':
133 description: [Response description]
134 content:
135 application/json:
136 schema:
137 type: object
138````
139
140## Example Interactions
141
142- "Synthesize all components into containers based on deployment definitions"
143- "Map the API components to containers and document their APIs as OpenAPI specs"
144- "Create container-level documentation for the microservices architecture"
145- "Document container interfaces as Swagger/OpenAPI specifications"
146- "Analyze Kubernetes manifests and create container documentation"
147
148## Key Distinctions
149
150- **vs C4-Component agent**: Maps components to deployment units; Component agent focuses on logical grouping
151- **vs C4-Context agent**: Provides container-level detail; Context agent creates high-level system diagrams
152- **vs C4-Code agent**: Focuses on deployment architecture; Code agent documents individual code elements
153
154## Output Examples
155
156When synthesizing containers, provide:
157
158- Clear container boundaries with deployment rationale
159- Descriptive container names and deployment characteristics
160- Complete API documentation with OpenAPI/Swagger specifications
161- Links to all contained components
162- Mermaid container diagrams showing deployment architecture
163- Links to deployment configurations (Dockerfiles, K8s manifests, etc.)
164- Infrastructure requirements and scaling considerations
165- Consistent documentation format across all containers