[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BJ1Z2QWEJJDG2WHMM708Z":3,"skill-same:01M71BJ1Z2QWEJJDG2WHMM708Z":111},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":31,"publishedAt":52,"linkOnly":53,"markdownContent":54,"markdownBody":55,"frontMatter":56,"refName":79,"commitSha":80,"skillDirectory":81,"forksCount":82,"repositoryHtmlUrl":83,"repositoryHomepageUrl":84,"ownerHtmlUrl":85,"ownerBlogUrl":6,"ownerDescription":86,"updatedAt":87,"install":88,"resources":100},"01M71BJ1Z2QWEJJDG2WHMM708Z","unikit-gd-brainstorm",null,"Ideate a brand-new game concept with the user, from a blank page or a one-line hint to a finished CONCEPT card. Use it whenever the user wants to come up with a new game — whether the project has no design document yet, or already has one and they're exploring a fresh idea. Through a structured divergence\u002Fconvergence dialogue it explores ideas, frames the hook, generates and scores concepts (market validation delegated to \u002Funikit-gd-explore), and settles pillars, loops, motivation, and a pre-mortem. Trigger whenever the user wants to make or invent a game, doesn't know where to start, or gives a genre\u002Ftheme hint, e.g. \"let's come up with a game\", \"I don't know what game to make\", \"I want to make a roguelike\", \"a game about zombies\", \"a farming game\", \"help me come up with a concept\". For researching or dissecting existing games use \u002Funikit-gd-explore; to write an already-chosen concept as the master GDD use \u002Funikit-gd-spec.","NintendaDev\u002Funikit-ai","NintendaDev","https:\u002F\u002Favatars.githubusercontent.com\u002Fu\u002F181320258?v=4","01M71BFH8JJ6EBGRXBWRZK894Y","Dmitrii Vasilev","01M71BFH9T4K66TTBFNV1ZWFN5",22,"MIT","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-brainstorm\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",{"categoryNo":27,"categoryName":28,"taxonomyType":29,"taxonomyTypeDesc":30},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49,50,51],"brainstorm","unikit gd brainstorm","theme","brand","as","concept","concepts","hook","master","start","edit","write","read","fresh","auto","design","explore","card","re","project","2026-11-10 10:12:30",false,"---\nname: unikit-gd-brainstorm\ndescription: >-\n  Ideate a brand-new game concept with the user, from a blank page or a one-line hint to\n  a finished CONCEPT card. Use it whenever the user wants to come up with a new game —\n  whether the project has no design document yet, or already has one and they're exploring\n  a fresh idea. Through a structured divergence\u002Fconvergence dialogue it explores ideas,\n  frames the hook, generates and scores concepts (market validation delegated to\n  \u002Funikit-gd-explore), and settles pillars, loops, motivation, and a pre-mortem. Trigger\n  whenever the user wants to make or invent a game, doesn't know where to start, or gives\n  a genre\u002Ftheme hint, e.g. \"let's come up with a game\", \"I don't know what game to make\",\n  \"I want to make a roguelike\", \"a game about zombies\", \"a farming game\", \"help me come up\n  with a concept\". For researching or dissecting existing games use \u002Funikit-gd-explore; to\n  write an already-chosen concept as the master GDD use \u002Funikit-gd-spec.\nargument-hint: \"[hint or theme]  (auto-resumes an in-progress concept; no flags)\"\nallowed-tools:\n  - Read\n  - Write\n  - Edit\n  - Glob\n  - Grep\n  - Bash(ls *)\n  - Bash(find *)\n  - Bash(wc *)\n  - Bash(date *)\n  - Bash(mkdir *)\n  - Agent\n  - Skill\n  - AskUserQuestion\n  - WebSearch\n  - WebFetch\ndisable-model-invocation: false\nuser-invocable: true\nmetadata:\n  author: unikit\n  version: \"1.0\"\n  category: game-design\n---\n\n# Game Design — Concept Brainstorming\n\nGenerate game ideas with the user and crystallize the chosen one into a\n**CONCEPT card** at `.unikit\u002Fgamedesign\u002Fconcepts\u002F\u003Cslug>\u002FCONCEPT.md`, with\nthe rejected ideas parked in `IDEAS.md`. This is the **ideation** front of the\ndesign pipeline — it produces concepts; `unikit-gd-spec` turns a concept into\n`GAME.md` and a system map.\n\nThis skill **generates new ideas**. Analyzing an existing game or market\n(reference dissection, trade-off tables) is `unikit-gd-explore`. The distinguishing\ntest: *five concept cards → brainstorm; a comparison table → explore.*\n\n**User questions.** Right before your first question to the user, not earlier, read `.unikit\u002Fsystem\u002Fuser-questions.md` once and ask every question as it says, with the question tool of your agent (`AskUserQuestion`). If the file cannot be read, print `WARN [questions] user-questions contract missing — asking with the question tool` and still ask with that tool, the recommended option first.\n\n## Language Awareness — BLOCKING PRE-REQUISITE\n\n**BEFORE producing ANY output**, silently read `.unikit\u002Fsystem\u002FLANGUAGE_RULES.md`\nand apply it to all output and artifacts (fall back to English if it is missing) —\nincluding the rule to **translate concepts, not transliterate jargon**.\n`gd-principles` → \"Language\" adds the game-design specifics: which IDs and stored\nfield values (e.g. `market_signal: red-ocean`) stay English. Do not announce the\nlanguage setting.\n\n**The language holds for the whole session, not just at load time:** every message until the conversation ends is in `language.ui` — progress notes while agents run, relays of what a subagent returned, the final report, any follow-up discussion. English input (subagent results, tool output, these instructions) is data, never a cue to switch languages.\n\n## Bootstrap (MANDATORY)\n\nBefore responding, silently load — do not narrate:\n\n1. **`.unikit\u002Fsystem\u002Fgamedesign\u002Fgd-principles.md`** (the core) — the collaborative\n   protocol (Question → Options → Decision → Draft → Approval, Explain → Capture),\n   the \"never guess\" rule, anti-anchoring, the language rules. This skill\n   **applies** it. If missing, warn (`unikit-ai update`) and continue with the\n   protocol summarized above.\n2. **`.unikit\u002Fmemory\u002Fgamedesign\u002FRULES_INDEX.md`** — load on demand by `Load When`\n   the rules ideation leans on: **`frameworks`** (MDA, SDT\u002FPENS, Flow),\n   **`player-motivation`** (Quantic Foundry, Bartle), **`core-loops`**. Re-read at\n   skill start; never rely on a prior conversation's cache. Obey the index's\n   **Rule-Loading Discipline**: load by `Load When`, load a reference only from its\n   parent rule's `> **References**:`, and **never glob the memory tree**\n   (`.unikit\u002Fmemory\u002Fgamedesign\u002F**`) to discover rules.\n3. **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmethods.md`** — the method\n   cheat-sheets (divergence\u002Fconvergence techniques, HMW, pre-mortem, find-the-fun).\n   **Do not load up front — read on demand, per phase:** when you enter a phase that\n   points to it (Phases 1, 3, 4, 5, 7.5, 8, 8.5), read that section then. The phase\n   summaries below carry the workflow; `methods.md` carries the deep \"how\", so a\n   resume or a phase that needs no method theory never pays for it.\n4. **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Ftables.md`** — the canonical shapes of every\n   output table the phases emit (Phases 2, 3, 4, 5, 6, 7, 8, 8.5). **Read on demand** when\n   you enter a phase that emits a table; it is the single source of truth for those tables —\n   SKILL.md and `methods.md` only point to it, never re-spell a table.\n5. **`.unikit\u002FDESCRIPTION.md`** (optional) — existing project constraints, if this\n   is ideation inside an established project.\n6. **`.unikit\u002FRULES.md`** (if present) — project overrides, highest priority. **Rule topics:** load the topic files listed under its `## Topics` whose `Load when` matches the design work at hand — the concept, system, flow or content type; when unsure, load.\n\n**Market validation is delegated, not ad-hoc.** This skill does **not** research the\nmarket inline or early — early data anchors timid ideas (anti-anchoring,\n`gd-principles`). Market evidence enters at **Phase 3.5**, where brainstorm spawns\n`unikit-gd-explore` as a subagent to scan the shortlist and **return a brief into\nthis session**. The delegation **interface** — the brief's fields, the canonical\nmarker, the four-verdict gate — is the contract at\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fdelegation-contract.md`, **loaded on\nentering Phase 3.5** (per-phase, like `methods.md`), not up front; brainstorm reads\nthat *interface*, never explore's engine (`market-scan.md`). General `WebSearch` \u002F\n`WebFetch` lookups remain available as read-only advisors — they never write and\nnever substitute for the Phase 3.5 scan.\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n## Skill calls\n\nWhere this skill says to **invoke `\u003Cskill>`** — optionally \"with the argument `\u003Ctext>`\" — it means one call, made in this session, now, on every runtime: not a command printed for the user. A call site that names no argument passes none.\n\n1. If you have a `Skill` tool that accepts arguments, call it with that skill and the arguments of the call site, in full and unchanged, then follow the skill.\n2. Otherwise — no `Skill` tool, or one that takes only a name — Read `{{skills_dir}}\u002F\u003Cskill>\u002FSKILL.md` in full, treat it as the instructions of this step and carry them out here, in this session, now, with the arguments of the call site as the skill's arguments.\n3. When the skill has run, go on to the step the call site names. Do not print a command for the user to run and do not stop.\n4. Only if that file cannot be read: print `Run: \u002Funikit-\u003Cskill> \u003Carguments>` for the user and stop.\n\n## Subagent launches\n\n**Subagent arguments.** Before the first subagent you launch, read `.unikit\u002Fsystem\u002Fsubagent-arguments.md`\nand `.unikit\u002Fconfig.yaml` once and settle the model and effort of every launch as that file says.\nKeys: `subagents.model.{{agent_id}}.\u003Crole>`, `subagents.effort.{{agent_id}}.\u003Crole>`;\nbuilt-in model of a reader and a validator: `\"{{agent_model_default}}\"`, of an executor: none.\nIf the file cannot be read, print\n`WARN [delegation] subagent-arguments contract missing — built-in model tier used, effort not passed`\nand use that model, no effort.\n\n## Phase 0 — Auto-Resume (no flags)\n\n*Brainstorming runs across many turns, so this step looks in the concepts index for\nan unfinished concept that matches the hint and offers to continue it — a session\ninterrupted by a `\u002Fclear` or a closed terminal is never lost.*\n\nRead `.unikit\u002Fgamedesign\u002Fconcepts\u002FINDEX.md` (if it exists). Each row carries a\nslug, title, keywords, **status** (`in-progress | complete | promoted | abandoned`),\nand the last phase reached. Semantically match the user's hint against the rows:\n\n- A live `in-progress` concept matches the hint →\n\n  ```\n  The question tool of your agent (`AskUserQuestion`): Found \"\u003Ctitle>\" — you left off at phase \u003CN>. What now?\n  Options:\n  1. Continue \"\u003Ctitle>\" from phase \u003CN> (recommended)\n  2. Start a fresh concept\n  3. List all concepts\n  ```\n\n- No match → start a new concept at `concepts\u002F\u003Cslug>\u002F`.\n- A match exists but the user chooses to start fresh → **ask for a different slug**, then\n  create `concepts\u002F\u003Cnew-slug>\u002F` and print `INFO [concept] creating \u003Cnew-slug>`.\n\n`promoted` and `abandoned` concepts are **never offered for resume**, but their\n`IDEAS.md` is read so the session does not re-pitch a killed idea. Repeated\nbrainstorms need a **different** slug — the user is asked for one; the date no longer\nsupplies the difference. **Appending an automatic suffix is forbidden**: the slug is\nderived from the topic, so a second run at one topic produces the same name, and a\nsilently suffixed folder is one the auto-resume above will never offer again.\n\nOn resume, jump to the saved phase — including the **fractional phases 3.5, 7.5, and\n8.5** (a session interrupted mid-scan, mid-flow-seeds, or mid-validation resumes there,\nnot back at 3, 7, or 8); on a fresh start, begin at Phase 1.\n\n## Phases 1–9\n\nRun the phases in order. Each phase below is the **workflow**; its deep method detail\nlives in `references\u002Fmethods.md` — read that section when you reach the phase, not up\nfront. Diverge and converge as **separate** moves — never score an idea as you\ngenerate it.\n\n### How to respond in each phase\n\n- **Go deep, not terse.** Each phase is a consultation, not a form to fill in. When\n  you present options, loops, pillars, or risks, explain the *reasoning* in a few\n  sentences — the framework it draws on, the comparable game that proves it, the\n  trade-off it carries — not a bare one-line bullet. The user is making a creative\n  decision and needs the *why*, not just the *what*. A phase answered in a single line\n  is almost always too thin; spend the words.\n- **Open every phase with its purpose.** The italic line under each heading below says\n  what the phase is and why it exists — orient the user the same way in your own words\n  before you dive into the questions, so no phase arrives unexplained.\n- **Readable plain markdown only.** Number options and concepts with plain `1.` \u002F `2.`\n  and label variants `A)` \u002F `B)`. Never use circled or enclosed glyphs (①②③, 🅰🅱, Ⓐ)\n  or other decorative unicode — they render as boxes or unreadable smudges in most\n  terminals. Bold, short tables, and plain headings carry all the structure you need.\n\n### Phase 1 — Creative Discovery (+ commercial frame)\n\n*Find the seed before generating anything: who you are designing for, the feeling you\nare chasing, and what \"success\" means commercially. This is what makes every idea that\nfollows aimed and yours, instead of generic.*\n\nAsk about the **person**, not the game: emotional anchors, three games they love\nand what those left them wanting, plus constraints (solo\u002Fteam, deadline, engine,\nexperience). Synthesize a **Creative Brief** (3–5 sentences) and confirm it.\n\nThen capture a **commercial frame** (one screen, kept separate from the person\nquestions):\n\n- **Target outcome tier** — hobby \u002F recoup \u002F commercial.\n- **Target platform** — ask explicitly, **never default to Steam** (the four options\n  below). Platform is a market-shaping decision, not a deployment detail.\n- **Budget \u002F team size** — solo \u002F small team \u002F funded. A **reachability** constraint:\n  a clone-dense mobile market is unreachable without a UA budget, however good the\n  concept. Phase 3.5 reads demand as *reachable* vs *someone else's* against it, and\n  passes it to the delegated scan as the `budget\u002Fteam` input.\n- **Target session length** — shapes platform fit (web rewards short instant loops;\n  premium PC tolerates long sessions); sets the card's platform-fit sanity line (field 8).\n- **Monetization intent** — premium \u002F F2P-IAP \u002F ads \u002F portal rev-share \u002F none. Feeds\n  the T8 `monetization_fit` read in Phase 3.5 (`monetization_intent` in the scan).\n- **Scan mode** — `quick` \u002F `standard` \u002F `deep` for the Phase 3.5 delegation;\n  `standard` is the default, `quick` for an early red-ocean sweep of 3–4 concepts.\n- **Kill-readiness** — drop on bad data, or passion-project regardless?\n\nPlatform options (name a *lead* even for cross\u002Fconsole):\n\n1. **PC \u002F Steam** — wishlist-driven, long tail, premium or early-access pricing.\n2. **Mobile** — store-feed and UA-driven, F2P norms, short sessions, clone-dense.\n3. **Web \u002F instant** — portal- and embed-driven (itch, CrazyGames, Poki): instant\n   play, near-zero install friction, ad\u002Fportal economics.\n4. **Cross \u002F console** — still name a *lead* platform; one store shapes every later\n   signal.\n\nThe platform **steers the Phase 3.5 scan** (each platform has its own demand signals,\nsources, and clone-density; the cross-market rule turns a mobile\u002Fweb target into a\nSteam demand-check plus a target-store clone-check — full per-platform table and the\ncross-market rule in `references\u002Fmethods.md` § Phase 1).\n\n**Anti-anchoring boundary (explicit).** Structural *platform* facts (mobile is\nclone-dense; web rewards an instant hook; Steam is wishlist-driven) may inform this\nframe now — they are not about any specific concept and do not anchor divergence.\n**Concept-specific demand data** (does *this* idea sell, how many clones of *this*\nconcept exist) is withheld until Phase 3.5, after divergence.\n\nThe frame **scopes Phase 3.5; it does not censor divergence.** A user with no\ncommercial intent leaves it **empty** — that is valid and **skips Phase 3.5**\n(`market-signal` then stays an ordinary Pugh judgment, not a delegated scan).\n\n### Phase 2 — How-Might-We Framing\n\n*Recast the brief as open \"How might we…\" questions that invite many answers instead\nof smuggling in one solution. Good framing is what keeps the next step — divergence —\ngenuinely wide.*\n\nReframe the brief as **3–5 \"How might we…\"** questions (positively framed, no\nbaked-in solution). **Present them as a table** so the user can weigh the framings side\nby side instead of reading a flat list, and mark the strongest **(Recommended)** with a\none-line WHY; the user picks one to diverge on. The table's columns and a worked example\nlive in `references\u002Ftables.md` § Phase 2 (the single source of truth for this table).\n\n### Phase 3 — Divergence\n\n*Generate breadth on purpose: five concepts from five different idea-generators, so\nthe field is genuinely varied and not five repaints of the first thought. Hold all\njudgment for later — quantity now, scoring in Phase 4.*\n\nGenerate **five concepts using five different methods** (verb-first, genre mashup\nwith the intersection-audience caveat, experience-first\u002FMDA-backward, world-first,\nconstraint-first — each method's prompt and source in `references\u002Fmethods.md`\n§ Phase 3). Render **each** concept as its own **nine-field card** — a `Field | Value`\ntable so the fields stay aligned and scannable instead of buried in prose. Then, after\nthe five cards, present one **comparison table** across all of them: the shortlist\ndecision is a side-by-side judgment (\"which two hooks are strongest?\") that five separate\ncards cannot support at a glance. The nine fields, the comparison columns, and worked\nexamples of both live in `references\u002Ftables.md` § Phase 3 (the single source of truth for\nthese tables).\n\nOnce the five are on the table, ask the user how to proceed — and offer three\ndistinct moves, not just \"pick some\":\n\n1. **Shortlist 2–4** to carry forward into validation \u002F scoring.\n2. **Five more** — *extend* the field with a stimulus method (random input \u002F SCAMPER \u002F\n   Lotus Blossom) built on the current favorite; keeps what is working and pushes for\n   adjacent variety.\n3. **Regenerate from scratch** — *discard this whole batch* and generate five **new**\n   concepts from different methods or a different How-Might-We angle. This is the right\n   call when none of the five land or they all feel like one idea wearing five hats.\n   The discarded batch still goes to `IDEAS.md` (with its revival condition) so nothing\n   is silently lost or re-pitched later.\n\n### Phase 3.5 — Market validation (delegated to explore) — **gated**\n\n*Pressure-test the shortlist against the real market — does a reachable audience\nexist, and is there unmet room for it — delegated to explore so brainstorm never\ngrades a market from memory. It runs after divergence, on purpose: early data anchors\ntimid ideas.*\n\n**Gate:** run this phase **only if Phase 1 produced a non-empty commercial frame.**\nEmpty frame → **skip**; `market-signal` stays an ordinary Phase 4 judgment, no\nsubagent.\n\nRun **after** divergence, on the user's **shortlist (2–4 concepts)** — never earlier\n(early data anchors timid ideas; `gd-principles`). brainstorm does **not** research\nthe market itself — it **delegates** to `unikit-gd-explore` and consumes the evidence.\n\n**Load the contract first.** On entering this phase, read\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fdelegation-contract.md` — the interface\nthis delegation follows: the brief's fields, the canonical marker, and the\nfour-verdict gate. brainstorm reads that *interface*, never explore's engine\n(`market-scan.md`). (Hard-code the `unikit-gd-explore` path — it is **not**\n`{{self_name}}`.)\n\n**Delegate** — spawn explore as a subagent and **wait for the return**. Expands to:\n\n```\nAgent(\n  {{agent_call_worker_quoted}}\n  prompt: \"{{agent_skill_call:unikit-gd-explore}} \u003Ccommercial frame incl. target platform + budget\u002Fteam + shortlist>. scan_mode: \u003Cquick|standard|default standard>. Validate cross-market per the platform rule. Return the brief into this session as text; do not save any files.\",\n  description: \"Market-validate the shortlist\"\n)\n```\n\nPass **`scan_mode`** explicitly: `standard` is the default; use `quick` for an early\n3–4 concept red-ocean sweep (it returns C-capped signals — enough to flag, not to\ncommit on). Carry the **budget\u002Fteam** slot from the commercial frame as a reachability\ninput; until Phase 1 captures it, it arrives `unknown` and the scan degrades\ngracefully (never fabricates a budget read). Substitute the real frame values into the\n`\u003C…>` placeholders.\n\n**Fallback (no Agent tool).** If the `Agent` tool is unavailable in this environment,\ndo **not** print the delegation as a recommendation — that is a known failure mode\nwhere the model renders the call instead of running it. Instead, invoke `unikit-gd-explore`\n(`## Skill calls`), passing the same commercial frame + shortlist and the canonical marker\nverbatim, and wait for its brief. If its file cannot be read — instead of step 4 of\n`## Skill calls`, which would stop here — run the scan yourself inline with\n`WebSearch` \u002F `WebFetch` against the technique catalogue in\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fmarket-scan.md` (comparable mapping, demand\nclassification, review mining, and the cross-market rule above), and label every\nfinding with the same `market_signal` + `validation_confidence` fields so the rest of\nthe flow is unchanged.\n\nThe prompt MUST carry the **canonical marker** verbatim, on one line:\n\n> *\"Return the brief into this session as text; do not save any files.\"*\n\nso explore runs its market lens deterministically and persists nothing (the\ncontract). The subagent returns, per concept, `market_signal` +\n`validation_confidence` + a short evidence brief **into this session**.\n\n**Carry the platform — the cross-market rule.** A market is platform-specific (a genre\nthat thrives on Steam can be a clone-saturated graveyard on mobile, and the reverse\nhappens too), so the delegation prompt names the **target platform from Phase 1** and,\nfor a non-PC target, asks explore to validate *across* markets: prove the genre on Steam\n(the clearest *demand* signal even when you ship elsewhere), then scan the *target* store\nfor clones, then read the gap — Steam-proven + no strong clone on the target store is the\nprize; Steam-proven **but** the target store already clone-dense is a red ocean on the\nplatform that actually matters. The mechanics of that rule live in\n`references\u002Fmethods.md` § Phase 1, and the scan engine that runs it in\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fmarket-scan.md`. Report the read **per platform** in the\nbrief; it feeds the kill gate below.\n\n**Consume — the calling session owns persistence:**\n- Lift the **six machine fields** (`market_signal`, `validation_confidence`,\n  `clone_density`, `trend_fit`, `monetization_fit`, `recommendation`) **verbatim** into\n  the **CONCEPT card** header machine-block, **outside the nine-field table** (the card\n  stays \"nine fields, no more\").\n- Distil `key_evidence` and `go_to_market_risk` (comparables, the unmet need, the reach\n  risk) into the card's **`## Notes`** — not just the machine fields.\n- **Write no `researches\u002F` file** — that directory is explore's; a delegated scan is\n  evidence for *this* concept, carried in the card.\n\n**Decision gate — four verdicts, not a binary.** Consume the brief's `recommendation`\nper concept and surface it **before** Phase 4 scoring (the contract's gate table):\n\n| Verdict | Meaning | Action |\n|---------|---------|--------|\n| **proceed** | white-space, confidence ≥ B | carry into Phase 4 as a strong candidate |\n| **proceed-with-differentiation** | contested, conf ≥ B, a clear twist exists | carry forward; sharpen the hook |\n| **validate-later** | white-space\u002Fcontested at conf C, or `unknown` | carry forward but route the open risk to the Phase 8.5 validation plan |\n| **pivot** | red-ocean **but** an adjacent white-space exists | cross-pollinate (below): graft the under-competed angle onto a stronger concept; render the hybrid as a full nine-field card |\n| **kill** | red-ocean, no adjacent white-space, unreachable at scope | park in `IDEAS.md` with a revival condition |\n\nNever silently carry a `kill`\u002F`pivot` concept forward, and never `proceed` or `kill`\non `unknown` — `unknown` always routes to `validate-later`. The gate informs; the\nuser decides.\n\n**Cross-pollinate before you cut (the `pivot` verdict).** A red-ocean concept is not\nonly a kill candidate — it is also raw material, and the gate's **`pivot`** verdict\nroutes here rather than to `kill`. When one shortlisted concept reads **red-ocean**\nwhile another reads **white-space \u002F contested**, do not just drop the crowded one:\nproactively offer\na **genre mash-up** that grafts the under-competed concept's angle onto the stronger\none (the genre-mashup divergence method, with its intersection-audience caveat — the\nhybrid must please *both* audiences, not merely exist). A saturated genre often hides a\nstrong twist the moment it is crossed with a fresher one. The hybrid is a **new candidate\nconcept**, so present it as a full **nine-field concept card** — the same `Field | Value`\ntable as Phase 3 (`references\u002Ftables.md` § Phase 3), not a loose prose pitch — so it is\ndirectly comparable to the shortlist; route it to Phase 4 \u002F Phase 8.5. Recommend it when\nthe evidence supports it, but never impose it — the user decides.\n\n### Phase 4 — Convergence (two-pass Pugh) → **incremental write**\n\n*Now judge. A two-pass Pugh matrix scores the survivors on locked creative criteria\nfirst, then on the market evidence — keeping the two apart so optimism can never\nout-vote data. Pugh scoring just compares each option against criteria to rank them\ntransparently.*\n\nScore the surviving concepts with a **two-pass Pugh matrix** (full method, the hard\nrule, and the `market-signal` vs `market_signal` terminology in `references\u002Fmethods.md`\n§ Phase 4 + § Content velocity):\n- **Pass 1 — creative** (lock *before* the scan): hook \u002F scope-fit \u002F team-fit \u002F\n  personal-fire \u002F **content-velocity** — can the design *feed itself* cheaply\n  (procedural \u002F systemic \u002F competitive \u002F UGC), or does every play-hour cost\n  author-hours of hand-made content? A low-velocity model is a hidden scope and\n  live-game risk, scored here as a real feasibility axis, not a footnote.\n- **Pass 2 — evidence** (from the Phase 3.5 brief, only if it ran): market-signal +\n  validation-confidence.\n\n**Hard rule:** the **market-signal** score may **not exceed what\nvalidation-confidence allows** — an unproven market read cannot win on optimism.\nShow the two passes as **two separate tables** (columns and a worked matrix in\n`references\u002Ftables.md` § Phase 4) — kept apart so locked creative scores and market\nevidence never share a column; the user weights, arithmetic transparent. If\nPhase 3.5 was skipped, `market-signal` is scored as an ordinary Pass-1 judgment. Use\n**How-Now-Wow** if \"I like all of them\". Do **not** approve a hybrid whose winning\nbet rests on a low-confidence market assumption — route it to Phase 8.5 instead.\nSelect or hybridize. Rejected concepts go to **`IDEAS.md`** (idea, essence, reason,\nrevival condition). **Persist now** — write the chosen card draft and `IDEAS.md`; an\ninterruption after this loses nothing.\n\n### Phase 5 — Loop Stack\n\n*Map the nested gameplay loops — from the 30-second core action up to the meta-game —\nplus the discoverability loops that decide whether anyone starts and comes back. This\nis the spine of moment-to-moment fun and the first read on whether the game retains.*\n\nDefine the nested loops (30 s \u002F 5 min \u002F session \u002F meta) plus the **discoverability\nloops** (first-session → retention, the 6-second trailer moment, the \"one more run\"\nretention hook — full detail in `references\u002Fmethods.md` § Phase 5). Then audit **SDT**\n(Autonomy \u002F Competence \u002F Relatedness — flag if only 1 of 3 is served) and **game feel**\n(does the core verb get ≤100 ms, multi-channel feedback? — Swink). Present all three as\ntables — the loop stack, the SDT audit, the game-feel check — so a gap (an unserved need,\na flat verb) is visible at a glance rather than lost in prose. Columns and worked examples\nare in `references\u002Ftables.md` § Phase 5 (the single source of truth).\n\n### Phase 6 — Pillars & Anti-Pillars → **incremental write**\n\n*Pillars are the 3–5 load-bearing design values every later decision gets tested\nagainst (\"does this serve a pillar?\"). Anti-pillars name what the game deliberately\nrefuses to be — together they keep scope honest and decisions consistent.*\n\nDerive **3–5 pillars**: active, each serving ≥1 emotion, each with a **design test**\nand mutual tension; reject empty pillars and task-pillars. For each pillar add\n**Evidence** (the data \u002F comparable that justifies it — ideally the Phase 3.5 brief's\nreview-mining) and a **Cut rule** (what is cut first under scope pressure); a pillar\nwith no evidence is a slogan — flag it. Add **≥3 anti-pillars** (\"We will NOT \u003CX>\nbecause PIL-n\"); the brief's review-mining (love \u002F hate \u002F wish) feeds these. Present the\npillars and anti-pillars as **two tables** — a pillar carries five columns (emotion,\ndesign test, evidence, cut rule) that only line up under scrutiny in a grid, and the\ntable makes a sloganeering pillar (empty evidence cell) impossible to hide. Columns and\nworked examples are in `references\u002Ftables.md` § Phase 6. Run a Lock \u002F Rename \u002F Swap cycle.\n**Persist now.**\n\n### Phase 7 — Player Motivation (player + buyer)\n\n*Pin who this is for psychologically (what drives them to play) and commercially (what\nmakes them buy or wishlist) — and, just as sharply, who it is NOT for. A concept that\nserves everyone usually moves no one.*\n\n**Quantic Foundry:** the user ranks the **top 3 of 12** motivations; the skill\nchecks them against the pillars and loops. Set MDA primary\u002Fsecondary and a one-line\nBartle read. Then separate **player from buyer**: the **buying trigger** and the\n**quitting \u002F refund trigger** (from the Phase 3.5 brief when it ran), plus an\nexplicit **anti-persona** — \"who this is NOT for\". Capture the whole read as one table\n(player psychology → buyer triggers → anti-persona) — columns and a worked example in\n`references\u002Ftables.md` § Phase 7.\n\n### Phase 7.5 — Scenario \u002F Flow seeds\n\n*Turn the loops (Phase 5) and pillars (Phase 6) into the **dynamics seeds** the Flow\naxis picks up downstream — this does not author flows, it seeds them (as Phase 6 seeds\nthe pillars the spec later formalizes).*\n\nDraft **3–5 scenario prompts** (the concrete player situations the game must deliver,\neach anchored to a pillar), a **candidate wiring mode** per scenario (`linear` \u002F\n`conditional` \u002F `emergent` — a candidate only; `\u002Funikit-gd-flow` confirms it), and\n**flow seeds** (1–3 draft `GOAL`-shaped objectives + the systems each would exercise,\n`GOAL → SYS`). Drafts, not registered ids — full method in `references\u002Fmethods.md`\n§ Phase 7.5. The seeds ride into Phase 9's Open Questions \u002F Next Steps for the Flow\naxis (`\u002Funikit-gd-explore` flow lens → `\u002Funikit-gd-flow`); brainstorm never writes a\n`FLOW.md` or `GD-IDS`.\n\n### Phase 8 — Pre-mortem & Scope → **incremental write**\n\n*Klein's pre-mortem: imagine it is six months out and the project already failed —\ntreat that as a fact — and list why. The certainty framing surfaces the doubts\noptimism normally hides, so you can cut scope down to the part that proves the fun.*\n\nRun **Klein's pre-mortem verbatim** (\"six months from now the project failed — that is\na fact — why?\" — the certainty framing *is* the technique; `references\u002Fmethods.md`\n§ Phase 8): 8–12 reasons across fun \u002F scope \u002F market \u002F tech \u002F team \u002F **content** (ran\nout of content, or it got too slow\u002Fexpensive to make — the content-velocity risk as a\nfailure mode). Present the 8–12 reasons as a table (reason · category · real? ·\nmitigation — `references\u002Ftables.md` § Phase 8); the user marks the real ones; mitigate\nonly those. Then settle the platform, the **MVP cut** — does the chosen scope match how fast you can actually ship\ncontent? — and the **find-the-fun test** (Cerny: the smallest prototype that proves or\nkills the core; `references\u002Fmethods.md` § Phase 8). **Persist now.**\n\n### Phase 8.5 — Validation Plan & Kill Criteria\n\n*Turn each real risk the pre-mortem found into the cheapest test that proves or kills\nit before full production — every test with a pass threshold, a deadline, and explicit\nkill-criteria numbers. The goal: spend the least to retire the biggest risk.*\n\nFor each **Critical** risk the pre-mortem marked real, design the **cheapest test\nthat proves or kills it** before building the full game (the test catalogue — fake-door\nSteam page \u002F prototype \u002F Discord poll \u002F capsule A\u002FB, each with its typical signal — in\n`references\u002Fmethods.md` § Phase 8.5). Each test names a **pass threshold + deadline +\nthe risk it retires**. State **2–4 explicit kill criteria with numbers** (reuse the\nPhase 3.5 brief's benchmarks, e.g. genre wishlist medians). Present both as tables — the\nvalidation tests and the kill criteria — per `references\u002Ftables.md` § Phase 8.5. This is where a\nlow-confidence market bet from Phase 4 gets a cheap real-world check instead of a\ntaste call. Record the tests and kill criteria in the card's **`## Notes`** — **no\nseparate file** (brainstorm owns one card, not a research bundle).\n\n### Phase 9 — Record & Handoff\n\n*Lock the finished concept into one approved CONCEPT card and hand off to the next\nstep. The card is the only artifact that survives the session, so it must carry the\nreasoning and the market evidence, not just the verdict.*\n\nPresent the **complete CONCEPT card** for **one approval** (\"not yet\" → edit\nsections, do not split the approval). When Phase 3.5 ran, the card must carry the\n**market evidence** so it is traceable: the **six machine fields** (`market_signal`,\n`validation_confidence`, `clone_density`, `trend_fit`, `monetization_fit`,\n`recommendation`) in the header block **and** the distilled argument in `## Notes` (no\n`researches\u002F` file was written — the card *is* the citation). Set the card header\n(`> Status: drafted · Version: 1 · Created: \u003Cdate>`).\n\nAlso set the **descriptive `genre:` hint** in the header — a human genre name\ninferred from the concept (the elevator-pitch *[genre]* slot, e.g. «симулятор\nломбарда», «match-3 головоломка»). It is an **intent, not a catalog id**: write\nwhat the game *is*, even if no genre-profile is named that. `unikit-gd-spec`\nresolves this hint best-fit to a bundled profile and installs it downstream.\n**Brainstorm stays CLI-free here** — it never runs `unikit-ai genres list` \u002F\n`genres install` and never recommends or installs a profile; the genre catalog is\nconsumed at spec, not here (this avoids the chicken-and-egg of an empty profile\nbefore install). Leave `genre:` empty\u002Fsoft when no clear genre — `unikit-gd-spec`'s\nuniversal baseline covers it.\n\nSet the INDEX row status to `complete`. Then recommend the follow-up (do not auto-invoke).\n\n## Writing the Artifacts\n\n```bash\nmkdir -p .unikit\u002Fgamedesign\u002Fconcepts\u002F\u003Cslug>\n```\n\n- **`CONCEPT.md`** — the nine-field card with a `## Notes` section for the reasoning\n  the table cannot hold (rejected alternatives, inspirations, the Phase 3.5 market\n  argument, the Phase 8.5 validation tests). When Phase 3.5 ran, the header carries a\n  **machine block** with the six machine fields (`market_signal`,\n  `validation_confidence`, `clone_density`, `trend_fit`, `monetization_fit`,\n  `recommendation`) **outside** the nine-field table (the table stays \"nine fields, no\n  more\"). These underscore fields are *evidence* — distinct from the hyphenated\n  `market-signal` Pugh *criterion*.\n  Header: `> Status: \u003Cexploring|drafted|approved> · Version: 1 · Created: \u003Cdate>`.\n  Also a `> genre: \"\u003Cdescriptive hint>\"` header field — the human genre name\n  (intent, not a catalog id; Phase 9). CLI-free: brainstorm writes the hint only;\n  `unikit-gd-spec` resolves it to a profile and installs it.\n- **`IDEAS.md`** — the rejected-idea backlog: each entry is *idea · essence ·\n  reason (scope \u002F not-fun \u002F off-theme \u002F duplicate) · revival condition*.\n- **`concepts\u002FINDEX.md`** — prepend (newest first) a row:\n  `slug · title · keywords · status · last phase · market_signal` (the last column\n  blank when Phase 3.5 was skipped). Create with a\n  `> Auto-maintained by \u002Funikit-gd-brainstorm. Do not edit manually.` header if\n  absent. Update the existing row's status\u002Fphase on resume.\n\n## Final: Compact Report & Next Steps\n\nThe terminal plaque (TIER A — `gd-principles` → Language: names lead, status is a plain\nphrase; the pillar ids live in GAME.md \u002F GD-IDS):\n\n```\nConcept: \u003Ctitle>  (.unikit\u002Fgamedesign\u002Fconcepts\u002F\u003Cslug>\u002F)\nStatus: \u003Cstill a draft | approved>  ·  reached phase 9\nPillars: \u003Cname>, \u003Cname>, …   Anti: \u003Cn>   MDA: \u003Cprimary>\u002F\u003Csecondary>\nFind-the-fun: \u003Cthe prototype that proves the core>\nRejected → IDEAS.md: \u003Cn>\n```\n\n**Next steps** (do not auto-invoke):\n\n- 🗺️ Build the master spec — \u002Funikit-gd-spec \u003Cslug>\n- 🔬 Research a reference or the market — \u002Funikit-gd-explore \u003Ctopic>\n\nPrototype-first is also valid — validate the find-the-fun before specing.\n\nNo summary document, no report file.\n\n## Ownership Boundaries\n\n- **Owns:** `.unikit\u002Fgamedesign\u002Fconcepts\u002F` — `CONCEPT.md`, `IDEAS.md`, and the\n  concepts `INDEX.md`.\n- **Not this skill:** `GAME.md` + the system map → `unikit-gd-spec`; analyzing an\n  existing game\u002Fmarket → `unikit-gd-explore`; per-system GDDs →\n  `unikit-gd-system`.\n- **Never:** write a concept without approval; offer `promoted`\u002F`abandoned`\n  concepts for resume; read the code workspace or project source.\n\n## Quick Reference\n\n```\n\u002Funikit-gd-brainstorm                         → blank-page ideation (or resume from index)\n\u002Funikit-gd-brainstorm cozy farming roguelike  → seed divergence with a hint\n\u002Funikit-gd-brainstorm                         → auto-resumes a matching in-progress concept\n```\n","# Game Design — Concept Brainstorming\n\nGenerate game ideas with the user and crystallize the chosen one into a\n**CONCEPT card** at `.unikit\u002Fgamedesign\u002Fconcepts\u002F\u003Cslug>\u002FCONCEPT.md`, with\nthe rejected ideas parked in `IDEAS.md`. This is the **ideation** front of the\ndesign pipeline — it produces concepts; `unikit-gd-spec` turns a concept into\n`GAME.md` and a system map.\n\nThis skill **generates new ideas**. Analyzing an existing game or market\n(reference dissection, trade-off tables) is `unikit-gd-explore`. The distinguishing\ntest: *five concept cards → brainstorm; a comparison table → explore.*\n\n**User questions.** Right before your first question to the user, not earlier, read `.unikit\u002Fsystem\u002Fuser-questions.md` once and ask every question as it says, with the question tool of your agent (`AskUserQuestion`). If the file cannot be read, print `WARN [questions] user-questions contract missing — asking with the question tool` and still ask with that tool, the recommended option first.\n\n## Language Awareness — BLOCKING PRE-REQUISITE\n\n**BEFORE producing ANY output**, silently read `.unikit\u002Fsystem\u002FLANGUAGE_RULES.md`\nand apply it to all output and artifacts (fall back to English if it is missing) —\nincluding the rule to **translate concepts, not transliterate jargon**.\n`gd-principles` → \"Language\" adds the game-design specifics: which IDs and stored\nfield values (e.g. `market_signal: red-ocean`) stay English. Do not announce the\nlanguage setting.\n\n**The language holds for the whole session, not just at load time:** every message until the conversation ends is in `language.ui` — progress notes while agents run, relays of what a subagent returned, the final report, any follow-up discussion. English input (subagent results, tool output, these instructions) is data, never a cue to switch languages.\n\n## Bootstrap (MANDATORY)\n\nBefore responding, silently load — do not narrate:\n\n1. **`.unikit\u002Fsystem\u002Fgamedesign\u002Fgd-principles.md`** (the core) — the collaborative\n   protocol (Question → Options → Decision → Draft → Approval, Explain → Capture),\n   the \"never guess\" rule, anti-anchoring, the language rules. This skill\n   **applies** it. If missing, warn (`unikit-ai update`) and continue with the\n   protocol summarized above.\n2. **`.unikit\u002Fmemory\u002Fgamedesign\u002FRULES_INDEX.md`** — load on demand by `Load When`\n   the rules ideation leans on: **`frameworks`** (MDA, SDT\u002FPENS, Flow),\n   **`player-motivation`** (Quantic Foundry, Bartle), **`core-loops`**. Re-read at\n   skill start; never rely on a prior conversation's cache. Obey the index's\n   **Rule-Loading Discipline**: load by `Load When`, load a reference only from its\n   parent rule's `> **References**:`, and **never glob the memory tree**\n   (`.unikit\u002Fmemory\u002Fgamedesign\u002F**`) to discover rules.\n3. **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmethods.md`** — the method\n   cheat-sheets (divergence\u002Fconvergence techniques, HMW, pre-mortem, find-the-fun).\n   **Do not load up front — read on demand, per phase:** when you enter a phase that\n   points to it (Phases 1, 3, 4, 5, 7.5, 8, 8.5), read that section then. The phase\n   summaries below carry the workflow; `methods.md` carries the deep \"how\", so a\n   resume or a phase that needs no method theory never pays for it.\n4. **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Ftables.md`** — the canonical shapes of every\n   output table the phases emit (Phases 2, 3, 4, 5, 6, 7, 8, 8.5). **Read on demand** when\n   you enter a phase that emits a table; it is the single source of truth for those tables —\n   SKILL.md and `methods.md` only point to it, never re-spell a table.\n5. **`.unikit\u002FDESCRIPTION.md`** (optional) — existing project constraints, if this\n   is ideation inside an established project.\n6. **`.unikit\u002FRULES.md`** (if present) — project overrides, highest priority. **Rule topics:** load the topic files listed under its `## Topics` whose `Load when` matches the design work at hand — the concept, system, flow or content type; when unsure, load.\n\n**Market validation is delegated, not ad-hoc.** This skill does **not** research the\nmarket inline or early — early data anchors timid ideas (anti-anchoring,\n`gd-principles`). Market evidence enters at **Phase 3.5**, where brainstorm spawns\n`unikit-gd-explore` as a subagent to scan the shortlist and **return a brief into\nthis session**. The delegation **interface** — the brief's fields, the canonical\nmarker, the four-verdict gate — is the contract at\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fdelegation-contract.md`, **loaded on\nentering Phase 3.5** (per-phase, like `methods.md`), not up front; brainstorm reads\nthat *interface*, never explore's engine (`market-scan.md`). General `WebSearch` \u002F\n`WebFetch` lookups remain available as read-only advisors — they never write and\nnever substitute for the Phase 3.5 scan.\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n## Skill calls\n\nWhere this skill says to **invoke `\u003Cskill>`** — optionally \"with the argument `\u003Ctext>`\" — it means one call, made in this session, now, on every runtime: not a command printed for the user. A call site that names no argument passes none.\n\n1. If you have a `Skill` tool that accepts arguments, call it with that skill and the arguments of the call site, in full and unchanged, then follow the skill.\n2. Otherwise — no `Skill` tool, or one that takes only a name — Read `{{skills_dir}}\u002F\u003Cskill>\u002FSKILL.md` in full, treat it as the instructions of this step and carry them out here, in this session, now, with the arguments of the call site as the skill's arguments.\n3. When the skill has run, go on to the step the call site names. Do not print a command for the user to run and do not stop.\n4. Only if that file cannot be read: print `Run: \u002Funikit-\u003Cskill> \u003Carguments>` for the user and stop.\n\n## Subagent launches\n\n**Subagent arguments.** Before the first subagent you launch, read `.unikit\u002Fsystem\u002Fsubagent-arguments.md`\nand `.unikit\u002Fconfig.yaml` once and settle the model and effort of every launch as that file says.\nKeys: `subagents.model.{{agent_id}}.\u003Crole>`, `subagents.effort.{{agent_id}}.\u003Crole>`;\nbuilt-in model of a reader and a validator: `\"{{agent_model_default}}\"`, of an executor: none.\nIf the file cannot be read, print\n`WARN [delegation] subagent-arguments contract missing — built-in model tier used, effort not passed`\nand use that model, no effort.\n\n## Phase 0 — Auto-Resume (no flags)\n\n*Brainstorming runs across many turns, so this step looks in the concepts index for\nan unfinished concept that matches the hint and offers to continue it — a session\ninterrupted by a `\u002Fclear` or a closed terminal is never lost.*\n\nRead `.unikit\u002Fgamedesign\u002Fconcepts\u002FINDEX.md` (if it exists). Each row carries a\nslug, title, keywords, **status** (`in-progress | complete | promoted | abandoned`),\nand the last phase reached. Semantically match the user's hint against the rows:\n\n- A live `in-progress` concept matches the hint →\n\n  ```\n  The question tool of your agent (`AskUserQuestion`): Found \"\u003Ctitle>\" — you left off at phase \u003CN>. What now?\n  Options:\n  1. Continue \"\u003Ctitle>\" from phase \u003CN> (recommended)\n  2. Start a fresh concept\n  3. List all concepts\n  ```\n\n- No match → start a new concept at `concepts\u002F\u003Cslug>\u002F`.\n- A match exists but the user chooses to start fresh → **ask for a different slug**, then\n  create `concepts\u002F\u003Cnew-slug>\u002F` and print `INFO [concept] creating \u003Cnew-slug>`.\n\n`promoted` and `abandoned` concepts are **never offered for resume**, but their\n`IDEAS.md` is read so the session does not re-pitch a killed idea. Repeated\nbrainstorms need a **different** slug — the user is asked for one; the date no longer\nsupplies the difference. **Appending an automatic suffix is forbidden**: the slug is\nderived from the topic, so a second run at one topic produces the same name, and a\nsilently suffixed folder is one the auto-resume above will never offer again.\n\nOn resume, jump to the saved phase — including the **fractional phases 3.5, 7.5, and\n8.5** (a session interrupted mid-scan, mid-flow-seeds, or mid-validation resumes there,\nnot back at 3, 7, or 8); on a fresh start, begin at Phase 1.\n\n## Phases 1–9\n\nRun the phases in order. Each phase below is the **workflow**; its deep method detail\nlives in `references\u002Fmethods.md` — read that section when you reach the phase, not up\nfront. Diverge and converge as **separate** moves — never score an idea as you\ngenerate it.\n\n### How to respond in each phase\n\n- **Go deep, not terse.** Each phase is a consultation, not a form to fill in. When\n  you present options, loops, pillars, or risks, explain the *reasoning* in a few\n  sentences — the framework it draws on, the comparable game that proves it, the\n  trade-off it carries — not a bare one-line bullet. The user is making a creative\n  decision and needs the *why*, not just the *what*. A phase answered in a single line\n  is almost always too thin; spend the words.\n- **Open every phase with its purpose.** The italic line under each heading below says\n  what the phase is and why it exists — orient the user the same way in your own words\n  before you dive into the questions, so no phase arrives unexplained.\n- **Readable plain markdown only.** Number options and concepts with plain `1.` \u002F `2.`\n  and label variants `A)` \u002F `B)`. Never use circled or enclosed glyphs (①②③, 🅰🅱, Ⓐ)\n  or other decorative unicode — they render as boxes or unreadable smudges in most\n  terminals. Bold, short tables, and plain headings carry all the structure you need.\n\n### Phase 1 — Creative Discovery (+ commercial frame)\n\n*Find the seed before generating anything: who you are designing for, the feeling you\nare chasing, and what \"success\" means commercially. This is what makes every idea that\nfollows aimed and yours, instead of generic.*\n\nAsk about the **person**, not the game: emotional anchors, three games they love\nand what those left them wanting, plus constraints (solo\u002Fteam, deadline, engine,\nexperience). Synthesize a **Creative Brief** (3–5 sentences) and confirm it.\n\nThen capture a **commercial frame** (one screen, kept separate from the person\nquestions):\n\n- **Target outcome tier** — hobby \u002F recoup \u002F commercial.\n- **Target platform** — ask explicitly, **never default to Steam** (the four options\n  below). Platform is a market-shaping decision, not a deployment detail.\n- **Budget \u002F team size** — solo \u002F small team \u002F funded. A **reachability** constraint:\n  a clone-dense mobile market is unreachable without a UA budget, however good the\n  concept. Phase 3.5 reads demand as *reachable* vs *someone else's* against it, and\n  passes it to the delegated scan as the `budget\u002Fteam` input.\n- **Target session length** — shapes platform fit (web rewards short instant loops;\n  premium PC tolerates long sessions); sets the card's platform-fit sanity line (field 8).\n- **Monetization intent** — premium \u002F F2P-IAP \u002F ads \u002F portal rev-share \u002F none. Feeds\n  the T8 `monetization_fit` read in Phase 3.5 (`monetization_intent` in the scan).\n- **Scan mode** — `quick` \u002F `standard` \u002F `deep` for the Phase 3.5 delegation;\n  `standard` is the default, `quick` for an early red-ocean sweep of 3–4 concepts.\n- **Kill-readiness** — drop on bad data, or passion-project regardless?\n\nPlatform options (name a *lead* even for cross\u002Fconsole):\n\n1. **PC \u002F Steam** — wishlist-driven, long tail, premium or early-access pricing.\n2. **Mobile** — store-feed and UA-driven, F2P norms, short sessions, clone-dense.\n3. **Web \u002F instant** — portal- and embed-driven (itch, CrazyGames, Poki): instant\n   play, near-zero install friction, ad\u002Fportal economics.\n4. **Cross \u002F console** — still name a *lead* platform; one store shapes every later\n   signal.\n\nThe platform **steers the Phase 3.5 scan** (each platform has its own demand signals,\nsources, and clone-density; the cross-market rule turns a mobile\u002Fweb target into a\nSteam demand-check plus a target-store clone-check — full per-platform table and the\ncross-market rule in `references\u002Fmethods.md` § Phase 1).\n\n**Anti-anchoring boundary (explicit).** Structural *platform* facts (mobile is\nclone-dense; web rewards an instant hook; Steam is wishlist-driven) may inform this\nframe now — they are not about any specific concept and do not anchor divergence.\n**Concept-specific demand data** (does *this* idea sell, how many clones of *this*\nconcept exist) is withheld until Phase 3.5, after divergence.\n\nThe frame **scopes Phase 3.5; it does not censor divergence.** A user with no\ncommercial intent leaves it **empty** — that is valid and **skips Phase 3.5**\n(`market-signal` then stays an ordinary Pugh judgment, not a delegated scan).\n\n### Phase 2 — How-Might-We Framing\n\n*Recast the brief as open \"How might we…\" questions that invite many answers instead\nof smuggling in one solution. Good framing is what keeps the next step — divergence —\ngenuinely wide.*\n\nReframe the brief as **3–5 \"How might we…\"** questions (positively framed, no\nbaked-in solution). **Present them as a table** so the user can weigh the framings side\nby side instead of reading a flat list, and mark the strongest **(Recommended)** with a\none-line WHY; the user picks one to diverge on. The table's columns and a worked example\nlive in `references\u002Ftables.md` § Phase 2 (the single source of truth for this table).\n\n### Phase 3 — Divergence\n\n*Generate breadth on purpose: five concepts from five different idea-generators, so\nthe field is genuinely varied and not five repaints of the first thought. Hold all\njudgment for later — quantity now, scoring in Phase 4.*\n\nGenerate **five concepts using five different methods** (verb-first, genre mashup\nwith the intersection-audience caveat, experience-first\u002FMDA-backward, world-first,\nconstraint-first — each method's prompt and source in `references\u002Fmethods.md`\n§ Phase 3). Render **each** concept as its own **nine-field card** — a `Field | Value`\ntable so the fields stay aligned and scannable instead of buried in prose. Then, after\nthe five cards, present one **comparison table** across all of them: the shortlist\ndecision is a side-by-side judgment (\"which two hooks are strongest?\") that five separate\ncards cannot support at a glance. The nine fields, the comparison columns, and worked\nexamples of both live in `references\u002Ftables.md` § Phase 3 (the single source of truth for\nthese tables).\n\nOnce the five are on the table, ask the user how to proceed — and offer three\ndistinct moves, not just \"pick some\":\n\n1. **Shortlist 2–4** to carry forward into validation \u002F scoring.\n2. **Five more** — *extend* the field with a stimulus method (random input \u002F SCAMPER \u002F\n   Lotus Blossom) built on the current favorite; keeps what is working and pushes for\n   adjacent variety.\n3. **Regenerate from scratch** — *discard this whole batch* and generate five **new**\n   concepts from different methods or a different How-Might-We angle. This is the right\n   call when none of the five land or they all feel like one idea wearing five hats.\n   The discarded batch still goes to `IDEAS.md` (with its revival condition) so nothing\n   is silently lost or re-pitched later.\n\n### Phase 3.5 — Market validation (delegated to explore) — **gated**\n\n*Pressure-test the shortlist against the real market — does a reachable audience\nexist, and is there unmet room for it — delegated to explore so brainstorm never\ngrades a market from memory. It runs after divergence, on purpose: early data anchors\ntimid ideas.*\n\n**Gate:** run this phase **only if Phase 1 produced a non-empty commercial frame.**\nEmpty frame → **skip**; `market-signal` stays an ordinary Phase 4 judgment, no\nsubagent.\n\nRun **after** divergence, on the user's **shortlist (2–4 concepts)** — never earlier\n(early data anchors timid ideas; `gd-principles`). brainstorm does **not** research\nthe market itself — it **delegates** to `unikit-gd-explore` and consumes the evidence.\n\n**Load the contract first.** On entering this phase, read\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fdelegation-contract.md` — the interface\nthis delegation follows: the brief's fields, the canonical marker, and the\nfour-verdict gate. brainstorm reads that *interface*, never explore's engine\n(`market-scan.md`). (Hard-code the `unikit-gd-explore` path — it is **not**\n`{{self_name}}`.)\n\n**Delegate** — spawn explore as a subagent and **wait for the return**. Expands to:\n\n```\nAgent(\n  {{agent_call_worker_quoted}}\n  prompt: \"{{agent_skill_call:unikit-gd-explore}} \u003Ccommercial frame incl. target platform + budget\u002Fteam + shortlist>. scan_mode: \u003Cquick|standard|default standard>. Validate cross-market per the platform rule. Return the brief into this session as text; do not save any files.\",\n  description: \"Market-validate the shortlist\"\n)\n```\n\nPass **`scan_mode`** explicitly: `standard` is the default; use `quick` for an early\n3–4 concept red-ocean sweep (it returns C-capped signals — enough to flag, not to\ncommit on). Carry the **budget\u002Fteam** slot from the commercial frame as a reachability\ninput; until Phase 1 captures it, it arrives `unknown` and the scan degrades\ngracefully (never fabricates a budget read). Substitute the real frame values into the\n`\u003C…>` placeholders.\n\n**Fallback (no Agent tool).** If the `Agent` tool is unavailable in this environment,\ndo **not** print the delegation as a recommendation — that is a known failure mode\nwhere the model renders the call instead of running it. Instead, invoke `unikit-gd-explore`\n(`## Skill calls`), passing the same commercial frame + shortlist and the canonical marker\nverbatim, and wait for its brief. If its file cannot be read — instead of step 4 of\n`## Skill calls`, which would stop here — run the scan yourself inline with\n`WebSearch` \u002F `WebFetch` against the technique catalogue in\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fmarket-scan.md` (comparable mapping, demand\nclassification, review mining, and the cross-market rule above), and label every\nfinding with the same `market_signal` + `validation_confidence` fields so the rest of\nthe flow is unchanged.\n\nThe prompt MUST carry the **canonical marker** verbatim, on one line:\n\n> *\"Return the brief into this session as text; do not save any files.\"*\n\nso explore runs its market lens deterministically and persists nothing (the\ncontract). The subagent returns, per concept, `market_signal` +\n`validation_confidence` + a short evidence brief **into this session**.\n\n**Carry the platform — the cross-market rule.** A market is platform-specific (a genre\nthat thrives on Steam can be a clone-saturated graveyard on mobile, and the reverse\nhappens too), so the delegation prompt names the **target platform from Phase 1** and,\nfor a non-PC target, asks explore to validate *across* markets: prove the genre on Steam\n(the clearest *demand* signal even when you ship elsewhere), then scan the *target* store\nfor clones, then read the gap — Steam-proven + no strong clone on the target store is the\nprize; Steam-proven **but** the target store already clone-dense is a red ocean on the\nplatform that actually matters. The mechanics of that rule live in\n`references\u002Fmethods.md` § Phase 1, and the scan engine that runs it in\n`{{skills_dir}}\u002Funikit-gd-explore\u002Freferences\u002Fmarket-scan.md`. Report the read **per platform** in the\nbrief; it feeds the kill gate below.\n\n**Consume — the calling session owns persistence:**\n- Lift the **six machine fields** (`market_signal`, `validation_confidence`,\n  `clone_density`, `trend_fit`, `monetization_fit`, `recommendation`) **verbatim** into\n  the **CONCEPT card** header machine-block, **outside the nine-field table** (the card\n  stays \"nine fields, no more\").\n- Distil `key_evidence` and `go_to_market_risk` (comparables, the unmet need, the reach\n  risk) into the card's **`## Notes`** — not just the machine fields.\n- **Write no `researches\u002F` file** — that directory is explore's; a delegated scan is\n  evidence for *this* concept, carried in the card.\n\n**Decision gate — four verdicts, not a binary.** Consume the brief's `recommendation`\nper concept and surface it **before** Phase 4 scoring (the contract's gate table):\n\n| Verdict | Meaning | Action |\n|---------|---------|--------|\n| **proceed** | white-space, confidence ≥ B | carry into Phase 4 as a strong candidate |\n| **proceed-with-differentiation** | contested, conf ≥ B, a clear twist exists | carry forward; sharpen the hook |\n| **validate-later** | white-space\u002Fcontested at conf C, or `unknown` | carry forward but route the open risk to the Phase 8.5 validation plan |\n| **pivot** | red-ocean **but** an adjacent white-space exists | cross-pollinate (below): graft the under-competed angle onto a stronger concept; render the hybrid as a full nine-field card |\n| **kill** | red-ocean, no adjacent white-space, unreachable at scope | park in `IDEAS.md` with a revival condition |\n\nNever silently carry a `kill`\u002F`pivot` concept forward, and never `proceed` or `kill`\non `unknown` — `unknown` always routes to `validate-later`. The gate informs; the\nuser decides.\n\n**Cross-pollinate before you cut (the `pivot` verdict).** A red-ocean concept is not\nonly a kill candidate — it is also raw material, and the gate's **`pivot`** verdict\nroutes here rather than to `kill`. When one shortlisted concept reads **red-ocean**\nwhile another reads **white-space \u002F contested**, do not just drop the crowded one:\nproactively offer\na **genre mash-up** that grafts the under-competed concept's angle onto the stronger\none (the genre-mashup divergence method, with its intersection-audience caveat — the\nhybrid must please *both* audiences, not merely exist). A saturated genre often hides a\nstrong twist the moment it is crossed with a fresher one. The hybrid is a **new candidate\nconcept**, so present it as a full **nine-field concept card** — the same `Field | Value`\ntable as Phase 3 (`references\u002Ftables.md` § Phase 3), not a loose prose pitch — so it is\ndirectly comparable to the shortlist; route it to Phase 4 \u002F Phase 8.5. Recommend it when\nthe evidence supports it, but never impose it — the user decides.\n\n### Phase 4 — Convergence (two-pass Pugh) → **incremental write**\n\n*Now judge. A two-pass Pugh matrix scores the survivors on locked creative criteria\nfirst, then on the market evidence — keeping the two apart so optimism can never\nout-vote data. Pugh scoring just compares each option against criteria to rank them\ntransparently.*\n\nScore the surviving concepts with a **two-pass Pugh matrix** (full method, the hard\nrule, and the `market-signal` vs `market_signal` terminology in `references\u002Fmethods.md`\n§ Phase 4 + § Content velocity):\n- **Pass 1 — creative** (lock *before* the scan): hook \u002F scope-fit \u002F team-fit \u002F\n  personal-fire \u002F **content-velocity** — can the design *feed itself* cheaply\n  (procedural \u002F systemic \u002F competitive \u002F UGC), or does every play-hour cost\n  author-hours of hand-made content? A low-velocity model is a hidden scope and\n  live-game risk, scored here as a real feasibility axis, not a footnote.\n- **Pass 2 — evidence** (from the Phase 3.5 brief, only if it ran): market-signal +\n  validation-confidence.\n\n**Hard rule:** the **market-signal** score may **not exceed what\nvalidation-confidence allows** — an unproven market read cannot win on optimism.\nShow the two passes as **two separate tables** (columns and a worked matrix in\n`references\u002Ftables.md` § Phase 4) — kept apart so locked creative scores and market\nevidence never share a column; the user weights, arithmetic transparent. If\nPhase 3.5 was skipped, `market-signal` is scored as an ordinary Pass-1 judgment. Use\n**How-Now-Wow** if \"I like all of them\". Do **not** approve a hybrid whose winning\nbet rests on a low-confidence market assumption — route it to Phase 8.5 instead.\nSelect or hybridize. Rejected concepts go to **`IDEAS.md`** (idea, essence, reason,\nrevival condition). **Persist now** — write the chosen card draft and `IDEAS.md`; an\ninterruption after this loses nothing.\n\n### Phase 5 — Loop Stack\n\n*Map the nested gameplay loops — from the 30-second core action up to the meta-game —\nplus the discoverability loops that decide whether anyone starts and comes back. This\nis the spine of moment-to-moment fun and the first read on whether the game retains.*\n\nDefine the nested loops (30 s \u002F 5 min \u002F session \u002F meta) plus the **discoverability\nloops** (first-session → retention, the 6-second trailer moment, the \"one more run\"\nretention hook — full detail in `references\u002Fmethods.md` § Phase 5). Then audit **SDT**\n(Autonomy \u002F Competence \u002F Relatedness — flag if only 1 of 3 is served) and **game feel**\n(does the core verb get ≤100 ms, multi-channel feedback? — Swink). Present all three as\ntables — the loop stack, the SDT audit, the game-feel check — so a gap (an unserved need,\na flat verb) is visible at a glance rather than lost in prose. Columns and worked examples\nare in `references\u002Ftables.md` § Phase 5 (the single source of truth).\n\n### Phase 6 — Pillars & Anti-Pillars → **incremental write**\n\n*Pillars are the 3–5 load-bearing design values every later decision gets tested\nagainst (\"does this serve a pillar?\"). Anti-pillars name what the game deliberately\nrefuses to be — together they keep scope honest and decisions consistent.*\n\nDerive **3–5 pillars**: active, each serving ≥1 emotion, each with a **design test**\nand mutual tension; reject empty pillars and task-pillars. For each pillar add\n**Evidence** (the data \u002F comparable that justifies it — ideally the Phase 3.5 brief's\nreview-mining) and a **Cut rule** (what is cut first under scope pressure); a pillar\nwith no evidence is a slogan — flag it. Add **≥3 anti-pillars** (\"We will NOT \u003CX>\nbecause PIL-n\"); the brief's review-mining (love \u002F hate \u002F wish) feeds these. Present the\npillars and anti-pillars as **two tables** — a pillar carries five columns (emotion,\ndesign test, evidence, cut rule) that only line up under scrutiny in a grid, and the\ntable makes a sloganeering pillar (empty evidence cell) impossible to hide. Columns and\nworked examples are in `references\u002Ftables.md` § Phase 6. Run a Lock \u002F Rename \u002F Swap cycle.\n**Persist now.**\n\n### Phase 7 — Player Motivation (player + buyer)\n\n*Pin who this is for psychologically (what drives them to play) and commercially (what\nmakes them buy or wishlist) — and, just as sharply, who it is NOT for. A concept that\nserves everyone usually moves no one.*\n\n**Quantic Foundry:** the user ranks the **top 3 of 12** motivations; the skill\nchecks them against the pillars and loops. Set MDA primary\u002Fsecondary and a one-line\nBartle read. Then separate **player from buyer**: the **buying trigger** and the\n**quitting \u002F refund trigger** (from the Phase 3.5 brief when it ran), plus an\nexplicit **anti-persona** — \"who this is NOT for\". Capture the whole read as one table\n(player psychology → buyer triggers → anti-persona) — columns and a worked example in\n`references\u002Ftables.md` § Phase 7.\n\n### Phase 7.5 — Scenario \u002F Flow seeds\n\n*Turn the loops (Phase 5) and pillars (Phase 6) into the **dynamics seeds** the Flow\naxis picks up downstream — this does not author flows, it seeds them (as Phase 6 seeds\nthe pillars the spec later formalizes).*\n\nDraft **3–5 scenario prompts** (the concrete player situations the game must deliver,\neach anchored to a pillar), a **candidate wiring mode** per scenario (`linear` \u002F\n`conditional` \u002F `emergent` — a candidate only; `\u002Funikit-gd-flow` confirms it), and\n**flow seeds** (1–3 draft `GOAL`-shaped objectives + the systems each would exercise,\n`GOAL → SYS`). Drafts, not registered ids — full method in `references\u002Fmethods.md`\n§ Phase 7.5. The seeds ride into Phase 9's Open Questions \u002F Next Steps for the Flow\naxis (`\u002Funikit-gd-explore` flow lens → `\u002Funikit-gd-flow`); brainstorm never writes a\n`FLOW.md` or `GD-IDS`.\n\n### Phase 8 — Pre-mortem & Scope → **incremental write**\n\n*Klein's pre-mortem: imagine it is six months out and the project already failed —\ntreat that as a fact — and list why. The certainty framing surfaces the doubts\noptimism normally hides, so you can cut scope down to the part that proves the fun.*\n\nRun **Klein's pre-mortem verbatim** (\"six months from now the project failed — that is\na fact — why?\" — the certainty framing *is* the technique; `references\u002Fmethods.md`\n§ Phase 8): 8–12 reasons across fun \u002F scope \u002F market \u002F tech \u002F team \u002F **content** (ran\nout of content, or it got too slow\u002Fexpensive to make — the content-velocity risk as a\nfailure mode). Present the 8–12 reasons as a table (reason · category · real? ·\nmitigation — `references\u002Ftables.md` § Phase 8); the user marks the real ones; mitigate\nonly those. Then settle the platform, the **MVP cut** — does the chosen scope match how fast you can actually ship\ncontent? — and the **find-the-fun test** (Cerny: the smallest prototype that proves or\nkills the core; `references\u002Fmethods.md` § Phase 8). **Persist now.**\n\n### Phase 8.5 — Validation Plan & Kill Criteria\n\n*Turn each real risk the pre-mortem found into the cheapest test that proves or kills\nit before full production — every test with a pass threshold, a deadline, and explicit\nkill-criteria numbers. The goal: spend the least to retire the biggest risk.*\n\nFor each **Critical** risk the pre-mortem marked real, design the **cheapest test\nthat proves or kills it** before building the full game (the test catalogue — fake-door\nSteam page \u002F prototype \u002F Discord poll \u002F capsule A\u002FB, each with its typical signal — in\n`references\u002Fmethods.md` § Phase 8.5). Each test names a **pass threshold + deadline +\nthe risk it retires**. State **2–4 explicit kill criteria with numbers** (reuse the\nPhase 3.5 brief's benchmarks, e.g. genre wishlist medians). Present both as tables — the\nvalidation tests and the kill criteria — per `references\u002Ftables.md` § Phase 8.5. This is where a\nlow-confidence market bet from Phase 4 gets a cheap real-world check instead of a\ntaste call. Record the tests and kill criteria in the card's **`## Notes`** — **no\nseparate file** (brainstorm owns one card, not a research bundle).\n\n### Phase 9 — Record & Handoff\n\n*Lock the finished concept into one approved CONCEPT card and hand off to the next\nstep. The card is the only artifact that survives the session, so it must carry the\nreasoning and the market evidence, not just the verdict.*\n\nPresent the **complete CONCEPT card** for **one approval** (\"not yet\" → edit\nsections, do not split the approval). When Phase 3.5 ran, the card must carry the\n**market evidence** so it is traceable: the **six machine fields** (`market_signal`,\n`validation_confidence`, `clone_density`, `trend_fit`, `monetization_fit`,\n`recommendation`) in the header block **and** the distilled argument in `## Notes` (no\n`researches\u002F` file was written — the card *is* the citation). Set the card header\n(`> Status: drafted · Version: 1 · Created: \u003Cdate>`).\n\nAlso set the **descriptive `genre:` hint** in the header — a human genre name\ninferred from the concept (the elevator-pitch *[genre]* slot, e.g. «симулятор\nломбарда», «match-3 головоломка»). It is an **intent, not a catalog id**: write\nwhat the game *is*, even if no genre-profile is named that. `unikit-gd-spec`\nresolves this hint best-fit to a bundled profile and installs it downstream.\n**Brainstorm stays CLI-free here** — it never runs `unikit-ai genres list` \u002F\n`genres install` and never recommends or installs a profile; the genre catalog is\nconsumed at spec, not here (this avoids the chicken-and-egg of an empty profile\nbefore install). Leave `genre:` empty\u002Fsoft when no clear genre — `unikit-gd-spec`'s\nuniversal baseline covers it.\n\nSet the INDEX row status to `complete`. Then recommend the follow-up (do not auto-invoke).\n\n## Writing the Artifacts\n\n```bash\nmkdir -p .unikit\u002Fgamedesign\u002Fconcepts\u002F\u003Cslug>\n```\n\n- **`CONCEPT.md`** — the nine-field card with a `## Notes` section for the reasoning\n  the table cannot hold (rejected alternatives, inspirations, the Phase 3.5 market\n  argument, the Phase 8.5 validation tests). When Phase 3.5 ran, the header carries a\n  **machine block** with the six machine fields (`market_signal`,\n  `validation_confidence`, `clone_density`, `trend_fit`, `monetization_fit`,\n  `recommendation`) **outside** the nine-field table (the table stays \"nine fields, no\n  more\"). These underscore fields are *evidence* — distinct from the hyphenated\n  `market-signal` Pugh *criterion*.\n  Header: `> Status: \u003Cexploring|drafted|approved> · Version: 1 · Created: \u003Cdate>`.\n  Also a `> genre: \"\u003Cdescriptive hint>\"` header field — the human genre name\n  (intent, not a catalog id; Phase 9). CLI-free: brainstorm writes the hint only;\n  `unikit-gd-spec` resolves it to a profile and installs it.\n- **`IDEAS.md`** — the rejected-idea backlog: each entry is *idea · essence ·\n  reason (scope \u002F not-fun \u002F off-theme \u002F duplicate) · revival condition*.\n- **`concepts\u002FINDEX.md`** — prepend (newest first) a row:\n  `slug · title · keywords · status · last phase · market_signal` (the last column\n  blank when Phase 3.5 was skipped). Create with a\n  `> Auto-maintained by \u002Funikit-gd-brainstorm. Do not edit manually.` header if\n  absent. Update the existing row's status\u002Fphase on resume.\n\n## Final: Compact Report & Next Steps\n\nThe terminal plaque (TIER A — `gd-principles` → Language: names lead, status is a plain\nphrase; the pillar ids live in GAME.md \u002F GD-IDS):\n\n```\nConcept: \u003Ctitle>  (.unikit\u002Fgamedesign\u002Fconcepts\u002F\u003Cslug>\u002F)\nStatus: \u003Cstill a draft | approved>  ·  reached phase 9\nPillars: \u003Cname>, \u003Cname>, …   Anti: \u003Cn>   MDA: \u003Cprimary>\u002F\u003Csecondary>\nFind-the-fun: \u003Cthe prototype that proves the core>\nRejected → IDEAS.md: \u003Cn>\n```\n\n**Next steps** (do not auto-invoke):\n\n- 🗺️ Build the master spec — \u002Funikit-gd-spec \u003Cslug>\n- 🔬 Research a reference or the market — \u002Funikit-gd-explore \u003Ctopic>\n\nPrototype-first is also valid — validate the find-the-fun before specing.\n\nNo summary document, no report file.\n\n## Ownership Boundaries\n\n- **Owns:** `.unikit\u002Fgamedesign\u002Fconcepts\u002F` — `CONCEPT.md`, `IDEAS.md`, and the\n  concepts `INDEX.md`.\n- **Not this skill:** `GAME.md` + the system map → `unikit-gd-spec`; analyzing an\n  existing game\u002Fmarket → `unikit-gd-explore`; per-system GDDs →\n  `unikit-gd-system`.\n- **Never:** write a concept without approval; offer `promoted`\u002F`abandoned`\n  concepts for resume; read the code workspace or project source.\n\n## Quick Reference\n\n```\n\u002Funikit-gd-brainstorm                         → blank-page ideation (or resume from index)\n\u002Funikit-gd-brainstorm cozy farming roguelike  → seed divergence with a hint\n\u002Funikit-gd-brainstorm                         → auto-resumes a matching in-progress concept\n```\n",{"name":5,"metadata":57,"description":7,"allowed-tools":61,"argument-hint":77,"user-invocable":78,"disable-model-invocation":53},{"author":58,"version":59,"category":60},"unikit","1.0","game-design",[62,63,64,65,66,67,68,69,70,71,72,73,74,75,76],"Read","Write","Edit","Glob","Grep","Bash(ls *)","Bash(find *)","Bash(wc *)","Bash(date *)","Bash(mkdir *)","Agent","Skill","AskUserQuestion","WebSearch","WebFetch","[hint or theme]  (auto-resumes an in-progress concept; no flags)",true,"main","ae3c6dfffd26d9b45b9d96d71ba2c122c50b67ae","skills\u002Funikit-gd-brainstorm",1,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai","https:\u002F\u002Funikit.nintenda.dev","https:\u002F\u002Fgithub.com\u002FNintendaDev","Unity Developer. Building games and UniKit AI","2026-11-08 15:05:51",{"source":8,"skillName":5,"commands":89,"prompt":99,"zipAvailable":78},[90,93,96],{"tool":91,"command":92},"npx","npx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-brainstorm",{"tool":94,"command":95},"bunx","bunx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-brainstorm",{"tool":97,"command":98},"pnpm","pnpm dlx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-brainstorm","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-brainstorm\u002FSKILL.md",[101,107],{"path":102,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fmethods.md","REFERENCE","参考文档",16968,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-brainstorm\u002Freferences\u002Fmethods.md",{"path":108,"resourceType":103,"resourceTypeDesc":104,"sizeBytes":109,"sourceHtmlUrl":110},"references\u002Ftables.md",13066,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-brainstorm\u002Freferences\u002Ftables.md",[112,134,159,181,201,227],{"skillNo":113,"name":58,"nameZh":6,"description":114,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":115,"categories":116,"keywords":118,"publishedAt":52},"01M71BQ00EXGX51PPCDY7VG334","Initialize the UniKit framework in a project. Scans the current project to detect the engine and real tech stack, then generates the base framework documents that give AI agents context about the project — the resolved project description, the architecture doc, AGENTS.md, and the user-editable .unikit\u002Fconfig.yaml. This is the one-time, whole-project setup run before any other unikit skill. Use whenever the user wants to initialize, set up, or onboard the framework, e.g. \"initialize unikit\", \"init the framework\", \"set up unikit\", \"set up the project\", \"configure AI context\", \"scan my project and set it up\", \"bootstrap the project\". It also actualizes the config of a project already set up — say \"update the config\", \"add missing settings\", \"actualize configuration\", \"fix my config\". On a set-up project it offers the actions to choose from.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit\u002FSKILL.md",[117],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[58,51,119,120,121,122,123,124,125,126,44,43,127,42,128,129,130,131,132,133],"time","actions","fix","documents","architecture","stack","run","update","config","git","context","initialize","tech","scan","use",{"skillNo":135,"name":136,"nameZh":6,"description":137,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":138,"categories":139,"keywords":144,"publishedAt":52},"01M71BPRTMKW7FRAZZBN44NW5Q","unikit-verify","Verify a completed implementation against the plan in .unikit\u002Fcode\u002Fplans\u002F. Checks that every task was implemented, nothing was forgotten, the code compiles, the recorded test run still matches the code, and {{engine_name}} conventions are followed. Use after \u002Funikit-implement completes, or when the user says \"verify\", \"check the work\", \"did we miss anything\". For code review use \u002Funikit-review instead.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-verify\u002FSKILL.md",[140,143],{"categoryNo":141,"categoryName":142,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[145,146,147,148,149,150,125,44,43,42,128,151,152,133,153,154,155,156,157,158],"unikit verify","verify","powershell","code review","phase","plan","for","system","implement","check","engine","research","name","quality",{"skillNo":160,"name":161,"nameZh":6,"description":162,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":163,"categories":164,"keywords":165,"publishedAt":52},"01M71BPM35M5ETPA4E7EKQYRWD","unikit-todo","Manage the project's TODO list in .unikit\u002FTODO.md — capture work to remember for later, not to do right now. Use it to add a deferred item, mark a todo complete, or show the list. The point is to park tasks you don't want to act on in the moment but don't want to forget. Trigger on \"add a todo\", \"add this to the todo list\", \"put X on the todo list\", \"remind me to...\", \"don't forget to...\", \"note this for later\", \"we should do this later\", \"mark this todo done\", \"what's on the todo list\", \"what's left to do\". This is only for parking reminders — to actually plan or do the work now, use \u002Funikit-plan, \u002Funikit-implement, or \u002Funikit-execute.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-todo\u002FSKILL.md",[],[166,167,168,169,51,170,171,172,173,174,175,176,150,177,178,179,44,43,42,180],"unikit todo","todo","remind","show","todo list","only","now","you","done","tasks","work","me","reminders","later","act",{"skillNo":182,"name":183,"nameZh":6,"description":184,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":185,"categories":186,"keywords":188,"publishedAt":52},"01M71BPEQDVD7DTGFQBQJQ7JKY","unikit-skills-context","Customize how a built-in unikit skill behaves in this specific project by writing workflow overrides into its skill-context file. These are per-skill workflow rules (e.g. \"\u002Funikit-review should also flag TODO comments\", \"\u002Funikit-implement should run tests after each task\"), not coding conventions. Use when the user wants to change, customize, or override how a particular unikit skill works in this project — \"customize the review skill\", \"make \u002Funikit-fix always add logging here\", \"the implement skill should do X differently\", \"add a skill rule for \u002Funikit-commit\". Use \"validate\" to find stale overrides against updated base skills. For a general coding convention (not tied to one skill) use \u002Funikit-rules; to derive rules from past mistakes use \u002Funikit-evolve.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-skills-context\u002FSKILL.md",[187],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[189,129,51,121,190,191,192,193,194,195,196,197,167,198,199,125,200,44,43,42],"unikit skills context","coding conventions","writing","when","workflow","commit","review","general coding","text","change","how","past",{"skillNo":202,"name":203,"nameZh":6,"description":204,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":205,"categories":206,"keywords":214,"publishedAt":52},"01M71BP7K5KEGJV4ASRKPG1DM8","unikit-rules","Add a short, project-specific rule, convention, or override to .unikit\u002FRULES.md — the quick-capture inbox for this project's rules (common rules always load; topic files in .unikit\u002Frules\u002F load when the work matches), automatically loaded by \u002Funikit-implement (later promotable via \u002Funikit-memory migrate-rules). Works only with a rule typed as a prompt — it does NOT read files, folders, URLs, or PDFs. Cross-checks the knowledge base (RULES_INDEX.md) to avoid duplicating core\u002Fstack entries. Use for one-line conventions and corrections: \"add a rule\", \"remember this\", \"convention\", \"always do X\", \"never use Y\", \"from now on do Z\", or when the user corrects agent behavior and wants it remembered; also \"split the rules into topics\" (optimise), \"clean up the rules\" (prune), \"shorten RULES.md\" (compact), by keyword or in plain words. If the user points to a source (file, folder, URL, PDF, article, book) or wants to research\u002Fdocument framework usage, use \u002Funikit-memory; for architecture decisions use ARCHITECTURE.md.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-rules\u002FSKILL.md",[207,210,213],{"categoryNo":208,"categoryName":209,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":211,"categoryName":212,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[215,216,217,218,51,219,220,221,222,223,123,224,197,225,124,179,44,43,42,226],"Rules","unikit rules","quick","PDF","clean","knowledge","files","URL","migrate","batch","knowledge base","prune",{"skillNo":228,"name":229,"nameZh":6,"description":230,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":231,"categories":232,"keywords":233,"publishedAt":52},"01M71BP02S49HHD4R5X6N12C9Q","unikit-rules-registry","Orchestrate the remote rules registry — the shared registry (often connected as a local folder or git repo) that the project's rules are published to and pulled from. Three modes, picked from the user's wording: create scaffolds a new local rules registry (\"create a local rules registry\", \"init a rules registry\"); update migrates\u002Fpromotes local knowledge-base rules from .unikit\u002Fmemory\u002F into the remote registry with automatic semver bumps (\"migrate local rules to the remote registry\", \"promote my rules to the registry\", \"push local rules\", \"publish local rules\", \"update the rules registry\"); sync pulls registry updates back into memory (\"sync the rules registry\", \"pull registry updates\"). Pass \"--module \u003Cid>\" to scope to one knowledge-base module. This skill ONLY orchestrates the CLI (`unikit-ai rules *`) — it never edits .unikit.json or .unikit\u002Fmemory\u002F sources directly.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-rules-registry\u002FSKILL.md",[],[234,215,235,236,51,237,220,238,223,239,126,44,43,128,240,241,242,243,36,244],"registry","unikit rules registry","shared","local","remote","create","ai rules","automatic","semver","knowledge-base","three"]