I have been thinking a lot about what would it look like if a teacher could own the file that shapes how an AI assistant responds to them?
Not a cloud account. Not a hidden preference panel. Not a vendor dashboard that changes under your feet.
A plain text file. That question led me to create teacher.md.
It starts with writing yourself into a file
I have been doing a version of this for a while with my own writing and work. I have tried to figure out how to write myself, my voice, my style, my tendencies, into a MarkDown (MD) file. A MD file is just a plaintext file, nothing really special about it.
The basic idea is to boil down the essence of who you are and how you operate into something explicit and readable. You provide specific details about the ways in which you think, learn, and teach.
Teachers already do something like this. We ask educators to write a teaching philosophy statement. In that document you identify how you think, how you feel, how you operate as an educator. You spell out what theories matter to you, what you believe about how students learn, what you think good assessment looks like. The hope is that when you go teach, you make that philosophy a reality.
teacher.md is the same idea, made practical for working with AI.
The idea
teacher.md is a small, readable profile file that helps a local AI assistant behave like it actually understands a classroom. It describes the teacher’s grade level, subjects, teaching style, output preferences, supports, and boundaries. The goal is not to make the model smarter in some abstract sense. The goal is to make its help more useful, more consistent, and more grounded in the realities of teaching.
That means the assistant should know things like:
- whether it is helping with lesson prep, handouts, or tutoring support
- whether students will ever interact with it directly
- how much text is too much
- what a good scaffold looks like
- what kinds of feedback are helpful
- what to avoid, especially when privacy matters
In other words, the file acts like a classroom-specific operating manual.
Why this matters for AI specifically
One of the real concerns with AI tools in teaching is that they give you materials that don’t align with how you think, or what you believe. For an educator, this is problematic as the outputs do not match how you actually think or what you actually believe about learning. The model does not know your students. It does not know your tone. It does not know that you never use multiple choice, or that you always include sentence starters, or that your class needs chunked directions.
Writing a teacher.md file gives you a chance to spell that out. It keeps your professional judgment at the center instead of letting the model fill in the gaps with whatever it learned from the internet.
Why I wanted this
I have spent enough time with AI tools to know that most of the friction is not really about “using AI.”
It is about context.
Every new chat asks the same question in a different form: who are you, what are you trying to do, and how should I help?
If the answer lives only in a vendor account or a buried prompt, it is easy to lose track of it. If the answer lives in a file you can open, read, edit, and version, the whole thing becomes more transparent. That matters to me for a few reasons.
- Teachers should be able to see and control what guides the assistant.
- Classroom data should not be assumed safe just because the tool feels local or friendly.
- Teacher judgment should stay central.
- The assistant should help with preparation, not replace decisions that belong to the teacher.
That last point matters a lot. This project is not trying to automate teacher judgment. It is trying to reduce the busywork that gets in the way of it.
What teacher.md actually contains
The profile I documented is intentionally practical. It includes:
- classroom context
- teaching philosophy
- curriculum and pacing notes
- preferred output style
- accommodations and scaffolds
- assessment and feedback preferences
- boundaries and guardrails
- examples of what good and bad output look like
The structure is simple on purpose. A teacher should not need to decode a complicated system just to get a useful response.
If the assistant is going to help with a fourth-grade reading lesson, it should already know that short sentences, clear directions, and lots of white space are probably better than a dense block of text. If the teacher prefers student-friendly materials with a teacher note, that should be part of the default. If the classroom needs chunked directions or sentence starters, that should be baked in too.
That is the promise of the profile. Less re-explaining, more usefulness.
How to actually build one
I started with a template — a set of questions organized into sections. You can access this, and suggest edits at github.com/wiobyrne/teacher.
From there, a teacher has a few options.
The simplest is to answer the questions on paper. No AI required. Treat it exactly like a teaching philosophy statement, just shorter, more specific, and structured so a tool can eventually use it. When you are done, you have the file. You can share it with an AI tool later, or not.
The AI-assisted path is to give the template to any AI tool of your choice. I tried to design this to be model-agnostic — it should work with ChatGPT, Claude, a local model, whatever you prefer. The AI walks you through the questions section by section. It pushes back a little. It asks follow-up questions to get at what you actually think and believe, not just what you write on the first pass. I tested this with different simulated teachers at different levels of clarity, and the model kept trying to get to the root of what the person valued.
At the end, the AI synthesizes everything into a finished teacher.md file.
The best case is that the file does not stop there. You keep adding to it, revising it as your teaching changes, updating it when you try something new and it works. It becomes a living document — a record of how you think about teaching and what you have learned.
What I hope this becomes
My hope is that teacher.md becomes a small but useful pattern for teacher-owned AI support.
Not a giant platform. Not a flashy demo. Just a practical workflow that helps teachers get better materials, faster, without giving up control of their classroom context.
If something feels off, you can open the file and see why. If the classroom changes, you can revise it. If the teacher wants a different tone, a different output style, or a different set of supports, the document can evolve with them.
If you want the system to serve the classroom, the classroom should get to define the system.
Go check it out here github.com/wiobyrne/teacher.