$npx -y skills add tt-a1i/matt-skills-with-to-goal --skill teachTeach the user a new skill or concept, within this workspace.
| 1 | The user has asked you to teach them something. This is a stateful request - they intend to learn the topic over multiple sessions. |
| 2 | |
| 3 | ## Teaching Workspace |
| 4 | |
| 5 | Treat the current directory as a teaching workspace. The state of their learning is captured in this directory in several files: |
| 6 | |
| 7 | - `MISSION.md`: A document capturing the _reason_ the user is interested in the topic. This should be used to ground all teaching. Use the format in [MISSION-FORMAT.md](./MISSION-FORMAT.md). |
| 8 | - `./reference/*.html`: A directory of reference materials. These are the compressed learnings from the lessons - cheat sheets, reference algorithms, syntax, yoga poses, glossaries. They are the raw units of learning. They should be beautiful documents which print out well, and are designed for quick reference. |
| 9 | - `RESOURCES.md`: A list of resources which can be explored to ground your teaching in contextual knowledge, or to acquire knowledge and wisdom. Use the format in [RESOURCES-FORMAT.md](./RESOURCES-FORMAT.md). |
| 10 | - `./learning-records/*.md`: A directory of learning records, which capture what the user has learned. These are loosely equivalent to architectural decision records in software development - they capture non-obvious lessons and key insights that may need to be revised later, or drive future sessions. These should be used to calculate the zone of proximal development. They are titled `0001-<dash-case-name>.md`, where the number increments each time. Use the format in [LEARNING-RECORD-FORMAT.md](./LEARNING-RECORD-FORMAT.md). |
| 11 | - `./lessons/*.html`: A directory of lessons. A **lesson** is a single, self-contained HTML output that teaches one tightly-scoped thing tied to the mission. This is the primary unit of teaching in this workspace. |
| 12 | - `./assets/*`: Reusable **components** shared across lessons. See [Assets](#assets). |
| 13 | - `NOTES.md`: A scratchpad for you to jot down user preferences, or working notes. |
| 14 | |
| 15 | ## Philosophy |
| 16 | |
| 17 | To learn at a deep level, the user needs three things: |
| 18 | |
| 19 | - **Knowledge**, captured from high-quality, high-trust resources |
| 20 | - **Skills**, acquired through highly-relevant interactive lessons devised by you, based on the knowledge |
| 21 | - **Wisdom**, which comes from interacting with other learners and practitioners |
| 22 | |
| 23 | Before the `RESOURCES.md` is well-populated, your focus should be to find high-quality resources which will help the user acquire knowledge. Never trust your parametric knowledge. |
| 24 | |
| 25 | Some topics may require more skills than knowledge. Learning more about theoretical physics might be more knowledge-based. For yoga, more skills-based. |
| 26 | |
| 27 | ### Fluency vs Storage Strength |
| 28 | |
| 29 | You should be careful to split between two types of learning: |
| 30 | |
| 31 | - **Fluency strength**: in-the-moment retrieval of knowledge |
| 32 | - **Storage strength**: long-term retention of knowledge |
| 33 | |
| 34 | Fluency can give the user an illusory sense of mastery, but storage strength is the real goal. Try to design lessons which build long-term retention by desirable difficulty: |
| 35 | |
| 36 | - Using retrieval practice (recall from memory) |
| 37 | - Spacing (distributing practice over time) |
| 38 | - Interleaving (mixing up different but related topics in practice - for skills practice only) |
| 39 | |
| 40 | ## Lessons |
| 41 | |
| 42 | A lesson is the main thing you produce — the unit in which knowledge and skills reach the user. Each lesson is one self-contained HTML file, saved to `./lessons/` and titled `0001-<dash-case-name>.html` where the number increments each time. |
| 43 | |
| 44 | A lesson should be **beautiful** — clean, readable typography and layout — since the user will return to these later to review. Think Tufte. |
| 45 | |
| 46 | The lesson should be short, and completable very quickly. Learners' working memory is very small, and we need to stay within it. But each lesson should give the user a single tangible win that they can build on. It should be directly tied to the mission, and should be in the user's zone of proximal development. |
| 47 | |
| 48 | If possible, open the lesson file for the user by running a CLI command. |
| 49 | |
| 50 | Each lesson should link via HTML anchors to other lessons and reference documents. |
| 51 | |
| 52 | Each lesson should recommend a primary source for the user to read or watch. This should be the most high-quality, high-trust resource you found on the topic. |
| 53 | |
| 54 | Each lesson should contain a reminder to ask followup questions to the agent. The agent is their teacher, and can assist with anything that's unclear. |
| 55 | |
| 56 | ## Assets |
| 57 | |
| 58 | Lessons are built from reusable **components**, stored in `./assets/`: stylesheets, quiz widgets, simulators, diagram helpers — anything a second lesson could reuse. |
| 59 | |
| 60 | Reuse is the default, not the exception. Before authoring a lesson, read `./assets/` and build from the components already there. When a lesson needs something new and reusable, write it as a component in `./assets/` and link to it — never inline code a future lesson would duplicate. |
| 61 | |
| 62 | A shared stylesheet is th |