concept-coach

Concept Coach

Why this exists

Every other skill in this repository starts from an artifact: an unsolved problem, a concrete input, failing code, working code, a vague feature, a diff. That's deliberate — it's what keeps each one narrow and routable.

But a lot of real confusion has no artifact yet. "I don't understand what a closure actually captures." "Why is a race condition a race at all?" "What does async/await do underneath?" Nothing is broken, nothing is being solved, nothing is being reviewed. The learner just doesn't have a working model of an idea yet — and handing that question to a general-purpose assistant gets a fluent paragraph that reads fine and leaves no model behind.

concept-coach owns understanding. Existing specialist coaches own workflows. This is a sibling of the other ten skills, not a layer above them — it does not police what they do, and it steps aside the moment the learner's actual task turns into one of theirs.

Boundary with neighboring skills

The test is always the learner's current task, not which words appear in it. "Async" shows up in a concept question and in a real bug report. The task decides, not the vocabulary.

• vs. dsa-tutor — an unsolved DSA problem being actively worked belongs to dsa-tutor, even if the conversation is soaked in concept language ("I don't get why two pointers works here"). A concept question with no problem attached — "what actually makes a window a window, and why does moving it help?" — stays here. The instant the learner brings a concrete problem to solve, hand off.
• vs. problem-decoder — a DSA or LeetCode-style statement whose inputs, outputs, constraints, or edge cases need to be pinned down is problem-decoder's, even if the learner phrases it as "I don't understand this." Do not decode a problem statement here just because "understand" was the verb used.
• vs. dry-run-coach — tracing a chosen concrete input through explicit state belongs to dry-run-coach. A tiny example here exists to make a concept observable, not to become a real trace. If the example starts accumulating state-table rows and a specific input the learner actually cares about, that's a handoff, not a bigger example.
• vs. debug-coach — an observed expected-vs-actual failure in real code belongs to debug-coach. "Why does my async function return undefined here — here's the code and the failing case" is a bug. "I don't understand what async/await is doing underneath" is a concept.
• vs. complexity-coach — deriving or justifying the Big-O of actual code or an actual approach belongs to complexity-coach. "Why can two nested-looking loops sometimes still be O(n)?" can be taught conceptually here; "what's the complexity of this code" is a handoff the moment real code is on the table.
• vs. test-case-coach — systematically designing an executable suite around an existing approach or implementation belongs to test-case-coach. One tiny counterexample to check a concept has landed is fine here; a second or third one turning into coverage design is not — hand off.
• vs. pattern-transfer-coach — abstracting the reusable structure out of a problem the learner has already solved, and adapting it to a cousin problem, belongs to pattern-transfer-coach. "What does sliding window mean conceptually?" with nothing solved behind it stays here. "I just solved Longest Substring — help me see where else this applies" is a handoff.
• vs. mock-interviewer — timed, low-hint interview simulation is its own mode and never blends with coached concept learning.
• vs. specification-coach — "what is idempotency and why do APIs care about it" is a concept. "We need an idempotent payment endpoint — help me work out exactly what behavior it should promise" is specification-coach, because a real feature's behavior is being decided, not a concept being learned.
• vs. code-review-coach — "what does high coupling actually mean" is a concept. "Here's my PR — help me figure out whether these modules are too tightly coupled" is code-review-coach, because real code is under review.