[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BNR70M0ZSWMZAZ4BB2ZHV":3,"skill-same:01M71BNR70M0ZSWMZAZ4BB2ZHV":96},{"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":26,"publishedAt":47,"linkOnly":48,"markdownContent":49,"markdownBody":50,"frontMatter":51,"refName":63,"commitSha":64,"skillDirectory":65,"forksCount":66,"repositoryHtmlUrl":67,"repositoryHomepageUrl":68,"ownerHtmlUrl":69,"ownerBlogUrl":6,"ownerDescription":70,"updatedAt":71,"install":72,"resources":85},"01M71BNR70M0ZSWMZAZ4BB2ZHV","unikit-review",null,"Perform a code review on {{engine_name}} {{engine_code_language}} code. Checks for bugs, security issues, performance problems, and best practices against the project's coding rules, design principles, and framework-specific conventions. Supports four modes — staged changes, a pull request, a commit range, or individual files. Use when the user says \"review code\", \"check my code\", \"code review\", \"review PR\", \"review staged changes\", \"review these commits\", or \"is this code okay\". Optional +check flag validates findings via a fresh-context subagent.","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-review\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",[27,28,29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46],"review","unikit review","review pr","modes","for","commits","context","coding","security","git","read","fresh","subagent","framework-specific","number","files","design","code review","project","branch","2026-11-10 10:12:30",false,"---\nname: unikit-review\ndescription: Perform a code review on {{engine_name}} {{engine_code_language}} code. Checks for bugs, security issues, performance problems, and best practices against the project's coding rules, design principles, and framework-specific conventions. Supports four modes — staged changes, a pull request, a commit range, or individual files. Use when the user says \"review code\", \"check my code\", \"code review\", \"review PR\", \"review staged changes\", \"review these commits\", or \"is this code okay\". Optional +check flag validates findings via a fresh-context subagent.\nargument-hint: \"[+check] [script.cs ... | @folder ... | PR number | branch\u002Fcommit\u002Ftag | empty]\"\nallowed-tools:\n  - Read\n  - Grep\n  - Glob\n  - Bash(find *)\n  - Bash(wc *)\n  - Bash(git *)\n  - Bash(gh *)\n  - Agent\n  - AskUserQuestion\n---\n\n# {{engine_name}} Code Reviewer\n\nAnalyze {{engine_code_language}} code against the project's coding rules and produce a structured review report.\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 its rules to ALL subsequent output.\nIf the file is missing or unreadable, fall back to English.\nDo not produce any user-facing output until language rules are loaded.\nDo not announce, confirm, or mention 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## Subagent launches\n\n**Subagent arguments.** Before the first subagent you launch, read `.unikit\u002Fsystem\u002Fsubagent-arguments.md`\nand `.unikit\u002Fconfig.yaml` once and settle the model and effort of every launch as that file says.\nKeys: `subagents.model.{{agent_id}}.\u003Crole>`, `subagents.effort.{{agent_id}}.\u003Crole>`;\nbuilt-in model of a reader and a validator: `\"{{agent_model_default}}\"`, of an executor: none.\nIf the file cannot be read, print\n`WARN [delegation] subagent-arguments contract missing — built-in model tier used, effort not passed`\nand use that model, no effort.\n\nIt covers every subagent of this review, with `+check` or without it: the `check-agent` below, and also\none you start yourself, such as a reviewer over part of a large diff, which no step here names.\nStart that one with the call head of `check-agent` below (it is read-only); its role is the\n`\u002Funikit-review` reviewers row of the roles table, and its model and effort are settled the same way.\n\n## Delegation agents\n\nThis skill uses a named delegation alias for `Agent(...)` calls. The alias is the single\nplace where its delegate's agent type and call arguments are declared — call sites name\nthe alias and never carry a type or a model argument of their own.\n\n- **`check-agent`** — fresh-context, read-only findings validator (`+check`). Expands to:\n\n  ```\n  Agent({{agent_call_reader}} prompt: \"\u003Crendered VALIDATOR.md template>\")\n  ```\n\n  Whether the agent is read-only is this runtime's own claim, so the read-only contract\n  rides on the prompt rather than on the dispatch: keep `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FVALIDATOR.md`'s\n  read-only paragraph (\"You never modify a file and never run a command that changes state\") in whatever is sent.\n\n  Fallback: the validator is **never** replaced by inline analysis — see\n  `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FCHECK-MODE.md` (`WARN [+check]: validator failed`).\n\n## Step 1: Load rules\n\nRead (they always apply):\n- `.unikit\u002FARCHITECTURE.md` — module boundaries, dependency rules. **Architecture topics:** the root always; then the topic files listed under its `## Topics` whose `Load when` matches a reviewed file — its path, type or area (Step 3); when unsure, load. A listed file that is missing → `WARN [architecture] topic file missing: .unikit\u002Farchitecture\u002F\u003Cslug>.md`, continue.\n- `.unikit\u002FROADMAP.md` (if present) — milestone alignment\n- `.unikit\u002Fsystem\u002Fgate-result-contract.md` — schema for the machine-readable `unikit-gate-result` block emitted in Step 5. If missing or unreadable, do not block: the Step 5 gate-result section is self-sufficient on the schema and degrades gracefully (see there).\n\nRead `.unikit\u002Fmemory\u002Fcode\u002FRULES_INDEX.md`. Load rules:\n- **RULES.md**: ALWAYS read `.unikit\u002FRULES.md` first (highest priority). **Rule topics:** the root here; its topic files load in Step 3, by the reviewed files.\n- **Core**: read the Core table. For EACH row where Required By = `all` or contains `{{self_name}}` — read that file from `.unikit\u002Fmemory\u002Fcode\u002Fcore\u002F` using the Read tool. Do NOT skip any matching row. Always re-read at skill start, never rely on prior conversation cache\n- **Stack**: load dynamically when the current task or context matches \"Load When\" column, or when a need arises during work\n\nRead `.unikit\u002Fskill-context\u002F{{self_name}}\u002FSKILL.md` if it exists — project-level overrides that win over this SKILL.md when conflicting.\n\n**The review is of work on a plan whose manifest has `## Experiment Context`** (the session started from such a plan, or the prompt carries a `Prototype plan:` note) → read `.unikit\u002Fsystem\u002Fprototype-profile.md` and follow its `## Role: quality and the rest` for the whole review. Missing or unreadable → `WARN [prototype] profile contract missing — reviewing as for an ordinary plan; run unikit-ai update`.\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n## Step 2: Route argument and get code\n\n**Parse `+check` first.** If `$ARGUMENTS` contains the `+check` token, strip it out (remember `check = true`) before running the routing chain below, so it is never mistaken for a file path or git ref. `+check` enables the fresh-context findings validator in Step 4.5; without it, that step is skipped entirely.\n\n### Routing chain\n\n1. **Empty** → Staged mode\n2. **Digits \u002F `#N` \u002F PR URL** (e.g. `123`, `#42`, `https:\u002F\u002Fgithub.com\u002F...\u002Fpull\u002F123`) → PR mode. Extract number from URL if needed\n3. **Starts with `@`** → File mode (folder). Strip `@`, glob `\u003Cpath>\u002F**\u002F*.cs`\n4. **Contains `.cs`** → File mode (explicit files)\n5. **Other** → `git rev-parse --verify \u003Carg>`:\n   - Valid → Commits mode\n   - Invalid → the question tool of your agent (`AskUserQuestion`) (staged \u002F cancel \u002F corrected ref)\n\n> `@` disambiguates folder paths from git refs with `\u002F`.\n\n### Staged mode\n\n1. `git diff --cached` → if empty, `git diff` → if empty, inform and **stop**\n2. Extract changed `.cs` files, read full content for stack rule detection\n\n### PR mode\n\n1. `gh pr view \u003CN> --json title,body,baseRefName,headRefName,files`\n2. `gh pr diff \u003CN>`\n3. Extract changed `.cs` files, read full content for stack rule detection\n\n### Commits mode\n\n1. Validate ref via `git rev-parse --verify`. Invalid → ask user\n2. `git log --oneline --reverse \u003Cref>..HEAD` → if empty, inform and **stop**\n3. If >20 commits → the question tool of your agent (`AskUserQuestion`) (all \u002F last 20 \u002F cancel)\n4. `git diff --name-only \u003Cref>..HEAD -- '*.cs'` → read full content for stack rule detection\n5. For each commit: `git show \u003Chash> --stat` and `git show \u003Chash>`\n\n### File mode\n\n- `.cs` args: locate via `Glob`\u002F`find`. Name without path → search entire project\n- `@folder` args: `Glob \u003Cfolder>\u002F**\u002F*.cs`. No results → report error, continue with others\n- Read full content of all found files for stack rule detection\n\n## Step 3: Load stack rules\n\nNow that target code is available, scan it for framework markers from the **Stack** section of `RULES_INDEX.md`. Each entry lists which keywords\u002Ftypes indicate relevance (\"Load When\" column). Load only matching rule files. If no markers match — skip stack rules entirely.\n\n**Rule topics.** In the same pass, load the topic files listed under `## Topics` in `.unikit\u002FRULES.md` **and in `.unikit\u002FARCHITECTURE.md`** whose `Load when` matches the reviewed files — their paths, types, area; when unsure, load (`RULES_INDEX.md` → Step 1). They apply in Step 4 together with the root's rules.\n\n## Step 4: Analyze\n\nApply **all loaded rules** (core + stack + project + the ARCHITECTURE.md root and its loaded topics) uniformly, regardless of mode.\n\nFor each file or diff hunk, check:\n- **Rule violations** — every loaded rule against the code\n- **Architecture alignment** — boundary\u002Fdependency violations (e.g. `Modules\u002F → Game\u002F` forbidden)\n- **Roadmap linkage** — for `feat`\u002F`fix`\u002F`perf` work, missing ROADMAP.md milestone link (suggestion only)\n- **Removed code** (diff modes) — broken contracts, dangling references\n\n**Commits mode only** — additionally per commit:\n- **Message accuracy** — does the message match the actual changes?\n- **Atomicity** — single logical unit, or mixed concerns?\n\n### Severity scale\n\n- 🔴 **Critical** — must fix (crashes, silent failures, memory leaks, data corruption)\n- 🟡 **Warning** — likely to cause bugs under specific conditions\n- 🟠 **Medium** — performance, code smell, maintainability\n- 🟢 **Suggestion** — quality improvement\n\nRecord exact line numbers (or commit hash + file:line for diff modes) and relevant code snippets.\n\n### General checklist\n\nAlways run these checks in addition to project rules. If a finding from the checklist contradicts a loaded project\u002Fcore\u002Fstack rule, the ARCHITECTURE.md root or a loaded topic (i.e. the code follows project conventions) — **suppress the finding**, it is not an issue.\n\n**Correctness:**\n- [ ] Logic errors or bugs\n- [ ] Edge cases handling\n- [ ] Null\u002Fundefined checks\n- [ ] Error handling completeness\n- [ ] Type safety\n\n**Performance:**\n- [ ] Memory leaks\n- [ ] Inefficient algorithms\n- [ ] N+1 query problems\n\n**Best Practices:**\n- [ ] Code duplication\n- [ ] Dead code\n- [ ] Magic numbers\u002Fstrings\n- [ ] Proper naming conventions\n- [ ] SOLID principles\n- [ ] DRY principle\n\n**Testing** (only when tests are due: a plan with `Testing: yes`, or the user asked for them; no tests by the user's choice is not a finding, and neither are tests still waiting for acceptance):\n- [ ] Tests for new logic; none that pin tunable values or authored content\n- [ ] Edge cases of the logic tested\n- [ ] Mocking appropriateness\n\n## Step 4.5: Validate Findings (`+check` only)\n\nRun this step **only** when `check = true` (the `+check` flag was parsed in Step 2). Draft the full review internally first (all sections of Step 5, including the gate-result inputs), then — **before** rendering anything to the user — run the procedure in **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FCHECK-MODE.md`**. It dispatches one fresh-context `check-agent` validator over the **Findings table** rows (one item per row; \"Questions\", \"Positive notes\", and per-commit findings are excluded), applies each `keep`\u002F`modify`\u002F`drop` verdict and any severity move across the four levels (🔴 Critical \u002F 🟡 Warning \u002F 🟠 Medium \u002F 🟢 Suggestion), tracks the `hidden` \u002F `adjusted` \u002F `reclassified` counters, and **recomputes** the `unikit-gate-result` block (Step 5 \"Machine-readable gate result\") from the post-filter table.\n\nWhen `+check` ran successfully, append one line after all review sections and before the `unikit-gate-result` fence:\n\n```\nFiltered: N hidden, M adjusted, K reclassified by +check\n```\n\n**Fallback (do NOT inline-analyze):** if the validator agent is unavailable\u002Fblocked or the dispatch fails, keep **all** findings as drafted, do NOT recompute the gate-result block (assemble it from the unfiltered table), and emit the single line `WARN [+check]: validator failed (\u003Creason>), all items kept as-is` above the fence — never re-do the validator's work with Glob\u002FGrep\u002FRead. An unavailable validator is silently skipped; the user is never asked.\n\nIf `+check` is not set, skip this step entirely — no validator-related lines appear and the gate-result block is computed once from the full draft.\n\n## Step 5: Output\n\nAll modes use the same report structure. Mode-specific sections are marked below.\n\n```markdown\n## Code Review Summary\n\n\u003C!-- PR mode only: -->\n**PR:** #[number] — [title]\n**Base:** [baseRefName] ← **Head:** [headRefName]\n\u003C!-- Commits mode only: -->\n**Range:** `\u003Cref>..HEAD`\n**Commits Reviewed:** [count]\n\n**Files Reviewed:** [count]\n**Risk Level:** 🟢 Low \u002F 🟡 Medium \u002F 🔴 High\n**Stack rules loaded:** [list or \"none\"]\n\n\u003C!-- Commits mode only: -->\n### Per-Commit Notes\n#### `\u003Cshort-hash>` — \u003Ccommit message>\n- **Atomicity:** ✅ Good \u002F ⚠️ Mixed concerns\n- **Message accuracy:** ✅ Matches \u002F ⚠️ Misleading\n- **Issues:** [findings with severity markers, or \"None\"]\n\n### Findings\n\n| # | Severity | Location | Rule | Issue | Fix |\n|---|----------|----------|------|-------|-----|\n| 1 | 🔴\u002F🟡\u002F🟠\u002F🟢 | file:L42 | Rule ref | What's wrong | How to fix |\n\n### Code Fixes\n\n\u003C!-- For 🔴 and 🟡 findings, show: -->\n**#1 — [issue title]** (`file:L42`)\n​```csharp\n\u002F\u002F ❌ Current\n\u003Cproblematic code>\n\n\u002F\u002F ✅ Fixed\n\u003Ccorrected code>\n​```\n\n### Questions\n[Ambiguous code or design decisions that need clarification from the author]\n\n### Summary\n\n- **Critical:** [count] | **Warning:** [count] | **Medium:** [count] | **Suggestion:** [count]\n- **Top issues:** 3 most impactful to fix first\n- **Positive notes:** Good patterns observed\n```\n\n### 5.1 Machine-Readable Gate Result\n\n> **Mirror of `unikit-verify` Step 4.4** (the canonical template). This section copies that one field-for-field — the only differences are `\"gate\": \"review\"` and the projection source (the Findings table below, instead of verify's task-audit + context gates). The graceful-degradation wording and the last-fence rule are kept textually identical to verify's so a single guard locks both; if verify's wording changes, this must change in lockstep.\n\nAfter the human-readable review above, append exactly one fenced `unikit-gate-result` JSON block. Use the schema loaded from `.unikit\u002Fsystem\u002Fgate-result-contract.md` in Step 1.\n\n**Last fence wins:** the `unikit-gate-result` block MUST be the LAST fenced block in this skill's output — orchestrators parse only the last one. Any earlier fence (the example below, quoted prior output) is illustrative and is not the gate result.\n\n**Projection (review):** derive the fields from the Findings table:\n\n- `\"gate\"`: always `\"review\"`.\n- `\"status\"`:\n  - `fail` — the table has at least one **blocking** finding (🔴 Critical or 🟡 Warning).\n  - `warn` — no blocking findings, but the table has 🟠 Medium \u002F 🟢 Suggestion rows.\n  - `pass` — the table is empty (no findings).\n- `\"blocking\"`: `true` only when `status` is `fail`.\n- `\"blockers\"`: include **only** the 🔴 Critical and 🟡 Warning rows, each `{ \"id\", \"severity\", \"file\", \"summary\" }`. Use stable ids (`review-finding-\u003Crow#>`). `severity` is `error` for these blocking rows (`warning` only when policy escalates). 🟠 Medium \u002F 🟢 Suggestion rows stay in the human table, never in `blockers`.\n- `\"affected_files\"`: the files the review actually evaluated or cited (not unrelated repo files); empty array when none apply.\n- `\"suggested_next.command\"`: from the allowlist in `gate-result-contract.md` — `\u002Funikit-fix` (code must change), `\u002Funikit-rules` (a rules-gate finding needs a writer update), `\u002Funikit-architecture` (architecture drift), `\u002Funikit-roadmap` (roadmap drift), `\u002Funikit-commit` (clean — natural next step), or `null`.\n\nWhen `+check` ran (Step 4.5), this projection runs over the **post-filter** table and `suggested_next.reason` notes the `+check` counters; on `+check` whole-dispatch failure the block is assembled from the unfiltered table and is **not** recomputed.\n\n```unikit-gate-result\n{\n  \"schema_version\": 1,\n  \"gate\": \"review\",\n  \"status\": \"pass\",\n  \"blocking\": false,\n  \"blockers\": [],\n  \"affected_files\": [],\n  \"suggested_next\": {\n    \"command\": \"\u002Funikit-commit\",\n    \"reason\": \"Review found no blocking issues.\"\n  }\n}\n```\n\nThe fenced block contains JSON only — no comments, trailing commas, or prose inside it.\n\n**Graceful degradation:** if `.unikit\u002Fsystem\u002Fgate-result-contract.md` is missing or unreadable, do not hard-fail — emit the block from the inline schema in this section; if even that is not possible, skip the block and append the single line `WARN [gate-result]: contract asset unavailable`.\n\n## Guidelines\n\n- Be precise: exact line numbers and code references\n- Be actionable: every finding includes a concrete fix\n- Be complete: check ALL loaded rules\n- No false positives: if uncertain, mark \"Potential — verify manually\"\n- Clean code → say so, don't invent issues\n- Read-only: do NOT modify any files\n- Be constructive: explain \"why\", acknowledge good code\n\n## Examples\n\n`\u002Funikit-review` — review staged changes\n`\u002Funikit-review PlayerController.cs` — review specific file\n`\u002Funikit-review @Assets\u002FScripts\u002FPlayer` — review folder recursively\n`\u002Funikit-review @Assets\u002FScripts\u002FPlayer @Assets\u002FModules\u002FWallets` — review multiple folders\n`\u002Funikit-review 123` or `\u002Funikit-review #42` — review PR by number\n`\u002Funikit-review https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fpull\u002F123` — review PR by URL\n`\u002Funikit-review master` — review commits vs master\n`\u002Funikit-review v1.0.0` — review commits vs tag\n`\u002Funikit-review feature\u002Fday-loop` — review commits vs branch\n\n> **Tip:** Context is heavy after review. Consider `\u002Fclear` or `\u002Fcompact` before continuing.\n","# {{engine_name}} Code Reviewer\n\nAnalyze {{engine_code_language}} code against the project's coding rules and produce a structured review report.\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 its rules to ALL subsequent output.\nIf the file is missing or unreadable, fall back to English.\nDo not produce any user-facing output until language rules are loaded.\nDo not announce, confirm, or mention 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## Subagent launches\n\n**Subagent arguments.** Before the first subagent you launch, read `.unikit\u002Fsystem\u002Fsubagent-arguments.md`\nand `.unikit\u002Fconfig.yaml` once and settle the model and effort of every launch as that file says.\nKeys: `subagents.model.{{agent_id}}.\u003Crole>`, `subagents.effort.{{agent_id}}.\u003Crole>`;\nbuilt-in model of a reader and a validator: `\"{{agent_model_default}}\"`, of an executor: none.\nIf the file cannot be read, print\n`WARN [delegation] subagent-arguments contract missing — built-in model tier used, effort not passed`\nand use that model, no effort.\n\nIt covers every subagent of this review, with `+check` or without it: the `check-agent` below, and also\none you start yourself, such as a reviewer over part of a large diff, which no step here names.\nStart that one with the call head of `check-agent` below (it is read-only); its role is the\n`\u002Funikit-review` reviewers row of the roles table, and its model and effort are settled the same way.\n\n## Delegation agents\n\nThis skill uses a named delegation alias for `Agent(...)` calls. The alias is the single\nplace where its delegate's agent type and call arguments are declared — call sites name\nthe alias and never carry a type or a model argument of their own.\n\n- **`check-agent`** — fresh-context, read-only findings validator (`+check`). Expands to:\n\n  ```\n  Agent({{agent_call_reader}} prompt: \"\u003Crendered VALIDATOR.md template>\")\n  ```\n\n  Whether the agent is read-only is this runtime's own claim, so the read-only contract\n  rides on the prompt rather than on the dispatch: keep `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FVALIDATOR.md`'s\n  read-only paragraph (\"You never modify a file and never run a command that changes state\") in whatever is sent.\n\n  Fallback: the validator is **never** replaced by inline analysis — see\n  `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FCHECK-MODE.md` (`WARN [+check]: validator failed`).\n\n## Step 1: Load rules\n\nRead (they always apply):\n- `.unikit\u002FARCHITECTURE.md` — module boundaries, dependency rules. **Architecture topics:** the root always; then the topic files listed under its `## Topics` whose `Load when` matches a reviewed file — its path, type or area (Step 3); when unsure, load. A listed file that is missing → `WARN [architecture] topic file missing: .unikit\u002Farchitecture\u002F\u003Cslug>.md`, continue.\n- `.unikit\u002FROADMAP.md` (if present) — milestone alignment\n- `.unikit\u002Fsystem\u002Fgate-result-contract.md` — schema for the machine-readable `unikit-gate-result` block emitted in Step 5. If missing or unreadable, do not block: the Step 5 gate-result section is self-sufficient on the schema and degrades gracefully (see there).\n\nRead `.unikit\u002Fmemory\u002Fcode\u002FRULES_INDEX.md`. Load rules:\n- **RULES.md**: ALWAYS read `.unikit\u002FRULES.md` first (highest priority). **Rule topics:** the root here; its topic files load in Step 3, by the reviewed files.\n- **Core**: read the Core table. For EACH row where Required By = `all` or contains `{{self_name}}` — read that file from `.unikit\u002Fmemory\u002Fcode\u002Fcore\u002F` using the Read tool. Do NOT skip any matching row. Always re-read at skill start, never rely on prior conversation cache\n- **Stack**: load dynamically when the current task or context matches \"Load When\" column, or when a need arises during work\n\nRead `.unikit\u002Fskill-context\u002F{{self_name}}\u002FSKILL.md` if it exists — project-level overrides that win over this SKILL.md when conflicting.\n\n**The review is of work on a plan whose manifest has `## Experiment Context`** (the session started from such a plan, or the prompt carries a `Prototype plan:` note) → read `.unikit\u002Fsystem\u002Fprototype-profile.md` and follow its `## Role: quality and the rest` for the whole review. Missing or unreadable → `WARN [prototype] profile contract missing — reviewing as for an ordinary plan; run unikit-ai update`.\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n## Step 2: Route argument and get code\n\n**Parse `+check` first.** If `$ARGUMENTS` contains the `+check` token, strip it out (remember `check = true`) before running the routing chain below, so it is never mistaken for a file path or git ref. `+check` enables the fresh-context findings validator in Step 4.5; without it, that step is skipped entirely.\n\n### Routing chain\n\n1. **Empty** → Staged mode\n2. **Digits \u002F `#N` \u002F PR URL** (e.g. `123`, `#42`, `https:\u002F\u002Fgithub.com\u002F...\u002Fpull\u002F123`) → PR mode. Extract number from URL if needed\n3. **Starts with `@`** → File mode (folder). Strip `@`, glob `\u003Cpath>\u002F**\u002F*.cs`\n4. **Contains `.cs`** → File mode (explicit files)\n5. **Other** → `git rev-parse --verify \u003Carg>`:\n   - Valid → Commits mode\n   - Invalid → the question tool of your agent (`AskUserQuestion`) (staged \u002F cancel \u002F corrected ref)\n\n> `@` disambiguates folder paths from git refs with `\u002F`.\n\n### Staged mode\n\n1. `git diff --cached` → if empty, `git diff` → if empty, inform and **stop**\n2. Extract changed `.cs` files, read full content for stack rule detection\n\n### PR mode\n\n1. `gh pr view \u003CN> --json title,body,baseRefName,headRefName,files`\n2. `gh pr diff \u003CN>`\n3. Extract changed `.cs` files, read full content for stack rule detection\n\n### Commits mode\n\n1. Validate ref via `git rev-parse --verify`. Invalid → ask user\n2. `git log --oneline --reverse \u003Cref>..HEAD` → if empty, inform and **stop**\n3. If >20 commits → the question tool of your agent (`AskUserQuestion`) (all \u002F last 20 \u002F cancel)\n4. `git diff --name-only \u003Cref>..HEAD -- '*.cs'` → read full content for stack rule detection\n5. For each commit: `git show \u003Chash> --stat` and `git show \u003Chash>`\n\n### File mode\n\n- `.cs` args: locate via `Glob`\u002F`find`. Name without path → search entire project\n- `@folder` args: `Glob \u003Cfolder>\u002F**\u002F*.cs`. No results → report error, continue with others\n- Read full content of all found files for stack rule detection\n\n## Step 3: Load stack rules\n\nNow that target code is available, scan it for framework markers from the **Stack** section of `RULES_INDEX.md`. Each entry lists which keywords\u002Ftypes indicate relevance (\"Load When\" column). Load only matching rule files. If no markers match — skip stack rules entirely.\n\n**Rule topics.** In the same pass, load the topic files listed under `## Topics` in `.unikit\u002FRULES.md` **and in `.unikit\u002FARCHITECTURE.md`** whose `Load when` matches the reviewed files — their paths, types, area; when unsure, load (`RULES_INDEX.md` → Step 1). They apply in Step 4 together with the root's rules.\n\n## Step 4: Analyze\n\nApply **all loaded rules** (core + stack + project + the ARCHITECTURE.md root and its loaded topics) uniformly, regardless of mode.\n\nFor each file or diff hunk, check:\n- **Rule violations** — every loaded rule against the code\n- **Architecture alignment** — boundary\u002Fdependency violations (e.g. `Modules\u002F → Game\u002F` forbidden)\n- **Roadmap linkage** — for `feat`\u002F`fix`\u002F`perf` work, missing ROADMAP.md milestone link (suggestion only)\n- **Removed code** (diff modes) — broken contracts, dangling references\n\n**Commits mode only** — additionally per commit:\n- **Message accuracy** — does the message match the actual changes?\n- **Atomicity** — single logical unit, or mixed concerns?\n\n### Severity scale\n\n- 🔴 **Critical** — must fix (crashes, silent failures, memory leaks, data corruption)\n- 🟡 **Warning** — likely to cause bugs under specific conditions\n- 🟠 **Medium** — performance, code smell, maintainability\n- 🟢 **Suggestion** — quality improvement\n\nRecord exact line numbers (or commit hash + file:line for diff modes) and relevant code snippets.\n\n### General checklist\n\nAlways run these checks in addition to project rules. If a finding from the checklist contradicts a loaded project\u002Fcore\u002Fstack rule, the ARCHITECTURE.md root or a loaded topic (i.e. the code follows project conventions) — **suppress the finding**, it is not an issue.\n\n**Correctness:**\n- [ ] Logic errors or bugs\n- [ ] Edge cases handling\n- [ ] Null\u002Fundefined checks\n- [ ] Error handling completeness\n- [ ] Type safety\n\n**Performance:**\n- [ ] Memory leaks\n- [ ] Inefficient algorithms\n- [ ] N+1 query problems\n\n**Best Practices:**\n- [ ] Code duplication\n- [ ] Dead code\n- [ ] Magic numbers\u002Fstrings\n- [ ] Proper naming conventions\n- [ ] SOLID principles\n- [ ] DRY principle\n\n**Testing** (only when tests are due: a plan with `Testing: yes`, or the user asked for them; no tests by the user's choice is not a finding, and neither are tests still waiting for acceptance):\n- [ ] Tests for new logic; none that pin tunable values or authored content\n- [ ] Edge cases of the logic tested\n- [ ] Mocking appropriateness\n\n## Step 4.5: Validate Findings (`+check` only)\n\nRun this step **only** when `check = true` (the `+check` flag was parsed in Step 2). Draft the full review internally first (all sections of Step 5, including the gate-result inputs), then — **before** rendering anything to the user — run the procedure in **`{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FCHECK-MODE.md`**. It dispatches one fresh-context `check-agent` validator over the **Findings table** rows (one item per row; \"Questions\", \"Positive notes\", and per-commit findings are excluded), applies each `keep`\u002F`modify`\u002F`drop` verdict and any severity move across the four levels (🔴 Critical \u002F 🟡 Warning \u002F 🟠 Medium \u002F 🟢 Suggestion), tracks the `hidden` \u002F `adjusted` \u002F `reclassified` counters, and **recomputes** the `unikit-gate-result` block (Step 5 \"Machine-readable gate result\") from the post-filter table.\n\nWhen `+check` ran successfully, append one line after all review sections and before the `unikit-gate-result` fence:\n\n```\nFiltered: N hidden, M adjusted, K reclassified by +check\n```\n\n**Fallback (do NOT inline-analyze):** if the validator agent is unavailable\u002Fblocked or the dispatch fails, keep **all** findings as drafted, do NOT recompute the gate-result block (assemble it from the unfiltered table), and emit the single line `WARN [+check]: validator failed (\u003Creason>), all items kept as-is` above the fence — never re-do the validator's work with Glob\u002FGrep\u002FRead. An unavailable validator is silently skipped; the user is never asked.\n\nIf `+check` is not set, skip this step entirely — no validator-related lines appear and the gate-result block is computed once from the full draft.\n\n## Step 5: Output\n\nAll modes use the same report structure. Mode-specific sections are marked below.\n\n```markdown\n## Code Review Summary\n\n\u003C!-- PR mode only: -->\n**PR:** #[number] — [title]\n**Base:** [baseRefName] ← **Head:** [headRefName]\n\u003C!-- Commits mode only: -->\n**Range:** `\u003Cref>..HEAD`\n**Commits Reviewed:** [count]\n\n**Files Reviewed:** [count]\n**Risk Level:** 🟢 Low \u002F 🟡 Medium \u002F 🔴 High\n**Stack rules loaded:** [list or \"none\"]\n\n\u003C!-- Commits mode only: -->\n### Per-Commit Notes\n#### `\u003Cshort-hash>` — \u003Ccommit message>\n- **Atomicity:** ✅ Good \u002F ⚠️ Mixed concerns\n- **Message accuracy:** ✅ Matches \u002F ⚠️ Misleading\n- **Issues:** [findings with severity markers, or \"None\"]\n\n### Findings\n\n| # | Severity | Location | Rule | Issue | Fix |\n|---|----------|----------|------|-------|-----|\n| 1 | 🔴\u002F🟡\u002F🟠\u002F🟢 | file:L42 | Rule ref | What's wrong | How to fix |\n\n### Code Fixes\n\n\u003C!-- For 🔴 and 🟡 findings, show: -->\n**#1 — [issue title]** (`file:L42`)\n​```csharp\n\u002F\u002F ❌ Current\n\u003Cproblematic code>\n\n\u002F\u002F ✅ Fixed\n\u003Ccorrected code>\n​```\n\n### Questions\n[Ambiguous code or design decisions that need clarification from the author]\n\n### Summary\n\n- **Critical:** [count] | **Warning:** [count] | **Medium:** [count] | **Suggestion:** [count]\n- **Top issues:** 3 most impactful to fix first\n- **Positive notes:** Good patterns observed\n```\n\n### 5.1 Machine-Readable Gate Result\n\n> **Mirror of `unikit-verify` Step 4.4** (the canonical template). This section copies that one field-for-field — the only differences are `\"gate\": \"review\"` and the projection source (the Findings table below, instead of verify's task-audit + context gates). The graceful-degradation wording and the last-fence rule are kept textually identical to verify's so a single guard locks both; if verify's wording changes, this must change in lockstep.\n\nAfter the human-readable review above, append exactly one fenced `unikit-gate-result` JSON block. Use the schema loaded from `.unikit\u002Fsystem\u002Fgate-result-contract.md` in Step 1.\n\n**Last fence wins:** the `unikit-gate-result` block MUST be the LAST fenced block in this skill's output — orchestrators parse only the last one. Any earlier fence (the example below, quoted prior output) is illustrative and is not the gate result.\n\n**Projection (review):** derive the fields from the Findings table:\n\n- `\"gate\"`: always `\"review\"`.\n- `\"status\"`:\n  - `fail` — the table has at least one **blocking** finding (🔴 Critical or 🟡 Warning).\n  - `warn` — no blocking findings, but the table has 🟠 Medium \u002F 🟢 Suggestion rows.\n  - `pass` — the table is empty (no findings).\n- `\"blocking\"`: `true` only when `status` is `fail`.\n- `\"blockers\"`: include **only** the 🔴 Critical and 🟡 Warning rows, each `{ \"id\", \"severity\", \"file\", \"summary\" }`. Use stable ids (`review-finding-\u003Crow#>`). `severity` is `error` for these blocking rows (`warning` only when policy escalates). 🟠 Medium \u002F 🟢 Suggestion rows stay in the human table, never in `blockers`.\n- `\"affected_files\"`: the files the review actually evaluated or cited (not unrelated repo files); empty array when none apply.\n- `\"suggested_next.command\"`: from the allowlist in `gate-result-contract.md` — `\u002Funikit-fix` (code must change), `\u002Funikit-rules` (a rules-gate finding needs a writer update), `\u002Funikit-architecture` (architecture drift), `\u002Funikit-roadmap` (roadmap drift), `\u002Funikit-commit` (clean — natural next step), or `null`.\n\nWhen `+check` ran (Step 4.5), this projection runs over the **post-filter** table and `suggested_next.reason` notes the `+check` counters; on `+check` whole-dispatch failure the block is assembled from the unfiltered table and is **not** recomputed.\n\n```unikit-gate-result\n{\n  \"schema_version\": 1,\n  \"gate\": \"review\",\n  \"status\": \"pass\",\n  \"blocking\": false,\n  \"blockers\": [],\n  \"affected_files\": [],\n  \"suggested_next\": {\n    \"command\": \"\u002Funikit-commit\",\n    \"reason\": \"Review found no blocking issues.\"\n  }\n}\n```\n\nThe fenced block contains JSON only — no comments, trailing commas, or prose inside it.\n\n**Graceful degradation:** if `.unikit\u002Fsystem\u002Fgate-result-contract.md` is missing or unreadable, do not hard-fail — emit the block from the inline schema in this section; if even that is not possible, skip the block and append the single line `WARN [gate-result]: contract asset unavailable`.\n\n## Guidelines\n\n- Be precise: exact line numbers and code references\n- Be actionable: every finding includes a concrete fix\n- Be complete: check ALL loaded rules\n- No false positives: if uncertain, mark \"Potential — verify manually\"\n- Clean code → say so, don't invent issues\n- Read-only: do NOT modify any files\n- Be constructive: explain \"why\", acknowledge good code\n\n## Examples\n\n`\u002Funikit-review` — review staged changes\n`\u002Funikit-review PlayerController.cs` — review specific file\n`\u002Funikit-review @Assets\u002FScripts\u002FPlayer` — review folder recursively\n`\u002Funikit-review @Assets\u002FScripts\u002FPlayer @Assets\u002FModules\u002FWallets` — review multiple folders\n`\u002Funikit-review 123` or `\u002Funikit-review #42` — review PR by number\n`\u002Funikit-review https:\u002F\u002Fgithub.com\u002Forg\u002Frepo\u002Fpull\u002F123` — review PR by URL\n`\u002Funikit-review master` — review commits vs master\n`\u002Funikit-review v1.0.0` — review commits vs tag\n`\u002Funikit-review feature\u002Fday-loop` — review commits vs branch\n\n> **Tip:** Context is heavy after review. Consider `\u002Fclear` or `\u002Fcompact` before continuing.\n",{"name":5,"description":7,"allowed-tools":52,"argument-hint":62},[53,54,55,56,57,58,59,60,61],"Read","Grep","Glob","Bash(find *)","Bash(wc *)","Bash(git *)","Bash(gh *)","Agent","AskUserQuestion","[+check] [script.cs ... | @folder ... | PR number | branch\u002Fcommit\u002Ftag | empty]","main","ae3c6dfffd26d9b45b9d96d71ba2c122c50b67ae","skills\u002Funikit-review",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":73,"prompt":83,"zipAvailable":84},[74,77,80],{"tool":75,"command":76},"npx","npx skills add NintendaDev\u002Funikit-ai --skill unikit-review",{"tool":78,"command":79},"bunx","bunx skills add NintendaDev\u002Funikit-ai --skill unikit-review",{"tool":81,"command":82},"pnpm","pnpm dlx skills add NintendaDev\u002Funikit-ai --skill unikit-review","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-review\u002FSKILL.md",true,[86,92],{"path":87,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":90,"sourceHtmlUrl":91},"references\u002FCHECK-MODE.md","REFERENCE","参考文档",11253,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-review\u002Freferences\u002FCHECK-MODE.md",{"path":93,"resourceType":88,"resourceTypeDesc":89,"sizeBytes":94,"sourceHtmlUrl":95},"references\u002FVALIDATOR.md",11289,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-review\u002Freferences\u002FVALIDATOR.md",[97,122,143,165,184,209],{"skillNo":98,"name":99,"nameZh":6,"description":100,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":101,"categories":102,"keywords":106,"publishedAt":47},"01M71BQ00EXGX51PPCDY7VG334","unikit","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",[103],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[99,45,107,108,109,110,111,112,113,114,37,115,116,117,36,33,118,119,120,121],"time","actions","fix","documents","architecture","stack","run","update","write","config","edit","initialize","tech","scan","use",{"skillNo":123,"name":124,"nameZh":6,"description":125,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":126,"categories":127,"keywords":130,"publishedAt":47},"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",[128,129],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[131,132,133,44,134,135,113,37,115,117,36,31,136,121,137,138,139,140,141,142],"unikit verify","verify","powershell","phase","plan","system","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":47},"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,45,154,155,156,157,158,159,160,135,161,162,163,37,115,117,164],"unikit todo","todo","remind","show","todo list","only","now","you","done","tasks","work","me","reminders","later","act",{"skillNo":166,"name":167,"nameZh":6,"description":168,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":169,"categories":170,"keywords":172,"publishedAt":47},"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",[171],{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[173,33,45,109,174,175,176,177,178,27,179,180,151,181,182,113,183,37,115,117],"unikit skills context","coding conventions","writing","when","workflow","commit","general coding","text","change","how","past",{"skillNo":185,"name":186,"nameZh":6,"description":187,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":188,"categories":189,"keywords":197,"publishedAt":47},"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",[190,193,196],{"categoryNo":191,"categoryName":192,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":194,"categoryName":195,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":104,"categoryName":105,"taxonomyType":21,"taxonomyTypeDesc":22},[198,199,200,201,45,202,203,42,204,205,111,206,180,207,112,163,37,115,117,208],"Rules","unikit rules","quick","PDF","clean","knowledge","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":47},"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,198,217,218,45,219,203,220,205,221,114,37,115,36,222,223,224,225,226,227],"registry","unikit rules registry","shared","local","remote","create","ai rules","automatic","semver","knowledge-base","as","three"]