teach: add high-level "How works" overview before lessons (#30)

4c9a025→main·

* teach: open the lesson with a high-level "How works" overview

The lesson template jumped from "What you'll learn" straight into checkpoint-anchored lessons, leaving readers without a picture of the system itself. Add a "How works" section before the lessons: what it does, the moving parts, the end-to-end lifecycle (now the home for the optional Mermaid diagram), and the key design idea.

Also distinguish it from "Mental model" (system vs how the team reasons about it) and require the overview to stay grounded in what the transcripts support rather than inventing architecture.

Co-Authored-By: Claude Opus 4.8 noreply@anthropic.com

* teach: drop "What you'll learn" and "Mental model"; bump version to 0.7.0

The "How works" overview now carries the lesson's framing, making the "What you'll learn" preamble and the separate "Mental model" section redundant. The lesson goes straight from the system overview into the checkpoint-anchored lessons.

Bump all plugin manifests (claude, codex, cursor, gemini, npm, marketplace) from 0.6.0 to 0.7.0.

Changes

7

• .claude-plugin

• Mmarketplace.json+1/-1

• Mplugin.json+1/-1

• .codex-plugin

• Mplugin.json+1/-1

• .cursor-plugin

• Mplugin.json+1/-1

• Mgemini-extension.json+1/-1

• Mpackage.json+1/-1

• skills/teach

• MSKILL.md+9/-7

Entire Teach

Use entire search and entire explain to pick 3-5 canonical checkpoints for a topic and teach the user as a guided lesson. Output is a structured lesson with a mental model and takeaways, not a list of checkpoints. Use entire search and entire explain to pick 3-5 canonical checkpoints for a topic and teach the user as a guided lesson. Output is a structured lesson that opens with a high-level "how it works" overview of the system, then checkpoint-anchored lessons with takeaways — not a list of checkpoints.

Response Format

Entire Teach:

## What you'll learn
<1-2 sentences: the topic and what mental model the user will walk away with>

## Mental model
<2-3 sentences distilled across the transcripts about how the team thinks about this topic — invariants, vocabulary, decision tree>
## How <topic> works
<A high-level explanation of the system itself, synthesized from the transcripts, before any lessons:
- What it does: 1-2 sentences on the problem the system solves, from the user's point of view.
- The moving parts: the main components/layers and what each owns (a short list or table).
- The lifecycle: the end-to-end flow from trigger to steady state, numbered steps. This is the natural home for the optional Mermaid diagram.
- The key design idea: 1-2 sentences on the central invariant or principle the design hangs on.>

## Lesson 1: <short title>
- Checkpoint <id> · <date> · <author>

- Anchor every claim to a checkpoint ID, file path, or commit SHA.
- Build the "How <topic> works" overview only from what the transcripts support — if they don't reveal the full architecture, cover what they do show and say so rather than inventing components.
- Keep each lesson short — a paragraph at most. The lesson is a teaching artifact, not a transcript dump.
- "Patterns to remember" is the most valuable section. It should generalize across the lessons, not restate them.

8. **Optional small Mermaid diagram.** Include a diagram only if there is a clear flow worth illustrating (request flow, decision flow, fallback flow). At most one diagram, 5-7 boxes, concept-level labels, behavioral flow only. Skip the diagram if the topic is not flow-shaped.