Explain
The control plane for game-dev agents — close the loop with verified compile, test, and cross-model review across Unity, Godot, Unreal, and S&box. Lifecycle-aware /qq:go routing, 26 /qq:* slash commands. Claude Code-first, agent-agnostic via HTTP and MCP.
npx -y skills add tykisgod/quick-question --skill explainAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
One thing to look at
- 10 stars10 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Explain the architecture and logic of a specified module or design in plain, approachable language.
SKILL.md
1.8 KB, as published. Nobody here has run it
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. Seeshared/tykit-first.md.
Arguments: $ARGUMENTS
- Module or design name (e.g., "PlayerController", "inventory system", "save system")
Behavior
- Read design docs: Start by checking for project documentation (e.g.,
Docs/,Documentation/, orAGENTS.md) to understand the design intent - Read core code: Find the key interfaces and implementation classes to understand the actual structure
- 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
- 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