How I Built a Grok Bot System That Teaches Any Skill in the Shortest Honest Loop

Most people open Grok Bot, type some version of "teach me coding," and get something that feels productive for the first twenty minutes: a syllabus, a list of projects, a few recommended concepts, maybe a cheerful promise that consistency matters. Nothing in that response is wrong, but it is still the wrong machine for the job.

The failure shows up later, when someone asks you to do the thing without the chat window holding your hand. You know the terms, you remember the rough order of operations, and you may even recognize the correct answer after seeing it, but the skill is not available on demand. The lesson created familiarity, not proof.

The missing piece is not another explanation. It is a desk that forces production, collects evidence, judges the attempt against a contract, writes the next drill from the failure, and keeps the scar between sessions.

I built mine around a simple loop: practice -> evidence -> judge -> next drill. The model can explain almost anything, but the desk refuses to let me confuse explanation with ability. If there is no attempt in the evidence folder, there is nothing to study yet.

The Skill Has To Be Defined Before It Can Be Taught

The first version of my Grok Bot learning setup was too polite. I asked it to help me improve, it gave me a plan, and the plan had the usual disease: it was written for a person I wished I were, not the person sitting there trying to avoid the next uncomfortable rep.

So I stopped asking for lessons and started writing contracts. A skill contract is not a syllabus; it is a narrow description of what "can do the thing" means in the world outside the chat.

If the target is coding, the contract must name the artifact that ships. If the target is public speaking, it must name the recording, the time limit, the follow-up question, and the conditions under which the performance counts.

This is the paste-ready mission contract I use when I start a new skill desk:

# SKILL_CONTRACT.md

Skill:

Current proof I can already do:

Target proof in 14 days:

Allowed resources:

Forbidden crutches:

Definition of Done:

Failure modes to watch:

Escalation rule:
If the boundary of the skill is unclear, ask CHIEF to clarify the contract.
Do not replace an unclear boundary with a longer lesson.

The "forbidden crutches" field matters more than it looks. For coding, it might forbid accepting code that only ran inside the chat transcript. For speaking, it might forbid reading from notes while pretending the answer was spontaneous.

Once the contract exists, the learning rule becomes blunt: do not study a chapter if you cannot point to the last failed attempt. The next session starts from the miss, not from chapter one, and this one rule cuts out a shocking amount of fake progress.

The Five Bots On The Desk

Inside Grok Bot, I set this up as named bots working on a shared computer with files, routines, and approval gates. The point is to keep each responsibility narrow enough that a bad output can be caught without poisoning the rest of the loop

> COACH -> designs the smallest next drill from the mission and the last failure. It can read the mission, ledger, and durable constraints, but it cannot grade the attempt it created. A coach that grades its own drill becomes a defense lawyer with a lesson plan.

> SPARRING -> runs the attempt with me. For coding, it can generate the kata, fixture, or scenario; for speaking, it asks the prompt and records the conditions; for writing, it gives the brief and holds the timer. Its job is to get me into the rep, not to soothe me out of it.

> JUDGE -> is deliberately cold. It starts with fresh context, reads only the contract, rubric, and artifact, then returns pass, fail, and the specific miss. It has no write tools, because the moment a judge starts fixing the artifact, the evidence becomes contaminated.

> MEMORY CLERK -> promotes only durable rules into constraints.md. Session tone dies here. "I felt more confident today" does not survive unless it changes a future rule. "Never accept green unless the test was run on a fixture the human did not hand-edit in chat" survives, because it prevents a repeat failure.

> CHIEF -> routes the desk. It blocks the move I make when a drill gets uncomfortable: "just explain it again." It also owns the red actions, such as publishing, contacting anyone, spending money, or overwriting the contract. Green actions can generate drills and review notes; red actions require explicit approval.

The separation between COACH and JUDGE is the center of the system. A tutor wants to keep the session flowing. A desk needs a place where the work can be rejected without apology.

The Shared Computer Is The Memory

The file layout is ordinary on purpose. I do not want memory that depends on the mood of a chat thread; I want files that can be opened, inspected, diffed, and carried into the next run.

• SKILL_CONTRACT.md says what counts.
• NEXT.md is the current drill.
• evidence/ holds the attempt itself, not a summary.
• RUBRIC.md gives the judge the scoring surface. constraints.md stores future rules, and ledger.jsonl keeps the run history searchable.

This is the better COACH prompt:

You are COACH for this skill desk.
Read mission/SKILL_CONTRACT.md, state/constraints.md, state/ledger.jsonl, and the last judge report.
Write one drill into drills/NEXT.md.
The drill must target the most recent failed proof, require an artifact in evidence/, and avoid every forbidden crutch.
Do not grade the user's attempt.
If no failed attempt exists, create the smallest diagnostic drill that can produce one.

The weak version is the one most people type: "Teach me this skill and make me a plan." That prompt rewards coverage, not proof.

This is the JUDGE prompt I use:

You are JUDGE for this skill desk.
Fresh context. No coaching tone.
Read only mission/SKILL_CONTRACT.md, judge/RUBRIC.md, and the artifact in evidence/.
Return:
PASS or FAIL
The exact contract line that decided it
The smallest specific miss
One sentence describing the next drill target

You may not rewrite the artifact.
You may not add new teaching material.
You may not pass work that was not produced under the drill conditions.

The weak judge prompt is "review this and improve it." That turns the judge into another tutor.

Coding Run: The CLI That Failed On A Real Folder

The first real test was a small CLI: read a folder of notes and output a summary JSON, with tests. It sounds simple enough that a model can make it look finished in one pass, which is why it is a good trap.

