[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BGRK83DQTCSXSKW4EYR34":3,"skill-same:01M71BGRK83DQTCSXSKW4EYR34":110},{"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":29,"publishedAt":50,"linkOnly":51,"markdownContent":52,"markdownBody":53,"frontMatter":54,"refName":70,"commitSha":71,"skillDirectory":72,"forksCount":73,"repositoryHtmlUrl":74,"repositoryHomepageUrl":75,"ownerHtmlUrl":76,"ownerBlogUrl":6,"ownerDescription":77,"updatedAt":78,"install":79,"resources":91},"01M71BGRK83DQTCSXSKW4EYR34","unikit-docs",null,"Generate and maintain the project's TECHNICAL documentation from its codebase — scans the project structure, tech stack, and module boundaries, then writes a lean README landing page plus detailed topic pages (architecture, modules, setup, build, APIs), only the docs that are relevant. Use whenever the user wants to create, update, or validate documentation of the CODE or the project itself, e.g. \"generate documentation\", \"create docs\", \"write the README\", \"update the project docs\", \"document the codebase\", \"document this project's architecture\", \"validate the project documentation\". This is CODE \u002F project documentation only — it never documents the game design. To render the GAME DESIGN (the GDD: systems, flows, content, economy) for people to read use \u002Funikit-gd-docs.","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-docs\u002FSKILL.md",[18,23,26],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000015","视觉设计",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发",[30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48,49],"docs","unikit docs","generate documentation","project docs","edit","write","read","update","generate","project structure","stack","structure","create","architecture","documents","design","lean","project","relevant","modules","2026-11-10 10:12:30",false,"---\nname: unikit-docs\ndescription: >-\n  Generate and maintain the project's TECHNICAL documentation from its codebase — scans\n  the project structure, tech stack, and module boundaries, then writes a lean README landing\n  page plus detailed topic pages (architecture, modules, setup, build, APIs), only the docs\n  that are relevant. Use whenever the user wants to create, update, or validate documentation\n  of the CODE or the project itself, e.g. \"generate documentation\", \"create docs\", \"write\n  the README\", \"update the project docs\", \"document the codebase\", \"document this\n  project's architecture\", \"validate the project documentation\". This is CODE \u002F project\n  documentation only — it never documents the game design. To render the GAME DESIGN (the GDD:\n  systems, flows, content, economy) for people to read use \u002Funikit-gd-docs.\nargument-hint: \"[--web]\"\nallowed-tools:\n  - Read\n  - Write\n  - Edit\n  - Glob\n  - Grep\n  - Bash(mkdir,ls)\n  - AskUserQuestion\n  - Agent\ndisable-model-invocation: false\nuser-invocable: true\nmetadata:\n  author: unikit\n  version: \"1.1\"\n  category: documentation\n---\n\n# Docs — Project Documentation Generator\n\nGenerate, maintain, and improve documentation for game projects following a landing-page README + detailed docs\u002F structure.\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## Core Principles\n\n1. **README is a landing page, not a manual.** ~80-120 lines. First impression, tech stack, quick start, links to details.\n2. **Details go to `docs\u002F`.** Each file is self-contained — one topic, one page.\n3. **No duplication.** If information lives in `docs\u002F`, README links to it — does not repeat it.\n4. **Detection-first.** Scan the project before deciding which documents to generate. Never assume specific frameworks, folder structures, or patterns — discover them.\n5. **Navigation.** Every docs\u002F file has a header line with prev\u002Fnext links following the Documentation table order. Every page ends with a \"See Also\" section linking to 2-3 related pages.\n6. **Scannable.** Use tables, bullet lists, and code blocks. Avoid long paragraphs.\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\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- **`recon-agent`** — read-only parallel reconnaissance. Expands to:\n\n  ```\n  Agent({{agent_call_reader}} prompt: \"\u003Cfocused question> You are read-only: edit and write nothing.\")\n  ```\n\n  Every question you send ends with the sentence `You are read-only: edit and write nothing.`, verbatim.\n\n  Fallback: if the `Agent` tool is unavailable, investigate inline with `Glob`\u002F`Grep`\u002F`Read`.\n\n## Skill-specific rules:\n- Navigation text is translated to the configured language (`[\u003C- Предыдущая]`, `Назад к README`, `Далее ->`, `См. также`)\n- `docs-config.json` is NOT translated — it stays in English (machine-readable config)\n\n## Workflow\n\n### Step 0: Load Project Context\n\n1. Read `.unikit\u002Fconfig.yaml` — extract `language.ui` and `language.artifacts` (all subsequent output uses these language settings)\n2. Read `.unikit\u002FDESCRIPTION.md` (if exists) — project overview, tech stack\n3. Read `.unikit\u002FARCHITECTURE.md` (if exists) — architecture decisions, module structure. **Architecture topics:** read the root and every topic file listed under its `## Topics`; a missing file → `WARN [architecture] topic file missing: .unikit\u002Farchitecture\u002F\u003Cslug>.md`, continue.\n4. Read `.unikit\u002Fskill-context\u002Funikit-docs\u002FSKILL.md` — **MANDATORY if exists.** Project-specific overrides. Skill-context rules win over general rules on conflict.\n5. Read `AGENTS.md` (if exists) — current documentation index\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n### Step 0.1: Parse Flags\n\n```\n--web → Also generate HTML version of documentation (see Step 6)\n```\n\n### Step 1: Auto-Detect Project\n\nThis is the heart of universality. Scan the project to understand its real structure before generating anything.\n\n#### 1.1: Load Engine Rules\n\nRead `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FENGINE_RULES.md` — this file is installed by the unikit setup and contains all engine-specific detection tables, folder structure patterns, module boundary mechanism, and deep analysis patterns for the current project's engine.\n\n#### 1.2: Detect Tech Stack\n\nUsing the detection tables from the loaded engine rules file, scan the project's package manifest and plugin directories for known frameworks.\n\nRecord detected stack — it determines which conditional documents to generate.\n\n#### 1.3: Detect Folder Structure\n\nUsing the folder structure patterns from the loaded engine rules file, scan the project for script locations, modular structures, special folders, scenes, and tests. Don't assume any specific structure — discover it.\n\nAlso scan for module boundary files (per engine rules) to map the project's module\u002Fassembly structure.\n\n#### 1.4: Load or Generate docs-config.json\n\nCheck if `.unikit\u002Fdocs-config.json` exists:\n\n**If exists** → load it, then run reconciliation (Step 1.5) to sync config with reality.\n\n**If not exists** → generate based on detection results:\n\n```json\n{\n  \"detected_stack\": {\n    \"engine\": \"{{engine_name}} 6 (6000.0.68f1)\",\n    \"di\": \"Zenject\",\n    \"async\": \"UniTask\",\n    \"events\": \"Custom SignalBus\",\n    \"ui\": \"ASPID MVVM\",\n    \"reactive\": \"R3\"\n  },\n  \"scan_paths\": {\n    \"scripts\": [\"Assets\u002FGame\u002FScripts\"],\n    \"modules\": [\"Assets\u002FModules\", \"Assets\u002FModules\u002FPawnshop\"],\n    \"scenes\": [\"Assets\u002FGame\u002FScenes\"],\n    \"editor\": [\"Assets\u002FEditor\", \"Assets\u002FGame\u002FScripts\u002FEditor\"],\n    \"tests\": [\"Assets\u002FGame\u002FTests\"]\n  },\n  \"exclude_paths\": [\n    \"Assets\u002FPlugins\",\n    \"Assets\u002FThird-Party Assets\"\n  ],\n  \"documents\": {\n    \"core\": [\"readme\", \"getting-started\", \"architecture\", \"project-map\"],\n    \"conditional\": [\"di-bindings\", \"events\", \"save-system\", \"game-systems\", \"testing\", \"editor-tools\"]\n  },\n  \"output_dir\": \"docs\"\n}\n```\n\nPresent the generated config to the user for confirmation before proceeding. This is their chance to add paths, remove documents, or adjust detection results.\n\n**Conditional document rules — generate only if detected:**\n\n| Document | Generate when |\n|----------|--------------|\n| `di-bindings` | DI framework detected (Zenject, VContainer, etc.) |\n| `events` | Event\u002Fsignal system detected |\n| `save-system` | Save serialization classes detected |\n| `game-systems` | Gameplay controllers, FSM, AI systems detected |\n| `testing` | Test assembly definitions detected |\n| `editor-tools` | Custom Editor scripts detected |\n| `build` | Addressables or custom build pipeline detected |\n| `ui-system` | UI framework beyond basic UGUI detected |\n\n#### 1.5: Reconciliation (config vs reality)\n\nWhen `docs-config.json` already exists, run a three-way comparison: **config** vs **detected state** vs **existing docs\u002F**. This ensures the config stays in sync as the project evolves.\n\n**a) Validate scan_paths — do configured paths still exist?**\n\nFor each path in `scan_paths`, check if it exists on disk:\n- Path exists → scan it normally\n- Path missing → `WARN`: \"Path `Assets\u002FOldFolder` from config not found. Remove from config?\"\n- Offer to remove dead paths. Don't auto-remove — the path might be temporarily missing (branch switch, pending asset import).\n\n**b) Detect new paths — did the project grow?**\n\nScan `Assets\u002F` for common script locations (same list from Step 1.2). If a new populated folder is found that isn't in `scan_paths` or `exclude_paths`:\n- `INFO`: \"Found `Assets\u002FNewModule\u002F` with scripts — not in config. Add to scan_paths?\"\n- Offer to add. Don't force — the user may intentionally exclude it.\n\n**c) Reconcile tech stack — did packages change?**\n\nRe-run detection (Step 1.1) and compare with `detected_stack` in config:\n\n| Situation | Action |\n|-----------|--------|\n| New framework found (not in config) | Suggest: \"Detected Mirror in manifest.json. Add `networking` document?\" → update config + generate doc |\n| Framework removed (in config but not detected) | Suggest: \"Zenject no longer detected. Keep `di-bindings` document?\" → user decides |\n| Version changed | Silently update `detected_stack` in config |\n\n**d) Reconcile documents — config vs docs\u002F folder**\n\n| Situation | Action |\n|-----------|--------|\n| Document in config but no file in docs\u002F | Generate it (probably new addition by user) |\n| Document NOT in config but file exists in docs\u002F | Do NOT delete. Skip updates. Warn: \"`docs\u002Fsave-system.md` exists but is not in config — it won't be updated\" |\n| Document in config, file exists | Update normally (State C behavior) |\n| **Any file under `docs\u002Fdesign\u002F**`** | **Out of scope — owned by `\u002Funikit-gd-docs`.** Do NOT warn, suggest, absorb into config, or touch it. Only the **top-level** `docs\u002F*.md` is reconciled here. |\n\n**e) Present reconciliation report**\n\nIf any discrepancies found, show a summary before proceeding:\n\n```\nConfig reconciliation:\n\nPaths:\n  ✅ Assets\u002FGame\u002FScripts — exists\n  ✅ Assets\u002FModules — exists\n  ⚠️ Assets\u002FOldFolder — not found (remove from config?)\n  🔍 Assets\u002FNewFeature\u002F — found, not in config (add?)\n\nTech stack:\n  ✅ DI: Zenject — unchanged\n  🔍 Networking: Mirror — detected, not in config\n  ❌ Save: Custom SaveSerializer — no longer detected\n\nDocuments:\n  ✅ 4 core + 3 conditional — in sync\n  🔍 networking — suggested (Mirror detected)\n  ⚠️ docs\u002Fsave-system.md — exists but removed from config\n\n```\n\nThen ask with the question tool of your agent (`AskUserQuestion`): Apply suggestions?\n\nOptions:\n1. Apply all\n2. Let me pick\n3. Skip — use config as-is\n\nBased on choice:\n- Apply all → update `docs-config.json` with all suggestions, proceed to Step 1.6\n- Let me pick → ask for each suggestion with the question tool of your agent (`AskUserQuestion`): `Apply` (recommended) or `Skip`; apply the selected\n- Skip → use config as-is, proceed to Step 1.6\n\nAfter reconciliation, update `docs-config.json` with confirmed changes and proceed to Step 1.5.\n\n### Step 1.6: Deep Code Analysis\n\nBefore generating any documents, systematically explore the codebase to build a deep understanding of how systems connect. This step transforms surface-level detection (Step 1) into the rich relationship map that makes documentation truly valuable.\n\n**This step is mandatory.** Shallow detection produces shallow docs — catalogs of classes without explaining how they work together. The quality of documentation directly depends on the depth of analysis performed here.\n\nLaunch multiple exploration tasks in parallel using the `recon-agent` alias (declared in `## Delegation agents`) to cover different analysis dimensions. Each substep below (1.6.1–1.6.4) should be a separate `recon-agent` dispatch with a focused prompt.\n\n**Fallback:** If Agent tool is unavailable, perform analysis inline using Glob\u002FGrep\u002FRead.\n\n#### 1.6.1: Bootstrap & Initialization Chain\n\nTrace the full startup sequence from entry scene to gameplay-ready state:\n- Find the entry scene → identify root GameObjects with context components\n- Find ALL `*Installer.cs` files → read each one fully, extract every binding\n- Map the initialization order: loading operations → IInitializable chain → NonLazy activations\n- Trace loading operation dependencies (what must complete before what)\n\n**Output:** Ordered initialization graph with dependencies between steps.\n\n#### 1.6.2: Complete Communication Map\n\nBuild a full catalog of ALL inter-system communication — not just the obvious signals:\n\n**SignalBus events:**\n- Find ALL `ISignal` implementations (grep `: ISignal` in all project `.cs` files)\n- For each signal: find every `Invoke\u003CSignal>` (publishers) and `Subscribe\u003CSignal>` (subscribers)\n- Detect signal chains — when a signal handler triggers another signal\n\n**R3 reactive streams:**\n- Find all `ReactiveProperty\u003C>`, `Subject\u003C>`, `ReadOnlyReactiveProperty\u003C>` declarations\n- Trace who subscribes to each stream (`.Subscribe()`, `.Select()`, `.Where()`, `.Switch()`)\n- Map the reactive data flow: Model → ViewModel → View\n\n**Direct DI dependencies:**\n- Read constructor parameters of key services to build the dependency graph\n- Identify hub services (injected by 3+ consumers)\n\n**Output:** Complete communication topology with three layers: signals, reactive streams, DI dependencies.\n\n#### 1.6.3: End-to-End Feature Flows\n\nTrace 2-3 key user-facing features from trigger to completion:\n- Start from user action or external trigger\n- Follow through every system touched: controller → service → model → view → save\n- Note every signal fired, every observable updated, every state change\n- Identify cross-module boundaries crossed\n- Record the communication mechanism at each step (DI call, signal, R3 stream, direct call)\n\nPick flows that touch the most systems — these reveal the real architecture.\n\n**Output:** Step-by-step sequence for each flow with class names and mechanisms at each boundary.\n\n#### 1.6.4: Cross-System Interaction Matrix\n\nBuild a matrix showing how major systems interact:\n\n```\n             | Characters | Trade | MiniGames | Wallets | Save | UI\nCharacters   |     —      |  DI   |   Signal  |   —     |  —   | R3\nTrade        |    DI      |   —   |     DI    |   DI    | Save | Signal\n```\n\nFor each non-empty cell: note the mechanism (DI, Signal, R3, Direct) and direction.\n\n**Output:** Interaction matrix with mechanism annotations + list of hub systems.\n\n#### 1.6.5: Consolidate Analysis\n\nMerge outputs from all parallel Agent results. This analysis is NOT published — it feeds into Step 3 to produce rich, connected documentation.\n\nKey things to capture:\n- Hub systems (many connections) vs isolated modules\n- Data that flows through many systems (e.g., customer data, wallet balance)\n- Recurring patterns across the codebase (Controller pattern, SaveSerializer pattern, etc.)\n- Surprising or non-obvious connections between systems\n- Any circular dependencies or architectural concerns\n\n### Step 2: Determine Current State\n\n```\nState A: No README.md                → Full generation (README + docs\u002F)\nState B: README.md exists, no docs\u002F  → Analyze README, propose split into docs\u002F\nState C: README.md + docs\u002F exist     → Audit and improve\n```\n\n**State C with `--web` flag** — ask the user:\n\n```\nDocumentation already exists (README.md + docs\u002F).\n\nOptions:\n1. Generate HTML only — build site from current docs\n2. Audit & improve first — check for issues, then generate HTML\n3. Audit only — check without generating HTML\n```\n\nBased on choice:\n- HTML only → skip Steps 3–5, proceed directly to Step 6 (HTML Generation) → **STOP** (do not run Steps 7, 8 — no markdown content was changed)\n- Audit & improve → run State C audit (Step 3, State C), fix issues, then proceed to Step 6\n- Audit only → run State C audit, report issues → **STOP**\n\n### Step 2.1: Check for Scattered Markdown Files\n\nScan project root for `.md` files. Propose consolidating relevant ones into `docs\u002F`:\n\n| Root file | Target in docs\u002F | Action |\n|-----------|-----------------|--------|\n| `CONTRIBUTING.md` | `docs\u002Fcontributing.md` | Move |\n| `ARCHITECTURE.md` | `docs\u002Farchitecture.md` | Move |\n| `SETUP.md` | `docs\u002Fgetting-started.md` | Merge |\n| `TESTING.md` | `docs\u002Ftesting.md` | Move |\n\n**Files that stay in root:** `README.md`, `CHANGELOG.md`, `LICENSE`, `CODE_OF_CONDUCT.md`, `AGENTS.md`.\n\nAlways ask before moving. Never force-move files.\n\n### Step 3: Generate Documents\n\n#### State A: Full Generation\n\n##### 3.1: Confirm document list\n\nPresent detected documents to the user:\n\n```\nBased on project scan:\n\nCore documents (always generated):\n  ✅ README.md — project landing page\n  ✅ docs\u002Fgetting-started.md — setup, prerequisites, first run\n  ✅ docs\u002Farchitecture.md — project structure and patterns\n  ✅ docs\u002Fproject-map.md — modules, assemblies, namespaces\n\nConditional documents (detected):\n  ✅ docs\u002Fdi-bindings.md — [FrameworkName] installer map\n  ✅ docs\u002Fevents.md — event system catalog\n  ✅ docs\u002Ftesting.md — test infrastructure\n  ❌ docs\u002Fnetworking.md — no networking framework detected\n\n```\n\nThen ask with the question tool of your agent (`AskUserQuestion`): Which documents should be generated?\n\nOptions:\n1. Generate all detected\n2. Let me pick\n3. Add more topics\n\nBased on choice:\n- Generate all detected → proceed to Step 3.2 with full document list\n- Let me pick → ask for each document with the question tool of your agent (`AskUserQuestion`): `Generate` (recommended) or `Skip`; generate only the selected\n- Add more topics → ask for the additional topics with the question tool of your agent (`AskUserQuestion`): its options are the conditional documents of the Step 1.4 table that were not detected, and the user writes their own topics in the free-text answer; merge with the detected list, re-confirm\n\n##### 3.2: Generate README.md\n\nFor the README template and content guidelines → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FDOC-TEMPLATES.md` (README section).\n\nKey rules:\n- Tech Stack table derived from `detected_stack`\n- Quick Start with real engine version (per engine rules: version detection method)\n- Key Features from `.unikit\u002FDESCRIPTION.md` or codebase scan\n- Documentation table linking to all generated docs\u002F pages\n- ~80-120 lines total\n\n##### 3.3: Generate docs\u002F files\n\nFor content guidelines per document type → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FDOC-TEMPLATES.md`.\n\nEvery file follows this structure (navigation text in project language):\n\n```markdown\n[\u003C- Previous](prev.md) . [Back to README](..\u002FREADME.md) . [Next ->](next.md)\n\n# Topic Title\n\nContent with tables, code blocks, diagrams.\n\n## See Also\n\n- [Related Topic](topic.md) — brief description\n```\n\nNavigation text is translated to the project language. For example, with `\"language\": \"ru\"`:\n```markdown\n[\u003C- Предыдущая](prev.md) . [Назад к README](..\u002FREADME.md) . [Далее ->](next.md)\n## См. также\n```\n\n**Navigation link order** follows the Documentation table in README.md. First page omits prev link; last page omits next link.\n\n**Content generation approach:**\n- Use the deep analysis from Step 1.6 as the primary source — it contains the communication map, dependency chains, and feature flows\n- Supplement with a `recon-agent` dispatch for specific details not covered by the analysis. Fallback: If Agent tool is unavailable, use Glob\u002FGrep\u002FRead inline\n- For each document, verify against actual code — don't guess at structures\n- Include real class names, real file paths, real namespace examples\n- Draw ASCII dependency diagrams, sequence diagrams, and interaction matrices\n- Show cross-system connections: how systems communicate, what triggers what, where data flows\n- Prefer \"how things connect\" over \"what things exist\" — connections are more valuable than catalogs\n\n#### State B: Split Existing README\n\n1. Analyze which sections should stay (landing page) vs move to docs\u002F\n2. Propose split plan to user\n3. Execute with confirmation\n4. Verify no content lost — every section from old README must exist somewhere\n\n#### State C: Improve Existing Docs\n\n1. **Audit:**\n   - README length (is it still a landing page, \u003C150 lines?)\n   - Missing topics (aspects of the project not documented)\n   - Stale content (references to files\u002FAPIs that no longer exist)\n   - Navigation (all docs have prev\u002Fnext + See Also?)\n   - Broken links (verify all internal links)\n   - Consistency (same formatting across all docs)\n2. **Propose improvements** with status indicators per item\n3. **Apply fixes** after user confirmation\n\n### Step 4: Documentation Review\n\n**Mandatory after any content change.** Read every generated\u002Fmodified file and run the full review.\n\nFor comprehensive checklists (Technical, {{engine_name}}-Specific, \"New User Eyes\" readability, Standards Compliance) → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FREVIEW-CHECKLISTS.md`.\n\nKey areas to verify:\n- **Technical accuracy** — file paths, class names, framework versions, assembly references match reality\n- **Readability** — prev\u002Fnext navigation, \"See Also\" sections, proper table formatting, no placeholders\n- **Language** — all prose in project language from `.unikit\u002Fconfig.yaml` (`language.artifacts`); code identifiers and file names in English\n- **Standards compliance** — gaps detected per checklist auto-fix table\n\nFix issues before presenting result to the user.\n\n### Step 5: Clean Up Moved Files\n\nIf files were moved from root into docs\u002F (Step 2.1) — offer to delete originals after review confirms content is preserved.\n\nAlways ask before deleting. The user may want to keep originals temporarily.\n\n### Step 6: HTML Generation (--web)\n\nWhen `--web` flag is passed:\n\nFor the complete conversion process, template placeholders, nav_links format, markdown→HTML conversion rules, and auto-features documentation → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FHTML-GENERATION.md`.\n\nSummary of the process:\n\n1. Create `docs-html\u002F` directory\n2. Read `{{skills_dir}}\u002F{{self_name}}\u002Ftemplates\u002Fhtml-template.html` (use as base for all pages)\n3. For each markdown file → convert to HTML following conversion rules from `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FHTML-GENERATION.md`\n4. Replace template placeholders (`{project_name}`, `{page_title}`, `{nav_links}`, `{content}`, `{prev_link}`, `{next_link}`)\n5. Fix `.md` links to `.html`\n6. Generate navigation sidebar with `class=\"active\"` on current page\n7. Add `docs-html\u002F` to `.gitignore` if not already there\n\nFile mapping: `README.md` → `index.html`, `docs\u002F*.md` → `*.html`. The `docs\u002F*.md` glob is\n**intentionally top-level \u002F non-recursive** — it does **not** descend into `docs\u002Fdesign\u002F**`,\nwhich is owned and rendered (Markdown and, under its own `--web`, HTML) by `\u002Funikit-gd-docs`,\nthe game-design GDD export. Never relink, convert, or overwrite a `docs\u002Fdesign\u002F` page.\n\n### Step 7: Update AGENTS.md\n\nIf `AGENTS.md` exists, update its `## Documentation` section:\n\n```markdown\n## Documentation\n\n| Document | Path | Description |\n|----------|------|-------------|\n| README | README.md | Project landing page |\n| Getting Started | docs\u002Fgetting-started.md | Installation and setup |\n| Architecture | docs\u002Farchitecture.md | Project structure and patterns |\n| ... | ... | ... |\n```\n\nList README first, then docs\u002F files in Documentation table order. Keep descriptions concise (\u003C10 words).\n\n### Step 8: Save docs-config.json\n\nIf config was generated in Step 1.3, save to `.unikit\u002Fdocs-config.json`. This allows future runs to skip detection and respect user customizations.\n\n### Context Cleanup\n\nSuggest the user to free up context space if needed: `\u002Fclear` (full reset) or `\u002Fcompact` (compress history).\n\n## Important Rules\n\n1. **Detection first** — never assume specific frameworks or folder structures. Scan, then decide.\n2. **Always ask before changes** to existing documentation — show the plan first.\n3. **Never delete content** without moving it somewhere else first.\n4. **Detect real project info** — don't invent features; read actual files.\n5. **Use project language** from `.unikit\u002Fconfig.yaml` (`language.artifacts`) for all prose, headings, navigation, descriptions, and user-facing messages. File names, code identifiers, and framework names stay in English.\n6. **Preserve existing content** — badges, logos, custom sections in README.\n7. **Ownership boundary** — this skill owns `README.md`, the **top-level** `docs\u002F*.md` (the non-design pages), `docs-html\u002F*`, `.unikit\u002Fdocs-config.json`, and the Documentation section in `AGENTS.md`. It does NOT own `docs\u002Fdesign\u002F**` (the game-design GDD render, owned by `\u002Funikit-gd-docs`), `.unikit\u002FARCHITECTURE.md`, `.unikit\u002FRULES.md`, or `.unikit\u002FDESCRIPTION.md`.\n8. **Don't duplicate .unikit\u002F content** — if `ARCHITECTURE.md` (the root and its topic files) or `DESCRIPTION.md` exist in `.unikit\u002F`, use them as source material and enrich, don't copy verbatim.\n9. **NEVER add `Co-Authored-By`** or any AI attribution trailers to commits.\n10. **Agent-based delegation** — use the `recon-agent` alias for deep code analysis. If Agent tool is unavailable, fall back to inline work (Glob\u002FGrep\u002FRead). Lightweight Glob\u002FGrep for quick checks is always allowed without delegation.\n","# Docs — Project Documentation Generator\n\nGenerate, maintain, and improve documentation for game projects following a landing-page README + detailed docs\u002F structure.\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## Core Principles\n\n1. **README is a landing page, not a manual.** ~80-120 lines. First impression, tech stack, quick start, links to details.\n2. **Details go to `docs\u002F`.** Each file is self-contained — one topic, one page.\n3. **No duplication.** If information lives in `docs\u002F`, README links to it — does not repeat it.\n4. **Detection-first.** Scan the project before deciding which documents to generate. Never assume specific frameworks, folder structures, or patterns — discover them.\n5. **Navigation.** Every docs\u002F file has a header line with prev\u002Fnext links following the Documentation table order. Every page ends with a \"See Also\" section linking to 2-3 related pages.\n6. **Scannable.** Use tables, bullet lists, and code blocks. Avoid long paragraphs.\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\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- **`recon-agent`** — read-only parallel reconnaissance. Expands to:\n\n  ```\n  Agent({{agent_call_reader}} prompt: \"\u003Cfocused question> You are read-only: edit and write nothing.\")\n  ```\n\n  Every question you send ends with the sentence `You are read-only: edit and write nothing.`, verbatim.\n\n  Fallback: if the `Agent` tool is unavailable, investigate inline with `Glob`\u002F`Grep`\u002F`Read`.\n\n## Skill-specific rules:\n- Navigation text is translated to the configured language (`[\u003C- Предыдущая]`, `Назад к README`, `Далее ->`, `См. также`)\n- `docs-config.json` is NOT translated — it stays in English (machine-readable config)\n\n## Workflow\n\n### Step 0: Load Project Context\n\n1. Read `.unikit\u002Fconfig.yaml` — extract `language.ui` and `language.artifacts` (all subsequent output uses these language settings)\n2. Read `.unikit\u002FDESCRIPTION.md` (if exists) — project overview, tech stack\n3. Read `.unikit\u002FARCHITECTURE.md` (if exists) — architecture decisions, module structure. **Architecture topics:** read the root and every topic file listed under its `## Topics`; a missing file → `WARN [architecture] topic file missing: .unikit\u002Farchitecture\u002F\u003Cslug>.md`, continue.\n4. Read `.unikit\u002Fskill-context\u002Funikit-docs\u002FSKILL.md` — **MANDATORY if exists.** Project-specific overrides. Skill-context rules win over general rules on conflict.\n5. Read `AGENTS.md` (if exists) — current documentation index\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n### Step 0.1: Parse Flags\n\n```\n--web → Also generate HTML version of documentation (see Step 6)\n```\n\n### Step 1: Auto-Detect Project\n\nThis is the heart of universality. Scan the project to understand its real structure before generating anything.\n\n#### 1.1: Load Engine Rules\n\nRead `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FENGINE_RULES.md` — this file is installed by the unikit setup and contains all engine-specific detection tables, folder structure patterns, module boundary mechanism, and deep analysis patterns for the current project's engine.\n\n#### 1.2: Detect Tech Stack\n\nUsing the detection tables from the loaded engine rules file, scan the project's package manifest and plugin directories for known frameworks.\n\nRecord detected stack — it determines which conditional documents to generate.\n\n#### 1.3: Detect Folder Structure\n\nUsing the folder structure patterns from the loaded engine rules file, scan the project for script locations, modular structures, special folders, scenes, and tests. Don't assume any specific structure — discover it.\n\nAlso scan for module boundary files (per engine rules) to map the project's module\u002Fassembly structure.\n\n#### 1.4: Load or Generate docs-config.json\n\nCheck if `.unikit\u002Fdocs-config.json` exists:\n\n**If exists** → load it, then run reconciliation (Step 1.5) to sync config with reality.\n\n**If not exists** → generate based on detection results:\n\n```json\n{\n  \"detected_stack\": {\n    \"engine\": \"{{engine_name}} 6 (6000.0.68f1)\",\n    \"di\": \"Zenject\",\n    \"async\": \"UniTask\",\n    \"events\": \"Custom SignalBus\",\n    \"ui\": \"ASPID MVVM\",\n    \"reactive\": \"R3\"\n  },\n  \"scan_paths\": {\n    \"scripts\": [\"Assets\u002FGame\u002FScripts\"],\n    \"modules\": [\"Assets\u002FModules\", \"Assets\u002FModules\u002FPawnshop\"],\n    \"scenes\": [\"Assets\u002FGame\u002FScenes\"],\n    \"editor\": [\"Assets\u002FEditor\", \"Assets\u002FGame\u002FScripts\u002FEditor\"],\n    \"tests\": [\"Assets\u002FGame\u002FTests\"]\n  },\n  \"exclude_paths\": [\n    \"Assets\u002FPlugins\",\n    \"Assets\u002FThird-Party Assets\"\n  ],\n  \"documents\": {\n    \"core\": [\"readme\", \"getting-started\", \"architecture\", \"project-map\"],\n    \"conditional\": [\"di-bindings\", \"events\", \"save-system\", \"game-systems\", \"testing\", \"editor-tools\"]\n  },\n  \"output_dir\": \"docs\"\n}\n```\n\nPresent the generated config to the user for confirmation before proceeding. This is their chance to add paths, remove documents, or adjust detection results.\n\n**Conditional document rules — generate only if detected:**\n\n| Document | Generate when |\n|----------|--------------|\n| `di-bindings` | DI framework detected (Zenject, VContainer, etc.) |\n| `events` | Event\u002Fsignal system detected |\n| `save-system` | Save serialization classes detected |\n| `game-systems` | Gameplay controllers, FSM, AI systems detected |\n| `testing` | Test assembly definitions detected |\n| `editor-tools` | Custom Editor scripts detected |\n| `build` | Addressables or custom build pipeline detected |\n| `ui-system` | UI framework beyond basic UGUI detected |\n\n#### 1.5: Reconciliation (config vs reality)\n\nWhen `docs-config.json` already exists, run a three-way comparison: **config** vs **detected state** vs **existing docs\u002F**. This ensures the config stays in sync as the project evolves.\n\n**a) Validate scan_paths — do configured paths still exist?**\n\nFor each path in `scan_paths`, check if it exists on disk:\n- Path exists → scan it normally\n- Path missing → `WARN`: \"Path `Assets\u002FOldFolder` from config not found. Remove from config?\"\n- Offer to remove dead paths. Don't auto-remove — the path might be temporarily missing (branch switch, pending asset import).\n\n**b) Detect new paths — did the project grow?**\n\nScan `Assets\u002F` for common script locations (same list from Step 1.2). If a new populated folder is found that isn't in `scan_paths` or `exclude_paths`:\n- `INFO`: \"Found `Assets\u002FNewModule\u002F` with scripts — not in config. Add to scan_paths?\"\n- Offer to add. Don't force — the user may intentionally exclude it.\n\n**c) Reconcile tech stack — did packages change?**\n\nRe-run detection (Step 1.1) and compare with `detected_stack` in config:\n\n| Situation | Action |\n|-----------|--------|\n| New framework found (not in config) | Suggest: \"Detected Mirror in manifest.json. Add `networking` document?\" → update config + generate doc |\n| Framework removed (in config but not detected) | Suggest: \"Zenject no longer detected. Keep `di-bindings` document?\" → user decides |\n| Version changed | Silently update `detected_stack` in config |\n\n**d) Reconcile documents — config vs docs\u002F folder**\n\n| Situation | Action |\n|-----------|--------|\n| Document in config but no file in docs\u002F | Generate it (probably new addition by user) |\n| Document NOT in config but file exists in docs\u002F | Do NOT delete. Skip updates. Warn: \"`docs\u002Fsave-system.md` exists but is not in config — it won't be updated\" |\n| Document in config, file exists | Update normally (State C behavior) |\n| **Any file under `docs\u002Fdesign\u002F**`** | **Out of scope — owned by `\u002Funikit-gd-docs`.** Do NOT warn, suggest, absorb into config, or touch it. Only the **top-level** `docs\u002F*.md` is reconciled here. |\n\n**e) Present reconciliation report**\n\nIf any discrepancies found, show a summary before proceeding:\n\n```\nConfig reconciliation:\n\nPaths:\n  ✅ Assets\u002FGame\u002FScripts — exists\n  ✅ Assets\u002FModules — exists\n  ⚠️ Assets\u002FOldFolder — not found (remove from config?)\n  🔍 Assets\u002FNewFeature\u002F — found, not in config (add?)\n\nTech stack:\n  ✅ DI: Zenject — unchanged\n  🔍 Networking: Mirror — detected, not in config\n  ❌ Save: Custom SaveSerializer — no longer detected\n\nDocuments:\n  ✅ 4 core + 3 conditional — in sync\n  🔍 networking — suggested (Mirror detected)\n  ⚠️ docs\u002Fsave-system.md — exists but removed from config\n\n```\n\nThen ask with the question tool of your agent (`AskUserQuestion`): Apply suggestions?\n\nOptions:\n1. Apply all\n2. Let me pick\n3. Skip — use config as-is\n\nBased on choice:\n- Apply all → update `docs-config.json` with all suggestions, proceed to Step 1.6\n- Let me pick → ask for each suggestion with the question tool of your agent (`AskUserQuestion`): `Apply` (recommended) or `Skip`; apply the selected\n- Skip → use config as-is, proceed to Step 1.6\n\nAfter reconciliation, update `docs-config.json` with confirmed changes and proceed to Step 1.5.\n\n### Step 1.6: Deep Code Analysis\n\nBefore generating any documents, systematically explore the codebase to build a deep understanding of how systems connect. This step transforms surface-level detection (Step 1) into the rich relationship map that makes documentation truly valuable.\n\n**This step is mandatory.** Shallow detection produces shallow docs — catalogs of classes without explaining how they work together. The quality of documentation directly depends on the depth of analysis performed here.\n\nLaunch multiple exploration tasks in parallel using the `recon-agent` alias (declared in `## Delegation agents`) to cover different analysis dimensions. Each substep below (1.6.1–1.6.4) should be a separate `recon-agent` dispatch with a focused prompt.\n\n**Fallback:** If Agent tool is unavailable, perform analysis inline using Glob\u002FGrep\u002FRead.\n\n#### 1.6.1: Bootstrap & Initialization Chain\n\nTrace the full startup sequence from entry scene to gameplay-ready state:\n- Find the entry scene → identify root GameObjects with context components\n- Find ALL `*Installer.cs` files → read each one fully, extract every binding\n- Map the initialization order: loading operations → IInitializable chain → NonLazy activations\n- Trace loading operation dependencies (what must complete before what)\n\n**Output:** Ordered initialization graph with dependencies between steps.\n\n#### 1.6.2: Complete Communication Map\n\nBuild a full catalog of ALL inter-system communication — not just the obvious signals:\n\n**SignalBus events:**\n- Find ALL `ISignal` implementations (grep `: ISignal` in all project `.cs` files)\n- For each signal: find every `Invoke\u003CSignal>` (publishers) and `Subscribe\u003CSignal>` (subscribers)\n- Detect signal chains — when a signal handler triggers another signal\n\n**R3 reactive streams:**\n- Find all `ReactiveProperty\u003C>`, `Subject\u003C>`, `ReadOnlyReactiveProperty\u003C>` declarations\n- Trace who subscribes to each stream (`.Subscribe()`, `.Select()`, `.Where()`, `.Switch()`)\n- Map the reactive data flow: Model → ViewModel → View\n\n**Direct DI dependencies:**\n- Read constructor parameters of key services to build the dependency graph\n- Identify hub services (injected by 3+ consumers)\n\n**Output:** Complete communication topology with three layers: signals, reactive streams, DI dependencies.\n\n#### 1.6.3: End-to-End Feature Flows\n\nTrace 2-3 key user-facing features from trigger to completion:\n- Start from user action or external trigger\n- Follow through every system touched: controller → service → model → view → save\n- Note every signal fired, every observable updated, every state change\n- Identify cross-module boundaries crossed\n- Record the communication mechanism at each step (DI call, signal, R3 stream, direct call)\n\nPick flows that touch the most systems — these reveal the real architecture.\n\n**Output:** Step-by-step sequence for each flow with class names and mechanisms at each boundary.\n\n#### 1.6.4: Cross-System Interaction Matrix\n\nBuild a matrix showing how major systems interact:\n\n```\n             | Characters | Trade | MiniGames | Wallets | Save | UI\nCharacters   |     —      |  DI   |   Signal  |   —     |  —   | R3\nTrade        |    DI      |   —   |     DI    |   DI    | Save | Signal\n```\n\nFor each non-empty cell: note the mechanism (DI, Signal, R3, Direct) and direction.\n\n**Output:** Interaction matrix with mechanism annotations + list of hub systems.\n\n#### 1.6.5: Consolidate Analysis\n\nMerge outputs from all parallel Agent results. This analysis is NOT published — it feeds into Step 3 to produce rich, connected documentation.\n\nKey things to capture:\n- Hub systems (many connections) vs isolated modules\n- Data that flows through many systems (e.g., customer data, wallet balance)\n- Recurring patterns across the codebase (Controller pattern, SaveSerializer pattern, etc.)\n- Surprising or non-obvious connections between systems\n- Any circular dependencies or architectural concerns\n\n### Step 2: Determine Current State\n\n```\nState A: No README.md                → Full generation (README + docs\u002F)\nState B: README.md exists, no docs\u002F  → Analyze README, propose split into docs\u002F\nState C: README.md + docs\u002F exist     → Audit and improve\n```\n\n**State C with `--web` flag** — ask the user:\n\n```\nDocumentation already exists (README.md + docs\u002F).\n\nOptions:\n1. Generate HTML only — build site from current docs\n2. Audit & improve first — check for issues, then generate HTML\n3. Audit only — check without generating HTML\n```\n\nBased on choice:\n- HTML only → skip Steps 3–5, proceed directly to Step 6 (HTML Generation) → **STOP** (do not run Steps 7, 8 — no markdown content was changed)\n- Audit & improve → run State C audit (Step 3, State C), fix issues, then proceed to Step 6\n- Audit only → run State C audit, report issues → **STOP**\n\n### Step 2.1: Check for Scattered Markdown Files\n\nScan project root for `.md` files. Propose consolidating relevant ones into `docs\u002F`:\n\n| Root file | Target in docs\u002F | Action |\n|-----------|-----------------|--------|\n| `CONTRIBUTING.md` | `docs\u002Fcontributing.md` | Move |\n| `ARCHITECTURE.md` | `docs\u002Farchitecture.md` | Move |\n| `SETUP.md` | `docs\u002Fgetting-started.md` | Merge |\n| `TESTING.md` | `docs\u002Ftesting.md` | Move |\n\n**Files that stay in root:** `README.md`, `CHANGELOG.md`, `LICENSE`, `CODE_OF_CONDUCT.md`, `AGENTS.md`.\n\nAlways ask before moving. Never force-move files.\n\n### Step 3: Generate Documents\n\n#### State A: Full Generation\n\n##### 3.1: Confirm document list\n\nPresent detected documents to the user:\n\n```\nBased on project scan:\n\nCore documents (always generated):\n  ✅ README.md — project landing page\n  ✅ docs\u002Fgetting-started.md — setup, prerequisites, first run\n  ✅ docs\u002Farchitecture.md — project structure and patterns\n  ✅ docs\u002Fproject-map.md — modules, assemblies, namespaces\n\nConditional documents (detected):\n  ✅ docs\u002Fdi-bindings.md — [FrameworkName] installer map\n  ✅ docs\u002Fevents.md — event system catalog\n  ✅ docs\u002Ftesting.md — test infrastructure\n  ❌ docs\u002Fnetworking.md — no networking framework detected\n\n```\n\nThen ask with the question tool of your agent (`AskUserQuestion`): Which documents should be generated?\n\nOptions:\n1. Generate all detected\n2. Let me pick\n3. Add more topics\n\nBased on choice:\n- Generate all detected → proceed to Step 3.2 with full document list\n- Let me pick → ask for each document with the question tool of your agent (`AskUserQuestion`): `Generate` (recommended) or `Skip`; generate only the selected\n- Add more topics → ask for the additional topics with the question tool of your agent (`AskUserQuestion`): its options are the conditional documents of the Step 1.4 table that were not detected, and the user writes their own topics in the free-text answer; merge with the detected list, re-confirm\n\n##### 3.2: Generate README.md\n\nFor the README template and content guidelines → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FDOC-TEMPLATES.md` (README section).\n\nKey rules:\n- Tech Stack table derived from `detected_stack`\n- Quick Start with real engine version (per engine rules: version detection method)\n- Key Features from `.unikit\u002FDESCRIPTION.md` or codebase scan\n- Documentation table linking to all generated docs\u002F pages\n- ~80-120 lines total\n\n##### 3.3: Generate docs\u002F files\n\nFor content guidelines per document type → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FDOC-TEMPLATES.md`.\n\nEvery file follows this structure (navigation text in project language):\n\n```markdown\n[\u003C- Previous](prev.md) . [Back to README](..\u002FREADME.md) . [Next ->](next.md)\n\n# Topic Title\n\nContent with tables, code blocks, diagrams.\n\n## See Also\n\n- [Related Topic](topic.md) — brief description\n```\n\nNavigation text is translated to the project language. For example, with `\"language\": \"ru\"`:\n```markdown\n[\u003C- Предыдущая](prev.md) . [Назад к README](..\u002FREADME.md) . [Далее ->](next.md)\n## См. также\n```\n\n**Navigation link order** follows the Documentation table in README.md. First page omits prev link; last page omits next link.\n\n**Content generation approach:**\n- Use the deep analysis from Step 1.6 as the primary source — it contains the communication map, dependency chains, and feature flows\n- Supplement with a `recon-agent` dispatch for specific details not covered by the analysis. Fallback: If Agent tool is unavailable, use Glob\u002FGrep\u002FRead inline\n- For each document, verify against actual code — don't guess at structures\n- Include real class names, real file paths, real namespace examples\n- Draw ASCII dependency diagrams, sequence diagrams, and interaction matrices\n- Show cross-system connections: how systems communicate, what triggers what, where data flows\n- Prefer \"how things connect\" over \"what things exist\" — connections are more valuable than catalogs\n\n#### State B: Split Existing README\n\n1. Analyze which sections should stay (landing page) vs move to docs\u002F\n2. Propose split plan to user\n3. Execute with confirmation\n4. Verify no content lost — every section from old README must exist somewhere\n\n#### State C: Improve Existing Docs\n\n1. **Audit:**\n   - README length (is it still a landing page, \u003C150 lines?)\n   - Missing topics (aspects of the project not documented)\n   - Stale content (references to files\u002FAPIs that no longer exist)\n   - Navigation (all docs have prev\u002Fnext + See Also?)\n   - Broken links (verify all internal links)\n   - Consistency (same formatting across all docs)\n2. **Propose improvements** with status indicators per item\n3. **Apply fixes** after user confirmation\n\n### Step 4: Documentation Review\n\n**Mandatory after any content change.** Read every generated\u002Fmodified file and run the full review.\n\nFor comprehensive checklists (Technical, {{engine_name}}-Specific, \"New User Eyes\" readability, Standards Compliance) → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FREVIEW-CHECKLISTS.md`.\n\nKey areas to verify:\n- **Technical accuracy** — file paths, class names, framework versions, assembly references match reality\n- **Readability** — prev\u002Fnext navigation, \"See Also\" sections, proper table formatting, no placeholders\n- **Language** — all prose in project language from `.unikit\u002Fconfig.yaml` (`language.artifacts`); code identifiers and file names in English\n- **Standards compliance** — gaps detected per checklist auto-fix table\n\nFix issues before presenting result to the user.\n\n### Step 5: Clean Up Moved Files\n\nIf files were moved from root into docs\u002F (Step 2.1) — offer to delete originals after review confirms content is preserved.\n\nAlways ask before deleting. The user may want to keep originals temporarily.\n\n### Step 6: HTML Generation (--web)\n\nWhen `--web` flag is passed:\n\nFor the complete conversion process, template placeholders, nav_links format, markdown→HTML conversion rules, and auto-features documentation → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FHTML-GENERATION.md`.\n\nSummary of the process:\n\n1. Create `docs-html\u002F` directory\n2. Read `{{skills_dir}}\u002F{{self_name}}\u002Ftemplates\u002Fhtml-template.html` (use as base for all pages)\n3. For each markdown file → convert to HTML following conversion rules from `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002FHTML-GENERATION.md`\n4. Replace template placeholders (`{project_name}`, `{page_title}`, `{nav_links}`, `{content}`, `{prev_link}`, `{next_link}`)\n5. Fix `.md` links to `.html`\n6. Generate navigation sidebar with `class=\"active\"` on current page\n7. Add `docs-html\u002F` to `.gitignore` if not already there\n\nFile mapping: `README.md` → `index.html`, `docs\u002F*.md` → `*.html`. The `docs\u002F*.md` glob is\n**intentionally top-level \u002F non-recursive** — it does **not** descend into `docs\u002Fdesign\u002F**`,\nwhich is owned and rendered (Markdown and, under its own `--web`, HTML) by `\u002Funikit-gd-docs`,\nthe game-design GDD export. Never relink, convert, or overwrite a `docs\u002Fdesign\u002F` page.\n\n### Step 7: Update AGENTS.md\n\nIf `AGENTS.md` exists, update its `## Documentation` section:\n\n```markdown\n## Documentation\n\n| Document | Path | Description |\n|----------|------|-------------|\n| README | README.md | Project landing page |\n| Getting Started | docs\u002Fgetting-started.md | Installation and setup |\n| Architecture | docs\u002Farchitecture.md | Project structure and patterns |\n| ... | ... | ... |\n```\n\nList README first, then docs\u002F files in Documentation table order. Keep descriptions concise (\u003C10 words).\n\n### Step 8: Save docs-config.json\n\nIf config was generated in Step 1.3, save to `.unikit\u002Fdocs-config.json`. This allows future runs to skip detection and respect user customizations.\n\n### Context Cleanup\n\nSuggest the user to free up context space if needed: `\u002Fclear` (full reset) or `\u002Fcompact` (compress history).\n\n## Important Rules\n\n1. **Detection first** — never assume specific frameworks or folder structures. Scan, then decide.\n2. **Always ask before changes** to existing documentation — show the plan first.\n3. **Never delete content** without moving it somewhere else first.\n4. **Detect real project info** — don't invent features; read actual files.\n5. **Use project language** from `.unikit\u002Fconfig.yaml` (`language.artifacts`) for all prose, headings, navigation, descriptions, and user-facing messages. File names, code identifiers, and framework names stay in English.\n6. **Preserve existing content** — badges, logos, custom sections in README.\n7. **Ownership boundary** — this skill owns `README.md`, the **top-level** `docs\u002F*.md` (the non-design pages), `docs-html\u002F*`, `.unikit\u002Fdocs-config.json`, and the Documentation section in `AGENTS.md`. It does NOT own `docs\u002Fdesign\u002F**` (the game-design GDD render, owned by `\u002Funikit-gd-docs`), `.unikit\u002FARCHITECTURE.md`, `.unikit\u002FRULES.md`, or `.unikit\u002FDESCRIPTION.md`.\n8. **Don't duplicate .unikit\u002F content** — if `ARCHITECTURE.md` (the root and its topic files) or `DESCRIPTION.md` exist in `.unikit\u002F`, use them as source material and enrich, don't copy verbatim.\n9. **NEVER add `Co-Authored-By`** or any AI attribution trailers to commits.\n10. **Agent-based delegation** — use the `recon-agent` alias for deep code analysis. If Agent tool is unavailable, fall back to inline work (Glob\u002FGrep\u002FRead). Lightweight Glob\u002FGrep for quick checks is always allowed without delegation.\n",{"name":5,"metadata":55,"description":7,"allowed-tools":59,"argument-hint":68,"user-invocable":69,"disable-model-invocation":51},{"author":56,"version":57,"category":58},"unikit","1.1","documentation",[60,61,62,63,64,65,66,67],"Read","Write","Edit","Glob","Grep","Bash(mkdir,ls)","AskUserQuestion","Agent","[--web]",true,"main","ae3c6dfffd26d9b45b9d96d71ba2c122c50b67ae","skills\u002Funikit-docs",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":80,"prompt":90,"zipAvailable":69},[81,84,87],{"tool":82,"command":83},"npx","npx skills add NintendaDev\u002Funikit-ai --skill unikit-docs",{"tool":85,"command":86},"bunx","bunx skills add NintendaDev\u002Funikit-ai --skill unikit-docs",{"tool":88,"command":89},"pnpm","pnpm dlx skills add NintendaDev\u002Funikit-ai --skill unikit-docs","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-docs\u002FSKILL.md",[92,98,102,106],{"path":93,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":96,"sourceHtmlUrl":97},"references\u002FDOC-TEMPLATES.md","REFERENCE","参考文档",14837,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-docs\u002Freferences\u002FDOC-TEMPLATES.md",{"path":99,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":100,"sourceHtmlUrl":101},"references\u002FHTML-GENERATION.md",7772,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-docs\u002Freferences\u002FHTML-GENERATION.md",{"path":103,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002FREVIEW-CHECKLISTS.md",5551,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-docs\u002Freferences\u002FREVIEW-CHECKLISTS.md",{"path":107,"resourceType":94,"resourceTypeDesc":95,"sizeBytes":108,"sourceHtmlUrl":109},"templates\u002Fhtml-template.html",31938,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-docs\u002Ftemplates\u002Fhtml-template.html",[111,129,154,176,196,220],{"skillNo":112,"name":56,"nameZh":6,"description":113,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":114,"categories":115,"keywords":117,"publishedAt":50},"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",[116],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[56,47,118,119,120,44,43,40,121,37,36,35,122,34,123,124,125,126,127,128],"time","actions","fix","run","config","git","context","initialize","tech","scan","use",{"skillNo":130,"name":131,"nameZh":6,"description":132,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":133,"categories":134,"keywords":139,"publishedAt":50},"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",[135,138],{"categoryNo":136,"categoryName":137,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[140,141,142,143,144,145,121,36,35,34,123,146,147,128,148,149,150,151,152,153],"unikit verify","verify","powershell","code review","phase","plan","for","system","implement","check","engine","research","name","quality",{"skillNo":155,"name":156,"nameZh":6,"description":157,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":158,"categories":159,"keywords":160,"publishedAt":50},"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",[],[161,162,163,164,47,165,166,167,168,169,170,171,145,172,173,174,36,35,34,175],"unikit todo","todo","remind","show","todo list","only","now","you","done","tasks","work","me","reminders","later","act",{"skillNo":177,"name":178,"nameZh":6,"description":179,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":180,"categories":181,"keywords":183,"publishedAt":50},"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",[182],{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[184,124,47,120,185,186,187,188,189,190,191,192,162,193,194,121,195,36,35,34],"unikit skills context","coding conventions","writing","when","workflow","commit","review","general coding","text","change","how","past",{"skillNo":197,"name":198,"nameZh":6,"description":199,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":200,"categories":201,"keywords":207,"publishedAt":50},"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",[202,203,206],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},{"categoryNo":204,"categoryName":205,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":27,"categoryName":28,"taxonomyType":21,"taxonomyTypeDesc":22},[208,209,210,211,47,212,213,214,215,216,43,217,192,218,40,174,36,35,34,219],"Rules","unikit rules","quick","PDF","clean","knowledge","files","URL","migrate","batch","knowledge base","prune",{"skillNo":221,"name":222,"nameZh":6,"description":223,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":224,"categories":225,"keywords":226,"publishedAt":50},"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",[],[227,208,228,229,47,230,213,231,216,42,37,36,35,123,232,233,234,235,236,237],"registry","unikit rules registry","shared","local","remote","ai rules","automatic","semver","knowledge-base","as","three"]