[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BKYV1AF5XFP3ZSYHA7VXY":3,"skill-same:01M71BKYV1AF5XFP3ZSYHA7VXY":107},{"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":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":71,"commitSha":72,"skillDirectory":73,"forksCount":74,"repositoryHtmlUrl":75,"repositoryHomepageUrl":76,"ownerHtmlUrl":77,"ownerBlogUrl":6,"ownerDescription":78,"updatedAt":79,"install":80,"resources":92},"01M71BKYV1AF5XFP3ZSYHA7VXY","unikit-gd-system",null,"Author and own ONE system's design document (the A–K SYSTEM GDD) at .unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md — the depth layer of the GDD, single-system scope. Create the skeleton and walk the collaborative section-cycle to write its parameters, rules, formulas, and acceptance criteria (\"detail the combat system\", \"write the GDD for the inventory system\", \"fill in the rest of this system doc\", \"spec out the parameters of X\"), AND revise it after approval under the delta discipline (\"raise the damage by 10%\", \"tune the economy\", \"rework the status system\", \"nerf X\", \"change this rule\") — a number change is Tuning, a small rule a Tweak, restructuring a Rework; each bumps the version and logs the delta. To add a NEW system or restructure the system map use \u002Funikit-gd-spec; to edit GAME.md content use \u002Funikit-gd-spec; the moment an edit also touches a second system, a content type, a flow, or GAME.md (two or more zones) use \u002Funikit-gd-apply; to invent a brand-new game concept use \u002Funikit-gd-brainstorm.","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-system\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000032","设计师","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"unikit gd system","system","for","formulas","brand","concept","revise","status","edit","write","read","at","inventory system","discipline","change","create","logs","number","design","mode","2026-11-10 10:12:30",false,"---\nname: unikit-gd-system\ndescription: >-\n  Author and own ONE system's design document (the A–K SYSTEM GDD) at\n  .unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md — the depth layer of the GDD, single-system\n  scope. Create the skeleton and walk the collaborative section-cycle to write its\n  parameters, rules, formulas, and acceptance criteria (\"detail the combat system\",\n  \"write the GDD for the inventory system\", \"fill in the rest of this system doc\",\n  \"spec out the parameters of X\"), AND revise it after approval under the delta discipline\n  (\"raise the damage by 10%\", \"tune the economy\", \"rework the status system\", \"nerf\n  X\", \"change this rule\") — a number change is Tuning, a small rule a Tweak, restructuring\n  a Rework; each bumps the version and logs the delta. To add a NEW system or\n  restructure the system map use \u002Funikit-gd-spec; to edit GAME.md content use \u002Funikit-gd-spec;\n  the moment an edit also touches a second system, a content type, a flow, or GAME.md (two\n  or more zones) use \u002Funikit-gd-apply; to invent a brand-new game concept use\n  \u002Funikit-gd-brainstorm.\nargument-hint: \"\u003Csystem name | SYS-slug> [\\\"\u003Cwhat to change>\\\"]  (mode inferred from doc state + intent; 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  - AskUserQuestion\ndisable-model-invocation: false\nuser-invocable: true\nmetadata:\n  author: unikit\n  version: \"1.0\"\n  category: game-design\n---\n\n# Game Design — Per-System GDD (Authoring & Revision)\n\nOwn **one system's design document** at\n`.unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md` — eleven sections (A–K) plus any\ndomain section-packs. This skill owns the **system zone** (`gd-principles` → Zone\nOwnership): the **full lifecycle** of a `SYSTEM.md` lives here — **create** the\nskeleton, **fill** its placeholders, and **revise** approved content (Tuning \u002F\nTweak \u002F Rework) under the delta discipline. There is no separate editor skill.\n\nIt never creates the master spec or the map, and never edits `GAME.md` content —\nthat is `unikit-gd-spec`; player-action flows are `unikit-gd-flow`'s.\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 stay English. Do not announce the language 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## Phase 0 — Bootstrap\n\nSilently load — do not narrate:\n\n1. **`.unikit\u002Fsystem\u002Fgamedesign\u002Fgd-principles.md`** (the core) — the collaborative\n   protocol, the facts registry \u002F ID conventions, and the language rules. Plus, from\n   the same `gamedesign\u002F` folder, the shards this skill needs: **`gd-authoring.md`**\n   (the **section-cycle authoring contract** + the **delta discipline** — the\n   mandatory Version +1 → changelog → registry-check → recommend-verify tail),\n   **`gd-lifecycle.md`** (the lifecycle & status spine), and **`gd-provenance.md`**\n   (the import provenance markers). This skill **applies** that contract; it does not\n   restate the mechanics. If missing, warn (`unikit-ai update`) and fall back to the\n   protocol as summarized in this file.\n2. **`.unikit\u002Fgamedesign\u002FGAME.md`** — pillars, loops, non-goals the system must\n   serve (its roster is in `## System Map [gen]`). If it does not exist, **stop** —\n   there is no master spec yet. Read `.unikit\u002Fgamedesign\u002Fconcepts\u002FINDEX.md` (if it\n   exists) to route precisely: a `drafted`\u002F`approved` concept present → recommend\n   `\u002Funikit-gd-spec` (build the master spec from it); no concept — or no\n   `concepts\u002FINDEX.md` (or no `concepts\u002F` dir) at all → recommend\n   `\u002Funikit-gd-brainstorm` first, then `\u002Funikit-gd-spec`.\n3. **`.unikit\u002Fgamedesign\u002FGD-IDS.yaml`** — find the target system's entry under\n   `systems`. If there is **no entry**, the system is not on the map: offer to add\n   it via `\u002Funikit-gd-spec` (**add-system** — graft this one system onto the map, not\n   a remap), or pick an existing `not-started` system. Do not author an off-map\n   system.\n4. **`.unikit\u002Fmemory\u002Fgamedesign\u002FRULES_INDEX.md`** — load the **core** domain\n   rules for this system's **behavioural domain**, on demand by `Load When`, plus\n   any studio `library` rule on the same topic. Read the domain from the system's\n   name and Overview (the behaviour it drives), **not** from the coarse GD-IDS\n   `category`. When the behaviour is **unambiguous**, attach the matching domain\n   automatically (its section-pack rides along — auto-attached with a veto, see item 6\n   and Phase 4); when it is **ambiguous** or the category is coarse (Gameplay \u002F Meta),\n   settle it with one plain question, asked with the question tool of your agent (`AskUserQuestion`) — framed as an outcome, no codes — rather\n   than guessing. A system may match more than one domain; they combine:\n\n   | Domain | Core rules to load | Section-pack |\n   |--------|--------------------|--------------|\n   | combat \u002F mechanics | `balance`, `frameworks` | combat |\n   | ai-behavior | `balance`, `frameworks` | ai-behavior |\n   | economy \u002F loot | `economy`, `balance` | economy |\n   | progression \u002F unlock | `progression`, `balance` | progression |\n   | level \u002F content | `level-design` | levels |\n   | narrative \u002F dialogue | `narrative` | narrative |\n   | ui \u002F onboarding | `ux-onboarding` | ux |\n   | liveops \u002F events | `liveops`, `economy` | liveops |\n   | persistence | `progression` | persistence |\n   | monetization | `monetization-ethics`, `economy` | monetization |\n   | meta \u002F other | `frameworks`, `core-loops` | — |\n\n   Every system also touches **accessibility** (section J) — load `accessibility`\n   when authoring J. Obey the index's **Rule-Loading Discipline**: load by `Load When`,\n   load a reference only from its parent rule's `> **References**:`, and **never glob the\n   memory tree** (`.unikit\u002Fmemory\u002Fgamedesign\u002F**`) to discover rules.\n5. **`.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.\n6. **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fsection-packs.md`** — the catalog of\n   domain section-packs. On an **unambiguous** domain the matching pack is\n   **auto-attached** — announced to the user in one outcome-language phrase (what it\n   adds for the player \u002F the design, never the word \"pack\" or a code) that they can\n   veto; on an **ambiguous** domain a single plain Yes\u002FNo decides it. Never a mandatory\n   pass after section K, never surfaced as registry jargon. Load the pack named in the\n   table above (when one applies).\n7. **Schema guard (clean break — no automatic migration).** `GD-IDS.yaml` MUST be\n   `version: 2`. If it is still `version: 1`, **STOP** and report: the design\n   workspace is on the pre-v2 layout — v2 dropped the standalone markdown\n   system-index and now renders the roster into `GAME.md` (`## System Map [gen]`);\n   there is no automatic migration. Tell the user to bump `GD-IDS.yaml` to\n   `version: 2` and fold the legacy system-index rows into GAME.md's\n   `## System Map [gen]` before re-running.\n\n**One-way boundary:** never read `.unikit\u002Fcode\u002F`, project source, or build\nartifacts. The only external read is `SOURCE.md` during an import (Phase 1).\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n## Phase 1 — Context\n\nGather the facts the system must stay consistent with (read-only):\n\n- **Known facts** from `GD-IDS.yaml` — pillars (`implements` targets), entities,\n  formulas, and terms already locked by other systems. These are constraints, not\n  suggestions.\n- **Neighbor GDDs** — for each system this one depends on (from the GD-IDS\n  `depends_on`, rendered in GAME.md `## System Map`), read its header and sections\n  **D (Formulas)** and **F (Dependencies)** to match data interfaces.\n- **Recent `unikit-gd-verify` reports** for this system, if any\n  (`.unikit\u002Fgamedesign\u002Freviews\u002F`).\n- **Import source** — if `GD-IDS`\u002FGAME mention an import, or a\n  `researches\u002Fimport-*\u002FSOURCE.md` covers this system, read it: section\n  content is **extracted** from it, not regenerated. Mark provenance per\n  `gd-provenance` → Provenance: place `\u003C!-- provenance: extracted from SOURCE.md -->`\n  under each section lifted from the source and `\u003C!-- provenance: generated -->`\n  under each section inferred to complete the skeleton; untagged sections are\n  normal authored content. Import folders created before dateless naming are named\n  `YYYY-MM-DD_import-\u003Cslug>`, and no folder was renamed, so the two formats coexist\n  permanently. The legacy glob `researches\u002F*import-*\u002FSOURCE.md` **subsumes** the\n  current one — a leading `*` matches zero characters — so one pattern would find\n  both eras; both are named here for legibility, not necessity, because the coexistence\n  is a fact a reader should not have to infer from glob semantics. Zero matches is not\n  a failure: a project with no import is the normal case and the branch stays silent.\n- **Explore research (internal design lens)** — if this system was grafted from an\n  `unikit-gd-explore` brief, discover the research **deterministically** (survives a\n  `\u002Fclear`): read the system's `GD-IDS` `research:` pointer (authoritative), falling\n  back to the `researches\u002FINDEX.md` entry whose `Target:` is this `SYS-\u003Cslug>`. Read\n  that research's `RESEARCH_BRIEF.md` → **`## New Feature Plan`** block and use its\n  **section seeds** as the *starting drafts* — a **seeded** section is **drafted\n  silently** in Generation (Phase 4) and confirmed in the group review (Phase 5); a\n  seed is a draft, not an approved write. For\n  a **revision** (Edit), the matching block is **`## Improvement Plan`** — its\n  ready-to-apply delta lines (`\u003CSection>: \u003Cold> → \u003Cnew>`), expected scale, touched\n  facts, and any `RF-\u003Cdate>-n` it closes pre-fill the change set (the user still\n  approves every edit). These explore-seeded drafts are **untagged normal authored\n  content** — do **not** mark them `extracted` \u002F `generated` (those markers are for\n  **imports** only; this is the generalization of import-reading stated canonically\n  in `gd-provenance` → Provenance, which this skill applies rather than restates).\n\n## Phase 2 — Resolve Mode + Depth (no flags)\n\nCheck `.unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md` and read the intent in the prompt:\n\n1. **Does not exist** → **Create**: build the skeleton (Phase 3), then author from\n   section A.\n2. **Exists** and the prompt describes a **change to approved content** (a value,\n   rule, or structure: \"raise damage\", \"tune the economy\", \"rework the status\n   system\", \"nerf X\", \"change this rule\") → **Edit**: classify the scale and apply\n   the delta (Revision below). Approved text is changed **only** through this path.\n3. **Exists with `[To be designed]` placeholders** and the intent is to continue \u002F\n   fill (or no change is described) → **Fill**: resume from the remaining placeholders.\n   Approved text is **never overwritten** — only placeholders are filled. Skip the\n   skeleton sub-step (Phase 3.1); still fork-scan and run Phases 4–5 over the\n   placeholders.\n4. **Exists, complete, no change described** → detailing is done; nothing to author.\n   Offer review \u002F verify (Phase 6) and stop.\n\nIf the system name is ambiguous (matches several entries, or none) →\nthe question tool of your agent (`AskUserQuestion`) listing candidates. Never guess the target. Print the candidates to the screen as plain\nmarkdown first.\n\n**Depth gate (Create \u002F Fill only).** Once the mode is Create or Fill, present **one**\ndepth picker — the named tiers `core\u002Fstandard\u002Ffull`, each with what it adds, not bare\nletters:\n\n```\nThe question tool of your agent (`AskUserQuestion`): How deep should this pass go?\nOptions:\n1. core (recommended) — the floor that gets the doc to a solid, usable base: Overview,\n   Player Fantasy, Detailed Design, Formulas, Acceptance Criteria.\n2. standard — core + Edge Cases, Dependencies, Tuning Knobs, Telemetry, Accessibility.\n3. full — every section + the relevant domain pack(s).\n```\n\nThe picked tier is the **ephemeral scope of this pass — NOT stored** (`gd-authoring` \u002F\n`gd-lifecycle`); the lasting fact is the inferred status at Phase 6. The matching\n**section-pack** for the system's domain (Phase 0 table) is **auto-attached when the\ndomain is unambiguous** — announced in one outcome-language phrase you can veto; an\nambiguous domain gets a single plain Yes\u002FNo in the Phase 4 decision round. **Edit** mode\nskips the depth gate entirely (it lies flat on the Revision flow).\n\n---\n\n## Load the Mode Body\n\nWith the mode resolved (Phase 2) and the depth picked (Create \u002F Fill only), load the\nmatching body on demand and follow it — do **not** keep both bodies in context. Each\nreturns to **Phase 6** (Final) below.\n\n| Mode | Reference body |\n|------|----------------|\n| **Create \u002F Fill** | `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmode-author.md` — the Decision-First section-cycle: the A–K section map + core-set, Phase 3 (Skeleton + Fork-Scan), Phase 4 (Decision Interview + Generation), Phase 5 (Group Review). |\n| **Edit** | `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmode-revise.md` — classify the scale (Tuning \u002F Tweak \u002F Rework \u002F Structural-redirect), apply the change, then the mandatory delta tail. |\n\n---\n\n## Phase 6 — Final: Registry & State + Handoff\n\n### Registry & State (Create \u002F Fill)\n\nAfter the sections are authored and accepted:\n\n1. **Scan the GDD** for registry candidates — entities, formulas, and constants\n   referenced in **two or more places** (within this doc or cross-system). Internal\n   single-use values stay in the GDD.\n2. Present a **NEW \u002F KNOWN** summary and get approval to write `GD-IDS.yaml`\n   (`entities`, `formulas`, plus the `systems` entry's `doc_status` \u002F `version`).\n   Existing values are never changed silently; every fact carries its `source`.\n3. **Status (inferred — `gd-lifecycle`).** Set the system's status in the **two places\n   that must agree** — the `SYSTEM.md` header `> Status:` token (inside the combined\n   header line, not a separate bold line) and the `GD-IDS.yaml` `doc_status`:\n   - `detailed` once the whole **core-set (A\u002FB\u002FC\u002FD\u002FH)** is authored.\n   - **held at `skeleton`** while any **core** section carries `\u003C!-- deferred -->` (the\n     soft floor guard; the WARN in Phase 4) — the status does **not** rise to\n     `detailed`.\n   - when the core is complete but ≥1 **non-core** section is deferred, the status is\n     `detailed` and the `## System Map [gen]` renders it `detailed · partial (n\u002Fm)`\n     (inferred from the markers, never a stored field).\n\n   Set `version: 1` in `GD-IDS.yaml` (and the header), write the initial changelog\n   block to section K (`#### v1 — \u003Cdate> — initial design` with the\n   `AC: + AC-\u003Cslug>-1 … N (new)` line) — the single current block (K1).\n\nThe `## System Map [gen]` renders this system's status\u002Fversion (incl. the `· partial`\nsuffix) **read-only** from `GD-IDS`; it is **not** this skill's surface — it is owned by\n`unikit-gd-spec` (B1) and re-renders on its next touch. `unikit-gd-verify` is read-only —\nit **prints** the System Map freshness, it does not re-render it (`gd-lifecycle` →\nLifecycle & Status). Recommending verify (below) surfaces the staleness.\n\n### Handoff\n\nRecommend the next steps (do not auto-invoke):\n\n- ✅ Verify consistency & impact — \u002Funikit-gd-verify SYS-\u003Cslug>\n- 🔍 Qualitative review (fresh session) — \u002Funikit-gd-review systems\u002FSYS-\u003Cslug>.md\n- 🧩 Detail the next system — \u002Funikit-gd-system \u003CSYS-slug>\n\nA review is most independent in a **fresh session** (the reviewer should not have\nauthored the doc). `unikit-gd-verify` is read-only — it checks the doc against the\nregistry and **prints** dependent impact + the `## System Map [gen]` freshness (the map\nre-renders on the next `unikit-gd-spec` touch).\n\n## Final: Compact Report\n\nThe terminal plaque (TIER A — `gd-principles` → Language): lead with the **name**; the\n`SYS-` \u002F `AC-` ids ride along as parenthetical copy-paste tags; render the lifecycle\nstatus as a **plain phrase**, never the raw enum.\n\n```\nSystem: \u003Cname>  (SYS-\u003Cslug>)\nMode: \u003Ccreate | fill | edit (tuning|tweak|rework)>   ·   Depth: \u003Ccore | standard | full>  (create\u002Ffill)\nDoc: .unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md — \u003Cready | ready, a couple of optional blocks left | skeleton, main blocks not filled yet>, vN\nSections authored\u002Fedited: \u003Cthe named list>   [deferred: \u003Cnames carrying \u003C!-- deferred --> > | none]\nRegistry: +\u003CE> entities, +\u003CF> formulas, +\u003CT> terms  (GD-IDS.yaml)\nAcceptance criteria: AC-\u003Cslug>-1 … AC-\u003Cslug>-N   [AC delta on an edit: +\u003Cn> \u002F changed \u003Cn> \u002F removed \u003Cn>]\n```\n\nNo summary document, no report file.\n\n## Ownership Boundaries\n\n- **Owns:** the **full lifecycle** of `systems\u002FSYS-\u003Cslug>.md` — creating the\n  skeleton, filling placeholders, **and revising approved content** (Tuning \u002F Tweak\n  \u002F Rework, with the version bump + changelog; the status stays `detailed`); the system's\n  `GD-IDS.yaml` facts (`entities`, `formulas`, `terms`) and its `doc_status` \u002F\n  `version`.\n- **Not this skill:** `GAME.md` content **or** structure \u002F the system map →\n  `unikit-gd-spec`; player-action flows → `unikit-gd-flow`; quality verdicts →\n  `unikit-gd-review`; consistency & impact → `unikit-gd-verify` (read-only — it prints,\n  it does not re-render); the `## System Map [gen]` render → `unikit-gd-spec`.\n- **Never:** write, fill, or edit without approval; overwrite approved text outside\n  the delta discipline; skip the version bump or changelog on an edit (unrecorded\n  delta); change a `GD-IDS.yaml` value silently; delete or renumber an ID; touch\n  structure or `GAME.md`; read the code workspace or project source.\n\n## Quick Reference\n\n```\n\u002Funikit-gd-system SYS-combat                        → create skeleton + author A–K (if no doc yet)\n\u002Funikit-gd-system combat                            → resolve to the SYS-slug; same flow\n\u002Funikit-gd-system SYS-combat                        → resume filling placeholders (partial doc)\n\u002Funikit-gd-system SYS-combat \"raise grunt damage 10%\" → Tuning: edit G\u002FC, one approval\n\u002Funikit-gd-system combat \"small fix to the parry rule\" → Tweak: targeted edit\n\u002Funikit-gd-system SYS-combat \"rework the status system\" → Rework: section-cycle old-vs-new\n```\n","# Game Design — Per-System GDD (Authoring & Revision)\n\nOwn **one system's design document** at\n`.unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md` — eleven sections (A–K) plus any\ndomain section-packs. This skill owns the **system zone** (`gd-principles` → Zone\nOwnership): the **full lifecycle** of a `SYSTEM.md` lives here — **create** the\nskeleton, **fill** its placeholders, and **revise** approved content (Tuning \u002F\nTweak \u002F Rework) under the delta discipline. There is no separate editor skill.\n\nIt never creates the master spec or the map, and never edits `GAME.md` content —\nthat is `unikit-gd-spec`; player-action flows are `unikit-gd-flow`'s.\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 stay English. Do not announce the language 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## Phase 0 — Bootstrap\n\nSilently load — do not narrate:\n\n1. **`.unikit\u002Fsystem\u002Fgamedesign\u002Fgd-principles.md`** (the core) — the collaborative\n   protocol, the facts registry \u002F ID conventions, and the language rules. Plus, from\n   the same `gamedesign\u002F` folder, the shards this skill needs: **`gd-authoring.md`**\n   (the **section-cycle authoring contract** + the **delta discipline** — the\n   mandatory Version +1 → changelog → registry-check → recommend-verify tail),\n   **`gd-lifecycle.md`** (the lifecycle & status spine), and **`gd-provenance.md`**\n   (the import provenance markers). This skill **applies** that contract; it does not\n   restate the mechanics. If missing, warn (`unikit-ai update`) and fall back to the\n   protocol as summarized in this file.\n2. **`.unikit\u002Fgamedesign\u002FGAME.md`** — pillars, loops, non-goals the system must\n   serve (its roster is in `## System Map [gen]`). If it does not exist, **stop** —\n   there is no master spec yet. Read `.unikit\u002Fgamedesign\u002Fconcepts\u002FINDEX.md` (if it\n   exists) to route precisely: a `drafted`\u002F`approved` concept present → recommend\n   `\u002Funikit-gd-spec` (build the master spec from it); no concept — or no\n   `concepts\u002FINDEX.md` (or no `concepts\u002F` dir) at all → recommend\n   `\u002Funikit-gd-brainstorm` first, then `\u002Funikit-gd-spec`.\n3. **`.unikit\u002Fgamedesign\u002FGD-IDS.yaml`** — find the target system's entry under\n   `systems`. If there is **no entry**, the system is not on the map: offer to add\n   it via `\u002Funikit-gd-spec` (**add-system** — graft this one system onto the map, not\n   a remap), or pick an existing `not-started` system. Do not author an off-map\n   system.\n4. **`.unikit\u002Fmemory\u002Fgamedesign\u002FRULES_INDEX.md`** — load the **core** domain\n   rules for this system's **behavioural domain**, on demand by `Load When`, plus\n   any studio `library` rule on the same topic. Read the domain from the system's\n   name and Overview (the behaviour it drives), **not** from the coarse GD-IDS\n   `category`. When the behaviour is **unambiguous**, attach the matching domain\n   automatically (its section-pack rides along — auto-attached with a veto, see item 6\n   and Phase 4); when it is **ambiguous** or the category is coarse (Gameplay \u002F Meta),\n   settle it with one plain question, asked with the question tool of your agent (`AskUserQuestion`) — framed as an outcome, no codes — rather\n   than guessing. A system may match more than one domain; they combine:\n\n   | Domain | Core rules to load | Section-pack |\n   |--------|--------------------|--------------|\n   | combat \u002F mechanics | `balance`, `frameworks` | combat |\n   | ai-behavior | `balance`, `frameworks` | ai-behavior |\n   | economy \u002F loot | `economy`, `balance` | economy |\n   | progression \u002F unlock | `progression`, `balance` | progression |\n   | level \u002F content | `level-design` | levels |\n   | narrative \u002F dialogue | `narrative` | narrative |\n   | ui \u002F onboarding | `ux-onboarding` | ux |\n   | liveops \u002F events | `liveops`, `economy` | liveops |\n   | persistence | `progression` | persistence |\n   | monetization | `monetization-ethics`, `economy` | monetization |\n   | meta \u002F other | `frameworks`, `core-loops` | — |\n\n   Every system also touches **accessibility** (section J) — load `accessibility`\n   when authoring J. Obey the index's **Rule-Loading Discipline**: load by `Load When`,\n   load a reference only from its parent rule's `> **References**:`, and **never glob the\n   memory tree** (`.unikit\u002Fmemory\u002Fgamedesign\u002F**`) to discover rules.\n5. **`.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.\n6. **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fsection-packs.md`** — the catalog of\n   domain section-packs. On an **unambiguous** domain the matching pack is\n   **auto-attached** — announced to the user in one outcome-language phrase (what it\n   adds for the player \u002F the design, never the word \"pack\" or a code) that they can\n   veto; on an **ambiguous** domain a single plain Yes\u002FNo decides it. Never a mandatory\n   pass after section K, never surfaced as registry jargon. Load the pack named in the\n   table above (when one applies).\n7. **Schema guard (clean break — no automatic migration).** `GD-IDS.yaml` MUST be\n   `version: 2`. If it is still `version: 1`, **STOP** and report: the design\n   workspace is on the pre-v2 layout — v2 dropped the standalone markdown\n   system-index and now renders the roster into `GAME.md` (`## System Map [gen]`);\n   there is no automatic migration. Tell the user to bump `GD-IDS.yaml` to\n   `version: 2` and fold the legacy system-index rows into GAME.md's\n   `## System Map [gen]` before re-running.\n\n**One-way boundary:** never read `.unikit\u002Fcode\u002F`, project source, or build\nartifacts. The only external read is `SOURCE.md` during an import (Phase 1).\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n## Phase 1 — Context\n\nGather the facts the system must stay consistent with (read-only):\n\n- **Known facts** from `GD-IDS.yaml` — pillars (`implements` targets), entities,\n  formulas, and terms already locked by other systems. These are constraints, not\n  suggestions.\n- **Neighbor GDDs** — for each system this one depends on (from the GD-IDS\n  `depends_on`, rendered in GAME.md `## System Map`), read its header and sections\n  **D (Formulas)** and **F (Dependencies)** to match data interfaces.\n- **Recent `unikit-gd-verify` reports** for this system, if any\n  (`.unikit\u002Fgamedesign\u002Freviews\u002F`).\n- **Import source** — if `GD-IDS`\u002FGAME mention an import, or a\n  `researches\u002Fimport-*\u002FSOURCE.md` covers this system, read it: section\n  content is **extracted** from it, not regenerated. Mark provenance per\n  `gd-provenance` → Provenance: place `\u003C!-- provenance: extracted from SOURCE.md -->`\n  under each section lifted from the source and `\u003C!-- provenance: generated -->`\n  under each section inferred to complete the skeleton; untagged sections are\n  normal authored content. Import folders created before dateless naming are named\n  `YYYY-MM-DD_import-\u003Cslug>`, and no folder was renamed, so the two formats coexist\n  permanently. The legacy glob `researches\u002F*import-*\u002FSOURCE.md` **subsumes** the\n  current one — a leading `*` matches zero characters — so one pattern would find\n  both eras; both are named here for legibility, not necessity, because the coexistence\n  is a fact a reader should not have to infer from glob semantics. Zero matches is not\n  a failure: a project with no import is the normal case and the branch stays silent.\n- **Explore research (internal design lens)** — if this system was grafted from an\n  `unikit-gd-explore` brief, discover the research **deterministically** (survives a\n  `\u002Fclear`): read the system's `GD-IDS` `research:` pointer (authoritative), falling\n  back to the `researches\u002FINDEX.md` entry whose `Target:` is this `SYS-\u003Cslug>`. Read\n  that research's `RESEARCH_BRIEF.md` → **`## New Feature Plan`** block and use its\n  **section seeds** as the *starting drafts* — a **seeded** section is **drafted\n  silently** in Generation (Phase 4) and confirmed in the group review (Phase 5); a\n  seed is a draft, not an approved write. For\n  a **revision** (Edit), the matching block is **`## Improvement Plan`** — its\n  ready-to-apply delta lines (`\u003CSection>: \u003Cold> → \u003Cnew>`), expected scale, touched\n  facts, and any `RF-\u003Cdate>-n` it closes pre-fill the change set (the user still\n  approves every edit). These explore-seeded drafts are **untagged normal authored\n  content** — do **not** mark them `extracted` \u002F `generated` (those markers are for\n  **imports** only; this is the generalization of import-reading stated canonically\n  in `gd-provenance` → Provenance, which this skill applies rather than restates).\n\n## Phase 2 — Resolve Mode + Depth (no flags)\n\nCheck `.unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md` and read the intent in the prompt:\n\n1. **Does not exist** → **Create**: build the skeleton (Phase 3), then author from\n   section A.\n2. **Exists** and the prompt describes a **change to approved content** (a value,\n   rule, or structure: \"raise damage\", \"tune the economy\", \"rework the status\n   system\", \"nerf X\", \"change this rule\") → **Edit**: classify the scale and apply\n   the delta (Revision below). Approved text is changed **only** through this path.\n3. **Exists with `[To be designed]` placeholders** and the intent is to continue \u002F\n   fill (or no change is described) → **Fill**: resume from the remaining placeholders.\n   Approved text is **never overwritten** — only placeholders are filled. Skip the\n   skeleton sub-step (Phase 3.1); still fork-scan and run Phases 4–5 over the\n   placeholders.\n4. **Exists, complete, no change described** → detailing is done; nothing to author.\n   Offer review \u002F verify (Phase 6) and stop.\n\nIf the system name is ambiguous (matches several entries, or none) →\nthe question tool of your agent (`AskUserQuestion`) listing candidates. Never guess the target. Print the candidates to the screen as plain\nmarkdown first.\n\n**Depth gate (Create \u002F Fill only).** Once the mode is Create or Fill, present **one**\ndepth picker — the named tiers `core\u002Fstandard\u002Ffull`, each with what it adds, not bare\nletters:\n\n```\nThe question tool of your agent (`AskUserQuestion`): How deep should this pass go?\nOptions:\n1. core (recommended) — the floor that gets the doc to a solid, usable base: Overview,\n   Player Fantasy, Detailed Design, Formulas, Acceptance Criteria.\n2. standard — core + Edge Cases, Dependencies, Tuning Knobs, Telemetry, Accessibility.\n3. full — every section + the relevant domain pack(s).\n```\n\nThe picked tier is the **ephemeral scope of this pass — NOT stored** (`gd-authoring` \u002F\n`gd-lifecycle`); the lasting fact is the inferred status at Phase 6. The matching\n**section-pack** for the system's domain (Phase 0 table) is **auto-attached when the\ndomain is unambiguous** — announced in one outcome-language phrase you can veto; an\nambiguous domain gets a single plain Yes\u002FNo in the Phase 4 decision round. **Edit** mode\nskips the depth gate entirely (it lies flat on the Revision flow).\n\n---\n\n## Load the Mode Body\n\nWith the mode resolved (Phase 2) and the depth picked (Create \u002F Fill only), load the\nmatching body on demand and follow it — do **not** keep both bodies in context. Each\nreturns to **Phase 6** (Final) below.\n\n| Mode | Reference body |\n|------|----------------|\n| **Create \u002F Fill** | `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmode-author.md` — the Decision-First section-cycle: the A–K section map + core-set, Phase 3 (Skeleton + Fork-Scan), Phase 4 (Decision Interview + Generation), Phase 5 (Group Review). |\n| **Edit** | `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmode-revise.md` — classify the scale (Tuning \u002F Tweak \u002F Rework \u002F Structural-redirect), apply the change, then the mandatory delta tail. |\n\n---\n\n## Phase 6 — Final: Registry & State + Handoff\n\n### Registry & State (Create \u002F Fill)\n\nAfter the sections are authored and accepted:\n\n1. **Scan the GDD** for registry candidates — entities, formulas, and constants\n   referenced in **two or more places** (within this doc or cross-system). Internal\n   single-use values stay in the GDD.\n2. Present a **NEW \u002F KNOWN** summary and get approval to write `GD-IDS.yaml`\n   (`entities`, `formulas`, plus the `systems` entry's `doc_status` \u002F `version`).\n   Existing values are never changed silently; every fact carries its `source`.\n3. **Status (inferred — `gd-lifecycle`).** Set the system's status in the **two places\n   that must agree** — the `SYSTEM.md` header `> Status:` token (inside the combined\n   header line, not a separate bold line) and the `GD-IDS.yaml` `doc_status`:\n   - `detailed` once the whole **core-set (A\u002FB\u002FC\u002FD\u002FH)** is authored.\n   - **held at `skeleton`** while any **core** section carries `\u003C!-- deferred -->` (the\n     soft floor guard; the WARN in Phase 4) — the status does **not** rise to\n     `detailed`.\n   - when the core is complete but ≥1 **non-core** section is deferred, the status is\n     `detailed` and the `## System Map [gen]` renders it `detailed · partial (n\u002Fm)`\n     (inferred from the markers, never a stored field).\n\n   Set `version: 1` in `GD-IDS.yaml` (and the header), write the initial changelog\n   block to section K (`#### v1 — \u003Cdate> — initial design` with the\n   `AC: + AC-\u003Cslug>-1 … N (new)` line) — the single current block (K1).\n\nThe `## System Map [gen]` renders this system's status\u002Fversion (incl. the `· partial`\nsuffix) **read-only** from `GD-IDS`; it is **not** this skill's surface — it is owned by\n`unikit-gd-spec` (B1) and re-renders on its next touch. `unikit-gd-verify` is read-only —\nit **prints** the System Map freshness, it does not re-render it (`gd-lifecycle` →\nLifecycle & Status). Recommending verify (below) surfaces the staleness.\n\n### Handoff\n\nRecommend the next steps (do not auto-invoke):\n\n- ✅ Verify consistency & impact — \u002Funikit-gd-verify SYS-\u003Cslug>\n- 🔍 Qualitative review (fresh session) — \u002Funikit-gd-review systems\u002FSYS-\u003Cslug>.md\n- 🧩 Detail the next system — \u002Funikit-gd-system \u003CSYS-slug>\n\nA review is most independent in a **fresh session** (the reviewer should not have\nauthored the doc). `unikit-gd-verify` is read-only — it checks the doc against the\nregistry and **prints** dependent impact + the `## System Map [gen]` freshness (the map\nre-renders on the next `unikit-gd-spec` touch).\n\n## Final: Compact Report\n\nThe terminal plaque (TIER A — `gd-principles` → Language): lead with the **name**; the\n`SYS-` \u002F `AC-` ids ride along as parenthetical copy-paste tags; render the lifecycle\nstatus as a **plain phrase**, never the raw enum.\n\n```\nSystem: \u003Cname>  (SYS-\u003Cslug>)\nMode: \u003Ccreate | fill | edit (tuning|tweak|rework)>   ·   Depth: \u003Ccore | standard | full>  (create\u002Ffill)\nDoc: .unikit\u002Fgamedesign\u002Fsystems\u002FSYS-\u003Cslug>.md — \u003Cready | ready, a couple of optional blocks left | skeleton, main blocks not filled yet>, vN\nSections authored\u002Fedited: \u003Cthe named list>   [deferred: \u003Cnames carrying \u003C!-- deferred --> > | none]\nRegistry: +\u003CE> entities, +\u003CF> formulas, +\u003CT> terms  (GD-IDS.yaml)\nAcceptance criteria: AC-\u003Cslug>-1 … AC-\u003Cslug>-N   [AC delta on an edit: +\u003Cn> \u002F changed \u003Cn> \u002F removed \u003Cn>]\n```\n\nNo summary document, no report file.\n\n## Ownership Boundaries\n\n- **Owns:** the **full lifecycle** of `systems\u002FSYS-\u003Cslug>.md` — creating the\n  skeleton, filling placeholders, **and revising approved content** (Tuning \u002F Tweak\n  \u002F Rework, with the version bump + changelog; the status stays `detailed`); the system's\n  `GD-IDS.yaml` facts (`entities`, `formulas`, `terms`) and its `doc_status` \u002F\n  `version`.\n- **Not this skill:** `GAME.md` content **or** structure \u002F the system map →\n  `unikit-gd-spec`; player-action flows → `unikit-gd-flow`; quality verdicts →\n  `unikit-gd-review`; consistency & impact → `unikit-gd-verify` (read-only — it prints,\n  it does not re-render); the `## System Map [gen]` render → `unikit-gd-spec`.\n- **Never:** write, fill, or edit without approval; overwrite approved text outside\n  the delta discipline; skip the version bump or changelog on an edit (unrecorded\n  delta); change a `GD-IDS.yaml` value silently; delete or renumber an ID; touch\n  structure or `GAME.md`; read the code workspace or project source.\n\n## Quick Reference\n\n```\n\u002Funikit-gd-system SYS-combat                        → create skeleton + author A–K (if no doc yet)\n\u002Funikit-gd-system combat                            → resolve to the SYS-slug; same flow\n\u002Funikit-gd-system SYS-combat                        → resume filling placeholders (partial doc)\n\u002Funikit-gd-system SYS-combat \"raise grunt damage 10%\" → Tuning: edit G\u002FC, one approval\n\u002Funikit-gd-system combat \"small fix to the parry rule\" → Tweak: targeted edit\n\u002Funikit-gd-system SYS-combat \"rework the status system\" → Rework: section-cycle old-vs-new\n```\n",{"name":5,"metadata":54,"description":7,"allowed-tools":58,"argument-hint":69,"user-invocable":70,"disable-model-invocation":50},{"author":55,"version":56,"category":57},"unikit","1.0","game-design",[59,60,61,62,63,64,65,66,67,68],"Read","Write","Edit","Glob","Grep","Bash(ls *)","Bash(find *)","Bash(wc *)","Bash(date *)","AskUserQuestion","\u003Csystem name | SYS-slug> [\"\u003Cwhat to change>\"]  (mode inferred from doc state + intent; no flags)",true,"main","ae3c6dfffd26d9b45b9d96d71ba2c122c50b67ae","skills\u002Funikit-gd-system",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":81,"prompt":91,"zipAvailable":70},[82,85,88],{"tool":83,"command":84},"npx","npx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-system",{"tool":86,"command":87},"bunx","bunx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-system",{"tool":89,"command":90},"pnpm","pnpm dlx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-system","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-system\u002FSKILL.md",[93,99,103],{"path":94,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":97,"sourceHtmlUrl":98},"references\u002Fmode-author.md","REFERENCE","参考文档",8418,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-system\u002Freferences\u002Fmode-author.md",{"path":100,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":101,"sourceHtmlUrl":102},"references\u002Fmode-revise.md",5428,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-system\u002Freferences\u002Fmode-revise.md",{"path":104,"resourceType":95,"resourceTypeDesc":96,"sizeBytes":105,"sourceHtmlUrl":106},"references\u002Fsection-packs.md",10169,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-system\u002Freferences\u002Fsection-packs.md",[108,133,156,178,197,223],{"skillNo":109,"name":55,"nameZh":6,"description":110,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":111,"categories":112,"keywords":116,"publishedAt":49},"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",[113],{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[55,117,118,119,120,121,122,123,124,125,39,38,126,37,127,128,129,130,131,132],"project","time","actions","fix","documents","architecture","stack","run","update","config","git","context","initialize","tech","scan","use",{"skillNo":134,"name":135,"nameZh":6,"description":136,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":137,"categories":138,"keywords":143,"publishedAt":49},"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",[139,142],{"categoryNo":140,"categoryName":141,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},[144,145,146,147,148,149,124,39,38,37,127,31,30,132,150,151,152,153,154,155],"unikit verify","verify","powershell","code review","phase","plan","implement","check","engine","research","name","quality",{"skillNo":157,"name":158,"nameZh":6,"description":159,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":160,"categories":161,"keywords":162,"publishedAt":49},"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",[],[163,164,165,166,117,167,168,169,170,171,172,173,149,174,175,176,39,38,37,177],"unikit todo","todo","remind","show","todo list","only","now","you","done","tasks","work","me","reminders","later","act",{"skillNo":179,"name":180,"nameZh":6,"description":181,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":182,"categories":183,"keywords":185,"publishedAt":49},"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",[184],{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},[186,128,117,120,187,188,189,190,191,192,193,194,164,43,195,124,196,39,38,37],"unikit skills context","coding conventions","writing","when","workflow","commit","review","general coding","text","how","past",{"skillNo":198,"name":199,"nameZh":6,"description":200,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":201,"categories":202,"keywords":210,"publishedAt":49},"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",[203,206,209],{"categoryNo":204,"categoryName":205,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":207,"categoryName":208,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":114,"categoryName":115,"taxonomyType":21,"taxonomyTypeDesc":22},[211,212,213,214,117,215,216,217,218,219,122,220,194,221,123,176,39,38,37,222],"Rules","unikit rules","quick","PDF","clean","knowledge","files","URL","migrate","batch","knowledge base","prune",{"skillNo":224,"name":225,"nameZh":6,"description":226,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":227,"categories":228,"keywords":229,"publishedAt":49},"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",[],[230,211,231,232,117,233,216,234,219,44,125,39,38,127,235,236,237,238,239,240],"registry","unikit rules registry","shared","local","remote","ai rules","automatic","semver","knowledge-base","as","three"]