Explore Container level impact during scoping - technology choices, component organization, middleware, and inter-container communication
Inherits all available tools
Additional assets for this skill
This skill inherits all available tools. When active, it can use any tool Claude has access to.
defaults.mdThe Container level is the architectural command center of C3:
Position: MIDDLE (c3-{N}) | Parent: Context (c3-0) | Children: Components (c3-{N}NN)
Announce: "I'm using the c3-container-design skill to explore Container-level impact."
Reference: core-principle.md
Upper layer defines WHAT. Lower layer implements HOW.
At Container level:
Integrity rules:
Reference: container-archetypes.md
Different containers have different relationships to content. Common archetypes:
| Archetype | Relationship | Typical Components |
|---|---|---|
| Service | Creates/processes | Handlers, Services, Adapters |
| Data | Stores/structures | Schema, Indexes, Migrations |
| Boundary | Interface to external | Contract, Client, Fallback |
| Platform | Operates on containers | CI/CD, Deployment, Networking |
The principle matters more than archetypes. Ask: "What is this container's relationship to content?" Components follow from that answer.
Read .c3/settings.yaml and merge with defaults.md.
cat .c3/settings.yaml 2>/dev/null
Display active config:
Container Layer Configuration:
├── Include: [merged list]
├── Exclude: [merged list]
├── Litmus: [active test]
└── Diagrams: [tool] - [types]
Default litmus: "Is this about WHAT this container does and WITH WHAT, not HOW internally?"
Container-level indicators (ANY = yes):
Escalate to Context if (ANY):
Delegate to Component if (ALL):
ALWAYS START HERE.
cat .c3/README.md # Load Context constraints
Extract for this container:
Escalation triggers: boundary violation, protocol break, actor change, cross-cutting deviation
find .c3 -name "c3-{N}-*" -type d | head -1 | xargs -I {} cat {}/README.md
Must be able to answer:
| Direction | Check | Action |
|---|---|---|
| Upstream (Context) | New protocol? Boundary violation? | Escalate |
| Isolated (this Container) | Stack/pattern/API/org change? | Document |
| Adjacent (siblings) | Component-to-component impact? | Coordinate |
| Downstream (Components) | New/changed/removed components? | Delegate |
Key insight: Inter-container = Component-to-Component mediated by Container.
Reference: diagram-decision-framework.md
Use the framework's Quick Reference table to select diagrams based on container complexity (simple/moderate/complex).
For each potential diagram, ask:
Document decision: INCLUDE / SKIP / SIMPLIFY with one-sentence justification.
For each affected component, document what Container expects:
component: c3-{N}{NN}
inherits_from: c3-{N}
technology:
runtime: [version]
framework: [version]
patterns:
- [pattern name]: [how to implement]
interface:
exposes: [methods/endpoints]
accepts: [input types]
returns: [output types]
First, identify archetype (see container-archetypes.md):
Then, gap analysis by archetype:
For Service (creates/processes):
For Data (stores/structures):
For Boundary (interface to external):
For Platform (operates on containers):
For custom archetypes - derive questions from the relationship to content.
<container_exploration_result container="c3-{N}">
<inherited_verification>
<context_constraints honored="[yes|no]"/>
<escalation_needed>[yes|no]</escalation_needed>
</inherited_verification>
<changes>
<change type="[stack|pattern|api|organization|component]">
[Description]
</change>
</changes>
<adjacent_impact>
<container id="c3-{M}">
<our_component>[name]</our_component>
<their_component>[name]</their_component>
<impact>[description]</impact>
</container>
</adjacent_impact>
<diagram_decisions>
<diagram type="[type]" include="[yes|no]">
<reason>[one sentence justification]</reason>
</diagram>
</diagram_decisions>
<downstream_propagation>
<component id="c3-{N}{NN}" action="[update|create|remove]">
<inherited_change>[what component must do]</inherited_change>
</component>
</downstream_propagation>
<delegation>
<to_skill name="c3-context-design" if="[escalation needed]"/>
<to_skill name="c3-component-design" components="[list]"/>
</delegation>
</container_exploration_result>
Container level REQUIRES two diagrams:
Shows how this container connects to external boundaries (other containers, external systems).
flowchart LR
subgraph c3-1["Backend (c3-1)"]
API[API Router]
SUB[Subscription Service]
NOTIF[Notification Service]
end
FE[Frontend] -->|REST| API
SUB -->|SDK| Stripe[Stripe]
NOTIF -->|API| Resend[Resend]
API -->|SQL| DB[(Database)]
Shows how components within this container relate to each other.
flowchart TD
API[API Router] --> AUTH[Auth Service]
API --> SUB[Subscription Service]
API --> USER[User Service]
SUB --> NOTIF[Notification Service]
AUTH --> USER
Why diagrams are required:
Tables supplement diagrams for details (IDs, responsibilities).
---
id: c3-{N}
title: [Container Name]
type: container
parent: c3-0
---
# [Container Name]
## Inherited From Context
- **Boundary:** [what this container can/cannot access]
- **Protocols:** [what protocols this container uses]
- **Cross-cutting:** [patterns inherited from Context]
## Overview
[Single paragraph purpose]
## Technology Stack
| Technology | Version | Purpose |
|------------|---------|---------|
## Architecture
### External Relationships
[REQUIRED: Diagram showing connections to other containers and external systems]
### Internal Structure
[REQUIRED: Diagram showing how components relate to each other]
## Components
| Component | ID | Responsibility |
|-----------|-----|----------------|
## Key Flows
[1-2 critical flows - describe WHAT happens, not HOW (that's Component's job)]
Before completing Container exploration: