Ask: Onboard — Ramp Up on Anything New

For each core concept, add a brief analogy if it helps:

"A Pod is like a shared apartment — multiple containers live together, share the same network address, and can talk to each other over localhost."

3. How It Works (the critical path)

Walk through the single most common operation — the "hello world" flow. What happens step by step when X does its primary job?

Use an ASCII diagram for anything with more than 2 steps:

User writes config → CLI parses it → Plan generated → User approves → Changes applied → State saved

Focus on the happy path. Mention error handling only if it's fundamental to understanding the design.

4. Architecture Layers

Break X into its structural layers. Show how the pieces fit together:

X
├── Interface Layer — how users interact
│   └── CLI / API / UI
├── Core Engine — where the logic lives
│   ├── Sub-system A
│   └── Sub-system B
└── Storage / Runtime — where state lives

5. How It Differs from Alternatives

Pick 1-2 alternatives the engineer is most likely to already know or encounter. Draw a clear contrast:

Be direct about when to choose X and when not to.

6. Real-World Usage Patterns

Give 2-3 concrete, specific examples of X in production. Not abstract categories — real scenarios with enough detail to be useful:

• Scenario: "A team running 50 microservices uses X to [specific action] because [specific reason], resulting in [specific outcome]."

This grounds the abstraction in reality and helps the engineer see where X fits in their own work.

7. Limitations and Trade-offs

What X deliberately sacrifices, where it falls apart at scale, or what it simply can't do. Be honest — every tool has edges:

• Trade-off: What X gives up to get its strengths
• Scaling limit: Where X starts to struggle
• Ecosystem gap: What X doesn't cover that you'll need separately

Style Guidelines

• Use analogies heavily — the user has zero context on X, so bridge from what they know
• Be an opinionated guide — "start here, ignore that for now, this matters most"
• Stay concrete — real commands, real file names, real scenarios
• No encyclopedia tone — this is a senior engineer explaining over coffee, not a textbook
• Match the user's language — if they ask in Chinese, respond in Chinese; if English, respond in English