[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BHN5TP32DPW4Y43SPR5RE":3,"skill-same:01M71BHN5TP32DPW4Y43SPR5RE":95},{"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":73,"commitSha":74,"skillDirectory":75,"forksCount":76,"repositoryHtmlUrl":77,"repositoryHomepageUrl":78,"ownerHtmlUrl":79,"ownerBlogUrl":6,"ownerDescription":80,"updatedAt":81,"install":82,"resources":94},"01M71BHN5TP32DPW4Y43SPR5RE","unikit-gd-apply",null,"Dispatch an explicit, user-dictated set of edits that spans TWO OR MORE zones of the GDD — the master spec, systems, content types, and flows — in one ordered pass. Writes nothing itself: it resolves each delta to its (target, zone), orders them so a system change lands before the content or flow that depends on it, delegates each to the owning skill (\u002Funikit-gd-spec, \u002Funikit-gd-system, \u002Funikit-gd-content, \u002Funikit-gd-flow), and closes with one \u002Funikit-gd-verify pass. Use when you already know the changes and they touch more than one part of the design, e.g. \"apply these GDD changes\", \"update the combat system and its loot and the boss flow\". It also takes a \u002Funikit-gd-review report file (applies its apply-ready bucket), and a bare \u002Funikit-gd-apply reads the last \u002Funikit-gd-verify output in the session. For a single-zone change call its owner directly; to research an open question use \u002Funikit-gd-explore first.","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-apply\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],"apply","unikit gd apply","touch","call","system","for","target","master","read","update","change","loot","you","question","design","open","explore","content types","reviews","ready","2026-11-10 10:12:30",false,"---\nname: unikit-gd-apply\ndescription: >-\n  Dispatch an explicit, user-dictated set of edits that spans TWO OR MORE zones of the\n  GDD — the master spec, systems, content types, and flows — in one ordered pass. Writes\n  nothing itself: it resolves each delta to its (target, zone), orders them so a system\n  change lands before the content or flow that depends on it, delegates each to the owning\n  skill (\u002Funikit-gd-spec, \u002Funikit-gd-system, \u002Funikit-gd-content, \u002Funikit-gd-flow), and closes\n  with one \u002Funikit-gd-verify pass. Use when you already know the changes and they touch more\n  than one part of the design, e.g. \"apply these GDD changes\", \"update the combat system and\n  its loot and the boss flow\". It also takes a \u002Funikit-gd-review report file (applies its\n  apply-ready bucket), and a bare \u002Funikit-gd-apply reads the last \u002Funikit-gd-verify output in\n  the session. For a single-zone change call its owner directly; to research an open question\n  use \u002Funikit-gd-explore first.\nargument-hint: \"[ \\\"\u003Cchanges>\\\" | \u003Creviews\u002F*_review-*.md> ]  (bare = read last \u002Funikit-gd-verify output in session; apply-ready bucket | prose deltas → zone owners; no flags)\"\nallowed-tools:\n  - Read\n  - Glob\n  - Grep\n  - Bash(ls *)\n  - Bash(find *)\n  - Bash(wc *)\n  - Bash(date *)\n  - AskUserQuestion\n  - Skill\ndisable-model-invocation: false\nuser-invocable: true\nmetadata:\n  author: unikit\n  version: \"1.0\"\n  category: game-design\n---\n\n# Game Design — Multi-Zone Edit Dispatcher\n\nApply **a set of explicit, user-dictated edits that crosses more than one zone of the\nGDD** — the master spec (`GAME.md` + roster), systems, content types, and flows — in a\nsingle ordered pass. This skill is a **dispatcher, not an author**: it owns **nothing**\nand writes **nothing**. For each delta it resolves the `(target, zone)`, orders the set\nso the change graph stays causally fresh, hands each delta to the zone that owns it\n(`unikit-gd-spec` \u002F `unikit-gd-system` \u002F `unikit-gd-content` \u002F `unikit-gd-flow`), and\ncloses with **one** consistency pass (`unikit-gd-verify`). The actual writing — sections,\nregistry facts, version bumps, `[gen]` re-renders — happens **inside the owner skills**,\nunder their collaborative protocol and delta discipline; this skill never bypasses it.\n\n**Three input shapes.** (1) **No argument** — the bare `\u002Funikit-gd-apply` reads the\n**last `unikit-gd-verify` output in this session** (free-text prose, no fence) and lifts\nits apply-ready deltas; this is verify's handoff path (verify ends on a bare\n`\u002Funikit-gd-apply`). (2) **Prose deltas** typed directly as the argument. (3) A\n**`unikit-gd-review` report file** (`reviews\u002F*_review-*.md`) — this skill reads the file's\n**`## Apply-ready`** bucket as the delta set (the **`## Research`** bucket is\n`unikit-gd-explore`'s job, not this skill's). All three flow through the same routing,\nordering, and closing verify below. If the bare call finds no recent verify deltas in the\nsession, it does nothing destructive — it softly recommends running `\u002Funikit-gd-verify`\nfirst.\n\n**When NOT to use it.** A change confined to **one** zone goes **straight to that owner**\n— there is nothing to dispatch (Phase 1, GATE 2). A change you **do not yet know how to\ndesign** (an open question, a mechanic to research, a balance to work out) goes to\n`unikit-gd-explore` **first** — this skill only carries out edits you have already decided\n(Phase 1, GATE 1).\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` and\napply it to all output (fall back to English if it is missing) — including the rule to\n**translate concepts, not transliterate jargon**. `gd-principles` → \"Language\" adds the\ngame-design specifics: which IDs and stored field values stay English (the owner skills\nre-apply it on every delegated write). 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. This skill loads **only routing context**, never domain\nrules (it authors nothing, so there is no system\u002Fflow\u002Fcontent to balance):\n\n1. **`.unikit\u002Fsystem\u002Fgamedesign\u002Fgd-principles.md`** (the core) — the **Zone Ownership\n   model + routing** (which zone owns what, the one-way boundary, the single sanctioned\n   `implemented` code→design write) and the facts-registry \u002F ID conventions. Plus, from\n   the same `gamedesign\u002F` folder, the two shards this skill needs to **order** a\n   dispatch: **`gd-authoring.md`** (the **delta discipline** — so it knows a schema \u002F\n   approved-content edit is a versioned delta the owner must record, and catalog churn is\n   not) and **`gd-lifecycle.md`** (the **lifecycle & status spine + cross-axis\n   staleness** — so it knows a system edit stales the content \u002F flows that depend on it,\n   which fixes the dispatch order). This skill **applies** these contracts to sequence the\n   work; it does **not** restate or perform the authoring mechanics. If missing, warn\n   (`unikit-ai update`) and fall back to the ordering summarized in this file.\n2. **`.unikit\u002Fgamedesign\u002FGD-IDS.yaml`** — the registry, read-only here: the `systems`,\n   `flows`, `content_types`, and their `depends_on` \u002F `belongs_to` edges, used to resolve\n   each delta's `(target, zone)` and to detect a delta that needs a **not-yet-registered**\n   system (the create-precondition). If it does not exist, **stop** — there is no design\n   to edit; route to `\u002Funikit-gd-spec` (or `\u002Funikit-gd-brainstorm` first) and stop.\n3. **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 workspace is\n   on the pre-v2 layout (the standalone markdown system-index was dropped; the maps now\n   render into `GAME.md`); there is no automatic migration — tell the user to upgrade via\n   `\u002Funikit-gd-spec` before re-running.\n\n**One-way boundary:** never read `.unikit\u002Fcode\u002F`, project source, or build artifacts\n(`gd-principles` → One-Way Boundary). This skill does not load `RULES_INDEX.md` domain\nrules — it dispatches, it does not design.\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 and not a delegation. Each delta is handed to its zone owner (`unikit-gd-\u003Czone>`; **not** a subagent — a read-only `Agent` could not write the GDD) **inline, one at a time, in the Phase 2 order**, waiting for each to return before starting the next — **never in parallel** (the order is the correctness guarantee). The owner runs its full interactive cycle in the main session, so its collaborative protocol, approvals and writes all hold, and returns control here. A call site that names no argument passes none. Printing the list of `\u002Funikit-gd-*` commands for the user to run, instead of making the calls, is a known failure mode here: every zone is an actual call.\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## Pipeline — ROUTING → DISPATCH → VERIFY\n\n### Phase 1 — ROUTING (resolve every delta → `(target, zone)`)\n\n**Input-mode resolution (first).** Resolve which of the three input shapes this run is:\n\n- **No argument (bare `\u002Funikit-gd-apply`)** → **session mode**. Read the **last\n  `unikit-gd-verify` output in this session** — its printed apply-ready deltas (free-text\n  prose, each citing a `target` + `zone`, no fence) — and lift those deltas as the set,\n  then continue below. If the session carries **no** recent verify output with apply-ready\n  deltas (a fresh session, a `\u002Fclear` since the verify run, or a clean verify PASS), do\n  **nothing destructive** — softly recommend `🔍 \u002Funikit-gd-verify` first and stop. (The\n  verify → apply pair is single-session by design; a `\u002Fclear` between them is fixed by\n  re-running verify — cheap.)\n- **Argument resolves to an existing `reviews\u002F*_review-*.md` path** (the durable handoff\n  from `unikit-gd-review`) → read it and take its **`## Apply-ready`** bucket as the delta\n  set: each apply-ready line is one decided edit carrying an `RF-\u003Cdate>-n` id and a named\n  `Fix (entailed)`. The **`## Research`** bucket is **ignored** here — it is\n  `unikit-gd-explore`'s input, not this skill's. An **empty** apply-ready bucket is a valid\n  input: there is nothing to dispatch — report it and stop, recommending\n  `\u002Funikit-gd-explore \u003Cfile>` for the research bucket.\n- **Any other argument** — including **inline prose deltas** typed directly — is the\n  literal change request, taken as prose.\n\n(The file reader is the **only** review-specific adapter; the no-arg session path + the\nprose path are what keep verify's bare-call handoff working — verify writes no file.)\n\nSplit the request into individual deltas. For each, resolve the **target** (a `SYS-`\u002F\n`CT-`\u002F`FLOW-` id or `GAME.md`) and the **zone** that owns it:\n\n| The delta is… | Target | Zone owner |\n|---------------|--------|------------|\n| a `GAME.md` content edit (pillar, win\u002Flose intent, monetization stance, loop stack) | `GAME.md` | `unikit-gd-spec` |\n| a **new system** added to the map | the roster | `unikit-gd-spec` (add-system) |\n| a system's rules \u002F numbers \u002F formulas \u002F AC | `SYS-\u003Cslug>` | `unikit-gd-system` |\n| a content type's schema (a field, a type, the scale, a `ref\u003C>`, `belongs_to`) | `CT-\u003Cslug>` | `unikit-gd-content` |\n| catalog churn (add\u002Fremove units, a `bulk` count) | `CT-\u003Cslug>` | `unikit-gd-content` |\n| a flow's objectives \u002F pacing \u002F dependencies \u002F events \u002F wiring mode | `FLOW-\u003Cslug>` | `unikit-gd-flow` |\n\nThe dispatcher is **dumb on purpose**: it resolves `(target, zone)` and hands the raw\ndelta to the owner — it does **not** pre-classify Tuning vs Tweak vs Rework, schema vs\nchurn, or create vs revise. Each owner makes that call under its own contract (subtlety\n② below).\n\n**GATE 1 — explicit-edit only (else → `unikit-gd-explore`).** Every delta must be a\n**concrete change the user has already decided**. A delta that is an open question, needs\nresearch, or is \"work out how to…\" is **not** an apply job — route it to\n`\u002Funikit-gd-explore` (research first, then come back with the decided edit). If the\nrequest mixes the two, dispatch the decided deltas and hand the open one to explore;\nannounce the split. This skill never researches.\n\n**GATE 2 — multi-zone only (else → the single owner).** The resolved set must touch\n**two or more zones** (or be a genuine multi-delta job). A request that resolves to a\n**single zone** has nothing to dispatch — **bounce it to that owner directly** and stop:\n\n- one system edit → `\u002Funikit-gd-system \u003CSYS>` · one schema edit → `\u002Funikit-gd-content \u003CCT>`\n- one flow edit → `\u002Funikit-gd-flow \u003CFLOW>` · one `GAME.md` edit → `\u002Funikit-gd-spec`\n- a lone **catalog churn** → `\u002Funikit-gd-content \u003CCT>` (it is data, not even a versioned\n  edit — there is nothing to order) · a lone **standalone create** → `\u002Funikit-gd-spec`\n  add-system (this skill does not write the roster — `unikit-gd-spec` does).\n\nA single-zone bounce is a real invocation (`## Skill calls`), not a printed suggestion.\n\n### Phase 2 — DISPATCH (ordered, one delta at a time)\n\nDispatch the resolved deltas in this **fixed order** — the carrying invariant is that\n**every system dispatch lands BEFORE any content or flow dispatch** that could depend on\nit, so the downstream owners read a fresh upstream and `unikit-gd-verify` never stale-flags\nfalsely (subtlety ① below):\n\n```\n1. GAME.md \u002F roster   → \u002Funikit-gd-spec      (content edits, and add-system for any new system a later delta needs)\n2. systems            → \u002Funikit-gd-system     (the single upstream source — always before content\u002Fflow)\n3. content types      → \u002Funikit-gd-content    (a sink of the system axis)\n4. flows              → \u002Funikit-gd-flow        (a sink of the system axis)\n```\n\n- **Create-precondition (write goes to the owner, not here).** A delta that needs a\n  **new system** — a content type's `belongs_to` \u002F `ref\u003CSYS>`, a flow's `GOAL`, or an\n  explicit \"add system X and then change Y\" — is dispatched as a `unikit-gd-spec`\n  **add-system** in the **first (spec) tier**, *before* the dependent revise. That yields\n  \"create + dependent revise in one pass\". The roster write is **gd-spec's**; this skill\n  only sequences it. A standalone create with no other delta does not reach here — GATE 2\n  bounced it.\n- **Content ↔ flow order is staleness-neutral** (both are sinks of systems; neither\n  stales the other) — it is fixed `content → flow` purely for **determinism** (subtlety\n  ⑤). What matters is only that both follow every system dispatch.\n- **One delta at a time.** Invoke the owner (`## Skill calls`), let it run its full cycle\n  (Context → Options → approval → write → delta tail → `[gen]` re-render), wait for it to\n  return, then dispatch the next. Each owner records its own version bump \u002F changelog and\n  re-renders its own `[gen]` map — this skill touches none of that.\n- **Carry the review-finding id.** When a delta came from a review file's apply-ready\n  bucket, pass its `RF-\u003Cdate>-n` with the delta to the owner so the owner cites the\n  finding in its changelog essence — the same provenance review-finding → changelog a\n  direct `unikit-gd-system` edit records. Typed \u002F verify-prose deltas with no id carry none.\n- **A delta the owner bounces** (e.g. a flow whose `GOAL` crosses into a missing system,\n  surfaced mid-dispatch) re-enters Phase 1 as a new system delta slotted into the spec\n  tier; re-order and continue.\n\n### Phase 3 — VERIFY (one sentinel pass, last)\n\nAfter **every** delta has been dispatched and its owner has returned, run **one**\nconsistency pass: invoke `unikit-gd-verify` with the argument `apply-phase3` — the reserved\n**loop-guard sentinel**, NOT a scope.\n\n`apply-phase3` is **not** a scope or an id list — it is the one reserved token that tells\n`unikit-gd-verify` this run is apply's closing Phase 3. verify recognises it,\n**suppresses** its standalone handoff offer\u002Finterview (so `apply → verify → apply` cannot\nloop), and derives its own changed-scope from the unverified design diff exactly as a bare\ncall would (changed-scope impact across the just-touched systems, flows, and content types;\notherwise a full check). Do **not** construct a union list of the touched ids and pass it\ninstead — `apply-phase3` is the only argument gd-apply ever passes here. This call follows the same recipe as a dispatch (`## Skill calls`).\n\n## Content-axis subtleties\n\nThe content zone is the **fourth** authoring zone, **isomorphic to flow** and, like flow,\na **sink** of the system axis. These five points govern how this skill orders and routes\ncontent deltas:\n\n1. **Content is a sink, never a source.** The change graph is\n   `GAME.md (vision) → systems (the single source) → { content, flows } (sinks)`.\n   Cross-axis staleness is **one-way** — a system edit stales the content types and flows\n   that depend on it (`SYS → CT`, `SYS → FLOW`); the reverse never holds. That is the whole\n   reason systems dispatch **before** content and flows (Phase 2).\n2. **Churn vs schema is the owner's call, not the dispatcher's.** This skill resolves\n   `(target = CT, zone = unikit-gd-content)` and hands over the raw delta; **`unikit-gd-content`\n   classifies** catalog churn (data — no version bump) vs a schema revise (a versioned code\n   contract). A lone pure churn never reaches dispatch — GATE 2 bounces it straight to\n   `\u002Funikit-gd-content`.\n3. **Churn does not clear a cross-axis stale-mark** — only a schema revise does. That is\n   correct and **not this skill's concern**: the stale-marks are `unikit-gd-verify`'s, set\n   and cleared in the final pass, never by the dispatcher.\n4. **Content's create-precondition mirrors flow's.** A content delta whose `belongs_to` \u002F\n   `ref\u003CSYS>` needs a **missing system** routes through `unikit-gd-spec` add-system in the\n   first tier (create + dependent schema revise in one pass) — exactly like a flow `GOAL`\n   that needs a missing system. gd-apply sequences it; gd-spec writes the roster.\n5. **Content ↔ flow order is fixed for determinism.** Because neither stales the other, the\n   `content → flow` order is a convention (reproducibility), not a correctness edge — only\n   the system-before-sinks edge is load-bearing.\n\n## Ownership Boundaries\n\n- **Owns:** **nothing** — no document, no registry fact, no `[gen]` render, no status or\n  version. This skill's only product is the **ordering and delegation** of a multi-zone\n  edit batch plus the single closing verify. There is deliberately **no `Write`\u002F`Edit`** in\n  `allowed-tools`: gd-apply *cannot* write the GDD, only route to the owners that can.\n- **Not this skill (every write):** `GAME.md` content + the system roster (add-system) →\n  `unikit-gd-spec`; a system's A–K doc → `unikit-gd-system`; a content type's schema +\n  catalog → `unikit-gd-content`; a flow's doc → `unikit-gd-flow`; consistency & cross-axis\n  impact → `unikit-gd-verify`; quality verdicts → `unikit-gd-review`; research \u002F open\n  questions → `unikit-gd-explore`.\n- **Never:** write or edit any GDD file or `GD-IDS.yaml` directly; classify a content delta\n  as churn vs schema (the owner does); pre-decide an edit scale (Tuning\u002FTweak\u002FRework);\n  dispatch content or a flow **before** the system it depends on; dispatch in parallel;\n  pass a union of ids to `unikit-gd-verify` (pass only the `apply-phase3` loop-guard\n  sentinel); act on the `## Research` bucket of a review file (that is `unikit-gd-explore`'s\n  job); print the `Run:` list when an inline invocation is possible; read the code workspace\n  or project source.\n\n## Quick Reference\n\n```\n\u002Funikit-gd-apply                                  → session mode: read the last \u002Funikit-gd-verify output → lift its\n                                                    apply-ready deltas → dispatch to owners → verify \"apply-phase3\";\n                                                    no recent verify deltas → softly recommend \u002Funikit-gd-verify first\n\u002Funikit-gd-apply reviews\u002F2026-06-25_review-SYS-combat.md\n                                                  → read the file's ## Apply-ready bucket → dispatch each entailed\n                                                    fix to its owner (carrying its RF-id) → verify \"apply-phase3\";\n                                                    the ## Research bucket → recommend \u002Funikit-gd-explore\n\u002Funikit-gd-apply \"buff combat damage 10%, add a rarity field to loot, retune onboarding pacing\"\n                                                  → 3 deltas across 3 zones: dispatch SYS-combat (system) →\n                                                    CT-loot schema (content) → FLOW-onboarding (flow) → verify\n\u002Funikit-gd-apply \"add a crafting system and a recipe content type that belongs_to it\"\n                                                  → create-precondition: gd-spec add-system SYS-crafting (first) →\n                                                    gd-content CT-recipe (belongs_to SYS-crafting) → verify\n\u002Funikit-gd-apply \"raise the damage by 10%\"        → single zone → bounce to \u002Funikit-gd-system SYS-combat\n\u002Funikit-gd-apply \"add three more sword cards\"     → lone catalog churn → bounce to \u002Funikit-gd-content CT-card\n\u002Funikit-gd-apply \"work out a better economy\"      → open question → route to \u002Funikit-gd-explore first\n```\n","# Game Design — Multi-Zone Edit Dispatcher\n\nApply **a set of explicit, user-dictated edits that crosses more than one zone of the\nGDD** — the master spec (`GAME.md` + roster), systems, content types, and flows — in a\nsingle ordered pass. This skill is a **dispatcher, not an author**: it owns **nothing**\nand writes **nothing**. For each delta it resolves the `(target, zone)`, orders the set\nso the change graph stays causally fresh, hands each delta to the zone that owns it\n(`unikit-gd-spec` \u002F `unikit-gd-system` \u002F `unikit-gd-content` \u002F `unikit-gd-flow`), and\ncloses with **one** consistency pass (`unikit-gd-verify`). The actual writing — sections,\nregistry facts, version bumps, `[gen]` re-renders — happens **inside the owner skills**,\nunder their collaborative protocol and delta discipline; this skill never bypasses it.\n\n**Three input shapes.** (1) **No argument** — the bare `\u002Funikit-gd-apply` reads the\n**last `unikit-gd-verify` output in this session** (free-text prose, no fence) and lifts\nits apply-ready deltas; this is verify's handoff path (verify ends on a bare\n`\u002Funikit-gd-apply`). (2) **Prose deltas** typed directly as the argument. (3) A\n**`unikit-gd-review` report file** (`reviews\u002F*_review-*.md`) — this skill reads the file's\n**`## Apply-ready`** bucket as the delta set (the **`## Research`** bucket is\n`unikit-gd-explore`'s job, not this skill's). All three flow through the same routing,\nordering, and closing verify below. If the bare call finds no recent verify deltas in the\nsession, it does nothing destructive — it softly recommends running `\u002Funikit-gd-verify`\nfirst.\n\n**When NOT to use it.** A change confined to **one** zone goes **straight to that owner**\n— there is nothing to dispatch (Phase 1, GATE 2). A change you **do not yet know how to\ndesign** (an open question, a mechanic to research, a balance to work out) goes to\n`unikit-gd-explore` **first** — this skill only carries out edits you have already decided\n(Phase 1, GATE 1).\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` and\napply it to all output (fall back to English if it is missing) — including the rule to\n**translate concepts, not transliterate jargon**. `gd-principles` → \"Language\" adds the\ngame-design specifics: which IDs and stored field values stay English (the owner skills\nre-apply it on every delegated write). 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. This skill loads **only routing context**, never domain\nrules (it authors nothing, so there is no system\u002Fflow\u002Fcontent to balance):\n\n1. **`.unikit\u002Fsystem\u002Fgamedesign\u002Fgd-principles.md`** (the core) — the **Zone Ownership\n   model + routing** (which zone owns what, the one-way boundary, the single sanctioned\n   `implemented` code→design write) and the facts-registry \u002F ID conventions. Plus, from\n   the same `gamedesign\u002F` folder, the two shards this skill needs to **order** a\n   dispatch: **`gd-authoring.md`** (the **delta discipline** — so it knows a schema \u002F\n   approved-content edit is a versioned delta the owner must record, and catalog churn is\n   not) and **`gd-lifecycle.md`** (the **lifecycle & status spine + cross-axis\n   staleness** — so it knows a system edit stales the content \u002F flows that depend on it,\n   which fixes the dispatch order). This skill **applies** these contracts to sequence the\n   work; it does **not** restate or perform the authoring mechanics. If missing, warn\n   (`unikit-ai update`) and fall back to the ordering summarized in this file.\n2. **`.unikit\u002Fgamedesign\u002FGD-IDS.yaml`** — the registry, read-only here: the `systems`,\n   `flows`, `content_types`, and their `depends_on` \u002F `belongs_to` edges, used to resolve\n   each delta's `(target, zone)` and to detect a delta that needs a **not-yet-registered**\n   system (the create-precondition). If it does not exist, **stop** — there is no design\n   to edit; route to `\u002Funikit-gd-spec` (or `\u002Funikit-gd-brainstorm` first) and stop.\n3. **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 workspace is\n   on the pre-v2 layout (the standalone markdown system-index was dropped; the maps now\n   render into `GAME.md`); there is no automatic migration — tell the user to upgrade via\n   `\u002Funikit-gd-spec` before re-running.\n\n**One-way boundary:** never read `.unikit\u002Fcode\u002F`, project source, or build artifacts\n(`gd-principles` → One-Way Boundary). This skill does not load `RULES_INDEX.md` domain\nrules — it dispatches, it does not design.\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 and not a delegation. Each delta is handed to its zone owner (`unikit-gd-\u003Czone>`; **not** a subagent — a read-only `Agent` could not write the GDD) **inline, one at a time, in the Phase 2 order**, waiting for each to return before starting the next — **never in parallel** (the order is the correctness guarantee). The owner runs its full interactive cycle in the main session, so its collaborative protocol, approvals and writes all hold, and returns control here. A call site that names no argument passes none. Printing the list of `\u002Funikit-gd-*` commands for the user to run, instead of making the calls, is a known failure mode here: every zone is an actual call.\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## Pipeline — ROUTING → DISPATCH → VERIFY\n\n### Phase 1 — ROUTING (resolve every delta → `(target, zone)`)\n\n**Input-mode resolution (first).** Resolve which of the three input shapes this run is:\n\n- **No argument (bare `\u002Funikit-gd-apply`)** → **session mode**. Read the **last\n  `unikit-gd-verify` output in this session** — its printed apply-ready deltas (free-text\n  prose, each citing a `target` + `zone`, no fence) — and lift those deltas as the set,\n  then continue below. If the session carries **no** recent verify output with apply-ready\n  deltas (a fresh session, a `\u002Fclear` since the verify run, or a clean verify PASS), do\n  **nothing destructive** — softly recommend `🔍 \u002Funikit-gd-verify` first and stop. (The\n  verify → apply pair is single-session by design; a `\u002Fclear` between them is fixed by\n  re-running verify — cheap.)\n- **Argument resolves to an existing `reviews\u002F*_review-*.md` path** (the durable handoff\n  from `unikit-gd-review`) → read it and take its **`## Apply-ready`** bucket as the delta\n  set: each apply-ready line is one decided edit carrying an `RF-\u003Cdate>-n` id and a named\n  `Fix (entailed)`. The **`## Research`** bucket is **ignored** here — it is\n  `unikit-gd-explore`'s input, not this skill's. An **empty** apply-ready bucket is a valid\n  input: there is nothing to dispatch — report it and stop, recommending\n  `\u002Funikit-gd-explore \u003Cfile>` for the research bucket.\n- **Any other argument** — including **inline prose deltas** typed directly — is the\n  literal change request, taken as prose.\n\n(The file reader is the **only** review-specific adapter; the no-arg session path + the\nprose path are what keep verify's bare-call handoff working — verify writes no file.)\n\nSplit the request into individual deltas. For each, resolve the **target** (a `SYS-`\u002F\n`CT-`\u002F`FLOW-` id or `GAME.md`) and the **zone** that owns it:\n\n| The delta is… | Target | Zone owner |\n|---------------|--------|------------|\n| a `GAME.md` content edit (pillar, win\u002Flose intent, monetization stance, loop stack) | `GAME.md` | `unikit-gd-spec` |\n| a **new system** added to the map | the roster | `unikit-gd-spec` (add-system) |\n| a system's rules \u002F numbers \u002F formulas \u002F AC | `SYS-\u003Cslug>` | `unikit-gd-system` |\n| a content type's schema (a field, a type, the scale, a `ref\u003C>`, `belongs_to`) | `CT-\u003Cslug>` | `unikit-gd-content` |\n| catalog churn (add\u002Fremove units, a `bulk` count) | `CT-\u003Cslug>` | `unikit-gd-content` |\n| a flow's objectives \u002F pacing \u002F dependencies \u002F events \u002F wiring mode | `FLOW-\u003Cslug>` | `unikit-gd-flow` |\n\nThe dispatcher is **dumb on purpose**: it resolves `(target, zone)` and hands the raw\ndelta to the owner — it does **not** pre-classify Tuning vs Tweak vs Rework, schema vs\nchurn, or create vs revise. Each owner makes that call under its own contract (subtlety\n② below).\n\n**GATE 1 — explicit-edit only (else → `unikit-gd-explore`).** Every delta must be a\n**concrete change the user has already decided**. A delta that is an open question, needs\nresearch, or is \"work out how to…\" is **not** an apply job — route it to\n`\u002Funikit-gd-explore` (research first, then come back with the decided edit). If the\nrequest mixes the two, dispatch the decided deltas and hand the open one to explore;\nannounce the split. This skill never researches.\n\n**GATE 2 — multi-zone only (else → the single owner).** The resolved set must touch\n**two or more zones** (or be a genuine multi-delta job). A request that resolves to a\n**single zone** has nothing to dispatch — **bounce it to that owner directly** and stop:\n\n- one system edit → `\u002Funikit-gd-system \u003CSYS>` · one schema edit → `\u002Funikit-gd-content \u003CCT>`\n- one flow edit → `\u002Funikit-gd-flow \u003CFLOW>` · one `GAME.md` edit → `\u002Funikit-gd-spec`\n- a lone **catalog churn** → `\u002Funikit-gd-content \u003CCT>` (it is data, not even a versioned\n  edit — there is nothing to order) · a lone **standalone create** → `\u002Funikit-gd-spec`\n  add-system (this skill does not write the roster — `unikit-gd-spec` does).\n\nA single-zone bounce is a real invocation (`## Skill calls`), not a printed suggestion.\n\n### Phase 2 — DISPATCH (ordered, one delta at a time)\n\nDispatch the resolved deltas in this **fixed order** — the carrying invariant is that\n**every system dispatch lands BEFORE any content or flow dispatch** that could depend on\nit, so the downstream owners read a fresh upstream and `unikit-gd-verify` never stale-flags\nfalsely (subtlety ① below):\n\n```\n1. GAME.md \u002F roster   → \u002Funikit-gd-spec      (content edits, and add-system for any new system a later delta needs)\n2. systems            → \u002Funikit-gd-system     (the single upstream source — always before content\u002Fflow)\n3. content types      → \u002Funikit-gd-content    (a sink of the system axis)\n4. flows              → \u002Funikit-gd-flow        (a sink of the system axis)\n```\n\n- **Create-precondition (write goes to the owner, not here).** A delta that needs a\n  **new system** — a content type's `belongs_to` \u002F `ref\u003CSYS>`, a flow's `GOAL`, or an\n  explicit \"add system X and then change Y\" — is dispatched as a `unikit-gd-spec`\n  **add-system** in the **first (spec) tier**, *before* the dependent revise. That yields\n  \"create + dependent revise in one pass\". The roster write is **gd-spec's**; this skill\n  only sequences it. A standalone create with no other delta does not reach here — GATE 2\n  bounced it.\n- **Content ↔ flow order is staleness-neutral** (both are sinks of systems; neither\n  stales the other) — it is fixed `content → flow` purely for **determinism** (subtlety\n  ⑤). What matters is only that both follow every system dispatch.\n- **One delta at a time.** Invoke the owner (`## Skill calls`), let it run its full cycle\n  (Context → Options → approval → write → delta tail → `[gen]` re-render), wait for it to\n  return, then dispatch the next. Each owner records its own version bump \u002F changelog and\n  re-renders its own `[gen]` map — this skill touches none of that.\n- **Carry the review-finding id.** When a delta came from a review file's apply-ready\n  bucket, pass its `RF-\u003Cdate>-n` with the delta to the owner so the owner cites the\n  finding in its changelog essence — the same provenance review-finding → changelog a\n  direct `unikit-gd-system` edit records. Typed \u002F verify-prose deltas with no id carry none.\n- **A delta the owner bounces** (e.g. a flow whose `GOAL` crosses into a missing system,\n  surfaced mid-dispatch) re-enters Phase 1 as a new system delta slotted into the spec\n  tier; re-order and continue.\n\n### Phase 3 — VERIFY (one sentinel pass, last)\n\nAfter **every** delta has been dispatched and its owner has returned, run **one**\nconsistency pass: invoke `unikit-gd-verify` with the argument `apply-phase3` — the reserved\n**loop-guard sentinel**, NOT a scope.\n\n`apply-phase3` is **not** a scope or an id list — it is the one reserved token that tells\n`unikit-gd-verify` this run is apply's closing Phase 3. verify recognises it,\n**suppresses** its standalone handoff offer\u002Finterview (so `apply → verify → apply` cannot\nloop), and derives its own changed-scope from the unverified design diff exactly as a bare\ncall would (changed-scope impact across the just-touched systems, flows, and content types;\notherwise a full check). Do **not** construct a union list of the touched ids and pass it\ninstead — `apply-phase3` is the only argument gd-apply ever passes here. This call follows the same recipe as a dispatch (`## Skill calls`).\n\n## Content-axis subtleties\n\nThe content zone is the **fourth** authoring zone, **isomorphic to flow** and, like flow,\na **sink** of the system axis. These five points govern how this skill orders and routes\ncontent deltas:\n\n1. **Content is a sink, never a source.** The change graph is\n   `GAME.md (vision) → systems (the single source) → { content, flows } (sinks)`.\n   Cross-axis staleness is **one-way** — a system edit stales the content types and flows\n   that depend on it (`SYS → CT`, `SYS → FLOW`); the reverse never holds. That is the whole\n   reason systems dispatch **before** content and flows (Phase 2).\n2. **Churn vs schema is the owner's call, not the dispatcher's.** This skill resolves\n   `(target = CT, zone = unikit-gd-content)` and hands over the raw delta; **`unikit-gd-content`\n   classifies** catalog churn (data — no version bump) vs a schema revise (a versioned code\n   contract). A lone pure churn never reaches dispatch — GATE 2 bounces it straight to\n   `\u002Funikit-gd-content`.\n3. **Churn does not clear a cross-axis stale-mark** — only a schema revise does. That is\n   correct and **not this skill's concern**: the stale-marks are `unikit-gd-verify`'s, set\n   and cleared in the final pass, never by the dispatcher.\n4. **Content's create-precondition mirrors flow's.** A content delta whose `belongs_to` \u002F\n   `ref\u003CSYS>` needs a **missing system** routes through `unikit-gd-spec` add-system in the\n   first tier (create + dependent schema revise in one pass) — exactly like a flow `GOAL`\n   that needs a missing system. gd-apply sequences it; gd-spec writes the roster.\n5. **Content ↔ flow order is fixed for determinism.** Because neither stales the other, the\n   `content → flow` order is a convention (reproducibility), not a correctness edge — only\n   the system-before-sinks edge is load-bearing.\n\n## Ownership Boundaries\n\n- **Owns:** **nothing** — no document, no registry fact, no `[gen]` render, no status or\n  version. This skill's only product is the **ordering and delegation** of a multi-zone\n  edit batch plus the single closing verify. There is deliberately **no `Write`\u002F`Edit`** in\n  `allowed-tools`: gd-apply *cannot* write the GDD, only route to the owners that can.\n- **Not this skill (every write):** `GAME.md` content + the system roster (add-system) →\n  `unikit-gd-spec`; a system's A–K doc → `unikit-gd-system`; a content type's schema +\n  catalog → `unikit-gd-content`; a flow's doc → `unikit-gd-flow`; consistency & cross-axis\n  impact → `unikit-gd-verify`; quality verdicts → `unikit-gd-review`; research \u002F open\n  questions → `unikit-gd-explore`.\n- **Never:** write or edit any GDD file or `GD-IDS.yaml` directly; classify a content delta\n  as churn vs schema (the owner does); pre-decide an edit scale (Tuning\u002FTweak\u002FRework);\n  dispatch content or a flow **before** the system it depends on; dispatch in parallel;\n  pass a union of ids to `unikit-gd-verify` (pass only the `apply-phase3` loop-guard\n  sentinel); act on the `## Research` bucket of a review file (that is `unikit-gd-explore`'s\n  job); print the `Run:` list when an inline invocation is possible; read the code workspace\n  or project source.\n\n## Quick Reference\n\n```\n\u002Funikit-gd-apply                                  → session mode: read the last \u002Funikit-gd-verify output → lift its\n                                                    apply-ready deltas → dispatch to owners → verify \"apply-phase3\";\n                                                    no recent verify deltas → softly recommend \u002Funikit-gd-verify first\n\u002Funikit-gd-apply reviews\u002F2026-06-25_review-SYS-combat.md\n                                                  → read the file's ## Apply-ready bucket → dispatch each entailed\n                                                    fix to its owner (carrying its RF-id) → verify \"apply-phase3\";\n                                                    the ## Research bucket → recommend \u002Funikit-gd-explore\n\u002Funikit-gd-apply \"buff combat damage 10%, add a rarity field to loot, retune onboarding pacing\"\n                                                  → 3 deltas across 3 zones: dispatch SYS-combat (system) →\n                                                    CT-loot schema (content) → FLOW-onboarding (flow) → verify\n\u002Funikit-gd-apply \"add a crafting system and a recipe content type that belongs_to it\"\n                                                  → create-precondition: gd-spec add-system SYS-crafting (first) →\n                                                    gd-content CT-recipe (belongs_to SYS-crafting) → verify\n\u002Funikit-gd-apply \"raise the damage by 10%\"        → single zone → bounce to \u002Funikit-gd-system SYS-combat\n\u002Funikit-gd-apply \"add three more sword cards\"     → lone catalog churn → bounce to \u002Funikit-gd-content CT-card\n\u002Funikit-gd-apply \"work out a better economy\"      → open question → route to \u002Funikit-gd-explore first\n```\n",{"name":5,"metadata":57,"description":7,"allowed-tools":61,"argument-hint":71,"user-invocable":72,"disable-model-invocation":53},{"author":58,"version":59,"category":60},"unikit","1.0","game-design",[62,63,64,65,66,67,68,69,70],"Read","Glob","Grep","Bash(ls *)","Bash(find *)","Bash(wc *)","Bash(date *)","AskUserQuestion","Skill","[ \"\u003Cchanges>\" | \u003Creviews\u002F*_review-*.md> ]  (bare = read last \u002Funikit-gd-verify output in session; apply-ready bucket | prose deltas → zone owners; no flags)",true,"main","ae3c6dfffd26d9b45b9d96d71ba2c122c50b67ae","skills\u002Funikit-gd-apply",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":83,"prompt":93,"zipAvailable":72},[84,87,90],{"tool":85,"command":86},"npx","npx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-apply",{"tool":88,"command":89},"bunx","bunx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-apply",{"tool":91,"command":92},"pnpm","pnpm dlx skills add NintendaDev\u002Funikit-ai --skill unikit-gd-apply","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-gd-apply\u002FSKILL.md",[],[96,120,143,164,183,209],{"skillNo":97,"name":58,"nameZh":6,"description":98,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":99,"categories":100,"keywords":102,"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",[101],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[58,103,104,105,106,107,108,109,110,41,40,111,112,113,114,115,116,117,118,119],"project","time","actions","fix","documents","architecture","stack","run","write","config","edit","git","context","initialize","tech","scan","use",{"skillNo":121,"name":122,"nameZh":6,"description":123,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":124,"categories":125,"keywords":130,"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",[126,129],{"categoryNo":127,"categoryName":128,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[131,132,133,134,135,136,110,40,111,113,114,37,36,119,137,138,139,140,141,142],"unikit verify","verify","powershell","code review","phase","plan","implement","check","engine","research","name","quality",{"skillNo":144,"name":145,"nameZh":6,"description":146,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":147,"categories":148,"keywords":149,"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",[],[150,151,152,153,103,154,155,156,44,157,158,159,136,160,161,162,40,111,113,163],"unikit todo","todo","remind","show","todo list","only","now","done","tasks","work","me","reminders","later","act",{"skillNo":165,"name":166,"nameZh":6,"description":167,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":168,"categories":169,"keywords":171,"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",[170],{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[172,115,103,106,173,174,175,176,177,178,179,180,151,42,181,110,182,40,111,113],"unikit skills context","coding conventions","writing","when","workflow","commit","review","general coding","text","how","past",{"skillNo":184,"name":185,"nameZh":6,"description":186,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":187,"categories":188,"keywords":196,"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",[189,192,195],{"categoryNo":190,"categoryName":191,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":193,"categoryName":194,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},[197,198,199,200,103,201,202,203,204,205,108,206,180,207,109,162,40,111,113,208],"Rules","unikit rules","quick","PDF","clean","knowledge","files","URL","migrate","batch","knowledge base","prune",{"skillNo":210,"name":211,"nameZh":6,"description":212,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":213,"categories":214,"keywords":215,"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",[],[216,197,217,218,103,219,202,220,205,221,41,40,111,114,222,223,224,225,226,227],"registry","unikit rules registry","shared","local","remote","create","ai rules","automatic","semver","knowledge-base","as","three"]