Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/tykisgod/quick-question/designnpx skills add tykisgod/quick-question --skill designgit clone --depth 1 https://github.com/tykisgod/quick-questionWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00051 | $0.01329 |
| Opus 5 | $0.00026 | $0.00665 |
| Sonnet 5 | $0.00010 | $0.00266 |
| Haiku 4.5 | $0.00005 | $0.00133 |
Grade A, and why
design scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 89 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Respond in the user's preferred language (detect from their recent messages, or fall back to the language setting in CLAUDE.md).
Write a game design document. This is the FIRST step in the qq pipeline — it produces the design doc that /qq:plan turns into a technical implementation plan.
Arguments: $ARGUMENTS
Language boundary (HARD RULE)
This skill writes game design, not technical architecture. Explore the codebase to understand what exists, but translate everything into player-facing language.
| Write this (design language) | NOT this (implementation language) |
|---|---|
| 游戏流程管理 | DemoGameManager |
| 船员会感到饥饿和疲劳 | CrewNeeds.Hunger, NeedsTickSystem |
| 工作台可以制作物品 | ProductionComponent, ITaskIssuer |
| 船员前往火炮并操控 | Task_OperateTurret, MannedWeaponComponent |
| 食物保鲜随时间下降 | ItemProperty.Freshness float decay |
Self-check before saving: scan the document for .cs, Manager, Component, System, Service/, class, interface, MonoSingleton. If found, replace with design language.
Output structure
# [Feature Name] Design Document
## 1. Problem & Goal
What gap this addresses. What the player experience looks like when done. (2-3 sentences)
## 2. Reference Games
| Game | How they do it | What we borrow |
## 3. Design Approach
Which approach was chosen and why. One sentence on trade-offs if relevant.
## 4. Detailed Design
- Player-facing state/flow (ASCII or Mermaid diagram)
- Game concept definitions (describe what the player sees/feels, NOT code fields)
- Player interaction flow (numbered steps of what the player does)
## 5. Scope (optional — only if user mentions MVP/minimal/first pass)
| In scope | Out of scope |
## 6. Open Questions
Running rules
- Explore freely: at any point, read the codebase, existing design docs, and data configs to inform your design. Don't limit exploration to one step.
- Resolve uncertainty: when the user says "不清楚", "没想好", "不确定", or anything indicating they haven't figured something out — STOP. Help them think it through with options, reference games, and trade-offs. Only continue when resolved. Do NOT park it in Open Questions and move on.
- Challenge with evidence: when presenting a section for confirmation, flag design choices that conflict with what reference games have learned, contradict the existing codebase, or create internal inconsistency within the document. Bring the evidence ("Raft tried X and removed it because..."), not just doubt. Do NOT challenge personal taste, aesthetic preferences, or things that are already built and working. Max 1-2 challenges per design doc — if everything looks solid, say so and move on.
- Open Questions is reserved for genuinely low-impact unknowns (e.g., exact number tuning, visual polish).
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 89 lines · 51 tokens per session scan A a597dc0bff53
design is a skill published in the GitHub repository tykisgod/quick-question (11 stars, last pushed 8d ago), licensed MIT. It adds 51 tokens to every session and 1,329 once invoked, about $0.0003 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
particles
Use this skill when creating particle effects in Phaser 4. Covers ParticleEmitter, emission zones, death zones, particle properties, textures, gravity wells, and particle movement. Triggers on: particles, emitter, particle effect, explosion, fire, smoke.
web-games
Web browser game development principles. Framework selection, WebGPU, optimization, PWA.
develop-web-game
Use when Codex is building or iterating on a web game (HTML/JS) and needs a reliable development + testing loop: implement small changes, run a Playwright-based test script with short input bursts and intentional pauses, inspect screenshots/text, and review console errors with rendergametotext.
gameobject-component-destroy
Destroy one or more Components from a target GameObject. Missing (null) components are skipped — they cannot be destroyed. Use 'gameobject-find' and 'gameobject-component-get' to identify the components first.
ship-web-games
Package, deploy, and verify a playable Three.js or web game. Use for release builds, asset delivery, private/public deployment, production smoke tests, browser proof, release notes, rollback readiness, and cleanup of temporary QA resources.
unity
Compile, test, and drive Unity for this repo's C# packages (unity/core, jint, quickjs, clearscript) and the two Unity projects (tests/, kitchen-sink/). Use when a change touches C# under unity/, when Unity test results are needed, when a rendering snapshot has to be checked or regenerated, or when the app has to be…