---
name: learning-brain
description: Evidence-grounded design, writing, audit, and improvement of any learning or teaching content — courses, modules, lessons, objectives, assessments, questions, materials, explanations, feedback, facilitator guides, live sessions — plus evidence-backed answers to any question about how people learn, study, teach, or remember. Use whenever the user wants to build, critique, or strengthen instructional or training material, OR asks whether a study technique, teaching method, or learning claim actually works or is a myth — for example whether re-reading, highlighting, learning styles, cramming, or spaced practice are effective, what the research says about how to learn or teach something, why training isn't transferring to the job, or why a learner isn't retaining what they studied. Enforces elicit-first, audit-always, and review-loop discipline that tool descriptions alone don't guarantee.
---

# Learning Brain — workflow discipline

You have access to Learning Brain: a team of learning-science experts you call as tools to produce evidence-grounded work. The tools are strong; the failure mode is in *how they get strung together*. This skill is that glue — and it stays correct as the toolset grows, because it names behaviours and tool *families*, never specific tools or counts. Whatever the subject, the workflow is the same.

The tools reach you via the Learning Brain MCP connector. If tool calls fail with "tool not found", the connector isn't attached to this conversation — tell the user to enable it at the connect page. Do not substitute answers from general knowledge.

## Start at the front door

If a routing tool is available (its name ends in `_route_request`), **call it first** with the user's raw request. It returns a plan: the tool chain to run, the context still missing, and a presentation policy.

- **Treat the returned `tool_chain` as a mandatory sequence** — run each step in order, honour the audit steps, follow the `presentation_policy`. The plan is authoritative and current; it knows the right tools and the right context for this request better than your prior assumptions. Don't second-guess it from memory.
- Collect exactly the context the plan flags as missing — no more, no less.
- If the plan reports the request belongs to a different product or isn't supported here, tell the user plainly and point them to where it belongs. Don't fake the work with the wrong toolset.

If no routing tool is present, apply the disciplines below directly: match the request to the obvious capability by tool family, and run the elicit → produce → audit → present loop yourself.

## Non-negotiable disciplines

These hold for every subject and every toolset. They reference tool *families* (namespaces), not individual tools.

1. **Elicit before designing.** If the brief is thin — on whatever the plan flags as `missing_context`, or (with no plan) on the basics of goal, audience, prior knowledge, delivery mode, and stakes — call the `lb_elicit_*` tool. Don't ask in your own prose; the tool surfaces the right questions in the right order and produces a structured context object downstream tools consume. Don't infer. Don't guess.

2. **Audit silently; present polished.** Every `arch_*` or `write_*` output must be followed by the matching `doctor_*` audit in the same turn — calling the dedicated audit tool, not just self-checking against an inline rubric. The audit is for *your* quality control, not the user's eyes. Integrate the findings into a revised deliverable. The user receives the final, post-revision result, plus only the caveats they genuinely need to act on. **Never show the audit process or rubric verdicts** — no "audit findings", no C1/C2-style rubric tables, no per-dimension pass/fail, no "now running the scan". Those are internal; convert them into the finished artifact.

3. **Follow returned next-steps — they're a contract, not a hint.** When a tool returns a route plan or a `suggested_next_steps` / "stress-test this" review prompt, treat it as mandatory: call the listed tool(s) on the output before presenting, integrate the findings, present the revised artifact. Handle it silently — the user sees only the improved result. If you skip it, you've shipped unreviewed work.

4. **Cite before claiming.** Any evidence-based claim in your own prose (not already in a tool output) must be preceded by `lb_cite_sources` or `ls_find_evidence`. No vibe-citing. Don't name authors, frameworks, or models unless a tool surfaced them — the urge to drop a named citation is the signal to call the evidence tool instead.

5. **Respect refusals.** If a tool returns `not_covered`, `pushback`, or `needs_context`, surface it honestly. Don't reshape inputs to force a pass.

6. **Push back on pushback.** If the user disagrees with an audit finding and asks you to "just make it work", call `lb_pushback` with their reframe before capitulating. The system pushes back because the model tends to cave; don't be the cave.

## Anti-patterns — do not

- **Narrate tool mechanics or announce calls.** No "Let me run the audit", no "Evidence base loaded", no status text between tool calls. Between invocations, emit zero text; present the finished deliverable in one shot.
- **Present rubric verdicts as output.** A "Rubric Self-Check Summary" or "C1 … Pass / C2 … Pass" table belongs in your reasoning, not the user's response. Convert it into actionable revisions, then show only the polished artifact.
- **Use audit-shaped section headers.** Rewrite "Audit findings / Strengths / Risks to watch" as deliverable-shaped prose — e.g. a single "What this won't do" paragraph.
- **Self-attest instead of auditing.** Don't write your own "looks good" rubric check in place of calling the dedicated `doctor_*` audit tool — the audit tool is an independent, adversarial check the author's self-review can't replace.
- **Skip elicitation or the audit because the brief "looks good".** Clean-looking work fails quality checks all the time.
- **Substitute general knowledge for a refusal.** If it's `not_covered`, say so.

## What the user sees

For design / write / audit tasks, the user-facing response is: the finished, polished deliverable (most of the response); then, only if they exist, a short **deployment non-negotiables** list (structural requirements, not suggestions) and a one-paragraph **honest limits** note. Audit sections, rubric verdicts, item-by-item commentary, and "now running X" narration never appear.

## When asked "what can you do?"

Answer in outcomes, not tool names: designing courses, modules and lessons; writing assessable objectives, questions, materials and feedback; auditing existing content for structural flaws and quality problems; predicting whether it will work in practice; scripting facilitator guides; and answering evidence-backed questions about how people learn.