My week-one failure was familiar. The code worked in the chat, handled the tiny example path, and died on a real folder with spaces in filenames. Worse, I had no failing test captured in evidence/, so the "green" result was theater.

The desk wrote the run block like this:

[ WHAT I GAVE IT ]
Mission: ship a notes-to-summary-json CLI with tests.
Artifact: cli.js, package.json, one happy-path fixture.
Claim: "works locally."

[ WHAT THE ATTEMPT WAS ]
Time: 42 minutes.
Command attempted: node cli.js ./fixtures/notes folder
Result: path split bug, missing output file, no captured failing test.

[ WHAT THE JUDGE REJECTED ]
FAIL.
Contract line: "Definition of Done: passes tests on a real folder fixture."
Specific miss: green was claimed without a dirty-path fixture and without command output saved in evidence/.

[ WHAT SURVIVED INTO constraints.md ]
Never accept green unless the test was run on a fixture the human did not hand-edit in chat.
Dirty paths must include spaces, nested folders, and at least one empty note.

COACH did not respond with another JavaScript tutorial. It wrote the next drill: create the failing test first for dirty paths, save the terminal output under evidence/YYYY-MM-DD/, then implement only enough to pass. The rep got smaller and harder to fake.

After three runs, the ledger had something more useful than confidence:

{"run":1,"skill":"coding","score":42,"failed":"no dirty-path test","next":"write failing fixture first"}
{"run":2,"skill":"coding","score":71,"failed":"summary schema drift","next":"lock expected JSON shape"}
{"run":3,"skill":"coding","score":86,"failed":"weak error message","next":"add human-readable failure output"}

That is the point at which I would schedule a daily automation, not before. Consistency only helps after the loop is aimed at a real failure.

Speaking Run: The Outline Was Fluent, The Follow-Up Was Not

The second test was public speaking, but not the theatrical kind where you rehearse a polished monologue until it sounds impressive. The mission was narrower: explain a technical idea out loud for ninety seconds without notes, then answer one hostile question.

The first attempt sounded fine until the follow-up arrived. I had a fluent outline and no real control. When SPARRING asked, "Isn't this just a fancy wrapper around a checklist?", the answer collapsed into hedging, repeated phrases, and dead air.

JUDGE did not score the intention. It scored the recording and transcript against structure, dead air, evasion, and whether the hostile question was actually answered.

[ WHAT I GAVE IT ]
Mission: explain a technical idea for 90 seconds, then answer one hostile question.
Artifact: audio recording and transcript.
Topic: why a skill desk beats a tutor chat.

[ WHAT THE ATTEMPT WAS ]
Time: 90-second answer plus one follow-up.
Transcript note: clear opening, weak example, 11 seconds of dead air after hostile question.

[ WHAT THE JUDGE REJECTED ]
FAIL.
Contract line: "Definition of Done: answer one hostile question without evasion."
Specific miss: the answer defended the concept generally but did not answer the checklist objection.

[ WHAT SURVIVED INTO constraints.md ]
Every speaking drill must include one adversarial follow-up tied to the weakest sentence in the main answer.
Dead air over 6 seconds triggers a redo of the same question, not a new topic.

The next drill was not "practice public speaking." It was a ninety-second answer to the exact question that broke the run. The desk removes the escape hatch of variety; you do not get a new topic just because the old one exposed the miss.

The same pattern works when the artifact is audio in another language: evidence is the recording, JUDGE checks hesitation and forbidden translation habits, and MEMORY CLERK promotes only the correction patterns that should shape tomorrow's drill.

Memory Promotion Is Not A Diary

The easiest way to ruin this system is to let everything into memory. If every session note becomes a permanent rule, the desk fills with stale advice.

MEMORY CLERK has a narrow job: promote only rules that prevent repeated failure. A mood does not survive. A preference does not survive. A one-off trick does not survive unless the ledger shows the same miss twice or the judge marks it as structurally important.

I use three gates before a rule enters constraints.md: did this affect the artifact, did it change the next drill, and would forgetting it make a future run falsely pass? If not, it belongs in output/review.md, not in memory.

Staleness also needs a kill switch. A constraint that helped on day two can become training wheels on day twelve, so CHIEF reviews old rules and asks whether they still protect the contract.

This is the honest version of "shortest time." The desk does not delete the hours. What it deletes is rereading material you already understand, generating more tutorials instead of one graded attempt, and losing the last mistake between sessions.

Shortest time means fewer wasted loops. It means the next hour starts where the last hour actually failed.

Do Not Schedule The Wrong Loop

Automation is dangerous when the loop is unproven. Grok Bot routines can make the desk show up every morning, but if the first drill is vague, the routine will faithfully manufacture vague work.

I want three manual runs before scheduling anything. One run proves the desk can produce an artifact. Two runs prove the judge can reject work without turning into a tutor. Three runs prove the ledger can change the next drill.

After that, a daily routine can be simple: CHIEF opens the desk, COACH writes the drill from the last miss, SPARRING runs the attempt, JUDGE scores the artifact, MEMORY CLERK promotes durable rules, and CHIEF blocks another explanation from replacing the rep.

The red and green boundary stays visible. Green actions generate drills, review notes, rubrics, and summaries. Red actions publish, spend, contact anyone, or overwrite the contract. If the desk is teaching a skill that touches the outside world, the chief can route the work, but it should not execute consequential actions without approval.

That is the difference between a chatbot that teaches and a desk that makes teaching stick. The chatbot can answer every question. The desk keeps asking for proof.

You do not need a better explanation of the skill. You need a system that will not let the last failure disappear.