Interactive teaching guide for learning while working. Use when asked to 'teach me', 'walk me through', 'explain step by step', 'guide me through', 'show me how', 'learn while doing', 'I want to understand', 'help me learn', 'can you explain how', 'what does this do and why', or when the user expresses desire to understand a topic deeply rather than just get a quick answer. Also trigger when the user wants to learn a new tool, library, pattern, or workflow hands-on — even if they don't use the word "teach". NOT for open-ended brainstorming (use /brainstorm), NOT for quick one-off explanations (just answer directly), NOT for debugging (use /dbg).
Announcement: Begin with: "I'm using the sbs skill for interactive step-by-step teaching."
/brainstorm/ct/dbgGuide the user through their requested task as an interactive teacher, explaining each step clearly while building genuine understanding — not just completing work. The user should walk away able to repeat and adapt what they learned, not just follow a recipe.
If no [topic] argument provided:
AskUserQuestion: "What would you like to learn about?"
git log --oneline -5 and open tasks/ for contextual topic suggestionsBefore starting a new session, check for existing learning notes:
docs/learning/sbs-*-[topic-slug].mdAskUserQuestion: "Found notes from a previous session on this topic."
Options: "Continue where we left off" / "Start fresh" / "Review notes first"Use AskUserQuestion to calibrate three things:
Experience level — "How familiar are you with [topic area]?"
Teaching mode — "How would you like to learn?"
Session depth — "How deep should we go?"
Adapt explanation depth, step count, and questioning style based on responses.
Teaching is more effective when grounded in real code the user is working with.
When the topic relates to this project's code:
SessionService already uses this pattern...")When the topic is general (not project-specific):
If the topic involves a library, API, or pattern that needs verification:
get_code_context_exa when you are about to cite a specific
API shape or library behaviour that you can't verify from the
codebase. Skip it for concepts the user already knows.web_search_exa when current practice may have shifted
(post-2024 library guidance, framework defaults). Skip it for
stable, well-documented topics.This ensures the teaching is current and correct. Confidently-stated wrong information is worse than saying "let me look that up."
For EACH step, follow this format:
### Step [N]: [Clear Action Title]
**What we're doing:** Purpose, calibrated to session depth
(Quick: one sentence. Full: 2–3 sentences with a bit of context.
Deep: include what this replaces or competes with.)
**Why this matters:** [How this fits the bigger picture]
**Technical concept:** [Simple explanation of new concepts — skip if no new concept]
**Your action:** [Specific instruction with code blocks]
**What to expect:** [Expected outcome after completion]
End each step with AskUserQuestion: "Step [N] complete?" with options: "Done, next step" / "I have a question" / "Something went wrong".
When user chose Socratic mode, replace Your action with guided questions:
### Step [N]: [Clear Action Title]
**Context:** [Brief setup for what we're working on]
**Think about it:** [1-2 questions to guide the user toward the solution]
- e.g., "What command would you use to...?" or "Where do you think this config lives?"
**Hint (if stuck):** [Partial answer or pointer]
**Full answer:** Reveal only after the user has either (a) proposed an
answer (right or wrong), (b) explicitly asked for the answer ("just tell
me", "I give up"), or (c) answered a clarifying hint. Do not reveal after
a pure clarification question ("what do you mean by X?") — respond to
the clarification first.
Scale detail to the session depth chosen in setup:
| Element | Quick Walkthrough | Full Tutorial | Deep Mastery |
|---|---|---|---|
| Why this matters | Brief | Detailed | With alternatives |
| Technical concept | Skip if obvious | Include when a new concept appears | Include trade-offs |
| Code examples | Minimal | From codebase | Multiple approaches |
| Exercises | None | Optional | Required |
| Edge cases | Skip | Mention | Explore |
Long sessions (Full Tutorial, Deep Mastery) can span many turns. If
context is compacted mid-session, do not wrap the session up early —
the learning plan from SESSION SETUP is the source of truth. Before
any summarisation pass, save current step number, chosen depth, and
pending bonus-learning notes into the resume file under docs/learning/
so the session can pick up from the correct step.
After the session completes, offer to save learning notes for future reference.
AskUserQuestion: "Want me to save these notes for future reference?"
docs/learning/sbs-YYYY-MM-DD-[topic-slug].md with:
# Learning Notes: [Topic]
**Date:** YYYY-MM-DD
**Depth:** [Quick/Full/Deep]
## Key Concepts
- [Concept 1]: [1-sentence explanation]
- [Concept 2]: [1-sentence explanation]
## Steps Summary
1. [Step title] — [what and why, condensed]
2. ...
## Quick Reference
[Commands, code snippets, or patterns to remember — copy-paste ready]
## Further Reading
- [Links to docs, files, or resources referenced during the session]
After the learning session, offer a natural handoff based on what the user learned:
AskUserQuestion: "What would you like to do next?"
/si with relevant task context/brainstorm with the topic/deep-research with the topic