# Explain To Junior

> Explain technical concepts and decisions at a level appropriate for junior developers or technical product managers. Use when the user asks to explain something, break down a concept, communicate a technical decision, or prepare a message for a less experienced audience.

- Skill: `jasonwangyvr/explain-to-junior` (Agent Skill)
- Install (CLI): `npx skillmds@latest add jasonwangyvr/explain-to-junior`
- Raw SKILL.md: https://api.skillmd.com/api/skills/jasonwangyvr/explain-to-junior/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: JasonWangYVR (https://skillmd.com/u/jasonwangyvr)
- Updated: 2026-09-22
- Page: https://skillmd.com/skills/jasonwangyvr/explain-to-junior

---


# Explain to Junior Dev / TPM

## Purpose

Translate complex technical ideas into clear, approachable explanations that help junior developers or technical product managers make informed decisions. Stay grounded in the specific task or problem at hand — avoid abstract lectures.

## Audience Calibration

Adapt tone and depth based on who you're writing for:

| Audience         | Assumes                                               | Adjust                                                                                                               |
| ---------------- | ----------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- |
| Junior developer | Basic coding literacy, familiar with common tools     | Use analogies to code concepts they know; light on jargon, but technical terms are OK if briefly defined             |
| Technical PM     | Understands product goals, light technical background | Lead with _why it matters_ for the product; translate technical trade-offs into impact (time, risk, user experience) |

If the audience isn't specified, default to TPM-level (broader, less jargon).

## Writing Style

- **Casual Slack tone** — write like you're explaining to a teammate over chat
- Keep it to **3–6 short paragraphs max** (aim for what fits in one Slack message without a "Show more")
- Use **bold** for key terms the first time they appear
- Use bullet lists for trade-offs or options
- One analogy or concrete example goes a long way — prefer real-world comparisons over abstract definitions

## Structure

Follow this loose structure (don't label the sections explicitly — keep it conversational):

1. **The situation** — one sentence on what we're dealing with
2. **The concept** — plain-language explanation of the technical idea, grounded in the current task
3. **Why it matters here** — how it affects the decision, timeline, or user experience
4. **Options / recommendation** (if applicable) — brief trade-offs, with a suggested path

## Example

**Prompt:** "Explain to our TPM why we want to move from polling to WebSockets for the live dashboard."

**Output:**

> Right now the dashboard checks the server for new data every 5 seconds — that's **polling**. It works, but it means users can see stale numbers for up to 5 seconds, and we're hammering the server with requests even when nothing has changed.
>
> **WebSockets** keep an open connection between the browser and the server, so the server can push updates the instant they happen. Think of it like the difference between refreshing your email vs. getting a push notification.
>
> For the live dashboard this means:
>
> - **Fresher data** — updates appear in under a second instead of up to five
> - **Less server load** — no wasted "anything new?" requests
> - **Slightly more complexity** — we need to handle reconnects if a user's connection drops
>
> The trade-off is worth it here since real-time accuracy is the whole point of this feature. We'd estimate about 2 extra days of work compared to keeping polling.

## Reminders

- Stay relevant to the task — don't explain Kubernetes if the question is about a CSS layout decision
- If there are multiple valid approaches, frame them as options with quick pros/cons rather than picking one silently
- When defining a term, do it inline and move on — don't derail into a glossary
- It's OK to say "you don't need to worry about the internals here" when deeper detail would just add noise