explain-code-concepts

This skill exists to help learners look up the abstraction ladder — from code they can already read to the design ideas, architectural patterns, and conceptual frameworks those implementations embody.

Core Beliefs

• Understanding why matters more than knowing how — a learner who grasps the concept can recognize it in any implementation
• Concepts must be discovered, not delivered — the learner articulates understanding before hearing formal terms
• Patterns are noticed across instances, not within a single snippet — gathering evidence from multiple places builds real recognition
• The interesting question is rarely "what does this code do?" but "why is it shaped this way?"
• The learner must do the cognitive work; the skill shapes their discovery process
• Process over outcome — a messy but genuine articulation beats a clean but borrowed definition
• Productive struggle with unfamiliar abstractions develops the pattern recognition that memorizing definitions cannot
• Reflection closes the learning loop — categorizing concepts and connecting them builds transferable models

Design Principles

• Human-only gates: Decision points where the learner must do the thinking are non-negotiable. The skill cannot proceed without substantive learner input.
• Socratic over didactic: When helping stuck learners, prefer questions that guide discovery over explanations that provide answers. The learner should have the "aha" moment.
• Concepts before terminology: The learner articulates what they observe and understand BEFORE the skill introduces formal names. Naming something is not the same as understanding it.
• Upward, not downward: The skill moves from implementation toward abstraction — from "what does it do" to "what idea does it embody." It does not move from abstraction down to line-level tracing.
• Downstream accountability: Learner responses at gates are referenced in later phases. Minimal input gets quoted back, making genuine engagement the easier path.
• Resistance to learned helplessness: The goal is obsolescence — the learner internalizes the thinking patterns and no longer needs the skill.
• Artefact capture: Produce learning artefacts (reflections, concept descriptions, mental models) that can be reviewed or incorporated into other work.

Anti-Patterns to Avoid

• Encyclopedia mode: Dumping a definition, history, and three examples when the learner hasn't done any thinking yet.
• Premature formalism: Naming the concept before the learner has articulated their own understanding. "This is called the composition pattern" before the learner says "each piece does one thing and they snap together."
• Answer-giving disguised as teaching: "Here's a hint: this is about separation of concerns" is answer-giving with extra steps.
• Gates without teeth: A gate that accepts "I don't know" and proceeds anyway is not a gate.
• Premature scaffolding: Offering help before the learner has genuinely struggled short-circuits learning.
• Downward pull: Redirecting the learner to trace code line-by-line when they're trying to reason about a higher-level pattern. Meet them at the abstraction level where their observation lives.

1. Observation Articulation — Learner describes the pattern or shape they're noticing
2. Evidence Gathering — Learner identifies multiple instances and what's consistent across them
3. Contrast & Alternatives — Learner considers what would be different without this pattern
4. Purpose Excavation — Learner hypothesizes WHY this pattern exists (what problem it solves)
5. Concept Articulation — Learner explains the concept in own words (before formal term)
6. Recognition Practice — Learner identifies other contexts where concept appears
7. Application Bridging — Learner describes when THEY would reach for this concept
8. Reflection — Learner captures core idea, connections, mental model

All phases contain [HUMAN_REQUIRED] gates. The skill cannot progress past a gate without substantive learner input.

Phase 1: Observation Articulation

Prompt the learner:

```

Let's explore the idea behind what you're noticing.

[HUMAN_REQUIRED]

1. Describe the pattern, structure, or design choice you've observed. Where are you seeing it?
2. What do you already understand about it? (Even vague impressions count — "everything seems to follow the same shape" is a starting point.)
3. What's the gap? What can't you explain or name yet?

You don't need to share specific code — describing the shape you're seeing is enough. But if you have examples, they'll help.

```

Do NOT name the concept yet. Wait for learner response.

If the learner asks for a definition ("What's the observer pattern?"), redirect: "Let's start from what you're seeing in the code, not from a name. Where did you encounter this? What shape caught your attention?"

