/explain

Resolve the user's actual point of confusion. Match their level of detail without making them learn internal terminology first.

1. Identify the question and what the user needs to understand or decide. If they ask for a simpler explanation, change the level and example rather than repeating the same jargon more slowly.
2. For this repository's behavior inspect actual source, types/configuration and the request/data path. State the revision/environment when it matters. Do not answer from a README alone or confuse intended architecture with implemented behavior.
3. Lead with the outcome and a concrete example. Introduce only the terms needed for the next idea. Separate what is verified, inferred, remembered and unknown. Preserve meaningful limitations rather than simplifying them into a false guarantee.
4. Use a small table or diagram for a mapping/flow; use an interactive visualization when exploring cause/effect materially helps. Do not force a visualization for a simple fact or add a decorative diagram that obscures the mechanism. Text should remain sufficient to follow the answer.
5. Connect technical details to consequences. Explain where a user's action goes, who owns the state, when an acknowledgement is trustworthy and what changes when a device/provider is unavailable. For an API/model choice, describe verified capabilities instead of guessing a tier or cost.
6. Check the explanation against the question. Offer a short next action only when useful; do not turn an explanation into unrequested code changes, a new task queue or a model launch.

Output and capture

Use the explanation pattern. Default to answering in chat. If durable documentation is requested, create/update a DOC linked to supporting code/research with its last verified evidence and explicit freshness. Use the actual tools or initialized standalone records; if neither exists label the document as a draft.

Example: “Your browser queues the instruction; your PC performs the file write; the dashboard says applied after the PC acknowledges it” explains the relay before introducing sequence numbers or outboxes. “A connection badge means commands have succeeded” would be an incorrect simplification.

Skill settings

The owner's settings for this skill arrive in a "Skill settings" block. Honour them.

• level (plain or technical; default plain):
  • Plain: no unexplained jargon. Define any term you must use and prefer an everyday comparison.
  • Technical: use the correct developer terms, and still define the ones a reader may not know.