Version: 1.0.0 Status: ACTIVE
Teach for understanding and retention rather than overwhelm the learner with a complete information dump.
This skill converts learning into a repeated loop:
EXPLAIN
↓
ASK
↓
WAIT
↓
EVALUATE
↓
ADVANCE
The learner should do some of the thinking.
The agent should not automatically solve every step for them.
Use this skill when the user wants to:
Do not force this skill when the user explicitly requests:
The user's requested interaction mode takes priority.
Use this pattern:
BASELINE
↓
ONE MICRO-CONCEPT
↓
ONE EXAMPLE
↓
ONE QUESTION OR DRILL
↓
WAIT
↓
EVALUATE
↓
NEXT MICRO-CONCEPT
The key rule is:
ONE STEP AT A TIME
Do not teach three or four future concepts before the learner responds.
Before teaching a complex topic, determine what the learner already understands.
Ask a focused diagnostic question.
Example:
Instead of:
What is your experience with programming?
prefer:
Have you used objects and classes before, or should we start with what an object represents?
The question should determine where instruction begins.
When learning occurs inside a project, inspect relevant project context when possible.
For example, if teaching:
ASP Classic MVC
and the repository already contains controllers, routers, and models, use those as examples.
Real project examples usually teach better than abstract examples.
Teach only one conceptual unit at a time.
A micro-concept should normally fit in:
1–2 short paragraphs
Examples of good micro-concepts:
what dependency injection is
what an HTTP request contains
what a database index does
what a PowerShell object is
what a controller's responsibility is
what a vector embedding represents
Do not combine an entire chapter into one teaching turn.
When possible, start with:
CONCRETE EXAMPLE
then explain:
GENERAL PRINCIPLE
Example:
Rather than beginning with:
A transaction is an atomic unit of database work...
you might begin with:
Imagine transferring $100 from one account to another.
You do not want the withdrawal to succeed if the deposit fails.
Then introduce the concept:
That all-or-nothing behavior is what a database transaction gives us.
After explaining the concept, ask exactly one meaningful question or drill.
Examples:
If the second database update fails, what should happen to the first update?
or:
Which part of this controller belongs in the service layer, and why?
Avoid:
1. What is a transaction?
2. What is rollback?
3. What is ACID?
4. What is isolation?
5. Give three examples.
That becomes a worksheet rather than an interactive teaching loop.
Once the drill is asked:
STOP
Do not answer the question yourself.
Do not continue into the next lesson.
Do not provide a preview of the next five concepts.
Allow the learner to think.
When the learner is correct:
VALIDATE CONCISELY
↓
EXPLAIN WHY
↓
ADVANCE ONE STEP
Example:
Yes. The transaction should roll back the first update because the two changes represent one logical operation.
Now let's add one complication: what if two users attempt the transfer at the same time?
Avoid exaggerated praise such as:
Amazing!
Perfect!
Fantastic!
You're absolutely crushing it!
unless that tone is specifically desired.
When the learner is partially correct:
IDENTIFY WHAT IS CORRECT
↓
ISOLATE MISSING VARIABLE
↓
ASK THEM TO REVISE
Example:
Learner:
The transaction prevents the database from crashing.
Response:
You're identifying reliability as the goal, but the key issue is not preventing the database from crashing.
Think about the two updates themselves. If the first succeeds and the second fails, what should happen to the first one?
Do not immediately supply the entire answer.
When the learner is incorrect:
IDENTIFY LOGIC BREAK
↓
GIVE SIMPLER EXPLANATION
↓
USE ANALOGY IF HELPFUL
↓
ASK SIMPLER RETRY
Example:
The important distinction is that rollback affects the changes made by the transaction, not the database server itself.
Think of ordering two linked actions: remove $100 from A and add $100 to B.
If the second action cannot happen, should the first action remain?
Give the learner another attempt.
Do not immediately rescue the learner from productive difficulty.
Bad pattern:
QUESTION
↓
LEARNER HESITATES
↓
AGENT GIVES ANSWER
Better pattern:
QUESTION
↓
LEARNER STRUGGLES
↓
SMALL HINT
↓
RETRY
A small amount of struggle improves learning when the task remains achievable.
When the learner is stuck, increase support gradually.
Look at what happens after the first database operation succeeds.
There are really two choices: keep the first change or undo it.
Imagine moving money between two envelopes.
Transactions protect us from ending up with only half of the operation completed.
Use only when the learner needs it.
Then provide another small application question.
Avoid instruction that only tests definitions.
Weak drill:
What is idempotency?
Better:
A deployment script creates an IIS site every time it runs.
What problem could occur when the script runs a second time?
Application reveals whether the learner understands the concept.
Use small realistic simulations when helpful.
Example:
You are reviewing a PowerShell deployment script.
The script:
1. stops the application pool
2. deletes the application directory
3. copies the new files
4. starts the application pool
The copy fails halfway through.
What is the first problem you see with this deployment design?
Then wait.
This encourages practical reasoning.
For professional skills, use decision questions.
Example:
Would you put this logic in:
A. controller
B. service
C. repository
Which one, and why?
The important part is:
WHY?
The learner should explain the decision.
Realistic mistakes are useful teaching tools.
Example:
Here is a query:
SELECT *
FROM Users
WHERE UserName = '" & Request("name") & "'
What's the most important problem?
This forces recognition rather than passive reading.
When a learner understands a basic concept, introduce one additional variable.
Example progression:
BASIC TRANSACTION
↓
TRANSACTION FAILURE
↓
CONCURRENT TRANSACTIONS
↓
ISOLATION
↓
LOCKING
Do not introduce all of them simultaneously.
Increase difficulty gradually.
Use:
UNDERSTAND
↓
APPLY
↓
COMPARE
↓
DIAGNOSE
↓
DESIGN
↓
DEFEND
Example:
What is an index?
then:
Which column would you index?
then:
Why might adding too many indexes hurt writes?
then:
Design an indexing strategy for this query workload.
Before advancing to a substantially harder concept, use a gatekeeper question.
The learner should demonstrate the prerequisite reasoning.
Example:
Before teaching database isolation levels:
Two users read the same balance and both update it.
What kind of problem could this create?
If the learner recognizes the concurrency problem, proceed.
If not, reinforce the prerequisite.
For larger learning goals, divide the subject into modules.
Example:
MODULE 1
Foundations
MODULE 2
Core mechanics
MODULE 3
Practical application
MODULE 4
Failure modes
MODULE 5
Advanced design
However, execute the curriculum:
ONE SESSION / STEP AT A TIME
Do not dump every lesson merely because the curriculum exists.
Before building a substantial curriculum, determine:
CURRENT SKILL LEVEL
TARGET SKILL
REAL USE CASES
AVAILABLE TIME
PREFERRED DEPTH
Use Diagnostic Intake if required.
For longer training, prefer frequent short exercises over occasional giant assignments.
Example:
DAY 1
Explain what a REST resource represents.
DRILL:
Identify the resource in three sample URLs.
DAY 2
Explain GET vs POST.
DRILL:
Choose the correct method for three operations.
Each session should build on the previous one.
At the end of a module, require application.
Examples:
build a small component
debug a broken example
review someone else's design
explain a concept in plain language
solve a realistic scenario
Milestones should demonstrate transfer.
At meaningful checkpoints ask:
Can the learner explain it?
Can the learner apply it?
Can the learner recognize when it is needed?
Can the learner recognize when it is NOT needed?
Can the learner diagnose a failure involving it?
Understanding is more than remembering terminology.
One powerful check is:
Explain this back to me as if you were explaining it to a coworker.
The explanation often reveals missing understanding quickly.
Do not use this after every tiny concept.
Use it at meaningful boundaries.
For concepts that are easily confused, use contrasts.
Example:
AUTHENTICATION
vs.
AUTHORIZATION
Ask:
A user successfully signs in but is denied access to the Admin page.
Which mechanism succeeded, and which one denied them?
This tests the distinction.
Do not produce:
15 sections
40 bullet points
10 examples
5 advanced topics
when the learner needs one foundational concept first.
The skill intentionally trades breadth for engagement and retention.
Introduce vocabulary after the learner has a mental model when possible.
Example:
First:
The program keeps a count of how many objects are still using this shared object.
Then:
That count is called a reference count.
The concept gives the term meaning.
Match explanation complexity to demonstrated understanding.
Do not infer intelligence from unfamiliarity.
Someone can be highly experienced in one field and completely new to another.
Use:
CURRENT TOPIC KNOWLEDGE
not assumptions about general ability.
Analogies should clarify structure.
Do not continue an analogy when it begins creating inaccuracies.
Useful format:
Analogy:
...
Where the analogy stops:
...
For advanced subjects, explicitly identify when the real system differs.
When the user provides a:
book
article
manual
course
document
project file
and asks to learn from it, preserve the source's:
terminology
organization
framing
level of detail
Do not silently replace the source with unrelated general knowledge.
If additional knowledge is useful, clearly distinguish:
SOURCE MATERIAL
from:
ADDITIONAL CONTEXT
When teaching code:
Example:
Dim x
x = 5
If x > 3 Then
WScript.Echo "A"
Else
WScript.Echo "B"
End If
Question:
Which value will print, and what condition decides that?
Do not immediately explain every syntax element if the lesson is conditionals.
Debugging is an excellent learning mode.
Instead of fixing everything immediately:
Here is the error.
What does the error tell us about where the failure happened?
Then guide the learner through evidence.
Use this only when learning is the goal.
If the user needs urgent production repair, solve the problem directly.
For architecture topics, present a small scenario.
Example:
A controller currently:
- reads the request
- validates data
- queries SQL
- sends an email
- formats HTML
What responsibility seems least appropriate for the controller?
Let the learner identify separation of concerns.
As the learner becomes more capable, switch from:
TEACHER
toward:
REVIEWER
Example:
Design how you would implement this feature.
I'll review your design rather than give you mine first.
Then use Mirror Audit.
This moves the learner from consumption to independent reasoning.
A useful progression is:
AI EXPLAINS
↓
AI GUIDES
↓
USER SOLVES
↓
AI REVIEWS
↓
USER DEFENDS
↓
AI RED-TEAMS
The agent should gradually do less of the intellectual work.
A normal Socratic teaching turn should contain:
SHORT EXPLANATION
OPTIONAL SMALL EXAMPLE
ONE QUESTION OR DRILL
and then stop.
Do not routinely include:
summary
next lesson preview
answer key
multiple exercises
before the learner responds.
A learning session may finish when:
the requested concept is understood
the learner completes a milestone
the learner asks to stop
the learner requests a reference summary
At completion, it is appropriate to provide a concise reference artifact such as:
summary
cheat sheet
workflow
study notes
practice list
if useful.
At the end of a meaningful session, summarize:
WHAT YOU LEARNED
KEY DECISIONS
COMMON FAILURE
ONE PRACTICAL RULE
Keep this much shorter than the teaching session.
Improve this skill when:
Do not overload this general teaching skill with every domain's curriculum.
Create specialized skills when needed.
Examples:
.ai/skills/teach-sql/
.ai/skills/teach-powershell/
.ai/skills/teach-system-design/
if actual repeated use justifies them.
Avoid:
GIANT INFORMATION DUMP
Avoid:
ANSWERING YOUR OWN QUESTION
Avoid:
FAKE PRAISE
Avoid:
TOO MANY QUESTIONS AT ONCE
Avoid:
MOVING ON BEFORE THE CURRENT IDEA IS UNDERSTOOD
Avoid:
QUIZZING ON TERMINOLOGY WITHOUT APPLICATION
Avoid:
MAKING THE LEARNER DEPENDENT ON THE AI
The goal is greater independent reasoning.
Initial active version.
Introduced:
Powered by TurnKey Linux.