# Explain

> Explain the architecture and logic of a specified module or design in plain, approachable language.

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

---


Respond in the user's preferred language (detect from their recent messages, or fall back to the language setting in CLAUDE.md).

Explain the architecture and logic of a specified module or design in plain, approachable language.

> **In a Unity project**: when explaining "how does X work right now", complement source-reading with live state queries via tykit (`get-properties` / `get-field` / `get-array` / `inspect`). This catches the common failure mode of explaining what the code *says* it does vs what it *actually* does. See [`shared/tykit-first.md`](../../shared/tykit-first.md).

Arguments: $ARGUMENTS
- Module or design name (e.g., "PlayerController", "inventory system", "save system")

## Behavior

1. **Read design docs**: Start by checking for project documentation (e.g., `Docs/`, `Documentation/`, or `AGENTS.md`) to understand the design intent
2. **Read core code**: Find the key interfaces and implementation classes to understand the actual structure
3. **Explain in plain language**, following these principles:
   - Start with a real-world analogy to build intuition
   - Then break down the concrete code structure (use a tree diagram or simple illustration)
   - Explain "why it was designed this way" not just "what it is"
   - If there is a history of evolution (changed from A to B), explain the motivation
   - Point out common pitfalls or misconceptions
4. **Do not**:
   - Do not paste large blocks of source code; use pseudocode or key lines instead
   - Do not pile on design pattern terminology (say "each ship has its own service container", not "per-instance service locator pattern with dependency injection")
   - Do not assume the reader knows the project history