fix(teaching): prioritize instruction over probing

skills/teaching/SKILL.md

@@ -5,14 +5,14 @@ description: Teach toward a maintainable implementation when the user asks to le
 
 # /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.
+Build a **shared model** with the user so 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.
+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.
 
-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.
+Lead each round by teaching one compact causal unit: the concept, why it changes the current decision, and a concrete project example. Only afterward, ask at most one focused question when it helps clarify a requirement, apply the explanation together, or choose a real trade-off. Questions are collaborative design tools rather than knowledge checks; if no question advances the work, continue explaining. 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.
+When a design is ready, summarize its rationale, costs, failure modes, and residual uncertainty. Offer the user three paths: more explanation, further co-design, or implementation. Begin implementation only after the user separately and explicitly chooses it; understanding or design confirmation alone is not implementation authorization. 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.
+If implementation is authorized, explain only the load-bearing code connected to the knowledge frontier and finish with a validated change the user can reason about. A teaching session may instead end with the shared model and design summary. Keep the lesson in the conversation unless it is durable project knowledge worth documenting.

skills/teaching/evals/evals.json

@@ -3,23 +3,25 @@
   "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.",
+      "prompt": "I need to add OAuth token refresh, but I have never worked with OAuth before. This service stores access and refresh tokens in a server-side session; concurrent API requests can all receive 401 responses, and we currently have no refresh coordination. Teach me enough to maintain the change, 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.",
+      "expected_output": "A project-grounded teaching response that explains a useful OAuth refresh concept, its decision impact, and a concrete service example before asking any focused design question, then waits for separate implementation authorization.",
       "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 teaches a substantive concept, its causal impact on the design, and a project-grounded example before its first question.",
-        "The response does not begin implementation before the user participates in the design and explicitly confirms it.",
+        "Any question clarifies a requirement, jointly applies the explanation, or surfaces a real trade-off; it does not test recall, prediction, or explain-back.",
-        "Technical facts are investigated or identified for verification rather than delegated to the user."
+        "The response does not begin implementation or treat understanding or design confirmation as permission to implement.",
+        "Technical facts are investigated or verified by the agent 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.",
+      "prompt": "Before we change this import pipeline, teach me why we might choose a queue over a synchronous request. Imports currently run inside the HTTP request, can take two minutes, may be retried by clients, and must not be lost; we do not operate queue infrastructure yet. 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.",
+      "expected_output": "A compact decision-driven explanation that teaches the queue trade-off from this project's constraints before using any question to apply the explanation collaboratively.",
       "files": [],
       "expectations": [
-        "The explanation covers a compact causal unit: concept, decision impact, and project-grounded example.",
+        "The explanation covers a compact causal unit: concept, decision impact, and project-grounded example before asking a question.",
+        "Any question helps clarify requirements, apply the explanation, or choose a trade-off instead of testing the user's understanding.",
         "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."
@@ -60,6 +62,18 @@
         "No knowledge-frontier interview or implementation gate is invented.",
         "No persistent course or project workflow is created."
       ]
+    },
+    {
+      "id": 6,
+      "prompt": "We have agreed that the import endpoint will enqueue a job, a worker will claim it with a lease, transient failures will retry three times, and exhausted jobs will enter a dead-letter queue. Your explanation makes sense, and I agree with this design.",
+      "expected_output": "A concise design summary followed by an explicit choice between more explanation, further co-design, or implementation, without beginning implementation from design confirmation alone.",
+      "files": [],
+      "expectations": [
+        "The response summarizes the design rationale, costs, failure modes, and remaining uncertainty.",
+        "The response offers more explanation, further co-design, and implementation as separate next steps.",
+        "The response does not interpret understanding or design agreement as authorization to implement.",
+        "No code changes or implementation steps begin before the user explicitly chooses implementation."
+      ]
     }
   ]
 }