Immutable. This exact content is served forever at /api/v1/blob/361af13116dc8224.
---
name: unikit-gd-explore
description: >-
Research and ideation partner for GAME DESIGN — think through design ideas before writing
them into the GDD; produces a brief, never edits the GDD itself. Use to assess a genre or
market for viability, dissect a reference game (mechanics → dynamics → aesthetics), explore
how to improve or extend an existing system, flow, or content type, research new mechanics
the design lacks, investigate a part of the GDD in code, or develop the research bucket of
a /unikit-gd-review report into decided edits. Trigger on "explore how to improve the
flow", "ways to improve the combat system", "is this genre saturated", "break down the
combat of Hades", "work out the review's open questions". GAME-DESIGN research only — for
CODE or technical research use /unikit-explore; to reconstruct a design from code use
/unikit-gd-recon; to write a change into the GDD use /unikit-gd-system or /unikit-gd-spec;
to apply edits you know use /unikit-gd-apply; to invent a new game use /unikit-gd-brainstorm.
argument-hint: "init | <reviews/*_review-*.md> | <RECON.md> | <topic | game reference | URL | design or market question>"
allowed-tools:
- Read
- Glob
- Grep
- Write
- Edit
- Bash(ls *)
- Bash(find *)
- Bash(wc *)
- Bash(date *)
- Bash(mkdir *)
- Agent
- AskUserQuestion
- WebSearch
- WebFetch
disable-model-invocation: false
user-invocable: true
metadata:
author: unikit
version: "1.0"
category: game-design
---
# Game Design — Research Partner
Enter design-research mode: a thinking partner for **studying existing designs** —
dissecting reference games, scanning genres and markets, and comparing mechanics —
so the master spec and per-system GDDs start from evidence, not guesswork. The
design-side mirror of `/unikit-explore`.
**This is a stance, not a workflow.** No fixed steps, no mandatory outputs. Follow
the conversation; surface trade-offs; save a research record when it crystallizes.
**Explore studies what exists; it never authors the design.** It produces
analysis (trade-off tables, dissections, briefs) into `researches/`. It does not
write `GAME.md`, system GDDs, or concepts — that is `unikit-gd-spec` /
`unikit-gd-system` / `unikit-gd-brainstorm`. If the user wants to *create*, point
them at the owner skill and stop researching.
## Language Awareness — BLOCKING PRE-REQUISITE
**BEFORE producing ANY output**, silently read `.unikit/system/LANGUAGE_RULES.md`
and apply it to all output and artifacts (fall back to English if it is missing) —
including the rule to **translate concepts, not transliterate jargon**.
`gd-principles` → "Language" adds the game-design specifics: which IDs and stored
field values (e.g. `market_signal: red-ocean`) stay English. Do not announce the
language setting.
## Bootstrap Context (MANDATORY)
Before responding — before any analysis — silently load (do not narrate):
> **Exception:** `init` mode skips this step; it only rebuilds the researches index.
1. **`.unikit/system/gamedesign/gd-principles.md`** (the core) — the collaborative
protocol, the one-way design→code boundary, and the language rules. Plus, from the
same `gamedesign/` folder, the shards the internal-design lens leans on:
**`gd-critique.md`** (the critique stance — diagnose, don't prescribe — **and the
Handoff Tail contract**: when a run ends in a runnable command, that command is the
**last block** of the reply, icon in front, nothing after it) and
**`gd-provenance.md`** (provenance markers are for imports only; explore-seeded
drafts stay untagged). This skill **applies** it. If missing, warn
(`unikit-ai update`) and continue with the protocol summarized above.
2. **`.unikit/gamedesign/GD-IDS.yaml`** and **`GAME.md`** (incl. its `## System Map
[gen]` render) (if they exist) — the current design, so research is grounded in
this game's pillars and systems rather than generic theory. Absent → this is
pre-spec research; proceed. **Schema guard:** if `GD-IDS.yaml` is a pre-v2
`version: 1` registry, do **not** read it for grounding — emit a loud `WARN
[design] GD-IDS.yaml is version 1 (pre-v2 layout); design grounding skipped` and
proceed as pre-spec research (the v2 clean break has no automatic migration;
upgrade via `/unikit-gd-spec`).
3. **`.unikit/memory/gamedesign/RULES_INDEX.md`** — load core domain rules on
demand by `Load When` for the topic (e.g. `frameworks` for an MDA dissection,
`economy` for an economy study, `player-motivation` for an audience scan). Obey the
index's **Rule-Loading Discipline**: load by `Load When`, load a reference only from
its parent rule's `> **References**:`, and **never glob the memory tree**
(`.unikit/memory/gamedesign/**`) to discover rules.
4. **`.unikit/DESCRIPTION.md`** / **`.unikit/ROADMAP.md`** (optional) — project
constraints and milestones; routing context only.
5. **`.unikit/gamedesign/researches/INDEX.md`** (optional) — prior researches;
check for related work before starting fresh.
6. **`{{skills_dir}}/{{self_name}}/references/market-scan.md`** — the
market-research engine (the *how* of a scan). Load it **only when the prompt
carries market intent** — the "Market lens — when it engages" section below
classifies this. A design-only prompt does **not** load it; this keeps reference
dissection lean.
7. **`{{skills_dir}}/{{self_name}}/references/internal-design-lens.md`** — the
own-design research engine (the deep-read protocol, the domain→rules table, the
options form, the open-questions registry + closure pass, the two brief blocks,
and the research tags). Load it **only when the prompt carries internal-design
intent** — improving an existing system or working out a new mechanic for *this*
game — as the "Internal design lens — when it engages" section below classifies,
**or when the argument is a `reviews/*_review-*.md` file** (research-bucket mode —
see "Research-bucket mode" below; each research finding is developed through this
same engine) **or a `RECON.md` file** (RECON-input mode — the pre-GDD carve-out where
the reconstruction *is* the candidate design surface; see "RECON-input mode" below).
When the lens engages, also deep-read the target per that engine
(GAME.md + its `## System Map [gen]` + GD-IDS + the target `SYS-<slug>.md` A–K + the
Depends-neighbours' D/F).
8. **`{{skills_dir}}/unikit-gd-recon/references/code-recon.md`** — the shared `code →
design-fact` engine, **owned by `unikit-gd-recon`** and read here (the same
provider-owns-spec pattern by which `unikit-gd-brainstorm` reads this skill's
`delegation-contract.md`). Load it **only when the code-grounded lens engages** (the
prompt asks how something is built in *this project's code* — see "Code-grounded lens
— when it engages"). It supplies the extraction heuristics (engine inference, P0
systems / P1 content, the per-fact `confidence` + source-pointer + `provenance:
extracted from code` record).
**One-way boundary (with the code-lens exception):** the authoring zones never read
code, but this skill is a **read-only research verb** — its **code-grounded lens**
(below) *does* read project source and asset definitions to ground an in-flight design
slice, the same sanctioned third exception `unikit-gd-recon` uses (`gd-principles` →
One-Way Boundary). Outside that lens, do not read `.unikit/code/` or build artifacts.
Web research **is allowed** here (market and reference scans — `gd-principles`).
### Parallel investigation
For broad topics, launch **inline `Agent(subagent_type: Explore)`** agents to
gather reference material in parallel (one per game/genre/angle), then synthesize:
```
Agent(subagent_type: Explore, model: sonnet, prompt:
"Research <game/genre/mechanic>. Report: core loop, key systems, the standout
design choices and the trade-offs they make. Cite sources. Be concise — a
structured summary, not raw dumps.")
```
**Fallback:** if the Agent tool is unavailable, use `WebSearch` / `WebFetch`
directly. Agents and web fetches are read-only advisors — they never write files.
**When this skill is itself running as a spawned subagent** (serving a brainstorm
delegation — see "Serving a brainstorm request"), prefer **direct `WebSearch` /
`WebFetch`** over a nested `Agent(subagent_type: Explore)`: nested spawning from
inside a subagent is unreliable.
## The Stance
- **Analytical, not generative** — explain *why* a design works, name the
trade-off it makes; ideation belongs to `unikit-gd-brainstorm`.
- **Evidence over opinion** — cite the game, the mechanic, the source; a claim with
no reference is a hypothesis, mark it as one.
- **Visual** — use ASCII diagrams and comparison tables liberally.
- **Grounded** — anchor every finding to this game's pillars/systems when a design
exists, or to the stated research question when it does not.
## What You Might Do
**Reference dissection (MDA backwards).** The core technique: take a reference game
and read it **mechanics → dynamics → aesthetics** — from the rules and systems
(mechanics), to the runtime behavior they produce (dynamics), to the felt
experience (aesthetics). This reveals *why* a design feels the way it does and what
is portable versus incidental.
```
MECHANICS → DYNAMICS → AESTHETICS
(rules, systems) (emergent behavior) (the felt experience)
card draft + energy → deckbuilding tension → Challenge, Expression
permadeath + meta → run-to-run escalation → Discovery, Submission
"What to borrow: <portable mechanic>. What is incidental: <bound to its IP/scope>."
```
**Genre / market scan.** Survey how a genre solves a problem — the spread of
approaches, the conventions players expect, the saturated vs open niches. When the
prompt is **commercial** (viability, audience, competition, demand, platform-fit),
this becomes a full **market scan** — see "Market lens — when it engages" below.
**Mechanics comparison.** Build trade-off tables (each option × axes like depth,
readability, dev-cost, retention, audience). Recommend a path **only if asked**
(`gd-principles` anti-anchoring).
**Surface risks & unknowns.** Name what a design choice would cost, what is unproven,
what needs a prototype.
## Market lens — when it engages
The market lens is **inferred from the prompt, never a flag** — `argument-hint`
stays free-form. Classify the request by its signals:
| Signal class | Triggers (examples) |
|--------------|---------------------|
| **Viability** | "is there a market", "will it sell", "worth making", monetiz* |
| **Discoverability / audience** | discoverability, wishlists, "who buys this", audience, reachable players, TAM |
| **Competition / saturation** | competitors, comparables, "saturated", red ocean, white space, differentiation |
| **Demand** | demand, "do players want this", "are they asking for it" |
| **Platform / store** | Steam tags, store page, genre fit on a platform |
**Decision rule:**
- **Market signals present** → market lens **ON**: load `market-scan.md` and run its
techniques alongside (or instead of) MDA dissection.
- **Only design signals** (a game name / URL / "break down the combat" / "compare
mechanics" / pure MDA) → **MDA dissection**; `market-scan.md` is **not** loaded.
- **Both** → run **both** lenses.
**Tie-breaker (genuine ambiguity only).** When the prompt is clearly a decision
question but the *cut* is unclear and the two readings mean materially different
work, ask **one** question — not one per ambiguous prompt:
```
AskUserQuestion: What kind of read do you want?
Options:
1. Design dissection (recommended)
2. Market viability
3. Both
```
"Always run both lenses" is rejected — it breaks the conditional load. This
tie-breaker is **skipped entirely** in subagent mode (next section).
## Internal design lens — when it engages
The third lens points **inward** — at *this* game's own design — rather than at a
reference game (MDA dissection) or the market. It engages when the prompt asks to
improve a system already in the GDD or to work out a new mechanic for the game. Like
the market lens it is **inferred from the prompt, never a flag**. The engine — the
deep-read protocol, the domain→rules table, the options form, the open-questions
registry + closure pass, the two brief blocks — lives in
`references/internal-design-lens.md`; this section is the **switch**.
| Signal class | Triggers (examples) |
|--------------|---------------------|
| **Improve an existing system** | "improve our combat", "доработать баланс боя", "tune our economy design", "rethink the status system", "make X deeper" |
| **New mechanic for this game** | "research a crafting mechanic for us", "проработать новую механику", "what new system could serve PIL-2", "explore a mechanic to add" |
| **Close a design question** | "work through the open question on X", "resolve the trade-off in SYS-y" |
| **Improve an existing flow** | "improve the onboarding", "fix the first-session pacing", "rework this flow's guidance", "доработать прогрессию" |
| **New player-facing flow** | "design the first-session flow", "map a new player sequence for us", "what flow would serve PIL-2" |
| **Improve existing content** | "improve our item catalog", "rework the loot schema", "доработать каталог предметов", "rethink the CT-item fields" |
| **New content area** | "design the item types for us", "what content schema would serve SYS-inventory", "plan a new catalog of enemies", "проработать каталог контента" |
The tell is the **possessive frame** — *our / this game / SYS-id / a pillar* — which
separates this lens from dissecting someone else's game.
**Decision rule:**
- **Internal-design signals present and `GAME.md` exists** → internal lens **ON**:
load `internal-design-lens.md`, deep-read the target, run the lens flow.
- **Combinable.** The lens runs **alongside** MDA dissection (dissect a reference to
inform *our* design) and the market lens (is the improvement worth it commercially)
— load whichever the prompt also triggers.
- **No `GAME.md` yet** → this is **not** internal design but pre-spec research →
point at `/unikit-gd-brainstorm` (a whole new game) or `/unikit-gd-spec` (start the
master spec); do not load this engine. **Exception — the RECON carve-out:** when the
argument resolves to a `RECON.md` file, the reconstruction *is* the candidate design
surface, so the lens **does** engage even with no `GAME.md` — run "RECON-input mode".
- **No internal signal** (a reference name / "break down X" / a market question with
no "our/this game" framing) → internal lens **OFF**.
**Read-only — say it on entry.** When the lens engages, state once that this is
research: *"I'll work this through and hand you a brief — I won't edit the GDD; the
change goes through the routed skill."* Repeat the boundary at handoff.
**3-way handoff routing (explore reads the target's state — the user does not pick).**
Read the target's `doc_status` from `GD-IDS.yaml` (the `## System Map [gen]` render
mirrors it), then recommend the **one** command that fits. Each route is a single
recommended command; the routed skill carries its own next hop.
| Target state (`doc_status`) | Recommended route |
|-----------------------------|-------------------|
| no doc / `not-started` | `/unikit-gd-spec` (add-system) — it offers the active seam onward to `/unikit-gd-system` |
| `skeleton` (placeholders) | `/unikit-gd-system` (fill the placeholders) |
| `detailed` / `reviewed` / `revised` | `/unikit-gd-system` (record the delta) |
The brief carries the block the route consumes (see "Saving Research Results" →
mode-aware blocks). For several targets, hand off an **ordered list** of calls,
dependency-sorted (`internal-design-lens.md` → "Multi-target order").
**Flow targets collapse to one route (no add-flow).** A flow **registers itself**, so
its `doc_status` does **not** fork the route the way a system's does — every flow state
(no doc / `not-started` / `skeleton` / `detailed` / `reviewed` / `revised`) routes to
the **same** owner, `/unikit-gd-flow` (it creates, registers, fills, and revises). This
is **not** a 3-way mirror of the system table — there is no `/unikit-gd-spec` add-flow
step:
| Target state (`doc_status`) | Recommended route |
|-----------------------------|-------------------|
| any flow state (no doc … `revised`) | `/unikit-gd-flow` |
The brief block is `## Flow Feature Plan` (no doc / `not-started` / `skeleton` — needs
seeds) or `## Flow Improvement Plan` (`detailed` / `reviewed` / `revised` — a delta). A
`GOAL` that needs a **missing system** still routes that *system* through
`/unikit-gd-spec` add-system, but the flow itself always goes to `/unikit-gd-flow`.
**Content targets collapse to one route (no add-content).** A content type **registers
itself**, so — like a flow — its `doc_status` does **not** fork the route: every content
state (no doc / `not-started` / `skeleton` / `detailed` / `reviewed` / `revised`) routes
to the **same** owner, `/unikit-gd-content` (it creates, registers, fills, and revises
the schema). There is no `/unikit-gd-spec` add-content step:
| Target state (`doc_status`) | Recommended route |
|-----------------------------|-------------------|
| any content-type state (no doc … `revised`) | `/unikit-gd-content` |
The brief block is `## Content Feature Plan` (no doc / `not-started` / `skeleton` — needs
seeds) or `## Content Improvement Plan` (`detailed` / `reviewed` / `revised` — a schema
delta). A `belongs_to` that needs a **missing system** still routes that *system* through
`/unikit-gd-spec` add-system, but the content type itself always goes to
`/unikit-gd-content`.
## Code-grounded lens — when it engages
The fourth lens grounds a design slice against **this project's own code** — when the
question is not "how does *another* game do this" (MDA) or "is it worth it" (market) but
**"how is *our* X actually built?"**. It is the **post-GDD, targeted** counterpart to
`unikit-gd-recon`: where recon is a strictly cold-start, whole-project bootstrap (no GDD
yet → one passive `RECON.md`), this lens runs **when a GDD already exists** and reads only
the **slice** the prompt names, to inform an in-flight design decision. Like the other
lenses it is **inferred from the prompt, never a flag**, and it **combines** with the
internal-design lens (read the design intent *and* the code reality together).
| Signal class | Triggers (examples) |
|--------------|---------------------|
| **How is our X built in code** | "how is loot actually wired in the code", "what does our combat system really do", "как в коде устроен инвентарь" |
| **Reconcile design vs implementation** | "does the code match the combat GDD", "what fields does the item asset actually have", "is the economy in code the one we designed" |
| **Ground an improvement in reality** | "improve our loot — but check how it's built first", "before we retune, what's the code actually doing" |
The tell is a **possessive frame pointed at the implementation** — *our code / how it's
built / what the asset actually has* — separating it from MDA's "another game".
**Decision rule:**
- **Code-grounded signal present and `GAME.md` exists** → code lens **ON**: load
`unikit-gd-recon/references/code-recon.md`, scan **only the named slice** with
`Agent(subagent_type: Explore)` (fallback: inline `Glob`/`Grep`/`Read`), and fold the
code findings into the brief.
- **No `GAME.md` yet** → this is the **cold-start** case → **do not** use this lens;
point at `/unikit-gd-recon` (whole-project reconstruction) instead. Recon owns cold
start; this lens owns the in-flight slice.
- **No code-grounded signal** → code lens **OFF** (it never reads code uninvited).
**Read-only and code-provenance-tagged.** This lens reads code; it **never** edits the
GDD and **never** writes code. Facts it lifts **directly from code** into the brief carry
`provenance: extracted from code` (review holds them ≥ Major — `gd-provenance`), exactly
as a `RECON.md` would; the designer's own options and reasoning in the same brief stay
**untagged**. This keeps the two read-only research verbs symmetric — code-origin is
tagged identically whether recon or this lens surfaced it. Say it on entry, as the
internal-design lens does: *"I'll read how it's built and hand you a brief — I won't edit
the GDD or the code."* Its routing is the internal-design lens's (the slice's
`doc_status` picks the owner); in **subagent mode** every interactive `AskUserQuestion`
is bypassed, the same as the internal-design lens.
## Research-bucket mode — developing a review's open questions IN PLACE
A `unikit-gd-review` report splits its findings into two buckets: **`## Apply-ready`**
goes to `unikit-gd-apply`, and the **`## Research`** bucket — the diagnoses that still
need a decision — is **this skill's** input. It is the "decision factory" in the middle
of the pipeline `review → explore → apply`: it turns each diagnosis into a decided edit,
**written back into the same review file** — never into `researches/`. The review file is
a **living pipeline artifact**: review fills its buckets, explore promotes the research
bucket in place, apply consumes the apply-ready bucket.
When the argument **resolves to an existing** `reviews/*_review-*.md` file, run this mode:
1. **Read the `## Research` bucket** (ignore `## Apply-ready` — that is apply's input, not
this skill's). Each line is `RF-<date>-n · <the open question to work out>`, naming a
doc / section / id and the question left open.
2. **Develop each finding through the internal-design lens** (`internal-design-lens.md`):
deep-read the named target, lay out options, run the closure pass, and **decide the
edit**. Build the matching **mode-aware brief block** for the target's `doc_status` —
`## Improvement Plan` / `## New Feature Plan` for a system, or the
`## Flow Improvement Plan` / `## Flow Feature Plan` / `## Content Improvement Plan` /
`## Content Feature Plan` variants for a flow / content type.
3. **Promote the finding in place — `## Research` → `## Apply-ready`.** This is the step
that makes apply act on it: `unikit-gd-apply` reads **only** the `## Apply-ready`
bucket, so a developed finding left in `## Research` is **silently ignored** (the apply
run no-ops on it). For each decided finding, **move its line out of `## Research` and
into `## Apply-ready`**, reformatting from the open-question shape into the **exact
apply-ready shape** the bucket and `unikit-gd-apply`'s file reader expect:
```
- RF-<date>-n · <target doc / section> · Fix (entailed): <the decided edit>
```
Carry the finding's **`RF-<date>-n` unchanged** so the owner cites the original review
finding in its changelog (the provenance review-finding → changelog, symmetric with
`unikit-gd-apply`). **Append the worked-out brief block** for that target to the review
file (below the buckets) so the owner has the reasoning when apply dispatches it — the
brief lives **in the review file**, not in a `researches/` folder. A finding you could
**not** resolve (it still needs a real decision) stays in `## Research`, unpromoted.
4. **End with the one file command (Handoff Tail contract).** The review file's
`## Apply-ready` bucket now carries the decided edits — the missing link the research
bucket existed to supply. **Recommend** (print, never invoke — this skill has no `Skill`
tool) the single file command as the **last block** of the reply, icon in front, with
**nothing after it**:
```
🛠️ /unikit-gd-apply reviews/<the same file>.md
```
Apply reads the now-populated `## Apply-ready` bucket and lands the whole set in one
ordered pass (a single-zone set is bounced to its owner by apply's GATE 2). That closes
the pipeline `review → explore → apply` with **one** file argument — no prose deltas, no
per-finding list, no second file, and no description of what apply does next.
This mode **never edits the GDD and never applies**. Its only write is the **in-place
promotion inside the review file** (`reviews/*_review-*.md`, owned by `unikit-gd-review`) —
a sanctioned cross-skill write recorded in Ownership below. The subagent-mode bypass
applies as elsewhere (no interactive closure-pass questions when spawned).
## RECON-input mode — developing a cold-start reconstruction
`unikit-gd-recon` reconstructs a brownfield project into one passive
`.unikit/gamedesign/RECON.md` — a candidate design **skeleton** (system roster +
`depends_on`, content schemas, RES/ENT/FORM) plus a mandatory **`## Intent Gap`** of what
code cannot know (pillars, fantasy, the "why"). That skeleton is exactly what the
**internal-design lens** is for: working the open questions into decided design before the
GDD is authored. When the argument **resolves to a `RECON.md` file**, run this mode.
**Pre-GDD carve-out.** The internal-design lens normally requires `GAME.md` (it reasons
about *this game's* design). RECON.md **is** that candidate design surface before a GDD
exists, so the lens engages on it directly — the one pre-GDD case where "no `GAME.md`"
does **not** bounce to brainstorm/spec.
1. **Deep-read `RECON.md`** as the candidate design (in place of `GAME.md` + system docs):
its `## Systems`, `## Content Types`, `## Resources · Entities · Forms`,
`## Provided Context`, and especially the **`## Intent Gap`**.
2. **Treat the `## Intent Gap` as the open-questions registry.** Each gap item — pillars,
target fantasy, win/lose intent, "are these numbers balanced or merely current?" — is
an open question; run the lens's closure pass over them (deep-read, options, decide),
exactly as the internal-design lens does for a GDD's open questions.
3. **Carry the code provenance.** Facts the lens lifts **from RECON's reconstructed
sections** stay `provenance: extracted from code` (held ≥ Major — `gd-provenance`); mark
them as such in the research record, symmetric with the code-grounded lens. The
designer's own decisions worked out on top stay **untagged**.
4. **Save the research AS USUAL — then backlink it (the asymmetry with review-file mode).**
Unlike a review file (mutated in place, no `researches/`), RECON.md is a **durable
seed**: save the research the normal way (`researches/<date>_<slug>/` via "Saving
Research Results"), then write a `research:` **backlink** into RECON.md's
**`## Explorations`** section — an accumulating registry of pointers, the cold-start
mirror of the `GD-IDS` `research:` pointer. Append (create the section if absent), one
line per research:
```
- research: `researches/<date>_<slug>/` — <1-line topic> (Target: <SYS-slug | Intent-Gap item>)
```
This is a **sanctioned write into RECON.md** (owned by `unikit-gd-recon`) — recorded in
Ownership below; explore writes nothing else to RECON.md.
5. **End with the import command (Handoff Tail contract).** The reconstruction is now
worked-through. **Recommend** (print, never invoke — no `Skill` tool) the import as the
**last block**, icon in front, nothing after it:
```
🗺️ /unikit-gd-spec .unikit/gamedesign/RECON.md
```
`/unikit-gd-spec` import mode extracts a `GAME.md` and asks the user to fill the Intent
Gap — now pre-worked by the linked research. The subagent-mode bypass applies as
elsewhere (no interactive closure-pass questions when spawned).
## Serving a brainstorm request (subagent mode)
`unikit-gd-brainstorm` delegates market validation to this skill by spawning it as a
subagent (`Agent(subagent_type: general-purpose, skills: ["unikit-gd-explore"], …)`).
The full contract — input, output fields, ownership, gate — is **this skill's own**
`references/delegation-contract.md` (Explore owns the spec, provider-owns-spec);
`references/market-scan.md` → "Subagent mode" holds the engine behavior. This section
is the SKILL-level switch.
**Detect delegation by the canonical marker** — the prompt contains, verbatim:
> **"Return the brief into this session as text; do not save any files."**
Detection is by this **exact phrase**, not by a loose reading of the prompt. On a
match, **load `references/delegation-contract.md`** — it fixes the brief's field shape,
the machine fields, and the four-verdict gate the brief's `recommendation` feeds — then
run **deterministically**:
- **Bypass every interactive `AskUserQuestion`** — the lens tie-breaker above, the
save-offer under "Saving Research Results", **and** the internal-design and
code-grounded lenses' interactive questions (the domain-confirmation prompt and the
whole open-questions **closure pass**). A subagent is non-interactive; any prompt would
hang it — and a brainstorm delegation is always a market scan, never an internal-design
or code-grounded read, so there is nothing left to disambiguate.
- **Run the market lens** and produce the **brainstorm-delegation brief**
(`market-scan.md`): per concept `market_signal` + `validation_confidence` +
evidence.
- **Return the brief into the session as text — save no file.** "Do not save" means
**skip the save step**, not answer "no" to a prompt (there is no prompt). The
calling session owns persistence.
- **Prefer direct `WebSearch` / `WebFetch`** over a nested `Agent(subagent_type:
Explore)` (see "Parallel investigation").
## Saving Research Results
When the conversation crystallizes, **offer** to save (never auto-save):
```
AskUserQuestion: Save this research to .unikit/gamedesign/researches/?
Research name: <date>_<kebab-slug>
Options: 1. 💾 Yes — save 2. 🚫 No
```
On yes:
```bash
mkdir -p .unikit/gamedesign/researches/<date>_<slug>
```
1. **`RESEARCH_RESULT.md`** — the complete research: every dissection, comparison
table, diagram, and conclusion presented to the user. Header:
```markdown
# <Research Title>
Date: <YYYY-MM-DD HH:MM>
Updated: <YYYY-MM-DD HH:MM>
Status: completed | in-progress | needs-follow-up
Research: <folder-name>
Target: SYS-<slug> | FLOW-<slug> | CONTENT-<slug> # internal-design lens only — the system, flow, or content type this research targets
Kind: feature | improvement # internal-design lens only — feature = new system/flow/content type, improvement = existing one
## Table of Contents
## Topic — 1–2 sentences
## Context — why this research started
## Findings — dissections, comparisons, diagrams, trade-off tables
## Conclusions — what the evidence supports
## Open Questions — what remains unproven
## Next Steps — concrete follow-ups (see routing below)
## References — games, articles, URLs (note any web/Agent sources used)
```
The Table of Contents is **mandatory** and reflects the real sections. The
**`Target:` / `Kind:`** lines are written **only** by the internal design lens
(`internal-design-lens.md` → "Research tags") — they let `unikit-gd-system` /
`unikit-gd-flow` / `unikit-gd-content` discover this research deterministically
after a `/clear`.
A reference-dissection or market research omits both.
2. **`RESEARCH_BRIEF.md`** — a compact brief built **for `unikit-gd-spec` /
`unikit-gd-system` to consume** (the acceptance bar: it must be usable as their
input). Sections:
```markdown
# Research Brief: <title>
- **Question**: <what was researched>
- **Key findings**: <bulleted, each with a source>
- **Portable mechanics**: <what to borrow> · **Incidental**: <what not to>
- **Trade-offs**: <the comparison table's conclusion>
- **Implications for our design**: <which pillars / systems this informs>
- **Recommended follow-up**: <spec / detail / brainstorm / prototype>
```
Fill sections with `N/A` rather than inventing content the research did not cover.
**Internal design lens — append the mode-aware block.** When this research came
from the internal design lens, append to `RESEARCH_BRIEF.md` the **one** block that
matches the resolved handoff route (full field lists in `internal-design-lens.md`
→ "Mode-aware brief"). The headings are **stable English anchors** so the routed
skill greps them deterministically:
- **`## Improvement Plan`** — when the route is `/unikit-gd-system` (target is
`detailed` / `reviewed` / `revised`): Target, expected scale, ready-to-apply
delta lines, touched GD-IDS facts, rejected alternatives, the `RF-<date>-n` it
closes (if any), deferred open questions.
- **`## New Feature Plan`** — when the route is `/unikit-gd-spec` (add-system) →
`/unikit-gd-system` (target has no doc / `not-started`): the map fields (slug,
Category, Tier, `implements: PIL-n`, `depends_on`) plus the A–K section seeds
`unikit-gd-system` pre-fills its section-cycle from.
- **`## Flow Improvement Plan`** — when the route is `/unikit-gd-flow` for a
`detailed` / `reviewed` / `revised` **flow**: Target `FLOW-<slug>`, expected scale,
delta lines (GOAL / beat / cue / event), touched GD-IDS facts, rejected
alternatives, the `RF-<date>-n` it closes (if any), deferred open questions.
- **`## Flow Feature Plan`** — when the route is `/unikit-gd-flow` for a **new flow**
(no doc / `not-started` / `skeleton`): the flow fields (slug, candidate `mode`,
`implements: PIL-n`, `depends_on: SYS-ids`) plus the A–F section seeds
`unikit-gd-flow` pre-fills its section-cycle from. (No add-flow step — the flow
zone registers itself.)
- **`## Content Improvement Plan`** — when the route is `/unikit-gd-content` for a
`detailed` / `reviewed` / `revised` **content type**: Target `CT-<slug>`, expected
scale, schema delta lines (field / type / `ref<>` / `scale`), touched GD-IDS facts,
rejected alternatives, the `RF-<date>-n` it closes (if any), deferred open questions.
- **`## Content Feature Plan`** — when the route is `/unikit-gd-content` for a **new
content type** (no doc / `not-started` / `skeleton`): the type fields (slug,
candidate `scale`, `belongs_to: SYS-<slug>`, candidate `CT.fields`) plus the A–F
section seeds `unikit-gd-content` pre-fills its section-cycle from. (No add-content
step — the content zone registers itself.)
For several targets, append one block per target (dependency-sorted).
**Next Steps routing** — turn insights into concrete follow-ups:
| Insight | Follow-up |
|---------|-----------|
| A direction worth ideating | 💡 `/unikit-gd-brainstorm` |
| Ready to formalize into the master spec / a system | 🗺️ `/unikit-gd-spec` / 🧩 `/unikit-gd-system` |
| **Internal lens** — improve a `detailed`/`reviewed`/`revised` system | 🧩 `/unikit-gd-system` (consumes `## Improvement Plan`) |
| **Internal lens** — a new mechanic (no doc / `not-started`) | 🗺️ `/unikit-gd-spec` (add-system) → 🧩 `/unikit-gd-system` (consumes `## New Feature Plan`) |
| **Internal lens** — fill a `skeleton` system | 🧩 `/unikit-gd-system` |
| **Internal lens** — improve a `detailed`/`reviewed`/`revised` flow | 🌊 `/unikit-gd-flow` (consumes `## Flow Improvement Plan`) |
| **Internal lens** — a new / `skeleton` flow | 🌊 `/unikit-gd-flow` (consumes `## Flow Feature Plan`) |
| **Internal lens** — improve a `detailed`/`reviewed`/`revised` content type | 📦 `/unikit-gd-content` (consumes `## Content Improvement Plan`) |
| **Internal lens** — a new / `skeleton` content type | 📦 `/unikit-gd-content` (consumes `## Content Feature Plan`) |
| A balance/economy/UX convention worth keeping | 🧠 `/unikit-memory --module gamedesign` |
| A consistency concern in the current design | ✅ `/unikit-gd-verify` |
3. **Update `researches/INDEX.md`** — **prepend** (newest first) after the header
(create with `> Auto-maintained by /unikit-gd-explore. Do not edit manually.`
if absent):
```markdown
---
### <Research Title>
- **Date**: <YYYY-MM-DD HH:MM>
- **Updated**: <YYYY-MM-DD HH:MM>
- **Status**: completed | in-progress | needs-follow-up
- **Summary**: <1–2 sentences from ## Topic>
- **Path**: `<folder-name>/`
- **Target**: SYS-<slug> (internal-design lens only — the fallback discovery key
for `unikit-gd-system`; omit for reference/market research)
```
On a new research `Updated` equals `Date`; on revision only `Updated` changes.
## Init: Rebuilding the Researches Index
When the argument is exactly `init`, synchronize
`.unikit/gamedesign/researches/INDEX.md` with the directory contents — a
maintenance command, no exploration:
1. List subdirectories of `.unikit/gamedesign/researches/`.
2. Parse the existing index for indexed `**Path**`s.
3. **Keep** entries whose directory still exists (unchanged); **Remove** entries
whose directory is gone; **Add** directories with no entry — read their
`RESEARCH_RESULT.md` for title/status/topic (date from the `Date:` line or the
folder prefix; `Updated` falls back to `Date`), and **when the header carries a
`Target:` line, carry it into the entry's `**Target**` field** (internal-design
lens researches — see "Research tags"; omit the field when the header has none).
Skip and warn on a missing `RESEARCH_RESULT.md`.
4. Rewrite the index (header + entries, newest-date first; same-date alphabetical).
5. Report: `Kept N · Added N (names) · Removed N (names)`.
Empty/absent directory → write a header-only index and report "No researches
found". Then **STOP** — do not enter explore mode.
## Ending
No required ending. It might flow into a saved research, into
`/unikit-gd-spec` / `/unikit-gd-brainstorm`, or just provide clarity. When things
crystallize, you might summarize the findings — but the thinking is often the value.
## Ownership Boundaries
- **Owns:** `.unikit/gamedesign/researches/` — `RESEARCH_RESULT.md`,
`RESEARCH_BRIEF.md`, and the researches `INDEX.md`.
- **Owns (spec):** `references/delegation-contract.md` — the brainstorm→explore
contract. This skill is its provider; brainstorm reads it as the interface. Keep its
canonical marker and brief field-list in sync with `references/market-scan.md`.
- **Internal design lens (read-only).** The lens (`references/internal-design-lens.md`)
deep-reads `GAME.md` / `GD-IDS.yaml` (+ its `## System Map [gen]` / `## Flow Map [gen]` /
`## Content Map [gen]` renders) / system docs / flow docs / content-type docs and hands
off a brief — it **never** writes the GDD, and it **never** writes the `research:`
pointer into `GD-IDS.yaml`; that pointer is owned by the registering zone
(`unikit-gd-spec` add-system for a **system**, `unikit-gd-flow` for a **flow**,
`unikit-gd-content` for a **content type** — there is no add-flow / add-content).
Explore only **tags** its own research (`Target:` / `Kind:`).
- **Read-only:** `GAME.md`, `GD-IDS.yaml`, systems, flows, content types, concepts —
route any design change to its owner skill, never edit them here.
- **Research-bucket mode (in-place promotion).** Developing a `unikit-gd-review`
report's `## Research` bucket turns each open finding into a decided edit and **promotes
it in place** — moving the line into the report's `## Apply-ready` bucket (reformatted as
`RF-<date>-n · <target> · Fix (entailed): <edit>`) and appending the worked-out brief —
then **recommends** the single file command `/unikit-gd-apply reviews/<file>.md`
(printed, never invoked: there is no `Skill` tool here). This in-place promotion is a
**sanctioned write into a file this skill does not own**: the `reviews/*_review-*.md`
report belongs to `unikit-gd-review`. It writes **nothing else** — not the GDD, not
`researches/` (this review-file mode never opens a `researches/` folder).
- **RECON-input mode (research + backlink).** Developing a `unikit-gd-recon` `RECON.md`
(the pre-GDD carve-out) saves the research the **normal** way (`researches/<date>_<slug>/`)
and appends a `research:` **backlink** into RECON.md's `## Explorations` section — a
**sanctioned write into a file this skill does not own** (`RECON.md` belongs to
`unikit-gd-recon`), limited to that section. It then recommends `/unikit-gd-spec
<RECON.md>` import. This is the **asymmetry** with review-file mode: a review file is
mutated in place (no `researches/`); RECON.md is durable, so the research is saved as
usual and only a pointer is written back.
- **Code-grounded lens (read-only).** When the code lens engages, this skill reads
project source and asset definitions — the sanctioned third exception to the one-way
boundary (`gd-principles`), shared with `unikit-gd-recon`. It reads only the **named
slice** (post-GDD), folds code findings into a brief tagged `provenance: extracted from
code`, and **never** edits the GDD or the code. Cold-start, whole-project
reconstruction is `unikit-gd-recon`'s, not this lens's.
- **Not this skill:** generating new concepts → `unikit-gd-brainstorm`; authoring
the spec/systems/flows/content → `unikit-gd-spec` / `unikit-gd-system` /
`unikit-gd-flow` / `unikit-gd-content`; cold-start code reconstruction →
`unikit-gd-recon`.
- **Never:** author or edit a design document; auto-save a research; read the code
workspace or project source **outside the code-grounded lens** (that lens is the one
sanctioned read — `gd-principles` third exception).
## Quick Reference
```
/unikit-gd-explore → enter design-research mode
/unikit-gd-explore break down the combat of Hades → reference dissection (MDA backwards)
/unikit-gd-explore roguelike meta-progression → genre / mechanics scan
/unikit-gd-explore is this roguelike niche saturated? → market lens (viability / white-space)
/unikit-gd-explore improve our combat balance → internal design lens (read-only) → routes to system / spec
/unikit-gd-explore how is our loot wired in the code → code-grounded lens (read-only, post-GDD slice) → brief
/unikit-gd-explore reviews/2026-06-25_review-SYS-combat.md → promote ## Research into ## Apply-ready in place → /unikit-gd-apply reviews/X.md
/unikit-gd-explore .unikit/gamedesign/RECON.md → develop the cold-start reconstruction (pre-GDD) → save research + ## Explorations backlink → /unikit-gd-spec import
/unikit-gd-explore https://… → dissect a linked design source
/unikit-gd-explore init → rebuild researches/INDEX.md
```