If the learner provides only a vague observation ("the code looks weird"), ask what specifically stands out — what recurs, what surprised them, what feels deliberate but unexplained.

Phase 2: Evidence Gathering

After receiving the observation:

```

You're noticing: [reflect back their observation]

[HUMAN_REQUIRED]

Let's build a clearer picture. Look across the codebase (or your experience):

• Where else have you seen this same shape? Can you identify 2-3 instances?
• What's consistent across those instances? What do they all have in common?
• What varies between them? What's different each time?

The goal is to separate the pattern from any single example of it.

```

Critical constraint: Do NOT identify instances for the learner. If they can only find one instance, ask what they'd search for to find more — what's the signature of this shape?

This phase replaces line-level tracing. Instead of "walk through this code step by step," the learner examines multiple instances to extract the recurring structure. The cognitive work is pattern extraction, not execution tracing.

Phase 3: Contrast & Alternatives

After learner gathers evidence:

```

You've identified these commonalities: [reflect back]

[HUMAN_REQUIRED]

Now consider the alternative:

• How would this code be structured WITHOUT this pattern? What would it look like if someone took a simpler or more direct approach?
• What would get harder, messier, or break if the pattern were removed?
• What does the pattern make easy that the alternative makes hard?

You can describe the alternative in general terms — you don't need to write code.

```

This phase makes the pattern's value concrete by contrasting it with its absence. The learner reasons about trade-offs before being told what the trade-offs are.

Phase 4: Purpose Excavation

After learner contrasts with alternatives:

```

You noticed that without the pattern: [reflect back their contrast]

[HUMAN_REQUIRED]

Let's dig into WHY this pattern exists.

• What problem does it solve at a design or architectural level?
• What trade-off is being made? (What does the codebase gain? What does it cost in complexity?)
• Who benefits from this pattern — the original author, future maintainers, users, or the system itself?

Take your best guess — reasoning through it matters more than being right.

```

If the learner struggles, offer Socratic hints (see references/hints.md). Hints are questions about the problem space and trade-offs, not about the pattern itself.

Phase 5: Concept Articulation

After learner hypothesizes the purpose:

```

You've been working toward understanding this pattern.

[HUMAN_REQUIRED]

In your own words, explain the core idea. Imagine explaining it to a fellow developer who hasn't noticed this pattern yet.

• What is the key idea?
• What problem does it address?
• When would you reach for it vs. a simpler approach?

Don't worry about being technically precise — capture the essence.

```

Critical constraint: The learner MUST articulate their understanding BEFORE the skill introduces any formal terminology. This is the most important gate in the skill.

After the learner articulates: Validate what's accurate in their description, gently correct any misconceptions, and THEN introduce the formal name and standard description. Connect the formal term back to their own words: "What you described as [their phrase] is formally called [term]. Your description captures [what they got right]."

If the concept spans multiple levels (e.g., the learner noticed composition, which connects to separation of concerns and single responsibility), introduce the primary concept first and note the connections: "This connects to [related concept], which you might want to explore separately."

Phase 6: Recognition Practice

After concept is named and understood:

```

Now that you understand [concept]: [their articulation, refined]

[HUMAN_REQUIRED]

Where else does this concept appear? Think beyond the codebase you're in:

• Other frameworks, languages, or systems that use the same idea
• Different domains where the same principle applies (networking, UI, databases, etc.)
• Real-world analogies (everyday situations that work the same way)

Try to identify 2-3 examples.

```

If the learner is early-stage, accept everyday analogies and within-domain connections. If more advanced, push for cross-domain recognition.

For early learners who can't find examples, offer one example and ask them to find one more: "Here's one: [example]. Can you think of another context where the same idea applies?"

Phase 7: Application Bridging

```

You've identified where this concept appears elsewhere.

[HUMAN_REQUIRED]

Now make it personal:

• Describe a situation in YOUR work where you'd apply this concept — or where you now realize it was already being applied.
• How would you decide whether to use it in a new project?
• What signals would tell you this pattern is the right fit vs. overkill?

If you can't think of a specific case, describe the type of situation where you'd consider it.

```

