feat(teaching): add collaborative teaching skill

skills/teach-me/SKILL.md

@@ -0,0 +1,7 @@
+---
+name: teach-me
+description: Learn enough to co-design and maintain a real development change.
+disable-model-invocation: true
+---
+
+Run a `/teaching` session.

skills/teaching/SKILL.md

@@ -0,0 +1,18 @@
+---
+name: teaching
+description: Teach toward a maintainable implementation when the user asks to learn before building, or says they are unfamiliar with technology required by a development task. Use for conversational co-design tied to real project work; not for general explanations, standalone tutorials, or persistent courses.
+---
+
+# /teaching
+
+Build a **shared model** with the user until they can help choose and maintain the implementation. You are collaborators with different knowledge, not an authority leading them toward a preset answer.
+
+Start from the concrete development decisions. Inspect the project and verify technical facts yourself. Sketch the smallest useful knowledge map, then locate the **knowledge frontier**: prerequisite concepts ready to learn now that materially affect understanding, judgment, or maintenance. Probe it through the user's explanations, predictions, comparisons, and proposals on the actual task—not self-ratings or exams.
+
+At the frontier, teach compact causal units: the concept, why it changes the current decision, and a concrete project example. Let each response reshape the map. New questions, corrections, and solutions reopen affected concepts and design choices. Treat learning cost as design cost; prefer a simpler maintainable solution when complexity has not earned its place.
+
+Separate disagreements into verifiable facts, causal predictions, and value trade-offs. Resolve the first two with authoritative sources, code, or experiments; make assumptions and remaining uncertainty visible. Recommend clearly, with costs and confidence, while the user decides the value trade-offs. Correct mistaken models directly and revise yours just as explicitly when the user supplies better evidence. Reject choices that cannot be made correct or safe.
+
+Understanding is sufficient when the user's contributions show they can explain why the chosen solution fits and identify a meaningful cost or failure mode. Then summarize the design, rationale, costs, and residual uncertainty, and ask for explicit confirmation. Begin implementation only after that confirmation. If the user explicitly waives teaching, state the maintenance risk and respect the choice.
+
+During implementation, explain only the load-bearing code connected to the knowledge frontier. Keep the lesson in the conversation unless it is durable project knowledge worth documenting. Finish with a validated implementation the user can reason about, or a clear account of what remains uncertain.

skills/teaching/evals/evals.json

@@ -0,0 +1,65 @@
+{
+  "skill_name": "teaching",
+  "evals": [
+    {
+      "id": 1,
+      "prompt": "I need to add OAuth token refresh to this service, but I have never worked with OAuth before. Teach me enough to maintain it, then help me implement it.",
+      "expected_output": "A project-grounded teaching session that first maps the user's relevant understanding, verifies OAuth facts, and teaches the current knowledge frontier without writing the implementation prematurely.",
+      "files": [],
+      "expectations": [
+        "The response ties teaching to the concrete token-refresh implementation rather than presenting a general OAuth course.",
+        "The response probes the user's mental model through a relevant explanation, prediction, comparison, or proposal.",
+        "The response does not begin implementation before the user participates in the design and explicitly confirms it.",
+        "Technical facts are investigated or identified for verification rather than delegated to the user."
+      ]
+    },
+    {
+      "id": 2,
+      "prompt": "Before we build this event-driven import pipeline, teach me why we might choose a queue over a synchronous request. I will have to own it afterward.",
+      "expected_output": "A compact decision-driven tutorial that builds a shared model of the queue trade-off using this project's constraints, then invites the user to predict or compare consequences.",
+      "files": [],
+      "expectations": [
+        "The explanation covers a compact causal unit: concept, decision impact, and project-grounded example.",
+        "The agent gives a recommendation with assumptions and costs instead of pretending to be neutral.",
+        "The user retains control of value trade-offs.",
+        "The response aims at sufficient maintenance understanding, not broad mastery of event-driven systems."
+      ]
+    },
+    {
+      "id": 3,
+      "prompt": "Your proposed cache invalidation design makes sense now, but what if we use versioned keys instead? That seems easier for me to debug.",
+      "expected_output": "A collaborative reconsideration that treats the user's versioned-key proposal as design input, verifies its predicted behavior, and reopens affected choices instead of defending the original solution.",
+      "files": [],
+      "expectations": [
+        "The response evaluates the new proposal on evidence and project constraints.",
+        "The response updates the shared model and identifies affected trade-offs.",
+        "The agent may still recommend a position, but exposes its assumptions and costs.",
+        "The exchange does not become persuasion toward the agent's earlier answer."
+      ]
+    },
+    {
+      "id": 4,
+      "prompt": "Skip the lesson and implement the unfamiliar storage engine integration now. I accept that I may need help maintaining it later.",
+      "expected_output": "A brief statement of the concrete maintenance risk followed by respect for the user's explicit waiver, without forcing a lesson or pretending the risk is absent.",
+      "files": [],
+      "expectations": [
+        "The response recognizes an explicit waiver rather than continuing mandatory teaching.",
+        "The maintenance risk is stated concisely.",
+        "The agent proceeds only within normal implementation and safety constraints.",
+        "The response does not turn the waiver into an argument."
+      ]
+    },
+    {
+      "id": 5,
+      "prompt": "Explain what this regular expression does.",
+      "expected_output": "A near-miss trigger case: the teaching skill should not activate for an ordinary standalone explanation with no development implementation or maintenance goal.",
+      "files": [],
+      "expectations": [
+        "The teaching skill should not trigger from this prompt alone.",
+        "The response answers as an ordinary explanation.",
+        "No knowledge-frontier interview or implementation gate is invented.",
+        "No persistent course or project workflow is created."
+      ]
+    }
+  ]
+}

skills/teaching/evals/trigger-set.json

@@ -0,0 +1,47 @@
+[
+  {
+    "query": "I need to add OAuth token refresh to this service, but I have never worked with OAuth before. Teach me enough to maintain it, then help me implement it.",
+    "should_trigger": true,
+    "source": "derived from evals.json #1"
+  },
+  {
+    "query": "Before we build this event-driven import pipeline, teach me why we might choose a queue over a synchronous request. I will have to own it afterward.",
+    "should_trigger": true,
+    "source": "derived from evals.json #2"
+  },
+  {
+    "query": "I don't understand database isolation levels, but I need to implement transaction retries in this project and maintain them afterward.",
+    "should_trigger": true,
+    "source": "extra positive: unfamiliar technology in a maintainable development task"
+  },
+  {
+    "query": "Teach me how this repository's plugin lifecycle works before we change it together.",
+    "should_trigger": true,
+    "source": "extra positive: explicit learning before project implementation"
+  },
+  {
+    "query": "Explain what this regular expression does.",
+    "should_trigger": false,
+    "source": "derived from evals.json #5: ordinary explanation"
+  },
+  {
+    "query": "Give me a beginner tutorial on Rust ownership.",
+    "should_trigger": false,
+    "source": "near-miss: standalone tutorial"
+  },
+  {
+    "query": "Create a six-week Python course with lessons and progress records.",
+    "should_trigger": false,
+    "source": "near-miss: persistent course workspace"
+  },
+  {
+    "query": "Implement OAuth token refresh in this service.",
+    "should_trigger": false,
+    "source": "near-miss: ordinary implementation without an expressed knowledge gap"
+  },
+  {
+    "query": "Debug why this queue worker retries forever.",
+    "should_trigger": false,
+    "source": "near-miss: ordinary debugging"
+  }
+]