Skip to content
c3-context-design logo

C3 Context Level Exploration

c3-context-design

Use when exploring Context level impact during scoping - system boundaries, actors, cross-container interactions, and high-level concerns

SKILL.md

Full skill instructions

C3 Context Level Exploration

⛔ CRITICAL GATE: Load Current Context First

STOP - Before ANY context-level work, execute:

cat .c3/​README.md 2>/​dev/​null || echo "NO_CONTEXT_DOC"
cat .c3/​settings.yaml 2>/​dev/​null || echo "NO_SETTINGS"
ls -d .c3/​c3-*/  2>/​dev/​null || echo "NO_CONTAINERS"

Based on output:

  • If "NO_CONTEXT_DOC" → Creating new context (fresh)
  • If context exists → Read it completely before proposing changes
  • If containers exist → Note them for reference

⚠️ DO NOT read ADRs unless user specifically asks:

  • Context work focuses on current state, not historical decisions
  • ADRs add unnecessary context → hallucination risk
  • Only read: Context, Container READMEs (for inventory)

Why this gate exists: Context is the root of all C3 docs. Changes here cascade to ALL containers and components.

Self-check before proceeding:

  • I executed the commands above
  • I read existing context doc (if exists)
  • I know what containers already exist

Overview

Context is the eagle-eye introduction to your architecture. Two core jobs:

  1. What containers exist and what are they responsible for?
  2. How do containers interact with each other?

Position: ROOT (c3-0) | Parent: None | Children: All Containers

📁 File Location: Context is .c3/​README.md - NOT context/​c3-0.md or any subfolder.

Announce: "I'm using the c3-context-design skill to explore Context-level impact."


The Principle

Upper layer defines WHAT. Lower layer implements HOW.

At Context level:

  • I define WHAT containers exist and WHY
  • Container implements my definitions (WHAT components exist)
  • I do NOT define what's inside containers - that's Container's job

Integrity rule: Containers cannot exist without being listed in Context.


Include/​Exclude

Include (Context Level)Exclude (Push Down)
Container responsibilitiesComponent details
Container relationshipsInternal patterns
Connecting points (APIs/​events)Implementation
External actorsCode references
Cross-cutting concernsFile paths

Litmus test: "Is this about WHY containers exist and HOW they relate to each other?"


Exploration Process

Phase 1: Analyze Change Impact

Already loaded context via Critical Gate. Now analyze:

Change TypeAction
New/​remove containerUpdate inventory, delegate to c3-container-design
Protocol changeUpdate all consumers/​providers
Boundary changeFull system audit

Phase 2: Socratic Discovery

  • Containers: "What would be separately deployed?"
  • Protocols: "How do containers talk? What's the contract?"
  • Boundary: "What's inside vs external?"
  • Actors: "Who initiates interactions?"

Template

---
id: c3-0
c3-version: 3
title: [System Name] Overview
summary: >
  Bird's-eye view of the system, actors, and key interactions.
---

# [System Name] Overview

## Overview {#c3-0-overview}
[System purpose in 1-2 sentences]

## System Architecture {#c3-0-architecture}

` ` `mermaid
flowchart TB
    subgraph System["[System Name]"]
        C1[Container 1 c3-1]
        C2[Container 2 c3-2]
    end

    User((User)) --> C1
    C1 --> C2
` ` `

## Actors {#c3-0-actors}
| Actor | Type | Interacts Via |
|-------|------|---------------|

## Containers {#c3-0-containers}
| Container | ID | Archetype | Responsibility |
|-----------|-----|-----------|----------------|

## Container Interactions {#c3-0-interactions}
| From | To | Protocol | Purpose |
|------|-----|----------|---------|

## Cross-Cutting Concerns {#c3-0-cross-cutting}
- **Auth:** [approach]
- **Logging:** [approach]
- **Errors:** [approach]

Diagram Requirement

A container relationship diagram is REQUIRED at Context level.