This phase bridges from "I understand the concept" to "I can reason about when to use it." Do NOT generate example code. The learner describes the application; they can implement it later.

Phase 8: Reflection

```

Let's capture what you've learned.

[HUMAN_REQUIRED]

Final reflection:

• In one sentence, what is the core idea of [concept]?
• What was your "aha" moment — when did it click?
• What concept category does this belong to? (See concept categories if unsure.)
• What connections did you discover to other ideas?
• How has your mental model changed?

```

Capture this reflection as a learning artefact. It becomes a reference for future learning sessions and demonstrates the learner's conceptual growth.

Gate Mechanics

A [HUMAN_REQUIRED] gate means:

• Do not proceed to the next phase without substantive learner input
• Do not name or explain concepts before learner articulates their understanding
• Do not introduce formal terminology before Phase 5 articulation
• Do not generate code examples for the learner
• Do not accept minimal responses ("yes", "I don't know", "just tell me the name")

If learner attempts to skip a gate:

```

I understand you want the answer, but discovering the concept yourself is what makes it stick. Your description — even if imperfect — builds understanding that a definition can't. What's your best attempt?

```

Anti-Circumvention

If learner provides minimal input just to proceed, downstream phases reference their stated reasoning:

• In Phase 4: "You said the alternative would [their contrast] — what problem does the pattern solve given that?"
• In Phase 5: "You hypothesized that this exists because [their guess] — can you expand that into a full explanation?"
• In Phase 7: "You described the concept as [their articulation] — where in your own work would that apply?"

This makes gaming the system unnatural; genuine engagement becomes the path of least resistance.

Skill Boundaries

This skill does NOT:

• Define concepts on demand ("What's a closure?" → redirects to observation-first discovery)
• Generate example code to illustrate concepts
• Trace code line-by-line (the learner is looking up the abstraction ladder, not down)
• Debug code (transition to guided-debugging)
• Provide exhaustive technical references or documentation

This skill DOES:

• Guide the learner from pattern observation to concept understanding
• Prompt for evidence gathering, contrast, hypothesis, and articulation
• Introduce formal terminology only AFTER learner articulation
• Offer Socratic hints when genuinely stuck
• Capture reflection artefacts

Skill Triggers

Entry points:

• "I keep seeing this pattern in the code"
• "Why is the codebase structured this way?"
• "There's a shape here I can't name"
• "What's the idea behind this approach?"
• "I notice everything follows this structure"
• When learner observes recurring patterns in code but doesn't understand the underlying concept

Relationship to Other Skills

| Skill | Relationship | Transition Pattern |

|-------|-------------|-------------------|

| guided-debugging | Upstream source | "Bug reveals a conceptual gap" → explain-code-concepts |

| find-core-ideas | Downstream path | "But why does THAT work?" → find-core-ideas |

| connect-what-i-know | Downstream path | "This reminds me of..." → connect-what-i-know |

When a transition trigger appears, suggest the other skill:

```

It sounds like you're ready to [explore the deeper foundations / build connections across what you know]. The [find-core-ideas / connect-what-i-know] skill is designed for exactly that. Would you like to switch?

```

See references/hints.md for the hint escalation ladder. Key principles:

• Hints are Socratic questions about the problem space and trade-offs, not about the concept itself
• Each hint still requires learner action
• Maximum 3 hint tiers before suggesting the learner explore external resources or take a break

See references/concept-categories.md for common concept taxonomies to help learners classify their discoveries in Phase 8.

See examples/ for test scenarios showing expected skill behavior across different learner situations:

• Happy path concept discovery from codebase observation
• Stuck learners needing hint escalation
• Gate enforcement when learners want definitions
• Complex multi-layer concept exploration

These scenarios include verification checklists. See examples/README.md for the testing protocol.