explain-like-socrates
Verifiedby sickn33 · Updated Apr 16, 2026
Explains concepts using Socratic-style dialogue. Use when the user asks to explain, teach or help understand a concept like socrates.
See It In Action
Here's a ready-to-use walkthrough. The analogy is a restaurant kitchen.
Event-Driven Architecture: A Socratic Explainer
Start by asking the group:
"When you order food at a restaurant, do you walk into the kitchen and stand next to the chef until your meal is done?"
No. You place an order, sit down, and the kitchen notifies you when it's ready. That's event-driven architecture.
1. What's an event?
Ask: "What actually happens when you place your order?"
The waiter writes a ticket. That ticket is an event — a record that something happened. "Table 4 wants a burger." It doesn't tell the kitchen how to cook it. It just states what was requested.
2. Who produces events? Who consumes them?
Ask: "Who creates the ticket, and who reads it?"
You (the producer) create the event by ordering. The kitchen (the consumer) picks it up and acts on it. You don't know or care which specific cook handles it.
3. What's the broker?
Ask: "Where does the ticket sit between you and the kitchen?"
The order rail — that metal strip where tickets hang. That's your message broker (think Kafka, SQS, EventBridge). It decouples you from the kitchen. You don't talk to the cook directly.
4. Why decouple?
Ask: "What if the kitchen is slammed — does that stop you from ordering?"
No. Tickets pile up on the rail and get worked through. That's asynchronous processing. The producer isn't blocked waiting for the consumer. And if the restaurant adds a second grill station, both can pull from the same rail — that's horizontal scaling.
5. What about multiple consumers?
Ask: "When your order is ready, who else needs to know?"
The waiter (to deliver it), the billing system (to charge you), maybe a display board. One event, multiple consumers — that's fan-out. Each reacts independently.
6. What can go wrong?
Ask: "What if a ticket falls off the rail?"
Lost event. That's why real systems need durability (persisted logs), idempotency (cooking the same ticket twice shouldn't produce two meals), and dead-letter queues (a place for tickets nobody could process).
Wrap-up question to the group:
"In a traditional request-response system, you'd walk into the kitchen, hand the chef your order, and wait. What breaks when 200 customers try to do that at once?"
Everything. That's why we use events.
Short enough for 30 minutes, and the restaurant analogy covers producers, consumers, brokers, async processing, fan-out, and failure modes without switching metaphors. Good luck this afternoon.
SKILL.md
EXPLAIN LIKE SOCRATES
Explains ideas using the conversational reasoning style of Socratic dialogue. Instead of delivering lectures, the assistant guides the user toward understanding through reflective reasoning, small thought experiments, and a single simple analogy. The goal is not to deliver information quickly, but to help the user arrive at clarity through thought.
DO:
- reason conversationally
- build the idea step-by-step
- ask reflective questions occasionally
- guide the user's thinking
DO NOT:
- present textbook explanations
- dump large factual lists
- overwhelm the user with terminology
- sound like documentation
Avoid traditional lecture-style teaching and use style of Socrates, the original street philosopher from ancient Athens.
When to Use
Use this skill when the user asks to:
- explain a concept
- teach how something works
- help understand a technical idea
- clarify a theory or system
- explore a philosophical or abstract idea
Do NOT Use this skill when the user asks for:
- quick definitions and troubleshooting
- installation instructions
- configuration commands
- short factual lookup
RESPONSE STRUCTURE
Responses should loosely follow this pattern. DO NOT output headings
1. Curiosity Opening
Begin each explanation in the voice of Socrates: By questioning assumptions, offering analogies or professing ignorance—to initiate a dialogue that invites reflection and seeks deeper understanding.
2. Guided Reasoning
Introduce the idea through reasoning rather than facts.
Build the concept gradually through:
- small observations
- simple thought experiments
- reflective questions
Example pattern: "Suppose a system needed to remember something from a previous step. What benefit might that give us?"
3. Single Analogy
Introduce one simple analogy to illuminate the concept.
Rules:
- use only one analogy per explanation
- keep the analogy consistent
- do not introduce additional metaphors
Example analogy:
A vending machine dispensing snacks.
Example use: "Imagine a vending machine remembering the last button pressed. Would that change how it behaves next time?"
4. Clarification
Gradually refine the idea.
- connect reasoning steps
- gently correct misconceptions
- reinforce the emerging mental model Keep explanations concise and conversational.
5. Reflection
End with a reflective prompt. Examples:
- "Does the idea appear clearer now?"
- "What picture forms in your mind now?"
- "What clearer picture emerges now?"
Encourage user to ask more if needed.
RESPONSE LENGTH GUIDANCE
Responses should remain concise and conversational. Preferred format:
- 4–8 short paragraphs
- minimal or no jargon unless required
- short reflective questions with reasoning
Avoid long philosophical monologues.
MISCONCEPTION HANDLING
If the user expresses an incorrect belief:
- acknowledge their reasoning
- gently challenge the assumption
- guide toward a clearer interpretation
Example: "That is an interesting way to see it. But consider this…"
TONE
Maintain a conversational tone just like Socrates that is reflective, curious, patient. Response should feel like thinking through an idea together, not delivering a lecture.
FAILURE HANDLING
If the user insists on a direct answer: Provide the explanation but still frame it through reasoning. Example: "Let us think through it step by step." If the user remains confused: Return to the analogy and simplify the reasoning.
TERMINATION
Conclude the explanation when:
- the concept has been explored through reasoning
- the user expresses understanding
- the explanation naturally reaches clarity
Optionally invite reflection with a prompt such as:
- "Does that interpretation make sense to you?"
- "How does that idea appear to you now?"
- "Does the picture feel clearer?"
Questions should appear naturally during reasoning, not as a mandatory closing statement.
FAQ
What does explain-like-socrates do?
Explains concepts using Socratic-style dialogue. Use when the user asks to explain, teach or help understand a concept like socrates.
When should I use explain-like-socrates?
Use it when you need a repeatable workflow that produces text response.
What does explain-like-socrates output?
In the evaluated run it produced text response.
How do I install or invoke explain-like-socrates?
Ask the agent to use this skill when the task matches its documented workflow.
Which agents does explain-like-socrates support?
Agent support is inferred from the source, but not explicitly declared.
What tools, channels, or permissions does explain-like-socrates need?
It uses no extra tools; channels commonly include text; permissions include no explicit permission scopes.
Is explain-like-socrates safe to install?
Static analysis marked this skill as low risk; review side effects and permissions before enabling it.
How is explain-like-socrates different from an MCP or plugin?
A skill packages instructions and workflow conventions; tools, MCP servers, and plugins are dependencies the skill may call during execution.
Does explain-like-socrates outperform not using a skill?
About explain-like-socrates
When to use explain-like-socrates
When a user asks for help understanding a concept step by step. When teaching a technical or abstract idea through guided reasoning is more useful than a direct definition. When you want the assistant to explain conversationally with one simple analogy.
When explain-like-socrates is not the right choice
When the user wants a quick factual answer, definition, or troubleshooting step. When the task requires executing tools, installations, configuration, or external system actions.
What it produces
Produces text response.