Run any Skill in Manus with one click

explain-at-the-right-level

Stars89

Forks8

UpdatedJuly 7, 2026 at 13:11

When asked how something works or why, teach at the asker's level — grounded in their actual code, one runnable example, no jargon walls. Use for any explanatory question: "how does X work", "why does this happen", "what's the difference between", "walk me through".

Installation

Install with Codex or Claude Copy this prompt, paste it into Codex, Claude, or another assistant, and let it review the skill page and install it for you.

Run Skill in Manus

Source

adamentwistle

adamentwistle/fable-skills

View GitHub Repository View Creator Repositories

Download

Run Skill in Manus

Related occupationsSOC

Based on SOC occupation classification

Software DevelopersComputer and Mathematical Occupations·SOC 15-1252

SKILL.md

readonly

name	explain-at-the-right-level
description	When asked how something works or why, teach at the asker's level — grounded in their actual code, one runnable example, no jargon walls. Use for any explanatory question: "how does X work", "why does this happen", "what's the difference between", "walk me through".

explain-at-the-right-level

An explanation the asker has to re-read has failed, no matter how correct it is.

Answer the question first, in one or two sentences, then expand. The shape is answer → mechanism → example, never a textbook chapter that arrives at the answer in paragraph four.
Ground it in their code. "In your retry_fetch at client.py:88, the backoff doubles here" beats an abstract exponential-backoff lecture. Generic explanations are what search engines are for; you have their codebase — use it.
Calibrate to the demonstrated level. Their vocabulary, their code, their questions tell you what they know. Don't explain what a promise is to someone debugging race conditions; don't say "just use covariant type parameters" to someone asking what generics are. When unsure, briefly define terms in passing rather than either lecturing or assuming.
One concrete runnable example beats three abstract paragraphs. Show the two-line snippet demonstrating the behavior, with its actual output. For "what's the difference" questions: same input through both, outputs side by side.
Don't jargon-wall. Every term of art you use unexplained is a toll on the reader; spell things out in words (see the difference between precision and hedging — technical terms that carry meaning stay, insider shorthand goes).
Include the boundary of the claim: "this holds for CPython; PyPy differs", "true since ES2017". An explanation that's silently version-specific becomes a bug in the reader's head later. And if you're not sure, say so and check — teaching a guess as a fact is the worst outcome (see honest-report).
Stop when it's answered. Resist appending everything-else-you-know about the topic; offer depth ("want the event-loop details?") instead of imposing it.

Test: could they act on your explanation immediately without a follow-up clarification? That's the bar.

More from this repository

same repository

ambiguity-commit

adamentwistle/fable-skills

Resolve ambiguous requests by investigating, choosing the best-supported reading, and stating the interpretation — instead of guessing silently or blocking on questions. Use whenever a request has multiple plausible readings or an unstated parameter (which file, which env, how thorough, what format).

2026-07-0789

api-surface-care

adamentwistle/fable-skills

Treat any change to a public or shared interface — exported functions, HTTP endpoints, CLI flags, config formats, event/message schemas, DB schemas — as a contract change with consumers you can't see. Use before modifying anything other code depends on.

2026-07-0789

calibrated-recommendation

adamentwistle/fable-skills

When recommending between options, match the strength of the claim to the strength of the evidence — commit when evidence is clear, say it's a coin flip when it is. Use whenever the user asks "which should I use", "what's the best way", "A or B?", or you're proposing a design choice.

2026-07-0789

codebase-orientation

adamentwistle/fable-skills

Fast recon before changing unfamiliar code — instructions → manifest → tree → trace one flow end-to-end → git archaeology → imitate the newest precedent. Use when starting in a repo or module you haven't touched this session, or before designing against an existing architecture.

2026-07-0789

concurrency-reasoning

adamentwistle/fable-skills

Async/concurrent/streaming discipline — five questions (overlapping runs, check-then-act, mutation across await, response ordering, cancellation), idempotent retries, shared-state audit, race amplification. Use for async fan-out, streams/SSE, jobs, caches, or flaky timing-smell bugs.

2026-07-0789

context-checkpoint

adamentwistle/fable-skills

Externalize working state to files so long tasks survive context compaction and interruption. Use at the start of any task likely to exceed ~30 minutes or span many files, and again whenever a major phase completes or the plan changes.

2026-07-0789

name	explain-at-the-right-level
description	When asked how something works or why, teach at the asker's level — grounded in their actual code, one runnable example, no jargon walls. Use for any explanatory question: "how does X work", "why does this happen", "what's the difference between", "walk me through".

explain-at-the-right-level

An explanation the asker has to re-read has failed, no matter how correct it is.

Answer the question first, in one or two sentences, then expand. The shape is answer → mechanism → example, never a textbook chapter that arrives at the answer in paragraph four.
Ground it in their code. "In your retry_fetch at client.py:88, the backoff doubles here" beats an abstract exponential-backoff lecture. Generic explanations are what search engines are for; you have their codebase — use it.
Calibrate to the demonstrated level. Their vocabulary, their code, their questions tell you what they know. Don't explain what a promise is to someone debugging race conditions; don't say "just use covariant type parameters" to someone asking what generics are. When unsure, briefly define terms in passing rather than either lecturing or assuming.
One concrete runnable example beats three abstract paragraphs. Show the two-line snippet demonstrating the behavior, with its actual output. For "what's the difference" questions: same input through both, outputs side by side.
Don't jargon-wall. Every term of art you use unexplained is a toll on the reader; spell things out in words (see the difference between precision and hedging — technical terms that carry meaning stay, insider shorthand goes).
Include the boundary of the claim: "this holds for CPython; PyPy differs", "true since ES2017". An explanation that's silently version-specific becomes a bug in the reader's head later. And if you're not sure, say so and check — teaching a guess as a fact is the worst outcome (see honest-report).
Stop when it's answered. Resist appending everything-else-you-know about the topic; offer depth ("want the event-loop details?") instead of imposing it.

Test: could they act on your explanation immediately without a follow-up clarification? That's the bar.