AdeleZhu/teacher-skill: The Repo That Turns a Teacher Into a Rollbackable AI Skill
It splits teaching style, persona, and subject knowledge into separate files, then recombines them into a tutor you can correct, update, and version like code.
- teacher-skill treats pedagogy as a layered artifact, not a single prompt, so the teacher can be edited without losing the original shape.
- Its knowledge layer matters because it captures the route into a concept, not just the fact set behind it.
- Correction and version management turn student feedback into a durable maintenance loop instead of a one-off prompt tweak.
- The repo points at a broader agent-skill future where educational identity can be packaged, synced, and updated like software.
Most AI tutor projects ask what the model should know. teacher-skill asks a better question: how do you preserve the way a specific teacher teaches, and how do you change it without erasing the original? That shift makes the repo feel less like a chatbot experiment and more like version control for pedagogy.
A teacher, split into three files
The repo is an expansion of colleague-skill, but it adds a third axis. Teaching captures method, persona captures voice and judgment, and knowledge captures the route into a topic. The result is not a single prompt blob. It is a profile you can inspect, edit, and recombine.
The pipeline is deliberately modular. intake.md gathers the raw material in rounds, the analyzers break it into structured understanding, the builders write the separate markdown artifacts, and tools/skill_writer.py merges them into one skill file with runtime coordination rules. That last part matters because it tells the model what to privilege when layers conflict.
Why the knowledge layer matters
The knowledge layer is the sharpest idea in the repo. It tries to preserve not just facts but the path a teacher takes into a fact: the everyday analogy, the mnemonic, the first example they always reach for, the sequence they use when a student is stuck. That is tacit knowledge, and it is what makes a favorite teacher feel like a favorite teacher.
同一个 Skill 要在不同 Agent 里各装一遍，版本还不一定一致，管理起来非常混乱。
That matters in a larger ecosystem that is already messy. Skill files move across agents, get duplicated, and drift. A versioned teaching profile is not just a nice-to-have. It is the only way the AI can keep a coherent identity while still accepting corrections.
Correction is a maintenance loop
prompts/correction_handler.md turns disagreement into a patch, not a rewrite. If a student says, "Our teacher would never say that," the system can isolate the mismatch, update the right layer, and then archive the prior version through tools/version_manager.py. That gives the project a safety rail most persona clones lack.
Before this, using skills in KiloCode required manually listing all skills in a main rule.
| Dimension | Generic tutor | colleague-skill | teacher-skill |
|---|---|---|---|
| Core unit | Single prompt that blends tone, facts, and policy. | Teaching and persona split into separate files. | Teaching, persona, and knowledge are separated. |
| Subject knowledge | Usually implicit or generic. | Present, but still secondary to style. | Stored as knowledge paths and entry points. |
| Corrections | Rewrite the prompt and hope for the best. | Manual edits across multiple files. | Correction patches target the right layer. |
| Rollback | None. | Manual history at best. | Previous versions are archived for rollback. |
| Best fit | Fast demos. | Mimicry of a colleague. | A durable, editable teacher model. |
The repo is still early, but the structure is already opinionated. Python handles ingestion and file management, tests cover the writer, and the prompt files are split around distinct jobs instead of one giant instruction. That is the right shape if the goal is to preserve teaching style without letting the style overwhelm the lesson.