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.