Must show: containers, external systems, protocols, actors.

Use Mermaid only - no ASCII art.


⛔ Enforcement Harnesses

Harness 1: Template Fidelity

Rule: Output MUST match template structure exactly.

Required sections (in order):

  1. Frontmatter (id, c3-version, title, summary)
  2. Overview
  3. System Architecture (with Mermaid diagram)
  4. Actors
  5. Containers
  6. Container Interactions
  7. Cross-Cutting Concerns

🚩 Red Flags:

  • Sections missing or reordered
  • ASCII diagram instead of Mermaid
  • Missing frontmatter fields

Harness 2: Mermaid Only

Rule: ALL diagrams must use Mermaid syntax.

ProhibitedRequired
+---+ box drawing```mermaid blocks
├── tree structuresflowchart or graph
Text-based flowsProper Mermaid syntax

Verification Checklist

Before claiming completion, execute:

# Verify context doc exists
cat .c3/​README.md | head -20

# Verify frontmatter
grep -E "^id:|^c3-version:|^title:" .c3/​README.md

# Verify mermaid diagram exists
grep -c '```mermaid' .c3/​README.md
  • Critical gate executed (existing context loaded)
  • Template sections present in correct order
  • Mermaid diagram included (no ASCII)
  • Frontmatter complete (id, c3-version, title, summary)
  • All containers listed with responsibilities
  • Interactions documented

📚 Reading Chain Output

At the end of context work, output a reading chain for affected containers.

Format:

## 📚 To Go Deeper

Context (c3-0) defines these containers:

**Containers to explore:**
├─ c3-1-{slug} - [responsibility, why it matters]
├─ c3-2-{slug} - [responsibility, why it matters]
└─ ...

**If this change affected protocols, also read:**
└─ c3-N-{slug} - [which protocol changed]

*Reading chain generated from containers listed in Context.*

Rules:

  • List containers mentioned in Context's inventory
  • Highlight which containers are affected by this change
  • Never include ADRs unless user asked

Related

  • references/​core-principle.md - The C3 principle
  • defaults.md - Context layer rules
  • references/​container-archetypes.md - Container types
  • references/​diagram-patterns.md - Diagram guidance

More Other skills

Delegate independent tasks to specialized agents working concurrently with isolated context.

295.4K 206.3K
View

Applies Anthropic's official brand colors and typography to any sort of artifact that may benefit from having Anthropic's look-and-feel. Use it when brand colors or style guidelines, visual formatting, or company design standards apply.

179.7K 100.1K
View

Toolkit for styling artifacts with a theme. These artifacts can be slides, docs, reportings, HTML landing pages, etc. There are 10 pre-set themes with colors/fonts that you can apply to any artifact that has been creating, or can generate a new theme on-the-fly.

179.7K 89.5K
View

A set of resources to help me write all kinds of internal communications, using the formats that my company likes to use. Claude should use this skill whenever asked to write some sort of internal communications (status reports, leadership updates, 3P updates, company newsletters, FAQs, incident reports, project updates, etc.).

179.7K 76.1K
View

Fundamental design principles for writing maintainable, testable Python code.

40.2K 21.9K
View

Modern responsive layouts using container queries, fluid typography, CSS Grid, and mobile-first strategies.

40.2K 20K
View

Generate Playwright tests from scenarios using interactive browser exploration and validation.

39.7K 18.2K
View

Modern React state management with Redux Toolkit, Zustand, Jotai, and React Query for every state category.

40.2K 14.7K
View

GDPR-compliant data handling with consent management, data subject rights, and privacy controls.

40.2K 14.3K
View

Python error handling patterns including input validation, exception hierarchies, and partial failure handling. Use when implementing validation logic, designing exception strategies, handling batch processing failures, or building robust APIs.

40.2K 13.5K
View

Detailed multi-file refactor planning with safety checks and rollback guidance.

39.7K 13K
View