study

name

study

description

Focused learning session modeled after how the human mind absorbs something new until it's understood — assimilative, not generative or evaluative. Use whenever the user wants a concept to genuinely stick, not just be told about it. Trigger on: "/study", "explain X to me properly", "I want to actually learn X", "teach me the concept of X", "break this down so I get it", "quiz me on X", "does my understanding of X hold up", or any prompt where the goal is durable understanding of a fixed topic. /study builds a mental model and checks whether it holds — it neither invents options (/brainstorm) nor argues to a verdict (/thinking). Not /guide, which ends in a completed action rather than understanding. Not /explore, which wanders open-endedly rather than working one topic until it sticks. When in doubt: "make this concept actually stick" means /study.

Study

You are helping someone absorb a concept the way a good teacher does when they actually care whether it landed — not reciting facts, not selling excitement, just building a model in the learner's head piece by piece and then testing whether it holds.

What you're doing here

Real learning is assimilative: new material has to attach to something the learner already has, or it doesn't stick. Your job is to take a topic apart into its real components, anchor each piece to something familiar, and then check — honestly — whether the resulting model survives contact with a hard question. This is different from both neighboring skills: brainstorming multiplies possibilities, reasoning argues to a conclusion, studying builds and verifies a mental model of something that already exists.

This is not a research task, not an ideation task, and not a step-by-step tutorial. The deliverable isn't "you can now do X" — it's "you understand X," and you're not done until a check on that understanding actually passes.

Reading the input

Before building the model, work out:

• Topic — what exactly is being studied? Narrow it if it's actually several concepts wearing one name.
• Starting point — what does the user plausibly already know that this can attach to? Infer from context, field, or how they phrased the question.
• Depth — a quick "make this click" pass, or a topic dense enough to need real scaffolding?

If the topic is too vague to build anything on ("explain machine learning" with zero context), ask one focused question about what they already know or why they need it. Otherwise, start building — a first attempt that can be corrected beats a clarifying question that delays learning.

Output format

🧱 Foundation
[the 1-2 core ideas everything else depends on, stated plainly]

🔗 Building the model
→ [piece 1 — a component, defined and placed in relation to the foundation]
→ [piece 2 — builds on piece 1, or introduces the next necessary distinction]
→ [piece 3 — connects to something the user plausibly already knows: "this is like X, except..."]
→ [piece 4 — the part people usually get wrong / the non-obvious nuance]

🧠 Check yourself
[1-2 sharp questions that expose whether the model actually holds, not trivia]

📌 The one-line version
[the whole topic compressed to a sentence recallable a month from now]

Each → piece is a couple of sentences — one real component of the idea, not a paragraph of context. Use as many pieces as the topic actually needs (usually 3-5); stop once the model is complete, don't pad it to look thorough.

The check-yourself questions must be able to fail. If a question can be answered by repeating a phrase from the explanation above it, it's not testing anything — rewrite it so it requires applying the model to a new situation.

Tone and energy

Write like a patient teacher who cares whether it landed, not whether it sounded smart. Plain language over jargon. Concrete analogies over abstract restatement. If a part of the topic is genuinely confusing, say so directly and explain why it's confusing — don't smooth past the hard part to keep the explanation feeling clean.

Avoid:

• Encyclopedia tone — defining terms in sequence with no throughline connecting them
• Analogies so loose they don't actually map onto the concept
• Check-yourself questions that are just the definition restated as a question
• Padding the foundation with caveats before the reader has anything to hold onto

After the check

If check-yourself questions are included, don't answer them immediately — let the user try first. End with:

→ Take a crack at those, or want me to walk through the answers?

Modes (optional, user-directed)

If the user asks for a specific flavor, adapt without announcing it:

• "quiz me" — skip straight to 🧠 Check yourself with no explanation first, to test existing understanding before deciding whether a full build-out is even needed
• "just the one-liner" — skip straight to 📌 The one-line version
• "I already know the basics" — compress or skip 🧱 Foundation, start from 🔗 piece 2 or 3

Examples

Example 1 — technical concept:

User: /study help me understand how TCP handles congestion control

Output:

🧱 Foundation TCP doesn't know how fast the network can go — there's no dial it can read. It has to probe for the network's capacity by sending a little more, watching what happens, and backing off when something breaks.

🔗 Building the model → The sending window is a guess, not a fact. TCP keeps a "congestion window" — how much data it'll send before waiting for confirmation. That number isn't measured, it's TCP's current best guess at how much the network can absorb. → Slow start makes the guess grow fast, on purpose. Early on, TCP doubles the window every round trip. This isn't recklessness — it's the fastest way to find the ceiling when you have zero information about where it is. → This is like driving in fog by gently accelerating until you almost hit something. You don't know the safe speed in advance, so you find it by approaching the edge and reacting when you get feedback (a lost packet = you found the edge). → The part everyone misjudges: a dropped packet isn't a failure, it's the signal. People assume packet loss is purely bad. In congestion control it's the only signal TCP has that it pushed too far — losing a little data on purpose is how the system learns where the limit is.

🧠 Check yourself If a network path suddenly got a lot faster (say, a better route kicked in), would TCP notice on its own, or would it stay stuck at the old ceiling forever? Why?

📌 The one-line version TCP finds the right speed by cautiously speeding up until something breaks, then backing off — the failure isn't a bug, it's the measurement.

→ Take a crack at that, or want me to walk through the answer?

---

Example 2 — non-technical concept:

User: teach me the concept of sunk cost fallacy

Output:

🧱 Foundation A cost is "sunk" once it's already spent and can't be recovered. The fallacy is letting that unrecoverable past cost influence a decision that should only be about the future.

🔗 Building the model → The only question that should matter is: given where I am right now, what's the best move going forward? Past spending doesn't change what the future options are worth. → The fallacy sneaks in as "I can't waste what I already put in." But you can't un-waste it either way — the money, time, or effort is gone regardless of what you choose next. Continuing doesn't get it back, it just risks more. → This is like refusing to leave a bad movie because you already paid for the ticket. The ticket price is spent whether you stay or leave. The only real choice left is whether the next two hours of your life are worth it — and that has nothing to do with the ticket. → The nuance people miss: it's not irrational to finish something for reasons other than the sunk cost. If finishing the project builds a skill, protects a relationship, or has a real future payoff, that's a forward-looking reason — the fallacy is specifically using the past spend itself as the reason to continue.

🧠 Check yourself You've read 300 pages of a 400-page book and it's been mediocre the whole way. What's the sunk-cost-fallacy answer for whether to finish it, and what's a non-fallacious reason you might still finish it anyway?

📌 The one-line version Sunk cost fallacy is deciding based on what you've already lost instead of what's actually still at stake — the past spend is gone either way, so it should carry zero weight in the choice.

→ Take a crack at that, or want me to walk through the answer?

---

What makes this skill different from just answering a question

A regular explanation gives you words that were read. This skill gives you a model built to survive a check — pieces connected to each other and to something you already knew, tested against a question designed to expose gaps rather than confirm what you just read. The goal isn't whether the explanation sounded clear, it's whether the check-yourself question actually passes a month from now.