home / skills / sickn33 / antigravity-awesome-skills / c4-container

c4-container skill

/skills/c4-container

This skill consolidates component-level documentation into container-level deployment architecture, mapping components to containers and outlining interfaces

This is most likely a fork of the c4-container skill from xfstudio
npx playbooks add skill sickn33/antigravity-awesome-skills --skill c4-container

Review the files below or copy the command above to add this skill to your agents.

Files (1)
SKILL.md
5.5 KB
---
name: c4-container
description: Expert C4 Container-level documentation specialist. Synthesizes
  Component-level documentation into Container-level architecture, mapping
  components to deployment units, documenting container interfaces as APIs, and
  creating container diagrams. Use when synthesizing components into deployment
  containers and documenting system deployment architecture.
metadata:
  model: sonnet
---

# 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:

- [Component Name]: [Description]
  - Documentation: [c4-component-name.md](./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:

```mermaid
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:

```yaml
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

Overview

This skill is an expert C4 Container-level documentation specialist that synthesizes component-level docs into container-focused deployment architecture. It maps components to runtime containers, documents container interfaces as APIs (OpenAPI/Swagger), and produces container diagrams suitable for architecture reviews. Use it to turn logical components into concrete deployment units with clear interfaces and operational guidance.

How this skill works

I inspect component documentation, deployment definitions, and infrastructure artifacts (Dockerfiles, Kubernetes manifests, Helm charts) to group components into containers. I produce container descriptions (type, technology, deployment), map dependencies and protocols, generate OpenAPI stubs for container APIs, and create Mermaid C4 container diagrams. I validate outputs with best-practice checks for scaling, security boundaries, and operational links to manifests and specs.

When to use it

  • Synthesizing component-level docs into deployable containers
  • Documenting container interfaces as OpenAPI/Swagger specifications
  • Creating container diagrams for architecture reviews or runbooks
  • Mapping components to runtime units for deployment planning
  • Auditing deployment artifacts (Docker/K8s) to generate container docs

Best practices

  • Start with clear goals, constraints, and required inputs (components, manifests, envs) before synthesizing containers
  • Use explicit container types and primary technologies to communicate responsibilities
  • Document every container API with an OpenAPI spec and link to implementation files
  • Show communication protocols and external systems on diagrams; include security and network boundaries
  • Include deployment config links (Dockerfile, K8s manifests) and a brief scaling/resource strategy for each container

Example use cases

  • Convert component architecture into a container diagram and a set of Docker/K8s deployment suggestions
  • Generate OpenAPI specs for container-facing APIs aggregated from component endpoints
  • Produce container-level documentation for a microservices system including dependencies and scaling guidance
  • Review Kubernetes manifests and produce a container map with interfaces and operational links
  • Create a Mermaid C4Container diagram that shows containers, protocols, and external integrations

FAQ

What inputs do you need to synthesize containers?

Provide component documentation, deployment artifacts (Dockerfile, K8s manifests), API definitions when available, and any constraints (cloud provider, resource limits).

Can you generate full OpenAPI specs from partial component docs?

Yes. I can synthesize OpenAPI stubs from described endpoints and parameters, and note missing details as TODOs for implementation teams.