Ctx Chain

Effect

Define dependencies between sub-contexts. Phase 1 must complete before Phase 2 can begin. Structures phased execution of complex projects, making it clear which phase you’re in and what prerequisites are met.

When to Use

• A project has 3+ phases of staged execution
• Earlier phases gate later ones (infra → deploy → auth → production)
• Some work can run in parallel while other work must follow strict order

How It Works

1. Document dependencies in the parent ctx

## Sub Contexts (Chain)

| Phase | Theme | File | Depends On | Status |
|-------|-------|------|------------|--------|
| 1 | GCP Infra | project/gcp-infra.md | — | ✅ Done |
| 2 | Deploy | project/deploy.md | Phase 1 | 🔧 In Progress |
| 3 | Auth | project/auth.md | Phase 2 | ⏳ Waiting |
| 4 | Production | project/production.md | Phase 3 | ⏳ Waiting |

2. Include dependency info in the sub-ctx

# Deploy — Sub ctx

**Parent ctx**: project_resume.md
**Phase**: 2
**depends_on**: Phase 1 (GCP Infra) ✅
**blocks**: Phase 3 (Auth)
**Status**: 🔧 In Progress

3. Progression rules

• Only start phases where all depends_on are ✅
• On phase completion, update blocked sub-contexts from “waiting” to “ready”
• Phases with the same depends_on can run in parallel (fork point)

Phase 1 (Infra)
  ├─ Phase 2a (Backend)   ← parallel
  ├─ Phase 2b (Frontend)  ← parallel
  └─ Phase 3 (Integration) ← requires both 2a + 2b

Combinations

Card	Synergy
Ctx Tree	Prerequisite. Chain adds ordering to Tree’s sub-contexts
Ctx Branch	Cut a branch per phase. Chain + Branch = “phased branch management”
Dryrun	Pre-validate before entering the next phase. Insert Dryrun at chain transitions
Ship	Final phase shipping decision. Full chain completion = Ship execution

---

“What advances out of order will inevitably break somewhere. When in a hurry, trust the chain.” — Eris

Want to use this card permanently? Convert it directly into a SKILL.md — Effect → Overview, When to Use → Trigger, How It Works → Steps.