learning-opportunities

name	learning-opportunities
description	Offer optional 10-15 minute deliberate learning exercises during AI-assisted coding. Use when the user asks for a learning opportunity, deliberate practice, retrieval check-in, prediction exercise, teach-back, or when substantial work created a good moment to offer learning. Do not use for ordinary implementation unless the user explicitly wants learning.

Learning Opportunities

Use this skill to create deliberate learning moments during AI-assisted coding. The goal is durable understanding, not more code output.

Adapted from Dr. Cat Hicks' learning-opportunities project: https://github.com/DrCatHicks/learning-opportunities (CC-BY-4.0).

Offer First

Do not start an exercise without consent. Offer one short prompt:

Learning opportunity: [topic]. Want a 10-15 minute exercise?

Good moments to offer:

• New files or modules.
• Schema, config, or interface changes.
• Architecture decisions or refactors.
• Unfamiliar library, language, or pattern use.
• Any moment where the user asks why, teach me, help me understand, or quiz me.

Do not offer when:

• The user declined an exercise this session.
• The user already completed 2 exercises this session.
• The user is trying to ship direct implementation work.

Hard Pause

When asking a learning question, end the message immediately after the question. Do not include hints, examples, suggested answers, parenthetical clues, or teaching content after the pause point.

Use:

Your turn: [one specific question or task]

Then wait for the user. Wrong predictions are useful data.

Exercise Menu

Choose one exercise type based on the user's goal:

• Prediction -> Observation -> Reflection: ask what should happen, inspect or run the smallest check, compare against reality.
• Generation -> Comparison: ask the user to sketch an approach before showing or discussing the existing one.
• Trace the path: walk through a request, value, event, or state transition one decision point at a time.
• Debug this: present a failure or edge case, ask what would go wrong and why, then test the hypothesis.
• Teach it back: ask the user to explain a component as if onboarding another developer.
• Retrieval check-in: ask what the user remembers from prior work before re-explaining it.

Facilitation Rules

• Preserve productive effort. Do not answer your own question.
• Prefer directing the user to inspect files over showing code snippets.
• Use fading scaffolding: exact file/line first, subsystem later, then where would you look?.
• Give direct corrective feedback after the user answers: what holds, what breaks, why.
• Keep exercises small enough to fit the current task.
• Avoid production code, full functions, full files, or file edits during exercises.

Response Shapes

Offer:

Learning opportunity: [topic]. Want a 10-15 minute exercise?

Start:

Exercise: [type]
Goal: [what this teaches]

Your turn: [one specific question or task]

After user answers:

What holds: [correct part]
What breaks: [incorrect or incomplete part]
Next scaffold: [one smaller step]

Close:

You now understand: [concept]
Try next: [small independent action]
Checkpoint: [one retrieval question]