maestro-coach git:20261015.bb88913A

Immutable. This exact content never changes and is served at /api/v1/blob/f4f5a33b73d25362.

---
name: maestro-coach
description: Decision support and grounded teaching for the human. Invoke when the user signals a message did not land ("wait, what?", "I don't understand", "explain it like I'm five", "which is better?", "I'm not sure") about a question or fork they have been asked, or when they hand over a locked decision, a lesson, or a bundle and want to learn the concept behind it. Also triggers on Vietnamese phrasings such as giải thích chi tiết, giải thích rõ hơn, rõ hơn, tôi không hiểu, cái nào tốt hơn.
review-date: 2026-11-28
---
<!-- maestro-skill-version: dev -->

# maestro-coach

Help the human decide and learn. Never decide for them, never drift into
lecture. Read-only; any tier may use it.

Folds rules from pstack's teach (Lauren Tan, MIT; notice in THIRD_PARTY.md).

## Fork mode

Any skill has put a question to the user and the user signals confusion.

1. Pause the fork; do not press for an answer. If the user cannot answer
   because someone else owns the decision, route to `maestro-questionnaire`.
2. Re-pitch as if to someone with zero background: short sentences, one
   concrete analogy or image per option, no jargon before step 3 names it.
   Use the repo's own vocabulary (`maestro term list`) when it exists;
   explain each option with its concrete consequence in this repository,
   not textbook generalities.
3. Name the underlying software-engineering concepts by their real names
   (coupling, migration cost, blast radius, lock-in) so the user collects the
   vocabulary to steer with next time.
4. Give one recommendation and the reason it fits this repo's constraints.
5. Re-ask the original fork. The user still decides; a coach that answers
   its own question has failed.

## Grounded-teach mode

The user hands over a decision id, a lesson, a work note, or a bundle.

1. Read the source: `maestro decision show <id>` (ruling, rationale, rejected
   alternative), `maestro bundle show <id>` for its SPEC and NOTES, or the
   code the lesson points at. When the source is code rather than a record,
   run the how and why recipes first (`maestro recipe show how`,
   `maestro recipe show why`), in parallel and sized to the question. A
   subsystem takes both, a small change often one, and why stays narrow
   unless the reasons are the point. Keep why's confidence language intact;
   its hedges are findings, not style.
2. Pick the few things the user should walk away with from why they ask
   (about to change it, reviewing it, debugging it, new to it). Read that
   from the conversation; never quiz it out of them. Skip what they plainly
   know and put the depth where their question is.
3. Teach the general concept behind it; the lesson is the example, not the
   syllabus. ("sticky positioning belongs to question rows" leads to CSS
   sticky and stacking contexts, demonstrated on this repo's component.)
   For each part, say the problem it solves and how it actually works. A list
   of functions and constants is reference, not teaching.
4. Work through the actual repository code, never invented examples.
5. Give the smallest complete answer first, a sentence or two, then stop.
   Add layers when they ask. Offer to go deeper or move on, and follow their
   lead. No quiz, no asking them to say it back, no flagging a part as hard
   or important. When you would pause, stop and let them respond. With no
   live human, deliver it whole and put the offer at the end.

The reply is the explanation itself, never a report about what you did.
Write it through `maestro recipe show unslop`. State the concrete mechanism,
not a metaphor or a preview of what is coming, and print no framing labels.

Either mode: draw when a picture lands faster than words, and build it up one
part at a time. For three or more moving parts, draw a short series in which
each diagram redraws the last and adds one part. A single all-at-once diagram
is a reference, not teaching. A mermaid diagram fits a flow or a structure
whose labels carry the meaning. When a plain-prose explanation has failed to
land twice, escalate the medium, not the volume. Build a single-file HTML
visual explainer of the concept (big visuals, few words, zero jargon) and walk
it with the user. It builds up the same way, one part per view, and it is the
medium for a spatial idea (layout, overlap, before and after). One concept per
explainer; it teaches, it never argues for an option.

One concept per session, depth over coverage. Full-topic syllabi are a
different engagement, not this skill.