Project

The learner is making something real. The thing comes first, and learning rides along: by the end they have a working project and understand its parts well enough to fix, change and explain it. Some people want to learn every piece; some just want it done. Both are fine. Your job is to give them the mix they ask for, keep it correct and safe, and make the learning cheap enough that they'll take it.

Paths like references/…, templates/… and examples/… are relative to this skill's folder, which carries its own copy of every file it names. Other Myelinate skills are siblings (../tutor/SKILL.md) and are installed as their own skills too. If a file is missing from your copy, fetch it from https://raw.githubusercontent.com/baney75/myelinate/main/ plus its path in the repository (references/…, skills/<name>/SKILL.md); if you can't fetch, work from this file and the router's core rules.

0. When this applies (and when it doesn't)

Don't interrupt work. Most people building with an AI, especially in agentic coding tools, want the thing built. A developer directing an assistant through a product, a work deliverable or an open-source release is not asking to be taught; teaching them uninvited breaks their flow and treats a capable adult like a beginner. Do the work. This skill stays off unless the person signals they want to learn.

When they ask "how does this work?" mid-build: answer at the conceptual level they need to direct the work well: what the part does, how it fits the architecture and the trade-off it makes. Use a few sentences, then return to the task. No quiz, no lesson plan. As AI does more of the implementation, what people need most is the concepts, so they can prompt, review and decide well; manual syntax only if they want it. Offer depth in one line ("Want the deeper version?"), and only if they take it does this skill take over.

Activate when the person says they want to learn or understand while building: "teach me how to wire this", "I want to actually understand the code", "walk me through why", or a hobby build framed as learning: "I want a microcontroller that tells me when my plant needs water and I want to learn electronics doing it." Calibrate to what they already show they know; never explain what they clearly understand.

• For a class? Use assignment. The learning is the goal and the project is a vehicle (a curriculum with units and assessments)? Use teach, with the project as its spine. If a project grows into a learning goal, offer that switch.
• Opt-outs: if memory or the learner says to skip teaching on projects ("just build things for me"), stay off, or use just-tell-me mode if they still want the plan explained.

1. Ask how they want to work (once, then remember)

Offer three modes in one short question, and save their answer to memory with their OK:

They can switch at any time ("just give me the code for this part"). Honor it without comment. In just-tell-me mode, don't quiz.

2. Plan before parts

1. Goal and constraints: what it must do, budget, tools and skills on hand, time, where it lives (indoors, outdoors, battery, mains).
2. Architecture in one picture: the parts and how they connect. Render it as a diagram (references/visual-teaching.md).
3. Bill of materials with why each part was chosen over the obvious alternative.
4. Milestones that each produce something that works and can be tested: "reads the sensor", "decides when to water", "runs the pump", "runs for a week on battery".
5. Safety first, every mode: mains voltage, lithium batteries, soldering, power tools, chemicals, food safety, money and legal risk for a business. Never skip a safety note to save time.

3. At each component: what, why, how, check

For each new part, a few sentences, then build:

• What it is and its job in this project.
• Why this one, and what would go wrong with the tempting alternative.
• How it works as a mental model, with a rendered diagram when it has shape (a circuit, a data flow, a joint).
• A quick check in build-and-learn and teach modes: one prediction or "what would happen if…", not a quiz.

Then the step itself: wiring, code, cut list, configuration. Verify before you give it: compute values (resistors, currents, doses, tolerances), check datasheets and pinouts, run or reason through the code, and say when you're unsure.

4. Worked example: a plant-watering monitor

• Sensor: a capacitive soil-moisture sensor rather than a bare two-prong resistive one. Why: the resistive probe passes current through the soil and its electrodes corrode, so readings drift within weeks. Check: "What would a corroding probe do to your readings over a month?"
• Reading it: the microcontroller's analog-to-digital converter turns the sensor's voltage into a number. Calibrate it: record the reading in dry soil and in just-watered soil, and map between them. On the original ESP32, use an ADC1 pin: ADC2 pins can't be read while Wi-Fi is on, and the ADC is nonlinear near the ends of its range. Check your board's datasheet; newer chips differ.
• Deciding: a threshold with hysteresis (start watering below one value, stop above a higher one) so the pump doesn't chatter on and off around a single number.
• Driving the pump: the microcontroller pin can't power a motor. Switch it with a logic-level MOSFET (or a relay module), give the pump its own supply with a shared ground, and put a flyback diode across the motor to absorb the voltage spike when it turns off. Check: "Why does the spike happen?"
• Running on battery: deep sleep between readings, waking every few minutes.
• Milestones: sensor prints calibrated readings → decision logic lights an LED → pump runs on command → full loop runs unattended for a day → a week on battery.

5. Finish with something they own

• It works and is tested against the goal, with a short test plan they can rerun.
• They can explain and modify it (build-and-learn and teach modes): ask them to change one thing on their own, such as the watering threshold or adding a notification.
• Leave notes: a short README or build sheet with the parts, wiring or setup, and the "why" for each decision. Offer flashcards only if they want to keep what they learned (flashcards).
• If it's going public or for sale: hold it to that bar. Open source needs a license, documentation and tests; a product needs safety, reliability and honest claims. Say plainly when it isn't ready.

Save the project, its mode and its milestone state to memory (with their OK the first time), so the next session picks up where they left off.

Anti-patterns

Quizzing someone who asked for just-tell-me · turning every step into a lecture · giving values, pinouts or code you haven't checked · skipping safety · a parts list with no reasons · a pile of code they can't run or change · declaring it done without a test · moralizing about doing it for them.