[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"skill:01M71BMJHWFR1C3B19ZASS7HS3":3,"skill-same:01M71BMJHWFR1C3B19ZASS7HS3":122},{"skillNo":4,"name":5,"nameZh":6,"description":7,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":16,"categories":17,"keywords":28,"publishedAt":49,"linkOnly":50,"markdownContent":51,"markdownBody":52,"frontMatter":53,"refName":78,"commitSha":79,"skillDirectory":80,"forksCount":81,"repositoryHtmlUrl":82,"repositoryHomepageUrl":83,"ownerHtmlUrl":84,"ownerBlogUrl":6,"ownerDescription":85,"updatedAt":86,"install":87,"resources":99},"01M71BMJHWFR1C3B19ZASS7HS3","unikit-implement",null,"Execute the tasks from an already-created feature plan in .unikit\u002Fcode\u002Fplans\u002F — read the plan manifest (the PLAN.md file in the plan folder), work through the uncompleted tasks in order, write the code, mark progress, and resume across sessions. Supports selective runs by phase or by task numbers, and continuing from where the last session stopped. Use whenever a plan exists and the user wants to build it, e.g. \"implement\", \"implement the plan\", \"start coding\", \"execute the plan\", \"run the plan\", \"do the next task\", \"implement phase 3\", \"implement tasks 2.1 and 2.3\", \"continue implementation\", \"continue where we left off\", \"keep going on the feature\". To create the plan first, use the planning skill — this one carries an existing plan out.","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-implement\u002FSKILL.md",[18,23],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000023","Skill与智能体开发","SCENARIO","使用场景",{"categoryNo":24,"categoryName":25,"taxonomyType":26,"taxonomyTypeDesc":27},"01JBSEEDCAT000000000000038","人力资源","PROFESSION","适用职业",[29,30,31,32,33,34,35,36,37,38,39,40,41,42,43,44,45,46,47,48],"unikit implement","implement","sessions","system","for","plan first","do","coding","list","start","status","git","edit","write","read","run","plan","create","phase","powershell","2026-11-10 10:12:30",false,"---\nname: unikit-implement\ndescription: >-\n  Execute the tasks from an already-created feature plan in .unikit\u002Fcode\u002Fplans\u002F — read\n  the plan manifest (the PLAN.md file in the plan folder), work through the uncompleted\n  tasks in order, write\n  the code, mark progress, and resume across sessions. Supports\n  selective runs by phase or by task numbers, and continuing from where the last session\n  stopped. Use whenever a plan exists and the user wants to build it, e.g. \"implement\",\n  \"implement the plan\", \"start coding\", \"execute the plan\", \"run the plan\", \"do the next\n  task\", \"implement phase 3\", \"implement tasks 2.1 and 2.3\", \"continue implementation\",\n  \"continue where we left off\", \"keep going on the feature\". To create the plan first,\n  use the planning skill — this one carries an existing plan out.\nargument-hint: \"[--list] [@\u003Cfolder>] [Phase N | Phases N-M | Tasks N.M N.K | status | empty for all pending]\"\nallowed-tools:\n  - Read\n  - Write\n  - Edit\n  - Glob\n  - Grep\n  - Bash(ls *)\n  - Bash(find *)\n  - Bash(wc *)\n  - Bash(git *)\n  - Bash(date *)\n  - Bash(node .unikit\u002Fsystem\u002Fresearch-hash.mjs *)\n  - PowerShell(node .unikit\u002Fsystem\u002Fresearch-hash.mjs *)\n  - Bash(node .unikit\u002Fsystem\u002Ftree-hash.mjs *)\n  - PowerShell(node .unikit\u002Fsystem\u002Ftree-hash.mjs *)\n  - Agent\n  - Skill\n  - AskUserQuestion\ndisable-model-invocation: false\nuser-invocable: true\nmetadata:\n  author: unikit\n  version: \"2.6\"\n  category: implementation\n---\n\n# {{engine_name}} Feature Implementation\n\nExecute the tasks of a feature plan stored in `.unikit\u002Fcode\u002Fplans\u002F`, inline, after a one-time Bootstrap of rules and principles.\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\n## Delegation agents\n\n- **`develop-agent`** — only for a true parallel scope or a deep-dive single task. Expands to:\n\n  ```\n  Agent(\n    {{agent_call_worker_quoted}}\n    prompt: \"{{agent_skill_call:unikit-execute}} Delegated hand-off: \u003Ctask details>\",\n    description: \"Implement \u003Ctask>\"\n  )\n  ```\n\n  `\u003Ctask details>` is a closed hand-off — what it must carry: Step 3.2, *Delegated execution*.\n\n- **`docs-agent`** — update or create documentation. Expands to:\n\n  ```\n  Agent(\n    {{agent_call_worker_quoted}}\n    prompt: \"{{agent_skill_call:unikit-docs}} \u003Ccontext>\",\n    description: \"Update documentation\"\n  )\n  ```\n\n## Skill calls\n\nWhere this skill says to **invoke `\u003Cskill>`** — optionally \"with the argument `\u003Ctext>`\" — it means one call, made in this session, now, on every runtime: not a command printed for the user and not a delegation (delegations are the aliases of `## Delegation agents`). A call site that names no argument passes none.\n\n1. If you have a `Skill` tool that accepts arguments, call it with that skill and the arguments of the call site, in full and unchanged, then follow the skill.\n2. Otherwise — no `Skill` tool, or one that takes only a name — Read `{{skills_dir}}\u002F\u003Cskill>\u002FSKILL.md` in full, treat it as the instructions of this step and carry them out here, in this session, now, with the arguments of the call site as the skill's arguments.\n3. When the skill has run, go on to the step the call site names. Do not print a command for the user to run and do not stop.\n4. Only if that file cannot be read: print `Run: \u002Funikit-\u003Cskill> \u003Carguments>` for the user and stop.\n\n## Input\n\n`$ARGUMENTS` — optional; any mix of:\n- **empty** — every pending task of the resolved plan, in dependency order\n- **`--list`** — list the plans in `.unikit\u002Fcode\u002Fplans\u002F` and STOP\n- **`@\u003Cpath>`** — an explicit plan folder, resolved from the project root (absolute paths work too), holding the manifest `\u003Cpath>\u002FPLAN.md`; no searching, highest priority\n- **`status`** — show progress, execute nothing\n- **selectors** — `Phase N`, `Phases N-M`, `Task N.M`, `Tasks N.M N.K`\n- **a feature name** (e.g. `core-loop`) — a substring match against the folder names in `.unikit\u002Fcode\u002Fplans\u002F`\n- **a test-run instruction** (e.g. `tests at the end of phase 6`) — where this call's tests run; it answers the Step 2.5 question in advance\n- **a PR checkpoint answer** — `combine PRs`, `stop at PR points` or `run \u002Funikit-pr at PR points`; it answers every PR checkpoint question of the run in advance\n\nMixed input works: `@.unikit\u002Fcode\u002Fplans\u002Fcustomers-system Phase 3`, `core-loop Phase 3`, `Tasks 2.1 2.3`.\n\n## Workflow\n\n### Step 0: Pre-flight Checks\n\n#### 0.1: Parse Arguments & Find the Feature Folder\n\n**Parse `$ARGUMENTS` (priority order):**\n\n1. `--list` → load `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmode-list.md` and follow it (it STOPs; Steps 0.2–5 do not run)\n2. `@\u003Cpath>` → the explicit feature folder; skip all auto-detection\n3. `status` → skip to **Status Display** (combines with `@\u003Cpath>`)\n4. Selectors — always explicitly prefixed; bare numbers are never selectors, they may be part of a feature name\n5. **A test-run instruction** — words saying where this call's tests run (`tests at the end of phase 6`, `тесты в конце фазы 6`, `run tests at every point`) → keep it for Step 2.5. It is neither a selector nor a feature name: recognise it **before** the selectors of item 4, because the phase number inside it names a run point and never narrows the scope.\n6. PR checkpoint answers given in advance — `combine PRs`, `stop at PR points`, `run \u002Funikit-pr at PR points` — are taken out of the argument before a folder is matched and answer every PR checkpoint of the run (`references\u002Fpr-checkpoints.md`).\n7. What remains, when there is no `@\u003Cpath>` → a feature name\n\n**An `@\u003Cpath>` that does not resolve** — no such folder, or no `\u003Cpath>\u002FPLAN.md` inside it:\n\n```\nFeature folder not found or invalid: \u003Cpath>\nExpected a folder with a PLAN.md manifest inside, for example:\n  \u002Funikit-implement @.unikit\u002Fcode\u002Fplans\u002F2026-03-10_core-loop\n\nIf this plan predates the manifest merge, run: unikit-ai update\n```\n→ STOP\n\nAn `@\u003Cpath>` on an unfinished plan (`.planning\u002FSTATE.md` there, no manifest — see *An unfinished plan is not a plan* below) prints its `NOTE` line instead of the block above → STOP.\n\n**Neither `@\u003Cpath>` nor a feature name → auto-detect** (priority order):\n\n1. **Fast plan check** — if `.unikit\u002Fcode\u002FPLAN.md` exists, use it (flat fast-mode plan).\n\n2. **Git branch match** — get current branch via `git branch --show-current`.\n   If git is unavailable, skip to the next priority level.\n\n   **Branch match.** From branch `\u003Cprefix>\u003Cname>`, collect every folder in `.unikit\u002Fcode\u002Fplans\u002F` that matches any of the three name formats: (1) exactly `\u003Cname>` — the current format; (2) ending with `_\u003Cname>` — the `YYYY-MM-DD_\u003Cname>` format; (3) ending with `-\u003Cname>` and beginning with three digits — the legacy `DDD-\u003Cname>` format. An experiment plan's folder does not carry its dated branch name (`experiment-\u003Ctopic>` on `experiment\u002F\u003Cdate>-\u003Ctopic>`), so its own record adds the folders whose manifest has, inside `## Experiment Context`, a `Branch:` line equal to the current branch and a `Base:` other than `none` (`Grep` `^Branch: ` over `.unikit\u002Fcode\u002Fplans\u002F*\u002FPLAN.md`); a folder found both ways counts once. Exactly one match → use it. **More than one → ask the user which one**, listing each with its `Updated:` — never by format precedence. No match → fall through to *latest*.\n\n3. **Latest** (fallback) — read the `Updated:` line from each candidate's `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md` and sort descending; ties break on `Created:` descending, then on folder name descending. A manifest with no `Updated:` is **excluded and named** — `WARN [plan] \u003Cfolder>: manifest has no Updated: — excluded; run unikit-ai update to backfill it` — never guessed from the folder name or the file's mtime.\n   **`latest fallback` is a guess, not a resolution:** the branch named no plan. With two\n   or more plans present, print the candidate table (folder, `Updated:`, tasks remaining)\n   and ask — never auto-select. With exactly one plan present there is nothing to choose\n   between: announce it with the branch miss named in the reason and continue.\n\n**An unfinished plan is not a plan.** A folder under `.unikit\u002Fcode\u002Fplans\u002F` that holds `.planning\u002FSTATE.md` but not its manifest `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md` is an ultra plan still being written: it is never a candidate, and it is named once:\n\n```\nNOTE [plan] \u003Cfolder> — unfinished planning: .planning\u002FSTATE.md is there, the manifest is not. Continue it with: \u002Funikit-plan ultra \u003Cfolder>\n```\n\n**Announce the resolution.** Print exactly one visible line before any other output:\n\n```\nINFO [plan] resolved: \u003Cpath> (\u003Creason>)\n```\n\n`\u003Creason>` is exactly one of: `explicit path` · `feature name` · `fast plan` · `fix plan` ·\n`branch match: \u003Cbranch>` · `latest fallback`. This is plain output, never the payload of an\ninteractive question.\n\n4. If `.unikit\u002Fcode\u002Fplans\u002F` is empty or absent and there is no `.unikit\u002Fcode\u002FPLAN.md`:\n   - **`.unikit\u002Fcode\u002FFIX_PLAN.md` exists** → it was created by `\u002Funikit-fix` and runs through the fix workflow: print `Fix plan detected (.unikit\u002Fcode\u002FFIX_PLAN.md) — launching \u002Funikit-fix`, invoke `unikit-fix` with no arguments (`## Skill calls`), and **STOP** when it returns.\n   - **No plan at all** → ask, act on the answer, and **STOP**:\n\n     ```\n     No active plan found. Current branch: \u003Ccurrent-branch>.\n\n     Options:\n     1. Plan a new feature — \u002Funikit-plan full \u003Cdescription>\n     2. Plan a quick task — \u002Funikit-plan fast \u003Cdescription>\n     3. Fix a bug — \u002Funikit-fix \u003Cdescription>\n     4. Just checking status — show branch info and stop\n     ```\n\n     Options 1-3 ask for the description, then run their command; option 4 shows `git branch --show-current` and `git log --oneline -5`.\n\n**If both `.unikit\u002Fcode\u002FPLAN.md` and a folder plan resolved by the branch match exist**, the requested work decides — the tasks named by the selectors of item 4, or every task when there are none. Pending means at least one of those tasks is `- [ ]` in the plan's manifest checklist.\n- **Pending in the folder plan** → use the folder plan without asking: the branch names it and the work is there. Announce `branch match: \u003Cbranch>`, then print `INFO [plan] fast plan .unikit\u002Fcode\u002FPLAN.md not used — the branch plan has pending work (\u003Cselectors | all tasks>)`.\n- **Nothing pending in the folder plan, but pending in the fast plan** → ask once: `Branch plan \u003Cfolder> has nothing pending\u003C, for the selectors>. Run the fast plan .unikit\u002Fcode\u002FPLAN.md?` — `Run the fast plan` (announce `fast plan`) · `Stop` (STOP).\n- **Pending in neither** → use the folder plan; Step 2 reports that nothing is left.\n\n**Ultra bundle check.** Read the first line of the resolved plan manifest. If it equals `\u003C!-- unikit:plan-mode:ultra -->`, this is an ultra bundle: follow `.unikit\u002Fsystem\u002Fultra-plan-read.md` for reading depth, integrity and mutability. Otherwise continue unchanged.\n\n**On resume**, re-read the active task's phase file, even when a previous session already read it.\n\n#### 0.2: Check for Uncommitted Changes\n\nBefore any implementation work, check `git status`. If git is unavailable (not initialized), skip this step entirely and proceed to plan loading.\n\n**If uncommitted changes exist**, the question is:\n\n```\nUncommitted changes detected.\n\nOptions:\n1. Commit now (recommended) — \u002Funikit-commit, then continue\n2. Stash and continue — git stash push -m \"unikit-implement: stash before execution\" (not offered while a merge is unfinished)\n3. Continue as is — leave the working tree untouched\n4. Cancel — \"Implementation cancelled.\" → STOP\n```\n\n**While a merge is unfinished** — `git rev-parse -q --verify MERGE_HEAD` succeeds — the question has no \"Stash and continue\": with conflicts unresolved `git stash` fails, and once they are resolved it drops `MERGE_HEAD` for good, so the merge commit would have one parent.\n\n**Ask it right before Step 3, not here** — in one call of the question tool of your agent (`AskUserQuestion`) together with the Step 2.5 question when Step 2.5 asks one, alone otherwise. Carry out its answer first: a commit or a stash happens before any mark is written into the manifest. **After a stash, re-read the manifest** and recompute the scope and its run points (Steps 2 and 2.5) before any mark is written: `git stash push` reverts a tracked, uncommitted manifest underneath the scope already counted.\n\n#### 0.3: Resume \u002F Recovery (after `\u002Fclear` or session break)\n\nIf the user is resuming after a break, says the session was abandoned, or context was likely lost (e.g. after `\u002Fclear`), rebuild context from the repo before continuing. If git is unavailable, skip git commands and rely on plan file state only.\n\n```bash\ngit status\ngit branch --show-current\ngit log --oneline --decorate -15\ngit diff --stat\n```\n\nThen reconcile plan state with reality:\n- Read the plan manifest (`.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md`, or the flat `.unikit\u002Fcode\u002FPLAN.md`) and check which tasks are marked `[x]`\n- For tasks marked `[x]`, spot-check that the corresponding code actually exists (read a key file or check for expected classes\u002Fmethods)\n- If code for a completed task is missing (e.g. after reset\u002Frebase), revert the checkbox back to `- [ ]` and inform the user\n- If code exists but the task isn't marked complete, mark it `[x]` and inform the user\n- A task labelled `⏳ AWAITING RESULT` is picked up here, and a ticked `Measure:` \u002F `Hand-back:` task is spot-checked by its row or its report file, not by code — `references\u002Fbalance-measure.md` → `## Resume (Step 0.3)`.\n\n### Step 1: Load Plan Context\n\n- Read the **plan manifest** — `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md`, or the flat `.unikit\u002Fcode\u002FPLAN.md`. Its section list: `{{skills_dir}}\u002Funikit-plan\u002Freferences\u002FTASK-FORMAT.md` → *Plan Manifest Template*. In an ultra bundle every task's detail lives in its phase file; the reading depth is set by `.unikit\u002Fsystem\u002Fultra-plan-read.md`.\n- `## Based on` names a research → do **NOT** read its `RESEARCH.md` as a substitute for the plan's own context: the plan's `## Technical Context` supersedes it. The drift check below runs a script over it and reads nothing itself.\n- Read **`.unikit\u002FDESCRIPTION.md`** — project specification, tech stack, constraints\n- Read **`.unikit\u002FARCHITECTURE.md`** — project structure, tech stack, and pointers to detailed rules. **Architecture topics:** only the root here; the topic files its `## Topics` table lists load per phase in Step 3.0.\n\n**Research drift check** — only when `## Based on` has at least one entry. Read `.unikit\u002Fsystem\u002Fresearch-link.md` now, and only now, and run its `## Checking an entry` against every entry.\n\n**If `.unikit\u002Fsystem\u002Fresearch-link.md` is missing or unreadable, do not block:** record no `Summary SHA256` and check none — print `WARN [research-drift]: research-link contract missing — drift detection off for this run; run unikit-ai update` once, and continue.\n\nDrift is printed **once**, here at plan load — not before each task. Execution continues on the plan's scope; the re-plan offer goes into the Step 4 summary as its `Research drifted` line.\n\n**Read `.unikit\u002Fskill-context\u002Funikit-implement\u002FSKILL.md`** — MANDATORY if the file exists. Project-specific overrides: a skill-context rule wins over a general rule of this skill on conflict; otherwise apply both.\n\n**Parse Settings** from the manifest's `## Settings`:\n- `Testing: yes | no` — whether tests are written (Step 3.8) and run (test-checkpoint tasks, Steps 2.5 and 3.2). Under `Testing: yes` read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Ftest-runs.md` now, once — Steps 2.5, 3.2, 3.4 and 3.8 follow it; under `Testing: no` never read it. File missing or unreadable → print `WARN [testing] test-run reference missing — test-checkpoint tasks are reported as blockers; run unikit-ai update` and then: every test-checkpoint task is a Step 3.3 blocker, Step 2.5 asks nothing and marks nothing (the points stay as written), and Step 3.8 writes tests by the Step 3.2 choice.\n- `Test checkpoints: task | phase | plan` → where the test-checkpoint tasks stand (Steps 2.5 and 3.2). **Line absent under `Testing: yes` → the plan is legacy:** its placement was never declared; its run points are run commands in the task text (`### Tests`, `### Verification`, the implementation steps) plus test-checkpoint tasks recognisable only by their heading. Confidence is lower here, and the Step 4 report says so in one line. Under `Testing: no` the line is omitted by design (`{{skills_dir}}\u002Funikit-plan\u002Freferences\u002FTASK-FORMAT.md`), and such a plan is not legacy.\n- `Docs: yes | no` → the documentation checkpoint of Step 5.3\n- `Editor tasks: engine-bridge | manual | direct` (the 2.x spelling `mcp` is read as the same value) → how tasks carrying an `Editor:` line are carried out (Step 3.2). **Line absent:** `engine-bridge` if `.unikit\u002Fsystem\u002Fengine-bridges\u002FBRIDGES.md` lists at least one bridge, otherwise `manual`. Never default to `direct` — it is irreversible and only ever an explicit choice.\n\n- `PR checkpoints: yes` → the product behaviour of a PR checkpoint task; without the line, a PR checkpoint task is legacy.\n\nNo `## Settings` at all → `Testing: no`, `Docs: no`, and `Editor tasks` by the same rule.\n\n**The checklist carries a `PR checkpoint:` line or the manifest has `## Modules`** → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fpr-checkpoints.md` now, once — Steps 2, 3.2, 3.4, 3.9, 4, 5.6, 5.8 and the status display follow it. Missing or unreadable → `WARN [pr] PR checkpoint reference missing — PR checkpoint tasks are reported as blockers; run unikit-ai update`, every PR checkpoint task is a Step 3.3 blocker, and the push rule below still holds.\n\n**The manifest has `## Balance Context`** → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fbalance-measure.md` now, once — Steps 0.3, 2, 3.2, 3.4, 3.6-3.9, 4, 5.4, 5.6 and 5.8 follow it. Missing or unreadable → `WARN [balance] balance reference missing — Measure: and Hand-back: tasks are reported as blockers; run unikit-ai update`, and every such task is a Step 3.3 blocker.\n\n**The manifest has `## Experiment Context`** → read `.unikit\u002Fsystem\u002Fprototype-profile.md` now, once, and follow its `## Role: execution` — the branch check at the end of Step 1, before Step 1.5, and Steps 3.2 (the note to a delegate), 3.7, 3.10, 5.1, 5.3 and 5.8 follow it. Missing or unreadable → `WARN [prototype] profile contract missing — treating the plan as ordinary; run unikit-ai update`, and carry on as for an ordinary plan.\n\n**While the checklist carries a `PR checkpoint:` line, every `unikit-commit` call of this run adds `no-push`.**\n\n### Step 1.5: Bootstrap Rules & Principles\n\nLoad the project knowledge base once, before the first task.\n\n**Read in parallel:**\n1. `.unikit\u002Fsystem\u002Fdev-principles.md` — **up to its lazy-read boundary**: find the marker line (`Grep -n '^\u003C!-- === LAZY-READ BOUNDARY === -->'`) and `Read` the file with `limit` set to that line number. The part **below the marker is read once, at plan load, when the checklist carries an `Editor:` line** — the deep reference plus the editor procedures D6–D8 this skill follows; a plan without `Editor:` lines never reads it. An agent that cannot read with a limit reads the whole file.\n2. `.unikit\u002FRULES.md` — project overrides (highest priority). **Rule topics:** only the root here; the topic files its `## Topics` table lists load per phase in Step 3.0.\n3. `.unikit\u002Fmemory\u002Fcode\u002FRULES_INDEX.md` — index of core\u002Fstack rules\n4. For EACH row in the Core table where Required By = `all` or contains `unikit-implement` — read that file from `.unikit\u002Fmemory\u002Fcode\u002Fcore\u002F` using the Read tool.\n\nStack rules and rule topics are NOT loaded here — they are loaded lazily per-phase in Step 3.0.\n\n**Engine-bridge rules (conditional, engine-neutral) — once per session, zero calls:**\n\n5. `.unikit\u002Fsystem\u002Fengine-bridges\u002FBRIDGES.md` — the whole file (one short block per bridge) — and, for **each** bridge whose block names a rules tree, that tree's `.unikit\u002Fsystem\u002Fengine-bridges\u002F\u003Cbridge>\u002FINDEX.md`, **base section only**: the stamp under the title (the `bridge` row) and every section **except** the `## Check` table, which is grepped per task, by area (Step 3.2). Also read `.unikit\u002Fbridges.yaml` (the bridge order) and, when it exists, `.unikit\u002Fbridge-routing.md` (the routing rules); a missing order file means the default order `BRIDGES.md` states, a missing routing file means no routing rules.\n6. For each bridge listed in `BRIDGES.md`: `.unikit\u002Fbridge-notes\u002F\u003Cbridge>.md`, **header only** (`bridge:` \u002F `audited:`) — this project's own accumulated findings, and they apply to that bridge only. Compare the header against the bridge the file is named for. On a mismatch print exactly one line and **apply the entries anyway**:\n\n   ```\n   WARN [bridges] notes header ≠ bridge (\u003Cheader> ≠ \u003Cbridge>)\n   ```\n\n   The entries are suspect, not void; retiring them belongs to `\u002Funikit-bridge-audit`.\n\n**A file absent → skip it, print one line, and continue with every right you had** (no `BRIDGES.md` reads as \"no bridge selected\"):\n\n```\nBridge rules: \u003Cbridge> has no INDEX.md — no known exceptions for it, rights unchanged\n```\n\nNo rules means no known exceptions, never no capabilities. Absence never disables an engine bridge and never turns a target into `⏸️ MANUAL` (`.unikit\u002Fsystem\u002Fdev-principles.md` → **A9**).\n\n**Ultra plan bundle reader contract — only for an ultra bundle:**\n\n7. `.unikit\u002Fsystem\u002Fultra-plan-read.md` — **only when Step 0.1 found the marker `\u003C!-- unikit:plan-mode:ultra -->`**: read it once — here, unless Step 0.1 already did — and follow it for detection, per-consumer reading depth, what is mutable during execution, and the blocking integrity checks. A plan without the marker never reads this file.\n   **If `.unikit\u002Fsystem\u002Fultra-plan-read.md` is missing or unreadable, do not block:** treat every plan as a single-file plan and continue exactly as before — a project that predates the ultra port has no bundles to read.\n\nKeep an in-memory list of loaded rule and topic file paths (`loaded_rules`). Used in Step 3.0 for delta detection.\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n### Step 2: Determine Work Scope\n\n**If all tasks are completed (`- [x]`):**\n\n```\nAll tasks in {feature-folder} are completed.\nNothing to implement.\n```\nSTOP here.\n\n**Counting rule for `⏸️ MANUAL`.** A task marked `- [x] … ⏸️ MANUAL` (Step 3.4) counts as **out of scope**, not as pending: it does not block \"all tasks are completed\" and it is never picked up again by a later run. It is also not counted as implemented — Step 4 reports it on its own line.\n\nA merged test-checkpoint task is the other third outcome, and it counts differently — the counting rule is in `references\u002Ftest-runs.md` → `## Step 2.5`.\n\nA PR checkpoint carrying a `⏭️ MERGED` label is not pending either — `references\u002Fpr-checkpoints.md` → `## Counting (Step 2)`.\n\nA task labelled `⏳ AWAITING RESULT` is **pending**, not out of scope — `references\u002Fbalance-measure.md` → `## Counting (Step 2)`.\n\n**If `$ARGUMENTS` contains phase\u002Ftask selectors:**\n\n- Collect the pending tasks the selectors name (Step 0.1); a named task that is already completed is skipped, and the user is told.\n- If a phase depends on an incomplete phase — its `**Dependencies:**` line in `## Checklist`, cross-checked against `## Dependency Graph` — warn `Phase {N} depends on Phase {M}, which has {X} incomplete tasks` and ask: implement Phase {M} first (recommended) · continue as is · skip Phase {N} and take the next independent phase\n\n**If no selectors (execute all pending):**\n\nCollect all pending tasks across all phases, respecting dependency order:\n1. Start with phases that have no unmet dependencies\n2. Within a phase, execute tasks in order (1.1, 1.2, 1.3...)\n3. After completing a phase, check if any new phases are now unblocked\n\n### Step 2.5: Resolve test-run checkpoints in scope\n\nRuns **before** the first task, and only when `Testing: yes`: follow `references\u002Ftest-runs.md` → `## Step 2.5` (read at Step 1). It may ask one question — in the same call as the Step 0.2 question when there is one.\n\n### Step 3: Execute Tasks\n\nKeep a running list of files you create, modify, or delete during execution — you'll need it for the completion summary and commit.\n\n**Execution overview — once per run, before the first task.** A run that executes at least one task opens Step 3 with it, before 3.0 of the first phase. A Step 0.2 or Step 2.5 question asked before Step 3 changes only the moment: carry out its answer first — the commit, the stash and its recount, the `⏭️ MERGED` marks — then print the overview with the counts as they stand now; the answer is no reason to skip it. Tool output is folded away from the user, so counts a command printed never reach the screen: print the overview as your own message.\n\n```\n## Implementation Progress\n\n✅ Completed: {X}\u002F{total} tasks\n🔄 Executing: Phase {N} — {Y} tasks pending in scope\n⏳ Remaining after scope: {Z} tasks\n```\n\n**3.0: Phase Rules Refresh (before starting each phase)**\n\nBefore executing the first task of any phase (including the first phase):\n1. Re-read `.unikit\u002Fmemory\u002Fcode\u002FRULES_INDEX.md`.\n2. Match the phase name and its task descriptions against the Stack table's `Load When` column **and against the `Load when` column of the `## Topics` tables in `.unikit\u002FRULES.md` and in `.unikit\u002FARCHITECTURE.md`** (both roots read at Steps 1 and 1.5; a root without that table has no topics).\n3. Compute delta: stack rules and topic files (rule and architecture) needed for this phase that are NOT in `loaded_rules`. A topic whose match is uncertain is needed.\n4. Read each delta rule — a stack rule from `.unikit\u002Fmemory\u002Fcode\u002Fstack\u002F`, a topic file from `.unikit\u002Frules\u002F` or `.unikit\u002Farchitecture\u002F` — using the Read tool. A topic file the table lists but the disk lacks → print `WARN [rules] topic file missing: .unikit\u002Frules\u002F\u003Cslug>.md` (an architecture topic: `WARN [architecture] topic file missing: .unikit\u002Farchitecture\u002F\u003Cslug>.md`) and continue.\n5. Add them to `loaded_rules`.\n\nInside a phase, do NOT re-check rules between individual tasks — they share the same loaded set.\n\nFor each task to execute:\n\n**3.1: Present the task**\n\nShow the user what you're about to implement:\n```\n## Phase {N}: {Phase Name}\n### Task {N.M}: {task description}\nStatus: Pending\nDependencies: {met\u002Funmet}\n```\n\n**3.2: Implement the task**\n\nThis skill writes sequential tasks itself, with `Read\u002FEdit\u002FWrite\u002FBash` and the rules already loaded in Step 1.5 + Step 3.0. Do NOT invoke `\u002Funikit-execute` via `Skill(...)`.\n\nChoose execution mode:\n- **Sequential within phase** (default for tasks that depend on each other or share files) → inline implementation. The skill writes code itself.\n- **Independent across phases** (per the manifest's `## Dependency Graph`, e.g. Phase 3 and Phase 4 can run in parallel) → spawn `develop-agent` (Agent + the `unikit-execute` skill) per independent scope. Use ONLY for true parallelism.\n- **Deep-dive single task** (requires extensive codebase exploration that would bloat parent context) → spawn `develop-agent` to isolate the exploration.\n\nWhen implementing inline, use the rules from Bootstrap + Phase Rules Refresh, the principles from `dev-principles.md`, the task description from the manifest's `## Checklist`, and the technical context from its `## Technical Context`.\n\n**In an ultra bundle the checklist line is a pointer, not the specification.** The task's specification is its `## Task N.M:` section in the phase file — `### Intent` through `### Verification` — and the manifest's `## Technical Context` supplies only the cross-phase part.\n\n**Fallback:** If `Agent` tool is unavailable, do NOT invoke `\u002Funikit-execute` inline (rules and dev-principles are already loaded in Step 1.5 \u002F Step 3.0). Instead, degrade parallel scopes to sequential and continue the inline implementation cycle for ALL tasks. Each phase still triggers Step 3.0 Phase Rules Refresh.\n\n**Tasks carrying an `Editor:` line** target the editor's serialized state, not source files. Handle each `Editor:` line — `[kind] \u003Ccontainer> → \u003Ctarget> : \u003Caction>` — by the `Editor tasks` mode parsed in Step 1:\n\n- **`engine-bridge`** — carry it out through the engine bridges by `.unikit\u002Fsystem\u002Fdev-principles.md` → **D6**, on **every** such task; a call that misled you is a finding (**D7**); D6 step 2 confirms the command you chose against the live schema, and the library reference has two triggers, none of them Bootstrap (**D8**). No rules file, or no check line for this area, changes nothing (A9). Name the bridge of every call and of every read-back in the task's report line.\n- **`manual`** — do **not** touch any file. Mark the task `⏸️ MANUAL` (Step 3.4) and hand the user the exact instruction in the form `[kind] container → target : action`, one line per target.\n- **`direct`** — **a rollback point must exist before editing** (this is mandatory and the whole reason the mode is gated):\n  - Files this run changed and has not committed yet → stage only those and commit them: invoke `unikit-commit`, like every other commit of this run — never with a `git commit` of your own; with auto-commit on (Step 3.9) it passes `auto` too. The user cancels that commit, or it does not complete → do not edit: put the task back on `manual` and print `WARN [editor] \u003Ctask>: no pre-edit commit — direct edit skipped, task back on manual` — without that commit there is no rollback point.\n  - Nothing of this run is uncommitted → `HEAD` already is the rollback point: no commit is needed.\n  - The target file itself has uncommitted changes this run did not make → a rollback would erase them. Before anything is staged, ask once with the question tool of your agent (`AskUserQuestion`): `\u003Ctarget> has uncommitted changes that are not from this run` — `Commit them with the pre-edit commit` \u002F `Leave this task on manual`. The first adds the target to the pre-edit commit; the second puts the task back on `manual` with that reason.\n\n  Once the rollback point exists, edit the serialized format directly, staying inside the bounds §6 allows for that format. Never use `direct` for a format §6 rates 🔴.\n\n  **§6 is owned by the `unikit-plan` skill** — read it from `{{skills_dir}}\u002Funikit-plan\u002Freferences\u002FENGINE_RULES.md`. This skill has no engine template of its own, so there is no local copy of §6 to read and none to keep in sync.\n\n  **If that file is not there**, treat every format as 🔴: refuse `direct`, put the task back on `manual`, and state the reason in one line. Continuing silently is not an option here — a binary serialized format edited as text is not reversible by review, and this gate is the only thing standing in front of that. This is **not** the A9 case: what is missing is not a rule that would grant a right, it is the permission for an irreversible text edit, and withholding it changes nothing about the `mcp` route.\n\n**A task carrying a `Test checkpoint: \u003Ccoverage>` line** is a test-checkpoint task: it leaves no project file changed, and its work is one test run plus its non-run steps — `references\u002Ftest-runs.md` → `## Step 3.2`.\n\n**A task carrying a `PR checkpoint:` line** closes a module and runs at the Step 3.9 position of its phase, after Steps 3.6-3.8 — `references\u002Fpr-checkpoints.md` → `## Step 3.2 — the PR checkpoint`, or `## Legacy` when `## Settings` has no `PR checkpoints: yes`.\n\n**A task carrying a `Measure:` or `Hand-back:` line** is carried out in this session and leaves its row or its report in the plan — `references\u002Fbalance-measure.md` → `## Step 3.2 — a Measure: task` and `## Step 3.2 — the Hand-back: task`.\n\n**Delegated execution.** `\u003Ctask details>` is a closed hand-off: whatever is not in it, the delegate does not see. When a task with `Editor:` goes to `develop-agent` or to `unikit-implement-worker`, the dispatch prompt MUST carry the `Editor:` lines **verbatim**, the already-resolved mode, and the matching `### EDITOR TARGETS` rows — from the manifest's `## Technical Context`, or in an ultra bundle from the task's own `### Required Interfaces and Contracts` in its phase file. A delegate that receives only the description implements the task as pure code and both mode gates are bypassed silently. **In an ultra bundle the whole task section goes into the prompt**, not just the `Editor:` lines: a delegate that receives only the checklist line loses the implementation steps, the contracts and the acceptance criteria along with the targets. `manual` is **never executed by a delegate** — the task comes back up marked `⏸️ MANUAL`. A PR checkpoint task, a `Measure:` task and a `Hand-back:` task are never delegated.\n\n**3.3: Handle Blockers**\n\nIf a task cannot be completed (compilation error, missing dependency, unclear requirement, etc.):\n\n```\nBlocker on task {N.M}\n\nProblem: {description of what went wrong}\n\nOptions:\n1. Skip and continue (task will be marked as blocked)\n2. Change implementation approach\n3. Stop implementation and discuss\n```\n\nBased on choice:\n- Skip → mark task as blocked in the manifest, continue to next task\n- Change approach → ask which approach with the question tool of your agent (`AskUserQuestion`): its options are the alternatives you see, the user writes their own in the free-text answer; retry the task with the chosen one\n- Stop → pause implementation → **STOP**\n\n**3.4: Mark task as completed**\n\nAfter successful implementation, update the manifest:\n- Change `- [ ] {task}` to `- [x] {task}`\n- If all tasks in a phase are done, update the phase status: `**Status:** [x] Completed`\n\n**Editor task handed to the user (`Editor tasks: manual`)** — a third outcome, neither done nor pending:\n- Write `- [x]` and append the marker `⏸️ MANUAL` to the task text: `- [x] Task 2.1 — wire the pause button ⏸️ MANUAL`. It counts by the `⏸️ MANUAL` rule of Step 2 and is reported separately (Step 4).\n\n**The task produced an MCP finding (Step 3.2)** — append its row to the plan's `## Engine Bridge Findings` table in this same `Edit`, by `dev-principles.md` → **D7**: `F\u003Cn>`, `observed` from `Bash(date *)`, `bridge` — the id of the bridge the misleading call went through, semantic dedup. A table in the 2.x form is converted first (`TASK-FORMAT.md` → `### Engine bridge findings section`). Not at the end of the phase, not at the end of the run. In every case — an `Editor:` task or not (the Step 3.6 console read, a test run) — a misleading call is also a candidate line in the run report (the raw call and the raw answer), and `.unikit\u002Fbridge-notes\u002F\u003Cbridge>.md` is never written from here.\n\n**A test-checkpoint task (Step 3.2)** — ticked and recorded by `references\u002Ftest-runs.md` → `## Step 3.4`.\n\n**A PR checkpoint task** — ticked and labelled by `references\u002Fpr-checkpoints.md` → `## Step 3.4 — labels`.\n\n**A `Measure:` task** — ticked, or labelled `⏳ AWAITING RESULT`, with its `## Measurements` row written in the same `Edit`: `references\u002Fbalance-measure.md` → `## Step 3.4 — ticking`.\n\n**The task produced a rule candidate** — a further outcome, recorded in the same pass:\n- Append a row to `## Rule Candidates`: `id | rule | full formulation | from | status`, with `status = open` and `from = task \u003CN.M>`.\n- **Id:** `R\u003Cn>`, one more than the highest already in the table — read it first: a re-run of the same task must not restart the numbering.\n- `rule` carries **one line, one directive** — exactly what would go into `.unikit\u002FRULES.md`. `full formulation` carries the long version with its rationale, under no length limit.\n- **Dedup is semantic:** a candidate saying the same thing as a row already present — of any status, `declined` included — is not added.\n- **Nothing here reaches `.unikit\u002FRULES.md`.** Step 5.2 proposes the candidates to the user; only `\u002Funikit-rules`, invoked with the batch the user selected, writes that file.\n- The plan carries no `## Rule Candidates` section (a legacy plan) → create it at `##` level under `## Engine Bridge Findings`, or above `## Dependency Graph` when that one is absent too, and print `INFO [rules] section ## Rule Candidates created`.\n\nUse the Edit tool to make these changes surgically.\n\n**3.5: Progress report**\n\nAfter each task (or batch of parallel tasks), briefly report:\n```\n✅ Task {N.M}: {one-line summary of what was done}\nProgress: {completed}\u002F{total} ({percent}%) · {remaining} remaining in scope\n```\n\n**3.6: Compilation & Console Check (after completing a phase)**\n\nAfter all tasks in a phase are done, check {{engine_name}} console for compilation errors.\n\n**Prerequisite:** `.unikit\u002Fsystem\u002Fengine-bridges\u002FBRIDGES.md` lists at least one bridge. None — skip this step entirely and proceed to 3.7. Otherwise follow `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fconsole-check.md`.\n\n**Do NOT proceed to commit (3.9) with compilation errors that belong to the current phase.** Future-phase errors are acceptable.\n\n**3.7: Update context artifacts (if project structure changed)**\n\nAfter completing a phase, check whether the implementation introduced structural changes that should be reflected in context files:\n\n- **If the tech stack changed** (new dependencies, integrations, or tools added) → update `.unikit\u002FDESCRIPTION.md` with factual deltas only. Do not rewrite — add or modify the relevant section.\n- **If new modules, directories, or layers were added** → update `AGENTS.md` — refresh the project structure tree and key entry points table to reflect new directories\u002Ffiles.\n- **If new modules, directories or layers were added, a dependency rule changed, or a contract or channel between modules was added** → update `.unikit\u002FARCHITECTURE.md` with one table row or one list line per fact: in the topic file whose `Load when` matches the area of the change, else in the root section that fits the kind (`Folder Structure`, `Dependency Rules`, `Cross-Module Communication`); when unsure, the root. Never a paragraph, a new topic or a moved block. A decision (principle, anti-pattern, pattern choice) or an explanation of how a mechanism works is not a delta: print `INFO [architecture] update suggested: \u003Cone line>` and leave the file.\n\nSkip this step if the phase only modified existing files without structural changes.\n\n**3.8: Tests (if Testing: yes — before the phase's test checkpoint, or after the phase)**\n\n`Testing: yes` → `references\u002Ftest-runs.md` → `## Step 3.8`. `Testing: no`, or no `## Settings` at all → skip this step.\n\n**3.9: Commit checkpoint (after completing a phase)**\n\nAfter all tasks in a phase are completed (and tests written if applicable):\n\n- **Auto-commit is on** (chosen at an earlier checkpoint of this session) → ask nothing: stage this phase's files and invoke `unikit-commit` with the argument `checkpoint: phase {N}, auto` — and `, no-push` after it while the checklist carries a `PR checkpoint:` line — it writes the message and commits without a question (its `## Auto mode`). Print its result line and go on to the next phase.\n- Otherwise ask:\n\n```\n✅ Phase {N} complete — {count} tasks done.\n\n💾 Commit checkpoint. Commit changes?\n\nOptions:\n1. Yes, commit — \u002Funikit-commit with this phase's files\n2. Yes, and from now on commit without asking — this and every later commit of this session\n3. No, continue to next phase\n4. Disable checkpoints — no more commit questions this session\n```\n\n**Option 1** invokes `unikit-commit` with the argument `checkpoint: phase {N}` — `, no-push` after it while the checklist carries a `PR checkpoint:` line.\n\nA phase closed by a PR checkpoint task was committed by that task — do not ask here for it.\n\n**Option 2 turns auto-commit on**, and this checkpoint already commits the auto way. From then on every commit this session makes through `unikit-commit` passes `auto`: each later checkpoint, the pre-edit commit of a `direct` editor task, and the commit of Step 5.6. It is held in this session's memory, like option 4 — after `\u002Fclear` or in a new session the question returns once. Auto-commit never pushes.\n\nStaging: **Important Rules** → *Commit only your own changes*.\n\nDo not suggest a message here. `\u002Funikit-commit` writes it from the plan's `## Overview` and this phase's `WHY:` lines; a subject assembled from a phase title is exactly the technical message its contract rules out.\n\nA scope of many phases: suggest `\u002Fcompact` or `\u002Fclear` before the next phase — with auto-commit on, `\u002Fcompact`: `\u002Fclear` forgets the choice.\n\n**3.10: Check ROADMAP.md progress (after all phases in scope are done)**\n\nIf `.unikit\u002FROADMAP.md` exists:\n1. Read it\n2. If the plan file includes `## Roadmap Linkage` with a non-`none` milestone, prefer that milestone for completion marking\n3. Check if the completed work corresponds to any unchecked milestone\n4. If yes — mark it `[x]` and add entry to the Completed table with today's date\n5. Tell the user which milestone was marked done\n6. If milestone mapping is ambiguous, emit `WARN [roadmap]` and suggest: `\u002Funikit-roadmap check`\n\n### Step 4: Completion Summary\n\nAfter all tasks in scope are done:\n\n```\n## Implementation Summary\n\nFeature: {feature-folder}\nScope: {all \u002F Phase N \u002F Tasks N.M, N.K}\n\nCompleted:\n- Task {N.M}: {summary}\n- Task {N.K}: {summary}\n...\n\nManual (editor targets):\n- Task {N.M}: {[kind] container → target : action}\n...\n\nBridges used: {ids, in the order used}   (only when a task went by `engine-bridge`)\n\nAwaiting results:\n- Task {N.M} — {instruction}\n...\n\nAffected files:\n- Created: {list of created files}\n- Modified: {list of modified files}\n- Deleted: {list of deleted files}\n\nRemaining tasks: {count} (in {phases} phases)\nDocumentation: {delegated to docs-agent | updated via \u002Funikit-docs (fallback for docs-agent) | warn-only (Docs: no\u002Funset)}\nTest checkpoints: legacy — placement not declared, runs found from the task text\nResearch drifted — consider \u002Funikit-improve \u003Cplan> before continuing\nPR checkpoints: task 4.5 → PR a1b2c3d · task 7.3 merged → task 11.4\nModule drift: M5 — consider \u002Funikit-improve\n```\n\nThe `PR checkpoints:` and `Module drift:` lines appear only when the run met a PR checkpoint, and only after a `WARN [plan-drift]`, respectively — `references\u002Fpr-checkpoints.md` → `## Report lines (Step 4)`.\n\nThe `Research drifted` line appears **only** when the Step 1 drift check emitted at least one `WARN [research-drift]`, and is omitted otherwise; it never stops the run.\n\nThe `Documentation:` line is the one Step 5.3 names; its value follows from `Docs:` and from whether the `Agent` tool exists, both known at Step 1. The `Test checkpoints: legacy` line appears only for a legacy plan under `Testing: yes` (Step 1) and is omitted otherwise.\n\nThe `Manual (editor targets)` block lists every task marked `⏸️ MANUAL` with its exact instruction, and is **omitted entirely** when there are none. The `Awaiting results` block appears only when a task carries the label; the `Hand-back: \u003Cpath>` line — `references\u002Fbalance-measure.md` → `## Report lines (Step 4)`.\n\n### Step 5: Post-Completion Actions\n\nAfter all tasks in the current scope are done, perform the following actions.\n\n**IMPORTANT:** Step 5.3 delegates to `docs-agent` and does NOT wait for it. **Step 5.2 blocks on the user** — it never writes a rule without an answer. Steps 5.4–5.8 are sequential and may involve user interaction.\n\n**5.1: Check TODO.md**\n\nIf `.unikit\u002FTODO.md` exists, tick every open task (`- [ ]` → `- [x]`, with `Edit`) that the completed work resolves — matched by meaning against the modified files, classes, methods and the plan's feature descriptions. No file, or no match → skip silently.\n\n**5.2: Propose New Rules**\n\nThe candidates are already collected: the rows whose status is `open` in the manifest's `## Rule Candidates` (Step 3.4). This step formulates nothing anew — it proposes what is written down, and records the choice.\n\n1. **No `open` candidate → silence** — not even a \"no rules found\" line.\n2. **Select at most three** `open` candidates. The filter: a general convention for future code; not about one task; not a description of the current code; absent from `.unikit\u002FRULES.md` and from `RULES_INDEX.md`; one line, one directive.\n3. **Print the candidates as plain markdown, in a block of their own** — before the question:\n\n   ```\n   Project rule candidates:\n\n   1. \u003Cthe rule text, as it will be written>\n      from: task 2.3\n   2. \u003Cthe rule text>\n      from: task 4.1\n   ```\n\n4. **Ask once, with the question tool of your agent (`AskUserQuestion`) and `multiSelect`:** one option per candidate plus an explicit **\"Add nothing\"** — four options at most, the tool's limit. Keep the option label short; the full rule text goes in the option's `description`.\n5. **Nothing is written without an answer. Do NOT add any rules until the user answers.**\n6. **What was selected goes to `unikit-rules` as one numbered batch** — invoke `unikit-rules` with the batch as its argument (`## Skill calls`). This is **a real call, not text in backticks**.\n7. **Show the user the `## Batch result` table** the skill returned, and update the statuses in `## Rule Candidates` from it: `added` for the rules it marked `added`, `declined` for those the user did not select. **`declined` is durable:** such a candidate is never offered again on a later run.\n8. Only then proceed to Step 5.3.\n\n**Verbose.** `INFO [rules] open candidates: \u003Cn>, proposed: \u003Cm>` before the block is printed. If the skill could not be invoked (its file was unreadable, so only the `Run:` line was printed), the statuses are **not** set to `added` — the rule was not written; print `WARN [rules] \u002Funikit-rules was not invoked — candidate statuses unchanged`. If the skill returned no table, the statuses stand as well: `WARN [rules] the \u002Funikit-rules report could not be parsed — candidate statuses unchanged`.\n\n**5.3: Documentation Checkpoint**\n\n**If `Docs: yes`** (from `## Settings`):\n\nDelegate to `docs-agent` to update or create documentation based on completed work. Do NOT wait for the agent to finish — proceed to Step 5.4 immediately.\n\n**Fallback** (no `Agent` tool): invoke `unikit-docs` yourself with the context `docs-agent` would have got (`## Skill calls`) — a real call, not a printed recommendation — then proceed to Step 5.4.\n\n**If `Docs: no` or the Settings section is missing:** do **not** delegate; emit `WARN [docs] Docs policy is no\u002Funset; skipping documentation`.\n\nThe Implementation Summary (Step 4) carries one documentation line: `Documentation: delegated to docs-agent` · `Documentation: updated via \u002Funikit-docs (fallback for docs-agent)` · `Documentation: warn-only (Docs: no\u002Funset)`.\n\n**5.4: Handle plan file after completion**\n\nA plan with `## Balance Context` never gets the archive line at 5.8, and while one of its tasks is pending no deletion is offered here — `references\u002Fbalance-measure.md` → `## Counting (Step 2)`, `## Step 5.8 — the hand-back command`.\n\n**If using the flat `.unikit\u002Fcode\u002FPLAN.md`** (fast-mode plan):\n\n```\nAll tasks completed. Delete .unikit\u002Fcode\u002FPLAN.md? (It's no longer needed)\n\nOptions:\n1. Yes, delete it\n2. No, keep it\n```\n\nYes → delete `.unikit\u002Fcode\u002FPLAN.md`; No → leave it.\n\n**If using a folder plan** (`.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002F`): keep it. **Never offer to delete `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md`.** A finished folder plan leaves the active list only through `\u002Funikit-archive`, which Step 5.8 names (not for a balance plan).\n\n**5.5: Engine Bridge Findings handoff**\n\nRead the plan's `## Engine Bridge Findings` table.\n\n- **No rows** (or no such heading) → say nothing at all — not even a \"no findings this run\" line — and go to 5.6.\n- **Rows present** → offer to move them to the durable surface:\n\n```\n\u003Cn> MCP findings recorded in this plan. Transfer them to the notes of their bridge (.unikit\u002Fbridge-notes\u002F)?\n```\n\n  On agreement, invoke `unikit-bridge-trap` with the argument `\u003Cpath to the plan file>` — the explicit path makes it read this plan and nothing else.\n\n**5.6: Verify or Commit**\n\n```\nAll tasks complete. What's next?\n\nOptions:\n1. 🔍 Verify first — \u002Funikit-review → \u002Funikit-commit (recommended)\n2. 💾 Skip to commit — \u002Funikit-commit directly\n```\n\nBased on choice:\n- **Verify first** → invoke `unikit-review`, wait for it to return, then invoke `unikit-commit` with the argument `final commit` — `, no-push` after it while the checklist carries a `PR checkpoint:` line.\n- **Skip to commit** → invoke `unikit-commit` with the argument `final commit` — the same `, no-push` rule.\n\n**Auto-commit on (Step 3.9)** → the question stays — it is about the review — and the commit it leads to is invoked with the argument `final commit, auto` — and `, no-push` after it while the checklist carries a `PR checkpoint:` line.\n\n**These are skill invocations, in this session — not delegations** (`## Skill calls`): each runs to the end before the next starts. They must be **real calls, not printed text**, and must not be wrapped in triple backticks.\n\n**Review is NOT delegated here — unlike Step 5.3.**\n\n**5.7: Context Cleanup**\n\nSuggest the user to free up context space if needed: `\u002Fclear` (full reset) or `\u002Fcompact` (compress history).\n\n**5.8: Next steps**\n\n```\nNext steps:\n- {suggest what to do next — e.g. \"Run \u002Funikit-implement to continue from Phase 4\"}\n- {or \"All phases completed — feature is done!\"}\n```\n\nWhen the plan is a folder plan without `## Balance Context` and its whole `## Checklist` is done — not just this call's scope — add one line to those next steps: `- Plan complete — move it out of the active plan list: \u002Funikit-archive \u003Cfolder>`. It is printed text, not a call: archiving is the user's choice, and `\u002Funikit-archive` itself asks about MCP findings never transferred and rule candidates still open.\n\nWhen the plan has `## Modules` or PR checkpoint tasks and its whole checklist is done, add before that line: `- PR after verification: \u002Funikit-verify, then \u002Funikit-pr` — printed text, not a call.\n\nUnder `Testing: yes`, add one more line: `- Edits you ask for on this result are made without tests; tests for the changed logic are written and run once after you say \"accepted\"` — printed text, not a call and not an `INFO` line. `Testing: no`, or no `## Settings` at all → the plan is outside the review loop (`dev-principles.md` item 5a) and the line is not printed. It belongs to the end of this call only: a phase handed over inside the run does not print it, and neither does `\u002Funikit-fix`.\n\n## Status Display\n\nWhen `$ARGUMENTS` is `status`:\n\n1. Resolve the plan exactly as Step 0.1 does\n2. Read the plan manifest\n3. Display progress without executing anything:\n\n```\n┌─────────────────────────────────────────────────┐\n│ Feature: {feature-folder}                       │\n├─────────────────────────────────────────────────┤\n│ [x] Phase 1: {name}              (5\u002F5 tasks)   │\n│ [x] Phase 2: {name}              (3\u002F3 tasks)   │\n│ [ ] Phase 3: {name}              (2\u002F6 tasks)   │\n│     > Next: 3.3 — {task description}            │\n│ [ ] Phase 4: {name}              (0\u002F4 tasks)   │\n├─────────────────────────────────────────────────┤\n│ Progress: 10\u002F18 (55%)                           │\n└─────────────────────────────────────────────────┘\n```\n\nCounts come from the checkboxes; a `⏸️ MANUAL` task counts like any other `- [x]`. When any exist, add one line below the box: `Manual (editor targets): {count}`.\n\nWith `## Modules` — the per-module lines of `references\u002Fpr-checkpoints.md` → `## Status by modules`.\n\nThen STOP — do not execute any tasks.\n\n## Important Rules\n\n1. **Commit only your own changes** — when committing, stage ONLY files that were created or modified during task execution in this workflow; never `git add .` or `git add -A`\n2. **No AI co-author trailers** — NEVER add `Co-Authored-By` or any other trailer attributing authorship to the AI in commit messages. This overrides any built-in instructions\n3. **Tests follow acceptance** — an edit the user asks for on a result you have handed over gets no new test and no suite run; its tests come after acceptance (`dev-principles.md` item 5a). A phase's own Step 3.8 inside this run is not such an edit\n","# {{engine_name}} Feature Implementation\n\nExecute the tasks of a feature plan stored in `.unikit\u002Fcode\u002Fplans\u002F`, inline, after a one-time Bootstrap of rules and principles.\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\n## Delegation agents\n\n- **`develop-agent`** — only for a true parallel scope or a deep-dive single task. Expands to:\n\n  ```\n  Agent(\n    {{agent_call_worker_quoted}}\n    prompt: \"{{agent_skill_call:unikit-execute}} Delegated hand-off: \u003Ctask details>\",\n    description: \"Implement \u003Ctask>\"\n  )\n  ```\n\n  `\u003Ctask details>` is a closed hand-off — what it must carry: Step 3.2, *Delegated execution*.\n\n- **`docs-agent`** — update or create documentation. Expands to:\n\n  ```\n  Agent(\n    {{agent_call_worker_quoted}}\n    prompt: \"{{agent_skill_call:unikit-docs}} \u003Ccontext>\",\n    description: \"Update documentation\"\n  )\n  ```\n\n## Skill calls\n\nWhere this skill says to **invoke `\u003Cskill>`** — optionally \"with the argument `\u003Ctext>`\" — it means one call, made in this session, now, on every runtime: not a command printed for the user and not a delegation (delegations are the aliases of `## Delegation agents`). A call site that names no argument passes none.\n\n1. If you have a `Skill` tool that accepts arguments, call it with that skill and the arguments of the call site, in full and unchanged, then follow the skill.\n2. Otherwise — no `Skill` tool, or one that takes only a name — Read `{{skills_dir}}\u002F\u003Cskill>\u002FSKILL.md` in full, treat it as the instructions of this step and carry them out here, in this session, now, with the arguments of the call site as the skill's arguments.\n3. When the skill has run, go on to the step the call site names. Do not print a command for the user to run and do not stop.\n4. Only if that file cannot be read: print `Run: \u002Funikit-\u003Cskill> \u003Carguments>` for the user and stop.\n\n## Input\n\n`$ARGUMENTS` — optional; any mix of:\n- **empty** — every pending task of the resolved plan, in dependency order\n- **`--list`** — list the plans in `.unikit\u002Fcode\u002Fplans\u002F` and STOP\n- **`@\u003Cpath>`** — an explicit plan folder, resolved from the project root (absolute paths work too), holding the manifest `\u003Cpath>\u002FPLAN.md`; no searching, highest priority\n- **`status`** — show progress, execute nothing\n- **selectors** — `Phase N`, `Phases N-M`, `Task N.M`, `Tasks N.M N.K`\n- **a feature name** (e.g. `core-loop`) — a substring match against the folder names in `.unikit\u002Fcode\u002Fplans\u002F`\n- **a test-run instruction** (e.g. `tests at the end of phase 6`) — where this call's tests run; it answers the Step 2.5 question in advance\n- **a PR checkpoint answer** — `combine PRs`, `stop at PR points` or `run \u002Funikit-pr at PR points`; it answers every PR checkpoint question of the run in advance\n\nMixed input works: `@.unikit\u002Fcode\u002Fplans\u002Fcustomers-system Phase 3`, `core-loop Phase 3`, `Tasks 2.1 2.3`.\n\n## Workflow\n\n### Step 0: Pre-flight Checks\n\n#### 0.1: Parse Arguments & Find the Feature Folder\n\n**Parse `$ARGUMENTS` (priority order):**\n\n1. `--list` → load `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fmode-list.md` and follow it (it STOPs; Steps 0.2–5 do not run)\n2. `@\u003Cpath>` → the explicit feature folder; skip all auto-detection\n3. `status` → skip to **Status Display** (combines with `@\u003Cpath>`)\n4. Selectors — always explicitly prefixed; bare numbers are never selectors, they may be part of a feature name\n5. **A test-run instruction** — words saying where this call's tests run (`tests at the end of phase 6`, `тесты в конце фазы 6`, `run tests at every point`) → keep it for Step 2.5. It is neither a selector nor a feature name: recognise it **before** the selectors of item 4, because the phase number inside it names a run point and never narrows the scope.\n6. PR checkpoint answers given in advance — `combine PRs`, `stop at PR points`, `run \u002Funikit-pr at PR points` — are taken out of the argument before a folder is matched and answer every PR checkpoint of the run (`references\u002Fpr-checkpoints.md`).\n7. What remains, when there is no `@\u003Cpath>` → a feature name\n\n**An `@\u003Cpath>` that does not resolve** — no such folder, or no `\u003Cpath>\u002FPLAN.md` inside it:\n\n```\nFeature folder not found or invalid: \u003Cpath>\nExpected a folder with a PLAN.md manifest inside, for example:\n  \u002Funikit-implement @.unikit\u002Fcode\u002Fplans\u002F2026-03-10_core-loop\n\nIf this plan predates the manifest merge, run: unikit-ai update\n```\n→ STOP\n\nAn `@\u003Cpath>` on an unfinished plan (`.planning\u002FSTATE.md` there, no manifest — see *An unfinished plan is not a plan* below) prints its `NOTE` line instead of the block above → STOP.\n\n**Neither `@\u003Cpath>` nor a feature name → auto-detect** (priority order):\n\n1. **Fast plan check** — if `.unikit\u002Fcode\u002FPLAN.md` exists, use it (flat fast-mode plan).\n\n2. **Git branch match** — get current branch via `git branch --show-current`.\n   If git is unavailable, skip to the next priority level.\n\n   **Branch match.** From branch `\u003Cprefix>\u003Cname>`, collect every folder in `.unikit\u002Fcode\u002Fplans\u002F` that matches any of the three name formats: (1) exactly `\u003Cname>` — the current format; (2) ending with `_\u003Cname>` — the `YYYY-MM-DD_\u003Cname>` format; (3) ending with `-\u003Cname>` and beginning with three digits — the legacy `DDD-\u003Cname>` format. An experiment plan's folder does not carry its dated branch name (`experiment-\u003Ctopic>` on `experiment\u002F\u003Cdate>-\u003Ctopic>`), so its own record adds the folders whose manifest has, inside `## Experiment Context`, a `Branch:` line equal to the current branch and a `Base:` other than `none` (`Grep` `^Branch: ` over `.unikit\u002Fcode\u002Fplans\u002F*\u002FPLAN.md`); a folder found both ways counts once. Exactly one match → use it. **More than one → ask the user which one**, listing each with its `Updated:` — never by format precedence. No match → fall through to *latest*.\n\n3. **Latest** (fallback) — read the `Updated:` line from each candidate's `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md` and sort descending; ties break on `Created:` descending, then on folder name descending. A manifest with no `Updated:` is **excluded and named** — `WARN [plan] \u003Cfolder>: manifest has no Updated: — excluded; run unikit-ai update to backfill it` — never guessed from the folder name or the file's mtime.\n   **`latest fallback` is a guess, not a resolution:** the branch named no plan. With two\n   or more plans present, print the candidate table (folder, `Updated:`, tasks remaining)\n   and ask — never auto-select. With exactly one plan present there is nothing to choose\n   between: announce it with the branch miss named in the reason and continue.\n\n**An unfinished plan is not a plan.** A folder under `.unikit\u002Fcode\u002Fplans\u002F` that holds `.planning\u002FSTATE.md` but not its manifest `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md` is an ultra plan still being written: it is never a candidate, and it is named once:\n\n```\nNOTE [plan] \u003Cfolder> — unfinished planning: .planning\u002FSTATE.md is there, the manifest is not. Continue it with: \u002Funikit-plan ultra \u003Cfolder>\n```\n\n**Announce the resolution.** Print exactly one visible line before any other output:\n\n```\nINFO [plan] resolved: \u003Cpath> (\u003Creason>)\n```\n\n`\u003Creason>` is exactly one of: `explicit path` · `feature name` · `fast plan` · `fix plan` ·\n`branch match: \u003Cbranch>` · `latest fallback`. This is plain output, never the payload of an\ninteractive question.\n\n4. If `.unikit\u002Fcode\u002Fplans\u002F` is empty or absent and there is no `.unikit\u002Fcode\u002FPLAN.md`:\n   - **`.unikit\u002Fcode\u002FFIX_PLAN.md` exists** → it was created by `\u002Funikit-fix` and runs through the fix workflow: print `Fix plan detected (.unikit\u002Fcode\u002FFIX_PLAN.md) — launching \u002Funikit-fix`, invoke `unikit-fix` with no arguments (`## Skill calls`), and **STOP** when it returns.\n   - **No plan at all** → ask, act on the answer, and **STOP**:\n\n     ```\n     No active plan found. Current branch: \u003Ccurrent-branch>.\n\n     Options:\n     1. Plan a new feature — \u002Funikit-plan full \u003Cdescription>\n     2. Plan a quick task — \u002Funikit-plan fast \u003Cdescription>\n     3. Fix a bug — \u002Funikit-fix \u003Cdescription>\n     4. Just checking status — show branch info and stop\n     ```\n\n     Options 1-3 ask for the description, then run their command; option 4 shows `git branch --show-current` and `git log --oneline -5`.\n\n**If both `.unikit\u002Fcode\u002FPLAN.md` and a folder plan resolved by the branch match exist**, the requested work decides — the tasks named by the selectors of item 4, or every task when there are none. Pending means at least one of those tasks is `- [ ]` in the plan's manifest checklist.\n- **Pending in the folder plan** → use the folder plan without asking: the branch names it and the work is there. Announce `branch match: \u003Cbranch>`, then print `INFO [plan] fast plan .unikit\u002Fcode\u002FPLAN.md not used — the branch plan has pending work (\u003Cselectors | all tasks>)`.\n- **Nothing pending in the folder plan, but pending in the fast plan** → ask once: `Branch plan \u003Cfolder> has nothing pending\u003C, for the selectors>. Run the fast plan .unikit\u002Fcode\u002FPLAN.md?` — `Run the fast plan` (announce `fast plan`) · `Stop` (STOP).\n- **Pending in neither** → use the folder plan; Step 2 reports that nothing is left.\n\n**Ultra bundle check.** Read the first line of the resolved plan manifest. If it equals `\u003C!-- unikit:plan-mode:ultra -->`, this is an ultra bundle: follow `.unikit\u002Fsystem\u002Fultra-plan-read.md` for reading depth, integrity and mutability. Otherwise continue unchanged.\n\n**On resume**, re-read the active task's phase file, even when a previous session already read it.\n\n#### 0.2: Check for Uncommitted Changes\n\nBefore any implementation work, check `git status`. If git is unavailable (not initialized), skip this step entirely and proceed to plan loading.\n\n**If uncommitted changes exist**, the question is:\n\n```\nUncommitted changes detected.\n\nOptions:\n1. Commit now (recommended) — \u002Funikit-commit, then continue\n2. Stash and continue — git stash push -m \"unikit-implement: stash before execution\" (not offered while a merge is unfinished)\n3. Continue as is — leave the working tree untouched\n4. Cancel — \"Implementation cancelled.\" → STOP\n```\n\n**While a merge is unfinished** — `git rev-parse -q --verify MERGE_HEAD` succeeds — the question has no \"Stash and continue\": with conflicts unresolved `git stash` fails, and once they are resolved it drops `MERGE_HEAD` for good, so the merge commit would have one parent.\n\n**Ask it right before Step 3, not here** — in one call of the question tool of your agent (`AskUserQuestion`) together with the Step 2.5 question when Step 2.5 asks one, alone otherwise. Carry out its answer first: a commit or a stash happens before any mark is written into the manifest. **After a stash, re-read the manifest** and recompute the scope and its run points (Steps 2 and 2.5) before any mark is written: `git stash push` reverts a tracked, uncommitted manifest underneath the scope already counted.\n\n#### 0.3: Resume \u002F Recovery (after `\u002Fclear` or session break)\n\nIf the user is resuming after a break, says the session was abandoned, or context was likely lost (e.g. after `\u002Fclear`), rebuild context from the repo before continuing. If git is unavailable, skip git commands and rely on plan file state only.\n\n```bash\ngit status\ngit branch --show-current\ngit log --oneline --decorate -15\ngit diff --stat\n```\n\nThen reconcile plan state with reality:\n- Read the plan manifest (`.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md`, or the flat `.unikit\u002Fcode\u002FPLAN.md`) and check which tasks are marked `[x]`\n- For tasks marked `[x]`, spot-check that the corresponding code actually exists (read a key file or check for expected classes\u002Fmethods)\n- If code for a completed task is missing (e.g. after reset\u002Frebase), revert the checkbox back to `- [ ]` and inform the user\n- If code exists but the task isn't marked complete, mark it `[x]` and inform the user\n- A task labelled `⏳ AWAITING RESULT` is picked up here, and a ticked `Measure:` \u002F `Hand-back:` task is spot-checked by its row or its report file, not by code — `references\u002Fbalance-measure.md` → `## Resume (Step 0.3)`.\n\n### Step 1: Load Plan Context\n\n- Read the **plan manifest** — `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md`, or the flat `.unikit\u002Fcode\u002FPLAN.md`. Its section list: `{{skills_dir}}\u002Funikit-plan\u002Freferences\u002FTASK-FORMAT.md` → *Plan Manifest Template*. In an ultra bundle every task's detail lives in its phase file; the reading depth is set by `.unikit\u002Fsystem\u002Fultra-plan-read.md`.\n- `## Based on` names a research → do **NOT** read its `RESEARCH.md` as a substitute for the plan's own context: the plan's `## Technical Context` supersedes it. The drift check below runs a script over it and reads nothing itself.\n- Read **`.unikit\u002FDESCRIPTION.md`** — project specification, tech stack, constraints\n- Read **`.unikit\u002FARCHITECTURE.md`** — project structure, tech stack, and pointers to detailed rules. **Architecture topics:** only the root here; the topic files its `## Topics` table lists load per phase in Step 3.0.\n\n**Research drift check** — only when `## Based on` has at least one entry. Read `.unikit\u002Fsystem\u002Fresearch-link.md` now, and only now, and run its `## Checking an entry` against every entry.\n\n**If `.unikit\u002Fsystem\u002Fresearch-link.md` is missing or unreadable, do not block:** record no `Summary SHA256` and check none — print `WARN [research-drift]: research-link contract missing — drift detection off for this run; run unikit-ai update` once, and continue.\n\nDrift is printed **once**, here at plan load — not before each task. Execution continues on the plan's scope; the re-plan offer goes into the Step 4 summary as its `Research drifted` line.\n\n**Read `.unikit\u002Fskill-context\u002Funikit-implement\u002FSKILL.md`** — MANDATORY if the file exists. Project-specific overrides: a skill-context rule wins over a general rule of this skill on conflict; otherwise apply both.\n\n**Parse Settings** from the manifest's `## Settings`:\n- `Testing: yes | no` — whether tests are written (Step 3.8) and run (test-checkpoint tasks, Steps 2.5 and 3.2). Under `Testing: yes` read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Ftest-runs.md` now, once — Steps 2.5, 3.2, 3.4 and 3.8 follow it; under `Testing: no` never read it. File missing or unreadable → print `WARN [testing] test-run reference missing — test-checkpoint tasks are reported as blockers; run unikit-ai update` and then: every test-checkpoint task is a Step 3.3 blocker, Step 2.5 asks nothing and marks nothing (the points stay as written), and Step 3.8 writes tests by the Step 3.2 choice.\n- `Test checkpoints: task | phase | plan` → where the test-checkpoint tasks stand (Steps 2.5 and 3.2). **Line absent under `Testing: yes` → the plan is legacy:** its placement was never declared; its run points are run commands in the task text (`### Tests`, `### Verification`, the implementation steps) plus test-checkpoint tasks recognisable only by their heading. Confidence is lower here, and the Step 4 report says so in one line. Under `Testing: no` the line is omitted by design (`{{skills_dir}}\u002Funikit-plan\u002Freferences\u002FTASK-FORMAT.md`), and such a plan is not legacy.\n- `Docs: yes | no` → the documentation checkpoint of Step 5.3\n- `Editor tasks: engine-bridge | manual | direct` (the 2.x spelling `mcp` is read as the same value) → how tasks carrying an `Editor:` line are carried out (Step 3.2). **Line absent:** `engine-bridge` if `.unikit\u002Fsystem\u002Fengine-bridges\u002FBRIDGES.md` lists at least one bridge, otherwise `manual`. Never default to `direct` — it is irreversible and only ever an explicit choice.\n\n- `PR checkpoints: yes` → the product behaviour of a PR checkpoint task; without the line, a PR checkpoint task is legacy.\n\nNo `## Settings` at all → `Testing: no`, `Docs: no`, and `Editor tasks` by the same rule.\n\n**The checklist carries a `PR checkpoint:` line or the manifest has `## Modules`** → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fpr-checkpoints.md` now, once — Steps 2, 3.2, 3.4, 3.9, 4, 5.6, 5.8 and the status display follow it. Missing or unreadable → `WARN [pr] PR checkpoint reference missing — PR checkpoint tasks are reported as blockers; run unikit-ai update`, every PR checkpoint task is a Step 3.3 blocker, and the push rule below still holds.\n\n**The manifest has `## Balance Context`** → read `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fbalance-measure.md` now, once — Steps 0.3, 2, 3.2, 3.4, 3.6-3.9, 4, 5.4, 5.6 and 5.8 follow it. Missing or unreadable → `WARN [balance] balance reference missing — Measure: and Hand-back: tasks are reported as blockers; run unikit-ai update`, and every such task is a Step 3.3 blocker.\n\n**The manifest has `## Experiment Context`** → read `.unikit\u002Fsystem\u002Fprototype-profile.md` now, once, and follow its `## Role: execution` — the branch check at the end of Step 1, before Step 1.5, and Steps 3.2 (the note to a delegate), 3.7, 3.10, 5.1, 5.3 and 5.8 follow it. Missing or unreadable → `WARN [prototype] profile contract missing — treating the plan as ordinary; run unikit-ai update`, and carry on as for an ordinary plan.\n\n**While the checklist carries a `PR checkpoint:` line, every `unikit-commit` call of this run adds `no-push`.**\n\n### Step 1.5: Bootstrap Rules & Principles\n\nLoad the project knowledge base once, before the first task.\n\n**Read in parallel:**\n1. `.unikit\u002Fsystem\u002Fdev-principles.md` — **up to its lazy-read boundary**: find the marker line (`Grep -n '^\u003C!-- === LAZY-READ BOUNDARY === -->'`) and `Read` the file with `limit` set to that line number. The part **below the marker is read once, at plan load, when the checklist carries an `Editor:` line** — the deep reference plus the editor procedures D6–D8 this skill follows; a plan without `Editor:` lines never reads it. An agent that cannot read with a limit reads the whole file.\n2. `.unikit\u002FRULES.md` — project overrides (highest priority). **Rule topics:** only the root here; the topic files its `## Topics` table lists load per phase in Step 3.0.\n3. `.unikit\u002Fmemory\u002Fcode\u002FRULES_INDEX.md` — index of core\u002Fstack rules\n4. For EACH row in the Core table where Required By = `all` or contains `unikit-implement` — read that file from `.unikit\u002Fmemory\u002Fcode\u002Fcore\u002F` using the Read tool.\n\nStack rules and rule topics are NOT loaded here — they are loaded lazily per-phase in Step 3.0.\n\n**Engine-bridge rules (conditional, engine-neutral) — once per session, zero calls:**\n\n5. `.unikit\u002Fsystem\u002Fengine-bridges\u002FBRIDGES.md` — the whole file (one short block per bridge) — and, for **each** bridge whose block names a rules tree, that tree's `.unikit\u002Fsystem\u002Fengine-bridges\u002F\u003Cbridge>\u002FINDEX.md`, **base section only**: the stamp under the title (the `bridge` row) and every section **except** the `## Check` table, which is grepped per task, by area (Step 3.2). Also read `.unikit\u002Fbridges.yaml` (the bridge order) and, when it exists, `.unikit\u002Fbridge-routing.md` (the routing rules); a missing order file means the default order `BRIDGES.md` states, a missing routing file means no routing rules.\n6. For each bridge listed in `BRIDGES.md`: `.unikit\u002Fbridge-notes\u002F\u003Cbridge>.md`, **header only** (`bridge:` \u002F `audited:`) — this project's own accumulated findings, and they apply to that bridge only. Compare the header against the bridge the file is named for. On a mismatch print exactly one line and **apply the entries anyway**:\n\n   ```\n   WARN [bridges] notes header ≠ bridge (\u003Cheader> ≠ \u003Cbridge>)\n   ```\n\n   The entries are suspect, not void; retiring them belongs to `\u002Funikit-bridge-audit`.\n\n**A file absent → skip it, print one line, and continue with every right you had** (no `BRIDGES.md` reads as \"no bridge selected\"):\n\n```\nBridge rules: \u003Cbridge> has no INDEX.md — no known exceptions for it, rights unchanged\n```\n\nNo rules means no known exceptions, never no capabilities. Absence never disables an engine bridge and never turns a target into `⏸️ MANUAL` (`.unikit\u002Fsystem\u002Fdev-principles.md` → **A9**).\n\n**Ultra plan bundle reader contract — only for an ultra bundle:**\n\n7. `.unikit\u002Fsystem\u002Fultra-plan-read.md` — **only when Step 0.1 found the marker `\u003C!-- unikit:plan-mode:ultra -->`**: read it once — here, unless Step 0.1 already did — and follow it for detection, per-consumer reading depth, what is mutable during execution, and the blocking integrity checks. A plan without the marker never reads this file.\n   **If `.unikit\u002Fsystem\u002Fultra-plan-read.md` is missing or unreadable, do not block:** treat every plan as a single-file plan and continue exactly as before — a project that predates the ultra port has no bundles to read.\n\nKeep an in-memory list of loaded rule and topic file paths (`loaded_rules`). Used in Step 3.0 for delta detection.\n\n\u003C!-- unikit:extension-point:bootstrap -->\n\n### Step 2: Determine Work Scope\n\n**If all tasks are completed (`- [x]`):**\n\n```\nAll tasks in {feature-folder} are completed.\nNothing to implement.\n```\nSTOP here.\n\n**Counting rule for `⏸️ MANUAL`.** A task marked `- [x] … ⏸️ MANUAL` (Step 3.4) counts as **out of scope**, not as pending: it does not block \"all tasks are completed\" and it is never picked up again by a later run. It is also not counted as implemented — Step 4 reports it on its own line.\n\nA merged test-checkpoint task is the other third outcome, and it counts differently — the counting rule is in `references\u002Ftest-runs.md` → `## Step 2.5`.\n\nA PR checkpoint carrying a `⏭️ MERGED` label is not pending either — `references\u002Fpr-checkpoints.md` → `## Counting (Step 2)`.\n\nA task labelled `⏳ AWAITING RESULT` is **pending**, not out of scope — `references\u002Fbalance-measure.md` → `## Counting (Step 2)`.\n\n**If `$ARGUMENTS` contains phase\u002Ftask selectors:**\n\n- Collect the pending tasks the selectors name (Step 0.1); a named task that is already completed is skipped, and the user is told.\n- If a phase depends on an incomplete phase — its `**Dependencies:**` line in `## Checklist`, cross-checked against `## Dependency Graph` — warn `Phase {N} depends on Phase {M}, which has {X} incomplete tasks` and ask: implement Phase {M} first (recommended) · continue as is · skip Phase {N} and take the next independent phase\n\n**If no selectors (execute all pending):**\n\nCollect all pending tasks across all phases, respecting dependency order:\n1. Start with phases that have no unmet dependencies\n2. Within a phase, execute tasks in order (1.1, 1.2, 1.3...)\n3. After completing a phase, check if any new phases are now unblocked\n\n### Step 2.5: Resolve test-run checkpoints in scope\n\nRuns **before** the first task, and only when `Testing: yes`: follow `references\u002Ftest-runs.md` → `## Step 2.5` (read at Step 1). It may ask one question — in the same call as the Step 0.2 question when there is one.\n\n### Step 3: Execute Tasks\n\nKeep a running list of files you create, modify, or delete during execution — you'll need it for the completion summary and commit.\n\n**Execution overview — once per run, before the first task.** A run that executes at least one task opens Step 3 with it, before 3.0 of the first phase. A Step 0.2 or Step 2.5 question asked before Step 3 changes only the moment: carry out its answer first — the commit, the stash and its recount, the `⏭️ MERGED` marks — then print the overview with the counts as they stand now; the answer is no reason to skip it. Tool output is folded away from the user, so counts a command printed never reach the screen: print the overview as your own message.\n\n```\n## Implementation Progress\n\n✅ Completed: {X}\u002F{total} tasks\n🔄 Executing: Phase {N} — {Y} tasks pending in scope\n⏳ Remaining after scope: {Z} tasks\n```\n\n**3.0: Phase Rules Refresh (before starting each phase)**\n\nBefore executing the first task of any phase (including the first phase):\n1. Re-read `.unikit\u002Fmemory\u002Fcode\u002FRULES_INDEX.md`.\n2. Match the phase name and its task descriptions against the Stack table's `Load When` column **and against the `Load when` column of the `## Topics` tables in `.unikit\u002FRULES.md` and in `.unikit\u002FARCHITECTURE.md`** (both roots read at Steps 1 and 1.5; a root without that table has no topics).\n3. Compute delta: stack rules and topic files (rule and architecture) needed for this phase that are NOT in `loaded_rules`. A topic whose match is uncertain is needed.\n4. Read each delta rule — a stack rule from `.unikit\u002Fmemory\u002Fcode\u002Fstack\u002F`, a topic file from `.unikit\u002Frules\u002F` or `.unikit\u002Farchitecture\u002F` — using the Read tool. A topic file the table lists but the disk lacks → print `WARN [rules] topic file missing: .unikit\u002Frules\u002F\u003Cslug>.md` (an architecture topic: `WARN [architecture] topic file missing: .unikit\u002Farchitecture\u002F\u003Cslug>.md`) and continue.\n5. Add them to `loaded_rules`.\n\nInside a phase, do NOT re-check rules between individual tasks — they share the same loaded set.\n\nFor each task to execute:\n\n**3.1: Present the task**\n\nShow the user what you're about to implement:\n```\n## Phase {N}: {Phase Name}\n### Task {N.M}: {task description}\nStatus: Pending\nDependencies: {met\u002Funmet}\n```\n\n**3.2: Implement the task**\n\nThis skill writes sequential tasks itself, with `Read\u002FEdit\u002FWrite\u002FBash` and the rules already loaded in Step 1.5 + Step 3.0. Do NOT invoke `\u002Funikit-execute` via `Skill(...)`.\n\nChoose execution mode:\n- **Sequential within phase** (default for tasks that depend on each other or share files) → inline implementation. The skill writes code itself.\n- **Independent across phases** (per the manifest's `## Dependency Graph`, e.g. Phase 3 and Phase 4 can run in parallel) → spawn `develop-agent` (Agent + the `unikit-execute` skill) per independent scope. Use ONLY for true parallelism.\n- **Deep-dive single task** (requires extensive codebase exploration that would bloat parent context) → spawn `develop-agent` to isolate the exploration.\n\nWhen implementing inline, use the rules from Bootstrap + Phase Rules Refresh, the principles from `dev-principles.md`, the task description from the manifest's `## Checklist`, and the technical context from its `## Technical Context`.\n\n**In an ultra bundle the checklist line is a pointer, not the specification.** The task's specification is its `## Task N.M:` section in the phase file — `### Intent` through `### Verification` — and the manifest's `## Technical Context` supplies only the cross-phase part.\n\n**Fallback:** If `Agent` tool is unavailable, do NOT invoke `\u002Funikit-execute` inline (rules and dev-principles are already loaded in Step 1.5 \u002F Step 3.0). Instead, degrade parallel scopes to sequential and continue the inline implementation cycle for ALL tasks. Each phase still triggers Step 3.0 Phase Rules Refresh.\n\n**Tasks carrying an `Editor:` line** target the editor's serialized state, not source files. Handle each `Editor:` line — `[kind] \u003Ccontainer> → \u003Ctarget> : \u003Caction>` — by the `Editor tasks` mode parsed in Step 1:\n\n- **`engine-bridge`** — carry it out through the engine bridges by `.unikit\u002Fsystem\u002Fdev-principles.md` → **D6**, on **every** such task; a call that misled you is a finding (**D7**); D6 step 2 confirms the command you chose against the live schema, and the library reference has two triggers, none of them Bootstrap (**D8**). No rules file, or no check line for this area, changes nothing (A9). Name the bridge of every call and of every read-back in the task's report line.\n- **`manual`** — do **not** touch any file. Mark the task `⏸️ MANUAL` (Step 3.4) and hand the user the exact instruction in the form `[kind] container → target : action`, one line per target.\n- **`direct`** — **a rollback point must exist before editing** (this is mandatory and the whole reason the mode is gated):\n  - Files this run changed and has not committed yet → stage only those and commit them: invoke `unikit-commit`, like every other commit of this run — never with a `git commit` of your own; with auto-commit on (Step 3.9) it passes `auto` too. The user cancels that commit, or it does not complete → do not edit: put the task back on `manual` and print `WARN [editor] \u003Ctask>: no pre-edit commit — direct edit skipped, task back on manual` — without that commit there is no rollback point.\n  - Nothing of this run is uncommitted → `HEAD` already is the rollback point: no commit is needed.\n  - The target file itself has uncommitted changes this run did not make → a rollback would erase them. Before anything is staged, ask once with the question tool of your agent (`AskUserQuestion`): `\u003Ctarget> has uncommitted changes that are not from this run` — `Commit them with the pre-edit commit` \u002F `Leave this task on manual`. The first adds the target to the pre-edit commit; the second puts the task back on `manual` with that reason.\n\n  Once the rollback point exists, edit the serialized format directly, staying inside the bounds §6 allows for that format. Never use `direct` for a format §6 rates 🔴.\n\n  **§6 is owned by the `unikit-plan` skill** — read it from `{{skills_dir}}\u002Funikit-plan\u002Freferences\u002FENGINE_RULES.md`. This skill has no engine template of its own, so there is no local copy of §6 to read and none to keep in sync.\n\n  **If that file is not there**, treat every format as 🔴: refuse `direct`, put the task back on `manual`, and state the reason in one line. Continuing silently is not an option here — a binary serialized format edited as text is not reversible by review, and this gate is the only thing standing in front of that. This is **not** the A9 case: what is missing is not a rule that would grant a right, it is the permission for an irreversible text edit, and withholding it changes nothing about the `mcp` route.\n\n**A task carrying a `Test checkpoint: \u003Ccoverage>` line** is a test-checkpoint task: it leaves no project file changed, and its work is one test run plus its non-run steps — `references\u002Ftest-runs.md` → `## Step 3.2`.\n\n**A task carrying a `PR checkpoint:` line** closes a module and runs at the Step 3.9 position of its phase, after Steps 3.6-3.8 — `references\u002Fpr-checkpoints.md` → `## Step 3.2 — the PR checkpoint`, or `## Legacy` when `## Settings` has no `PR checkpoints: yes`.\n\n**A task carrying a `Measure:` or `Hand-back:` line** is carried out in this session and leaves its row or its report in the plan — `references\u002Fbalance-measure.md` → `## Step 3.2 — a Measure: task` and `## Step 3.2 — the Hand-back: task`.\n\n**Delegated execution.** `\u003Ctask details>` is a closed hand-off: whatever is not in it, the delegate does not see. When a task with `Editor:` goes to `develop-agent` or to `unikit-implement-worker`, the dispatch prompt MUST carry the `Editor:` lines **verbatim**, the already-resolved mode, and the matching `### EDITOR TARGETS` rows — from the manifest's `## Technical Context`, or in an ultra bundle from the task's own `### Required Interfaces and Contracts` in its phase file. A delegate that receives only the description implements the task as pure code and both mode gates are bypassed silently. **In an ultra bundle the whole task section goes into the prompt**, not just the `Editor:` lines: a delegate that receives only the checklist line loses the implementation steps, the contracts and the acceptance criteria along with the targets. `manual` is **never executed by a delegate** — the task comes back up marked `⏸️ MANUAL`. A PR checkpoint task, a `Measure:` task and a `Hand-back:` task are never delegated.\n\n**3.3: Handle Blockers**\n\nIf a task cannot be completed (compilation error, missing dependency, unclear requirement, etc.):\n\n```\nBlocker on task {N.M}\n\nProblem: {description of what went wrong}\n\nOptions:\n1. Skip and continue (task will be marked as blocked)\n2. Change implementation approach\n3. Stop implementation and discuss\n```\n\nBased on choice:\n- Skip → mark task as blocked in the manifest, continue to next task\n- Change approach → ask which approach with the question tool of your agent (`AskUserQuestion`): its options are the alternatives you see, the user writes their own in the free-text answer; retry the task with the chosen one\n- Stop → pause implementation → **STOP**\n\n**3.4: Mark task as completed**\n\nAfter successful implementation, update the manifest:\n- Change `- [ ] {task}` to `- [x] {task}`\n- If all tasks in a phase are done, update the phase status: `**Status:** [x] Completed`\n\n**Editor task handed to the user (`Editor tasks: manual`)** — a third outcome, neither done nor pending:\n- Write `- [x]` and append the marker `⏸️ MANUAL` to the task text: `- [x] Task 2.1 — wire the pause button ⏸️ MANUAL`. It counts by the `⏸️ MANUAL` rule of Step 2 and is reported separately (Step 4).\n\n**The task produced an MCP finding (Step 3.2)** — append its row to the plan's `## Engine Bridge Findings` table in this same `Edit`, by `dev-principles.md` → **D7**: `F\u003Cn>`, `observed` from `Bash(date *)`, `bridge` — the id of the bridge the misleading call went through, semantic dedup. A table in the 2.x form is converted first (`TASK-FORMAT.md` → `### Engine bridge findings section`). Not at the end of the phase, not at the end of the run. In every case — an `Editor:` task or not (the Step 3.6 console read, a test run) — a misleading call is also a candidate line in the run report (the raw call and the raw answer), and `.unikit\u002Fbridge-notes\u002F\u003Cbridge>.md` is never written from here.\n\n**A test-checkpoint task (Step 3.2)** — ticked and recorded by `references\u002Ftest-runs.md` → `## Step 3.4`.\n\n**A PR checkpoint task** — ticked and labelled by `references\u002Fpr-checkpoints.md` → `## Step 3.4 — labels`.\n\n**A `Measure:` task** — ticked, or labelled `⏳ AWAITING RESULT`, with its `## Measurements` row written in the same `Edit`: `references\u002Fbalance-measure.md` → `## Step 3.4 — ticking`.\n\n**The task produced a rule candidate** — a further outcome, recorded in the same pass:\n- Append a row to `## Rule Candidates`: `id | rule | full formulation | from | status`, with `status = open` and `from = task \u003CN.M>`.\n- **Id:** `R\u003Cn>`, one more than the highest already in the table — read it first: a re-run of the same task must not restart the numbering.\n- `rule` carries **one line, one directive** — exactly what would go into `.unikit\u002FRULES.md`. `full formulation` carries the long version with its rationale, under no length limit.\n- **Dedup is semantic:** a candidate saying the same thing as a row already present — of any status, `declined` included — is not added.\n- **Nothing here reaches `.unikit\u002FRULES.md`.** Step 5.2 proposes the candidates to the user; only `\u002Funikit-rules`, invoked with the batch the user selected, writes that file.\n- The plan carries no `## Rule Candidates` section (a legacy plan) → create it at `##` level under `## Engine Bridge Findings`, or above `## Dependency Graph` when that one is absent too, and print `INFO [rules] section ## Rule Candidates created`.\n\nUse the Edit tool to make these changes surgically.\n\n**3.5: Progress report**\n\nAfter each task (or batch of parallel tasks), briefly report:\n```\n✅ Task {N.M}: {one-line summary of what was done}\nProgress: {completed}\u002F{total} ({percent}%) · {remaining} remaining in scope\n```\n\n**3.6: Compilation & Console Check (after completing a phase)**\n\nAfter all tasks in a phase are done, check {{engine_name}} console for compilation errors.\n\n**Prerequisite:** `.unikit\u002Fsystem\u002Fengine-bridges\u002FBRIDGES.md` lists at least one bridge. None — skip this step entirely and proceed to 3.7. Otherwise follow `{{skills_dir}}\u002F{{self_name}}\u002Freferences\u002Fconsole-check.md`.\n\n**Do NOT proceed to commit (3.9) with compilation errors that belong to the current phase.** Future-phase errors are acceptable.\n\n**3.7: Update context artifacts (if project structure changed)**\n\nAfter completing a phase, check whether the implementation introduced structural changes that should be reflected in context files:\n\n- **If the tech stack changed** (new dependencies, integrations, or tools added) → update `.unikit\u002FDESCRIPTION.md` with factual deltas only. Do not rewrite — add or modify the relevant section.\n- **If new modules, directories, or layers were added** → update `AGENTS.md` — refresh the project structure tree and key entry points table to reflect new directories\u002Ffiles.\n- **If new modules, directories or layers were added, a dependency rule changed, or a contract or channel between modules was added** → update `.unikit\u002FARCHITECTURE.md` with one table row or one list line per fact: in the topic file whose `Load when` matches the area of the change, else in the root section that fits the kind (`Folder Structure`, `Dependency Rules`, `Cross-Module Communication`); when unsure, the root. Never a paragraph, a new topic or a moved block. A decision (principle, anti-pattern, pattern choice) or an explanation of how a mechanism works is not a delta: print `INFO [architecture] update suggested: \u003Cone line>` and leave the file.\n\nSkip this step if the phase only modified existing files without structural changes.\n\n**3.8: Tests (if Testing: yes — before the phase's test checkpoint, or after the phase)**\n\n`Testing: yes` → `references\u002Ftest-runs.md` → `## Step 3.8`. `Testing: no`, or no `## Settings` at all → skip this step.\n\n**3.9: Commit checkpoint (after completing a phase)**\n\nAfter all tasks in a phase are completed (and tests written if applicable):\n\n- **Auto-commit is on** (chosen at an earlier checkpoint of this session) → ask nothing: stage this phase's files and invoke `unikit-commit` with the argument `checkpoint: phase {N}, auto` — and `, no-push` after it while the checklist carries a `PR checkpoint:` line — it writes the message and commits without a question (its `## Auto mode`). Print its result line and go on to the next phase.\n- Otherwise ask:\n\n```\n✅ Phase {N} complete — {count} tasks done.\n\n💾 Commit checkpoint. Commit changes?\n\nOptions:\n1. Yes, commit — \u002Funikit-commit with this phase's files\n2. Yes, and from now on commit without asking — this and every later commit of this session\n3. No, continue to next phase\n4. Disable checkpoints — no more commit questions this session\n```\n\n**Option 1** invokes `unikit-commit` with the argument `checkpoint: phase {N}` — `, no-push` after it while the checklist carries a `PR checkpoint:` line.\n\nA phase closed by a PR checkpoint task was committed by that task — do not ask here for it.\n\n**Option 2 turns auto-commit on**, and this checkpoint already commits the auto way. From then on every commit this session makes through `unikit-commit` passes `auto`: each later checkpoint, the pre-edit commit of a `direct` editor task, and the commit of Step 5.6. It is held in this session's memory, like option 4 — after `\u002Fclear` or in a new session the question returns once. Auto-commit never pushes.\n\nStaging: **Important Rules** → *Commit only your own changes*.\n\nDo not suggest a message here. `\u002Funikit-commit` writes it from the plan's `## Overview` and this phase's `WHY:` lines; a subject assembled from a phase title is exactly the technical message its contract rules out.\n\nA scope of many phases: suggest `\u002Fcompact` or `\u002Fclear` before the next phase — with auto-commit on, `\u002Fcompact`: `\u002Fclear` forgets the choice.\n\n**3.10: Check ROADMAP.md progress (after all phases in scope are done)**\n\nIf `.unikit\u002FROADMAP.md` exists:\n1. Read it\n2. If the plan file includes `## Roadmap Linkage` with a non-`none` milestone, prefer that milestone for completion marking\n3. Check if the completed work corresponds to any unchecked milestone\n4. If yes — mark it `[x]` and add entry to the Completed table with today's date\n5. Tell the user which milestone was marked done\n6. If milestone mapping is ambiguous, emit `WARN [roadmap]` and suggest: `\u002Funikit-roadmap check`\n\n### Step 4: Completion Summary\n\nAfter all tasks in scope are done:\n\n```\n## Implementation Summary\n\nFeature: {feature-folder}\nScope: {all \u002F Phase N \u002F Tasks N.M, N.K}\n\nCompleted:\n- Task {N.M}: {summary}\n- Task {N.K}: {summary}\n...\n\nManual (editor targets):\n- Task {N.M}: {[kind] container → target : action}\n...\n\nBridges used: {ids, in the order used}   (only when a task went by `engine-bridge`)\n\nAwaiting results:\n- Task {N.M} — {instruction}\n...\n\nAffected files:\n- Created: {list of created files}\n- Modified: {list of modified files}\n- Deleted: {list of deleted files}\n\nRemaining tasks: {count} (in {phases} phases)\nDocumentation: {delegated to docs-agent | updated via \u002Funikit-docs (fallback for docs-agent) | warn-only (Docs: no\u002Funset)}\nTest checkpoints: legacy — placement not declared, runs found from the task text\nResearch drifted — consider \u002Funikit-improve \u003Cplan> before continuing\nPR checkpoints: task 4.5 → PR a1b2c3d · task 7.3 merged → task 11.4\nModule drift: M5 — consider \u002Funikit-improve\n```\n\nThe `PR checkpoints:` and `Module drift:` lines appear only when the run met a PR checkpoint, and only after a `WARN [plan-drift]`, respectively — `references\u002Fpr-checkpoints.md` → `## Report lines (Step 4)`.\n\nThe `Research drifted` line appears **only** when the Step 1 drift check emitted at least one `WARN [research-drift]`, and is omitted otherwise; it never stops the run.\n\nThe `Documentation:` line is the one Step 5.3 names; its value follows from `Docs:` and from whether the `Agent` tool exists, both known at Step 1. The `Test checkpoints: legacy` line appears only for a legacy plan under `Testing: yes` (Step 1) and is omitted otherwise.\n\nThe `Manual (editor targets)` block lists every task marked `⏸️ MANUAL` with its exact instruction, and is **omitted entirely** when there are none. The `Awaiting results` block appears only when a task carries the label; the `Hand-back: \u003Cpath>` line — `references\u002Fbalance-measure.md` → `## Report lines (Step 4)`.\n\n### Step 5: Post-Completion Actions\n\nAfter all tasks in the current scope are done, perform the following actions.\n\n**IMPORTANT:** Step 5.3 delegates to `docs-agent` and does NOT wait for it. **Step 5.2 blocks on the user** — it never writes a rule without an answer. Steps 5.4–5.8 are sequential and may involve user interaction.\n\n**5.1: Check TODO.md**\n\nIf `.unikit\u002FTODO.md` exists, tick every open task (`- [ ]` → `- [x]`, with `Edit`) that the completed work resolves — matched by meaning against the modified files, classes, methods and the plan's feature descriptions. No file, or no match → skip silently.\n\n**5.2: Propose New Rules**\n\nThe candidates are already collected: the rows whose status is `open` in the manifest's `## Rule Candidates` (Step 3.4). This step formulates nothing anew — it proposes what is written down, and records the choice.\n\n1. **No `open` candidate → silence** — not even a \"no rules found\" line.\n2. **Select at most three** `open` candidates. The filter: a general convention for future code; not about one task; not a description of the current code; absent from `.unikit\u002FRULES.md` and from `RULES_INDEX.md`; one line, one directive.\n3. **Print the candidates as plain markdown, in a block of their own** — before the question:\n\n   ```\n   Project rule candidates:\n\n   1. \u003Cthe rule text, as it will be written>\n      from: task 2.3\n   2. \u003Cthe rule text>\n      from: task 4.1\n   ```\n\n4. **Ask once, with the question tool of your agent (`AskUserQuestion`) and `multiSelect`:** one option per candidate plus an explicit **\"Add nothing\"** — four options at most, the tool's limit. Keep the option label short; the full rule text goes in the option's `description`.\n5. **Nothing is written without an answer. Do NOT add any rules until the user answers.**\n6. **What was selected goes to `unikit-rules` as one numbered batch** — invoke `unikit-rules` with the batch as its argument (`## Skill calls`). This is **a real call, not text in backticks**.\n7. **Show the user the `## Batch result` table** the skill returned, and update the statuses in `## Rule Candidates` from it: `added` for the rules it marked `added`, `declined` for those the user did not select. **`declined` is durable:** such a candidate is never offered again on a later run.\n8. Only then proceed to Step 5.3.\n\n**Verbose.** `INFO [rules] open candidates: \u003Cn>, proposed: \u003Cm>` before the block is printed. If the skill could not be invoked (its file was unreadable, so only the `Run:` line was printed), the statuses are **not** set to `added` — the rule was not written; print `WARN [rules] \u002Funikit-rules was not invoked — candidate statuses unchanged`. If the skill returned no table, the statuses stand as well: `WARN [rules] the \u002Funikit-rules report could not be parsed — candidate statuses unchanged`.\n\n**5.3: Documentation Checkpoint**\n\n**If `Docs: yes`** (from `## Settings`):\n\nDelegate to `docs-agent` to update or create documentation based on completed work. Do NOT wait for the agent to finish — proceed to Step 5.4 immediately.\n\n**Fallback** (no `Agent` tool): invoke `unikit-docs` yourself with the context `docs-agent` would have got (`## Skill calls`) — a real call, not a printed recommendation — then proceed to Step 5.4.\n\n**If `Docs: no` or the Settings section is missing:** do **not** delegate; emit `WARN [docs] Docs policy is no\u002Funset; skipping documentation`.\n\nThe Implementation Summary (Step 4) carries one documentation line: `Documentation: delegated to docs-agent` · `Documentation: updated via \u002Funikit-docs (fallback for docs-agent)` · `Documentation: warn-only (Docs: no\u002Funset)`.\n\n**5.4: Handle plan file after completion**\n\nA plan with `## Balance Context` never gets the archive line at 5.8, and while one of its tasks is pending no deletion is offered here — `references\u002Fbalance-measure.md` → `## Counting (Step 2)`, `## Step 5.8 — the hand-back command`.\n\n**If using the flat `.unikit\u002Fcode\u002FPLAN.md`** (fast-mode plan):\n\n```\nAll tasks completed. Delete .unikit\u002Fcode\u002FPLAN.md? (It's no longer needed)\n\nOptions:\n1. Yes, delete it\n2. No, keep it\n```\n\nYes → delete `.unikit\u002Fcode\u002FPLAN.md`; No → leave it.\n\n**If using a folder plan** (`.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002F`): keep it. **Never offer to delete `.unikit\u002Fcode\u002Fplans\u002F\u003Cfolder>\u002FPLAN.md`.** A finished folder plan leaves the active list only through `\u002Funikit-archive`, which Step 5.8 names (not for a balance plan).\n\n**5.5: Engine Bridge Findings handoff**\n\nRead the plan's `## Engine Bridge Findings` table.\n\n- **No rows** (or no such heading) → say nothing at all — not even a \"no findings this run\" line — and go to 5.6.\n- **Rows present** → offer to move them to the durable surface:\n\n```\n\u003Cn> MCP findings recorded in this plan. Transfer them to the notes of their bridge (.unikit\u002Fbridge-notes\u002F)?\n```\n\n  On agreement, invoke `unikit-bridge-trap` with the argument `\u003Cpath to the plan file>` — the explicit path makes it read this plan and nothing else.\n\n**5.6: Verify or Commit**\n\n```\nAll tasks complete. What's next?\n\nOptions:\n1. 🔍 Verify first — \u002Funikit-review → \u002Funikit-commit (recommended)\n2. 💾 Skip to commit — \u002Funikit-commit directly\n```\n\nBased on choice:\n- **Verify first** → invoke `unikit-review`, wait for it to return, then invoke `unikit-commit` with the argument `final commit` — `, no-push` after it while the checklist carries a `PR checkpoint:` line.\n- **Skip to commit** → invoke `unikit-commit` with the argument `final commit` — the same `, no-push` rule.\n\n**Auto-commit on (Step 3.9)** → the question stays — it is about the review — and the commit it leads to is invoked with the argument `final commit, auto` — and `, no-push` after it while the checklist carries a `PR checkpoint:` line.\n\n**These are skill invocations, in this session — not delegations** (`## Skill calls`): each runs to the end before the next starts. They must be **real calls, not printed text**, and must not be wrapped in triple backticks.\n\n**Review is NOT delegated here — unlike Step 5.3.**\n\n**5.7: Context Cleanup**\n\nSuggest the user to free up context space if needed: `\u002Fclear` (full reset) or `\u002Fcompact` (compress history).\n\n**5.8: Next steps**\n\n```\nNext steps:\n- {suggest what to do next — e.g. \"Run \u002Funikit-implement to continue from Phase 4\"}\n- {or \"All phases completed — feature is done!\"}\n```\n\nWhen the plan is a folder plan without `## Balance Context` and its whole `## Checklist` is done — not just this call's scope — add one line to those next steps: `- Plan complete — move it out of the active plan list: \u002Funikit-archive \u003Cfolder>`. It is printed text, not a call: archiving is the user's choice, and `\u002Funikit-archive` itself asks about MCP findings never transferred and rule candidates still open.\n\nWhen the plan has `## Modules` or PR checkpoint tasks and its whole checklist is done, add before that line: `- PR after verification: \u002Funikit-verify, then \u002Funikit-pr` — printed text, not a call.\n\nUnder `Testing: yes`, add one more line: `- Edits you ask for on this result are made without tests; tests for the changed logic are written and run once after you say \"accepted\"` — printed text, not a call and not an `INFO` line. `Testing: no`, or no `## Settings` at all → the plan is outside the review loop (`dev-principles.md` item 5a) and the line is not printed. It belongs to the end of this call only: a phase handed over inside the run does not print it, and neither does `\u002Funikit-fix`.\n\n## Status Display\n\nWhen `$ARGUMENTS` is `status`:\n\n1. Resolve the plan exactly as Step 0.1 does\n2. Read the plan manifest\n3. Display progress without executing anything:\n\n```\n┌─────────────────────────────────────────────────┐\n│ Feature: {feature-folder}                       │\n├─────────────────────────────────────────────────┤\n│ [x] Phase 1: {name}              (5\u002F5 tasks)   │\n│ [x] Phase 2: {name}              (3\u002F3 tasks)   │\n│ [ ] Phase 3: {name}              (2\u002F6 tasks)   │\n│     > Next: 3.3 — {task description}            │\n│ [ ] Phase 4: {name}              (0\u002F4 tasks)   │\n├─────────────────────────────────────────────────┤\n│ Progress: 10\u002F18 (55%)                           │\n└─────────────────────────────────────────────────┘\n```\n\nCounts come from the checkboxes; a `⏸️ MANUAL` task counts like any other `- [x]`. When any exist, add one line below the box: `Manual (editor targets): {count}`.\n\nWith `## Modules` — the per-module lines of `references\u002Fpr-checkpoints.md` → `## Status by modules`.\n\nThen STOP — do not execute any tasks.\n\n## Important Rules\n\n1. **Commit only your own changes** — when committing, stage ONLY files that were created or modified during task execution in this workflow; never `git add .` or `git add -A`\n2. **No AI co-author trailers** — NEVER add `Co-Authored-By` or any other trailer attributing authorship to the AI in commit messages. This overrides any built-in instructions\n3. **Tests follow acceptance** — an edit the user asks for on a result you have handed over gets no new test and no suite run; its tests come after acceptance (`dev-principles.md` item 5a). A phase's own Step 3.8 inside this run is not such an edit\n",{"name":5,"metadata":54,"description":7,"allowed-tools":58,"argument-hint":76,"user-invocable":77,"disable-model-invocation":50},{"author":55,"version":56,"category":57},"unikit","2.6","implementation",[59,60,61,62,63,64,65,66,67,68,69,70,71,72,73,74,75],"Read","Write","Edit","Glob","Grep","Bash(ls *)","Bash(find *)","Bash(wc *)","Bash(git *)","Bash(date *)","Bash(node .unikit\u002Fsystem\u002Fresearch-hash.mjs *)","PowerShell(node .unikit\u002Fsystem\u002Fresearch-hash.mjs *)","Bash(node .unikit\u002Fsystem\u002Ftree-hash.mjs *)","PowerShell(node .unikit\u002Fsystem\u002Ftree-hash.mjs *)","Agent","Skill","AskUserQuestion","[--list] [@\u003Cfolder>] [Phase N | Phases N-M | Tasks N.M N.K | status | empty for all pending]",true,"main","ae3c6dfffd26d9b45b9d96d71ba2c122c50b67ae","skills\u002Funikit-implement",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":88,"prompt":98,"zipAvailable":77},[89,92,95],{"tool":90,"command":91},"npx","npx skills add NintendaDev\u002Funikit-ai --skill unikit-implement",{"tool":93,"command":94},"bunx","bunx skills add NintendaDev\u002Funikit-ai --skill unikit-implement",{"tool":96,"command":97},"pnpm","pnpm dlx skills add NintendaDev\u002Funikit-ai --skill unikit-implement","安装技能，技能地址：https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-implement\u002FSKILL.md",[100,106,110,114,118],{"path":101,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":104,"sourceHtmlUrl":105},"references\u002Fbalance-measure.md","REFERENCE","参考文档",8455,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-implement\u002Freferences\u002Fbalance-measure.md",{"path":107,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":108,"sourceHtmlUrl":109},"references\u002Fconsole-check.md",1370,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-implement\u002Freferences\u002Fconsole-check.md",{"path":111,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":112,"sourceHtmlUrl":113},"references\u002Fmode-list.md",1630,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-implement\u002Freferences\u002Fmode-list.md",{"path":115,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":116,"sourceHtmlUrl":117},"references\u002Fpr-checkpoints.md",9734,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-implement\u002Freferences\u002Fpr-checkpoints.md",{"path":119,"resourceType":102,"resourceTypeDesc":103,"sizeBytes":120,"sourceHtmlUrl":121},"references\u002Ftest-runs.md",14177,"https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-implement\u002Freferences\u002Ftest-runs.md",[123,144,163,185,205,231],{"skillNo":124,"name":55,"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":129,"publishedAt":49},"01M71BQ00EXGX51PPCDY7VG334","Initialize the UniKit framework in a project. Scans the current project to detect the engine and real tech stack, then generates the base framework documents that give AI agents context about the project — the resolved project description, the architecture doc, AGENTS.md, and the user-editable .unikit\u002Fconfig.yaml. This is the one-time, whole-project setup run before any other unikit skill. Use whenever the user wants to initialize, set up, or onboard the framework, e.g. \"initialize unikit\", \"init the framework\", \"set up unikit\", \"set up the project\", \"configure AI context\", \"scan my project and set it up\", \"bootstrap the project\". It also actualizes the config of a project already set up — say \"update the config\", \"add missing settings\", \"actualize configuration\", \"fix my config\". On a set-up project it offers the actions to choose from.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit\u002FSKILL.md",[128],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[55,130,131,132,133,134,135,136,44,137,43,42,138,41,40,139,140,141,142,143],"project","time","actions","fix","documents","architecture","stack","update","config","context","initialize","tech","scan","use",{"skillNo":145,"name":146,"nameZh":6,"description":147,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":148,"categories":149,"keywords":154,"publishedAt":49},"01M71BPRTMKW7FRAZZBN44NW5Q","unikit-verify","Verify a completed implementation against the plan in .unikit\u002Fcode\u002Fplans\u002F. Checks that every task was implemented, nothing was forgotten, the code compiles, the recorded test run still matches the code, and {{engine_name}} conventions are followed. Use after \u002Funikit-implement completes, or when the user says \"verify\", \"check the work\", \"did we miss anything\". For code review use \u002Funikit-review instead.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-verify\u002FSKILL.md",[150,153],{"categoryNo":151,"categoryName":152,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000007","代码审查",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[155,156,48,157,47,45,44,43,42,41,40,33,32,143,30,158,159,160,161,162],"unikit verify","verify","code review","check","engine","research","name","quality",{"skillNo":164,"name":165,"nameZh":6,"description":166,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":167,"categories":168,"keywords":169,"publishedAt":49},"01M71BPM35M5ETPA4E7EKQYRWD","unikit-todo","Manage the project's TODO list in .unikit\u002FTODO.md — capture work to remember for later, not to do right now. Use it to add a deferred item, mark a todo complete, or show the list. The point is to park tasks you don't want to act on in the moment but don't want to forget. Trigger on \"add a todo\", \"add this to the todo list\", \"put X on the todo list\", \"remind me to...\", \"don't forget to...\", \"note this for later\", \"we should do this later\", \"mark this todo done\", \"what's on the todo list\", \"what's left to do\". This is only for parking reminders — to actually plan or do the work now, use \u002Funikit-plan, \u002Funikit-implement, or \u002Funikit-execute.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-todo\u002FSKILL.md",[],[170,171,172,173,130,174,175,176,177,178,179,180,45,181,182,183,43,42,41,184],"unikit todo","todo","remind","show","todo list","only","now","you","done","tasks","work","me","reminders","later","act",{"skillNo":186,"name":187,"nameZh":6,"description":188,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":189,"categories":190,"keywords":192,"publishedAt":49},"01M71BPEQDVD7DTGFQBQJQ7JKY","unikit-skills-context","Customize how a built-in unikit skill behaves in this specific project by writing workflow overrides into its skill-context file. These are per-skill workflow rules (e.g. \"\u002Funikit-review should also flag TODO comments\", \"\u002Funikit-implement should run tests after each task\"), not coding conventions. Use when the user wants to change, customize, or override how a particular unikit skill works in this project — \"customize the review skill\", \"make \u002Funikit-fix always add logging here\", \"the implement skill should do X differently\", \"add a skill rule for \u002Funikit-commit\". Use \"validate\" to find stale overrides against updated base skills. For a general coding convention (not tied to one skill) use \u002Funikit-rules; to derive rules from past mistakes use \u002Funikit-evolve.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-skills-context\u002FSKILL.md",[191],{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[193,139,130,133,194,195,196,197,198,199,200,201,171,202,203,44,204,43,42,41],"unikit skills context","coding conventions","writing","when","workflow","commit","review","general coding","text","change","how","past",{"skillNo":206,"name":207,"nameZh":6,"description":208,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":209,"categories":210,"keywords":218,"publishedAt":49},"01M71BP7K5KEGJV4ASRKPG1DM8","unikit-rules","Add a short, project-specific rule, convention, or override to .unikit\u002FRULES.md — the quick-capture inbox for this project's rules (common rules always load; topic files in .unikit\u002Frules\u002F load when the work matches), automatically loaded by \u002Funikit-implement (later promotable via \u002Funikit-memory migrate-rules). Works only with a rule typed as a prompt — it does NOT read files, folders, URLs, or PDFs. Cross-checks the knowledge base (RULES_INDEX.md) to avoid duplicating core\u002Fstack entries. Use for one-line conventions and corrections: \"add a rule\", \"remember this\", \"convention\", \"always do X\", \"never use Y\", \"from now on do Z\", or when the user corrects agent behavior and wants it remembered; also \"split the rules into topics\" (optimise), \"clean up the rules\" (prune), \"shorten RULES.md\" (compact), by keyword or in plain words. If the user points to a source (file, folder, URL, PDF, article, book) or wants to research\u002Fdocument framework usage, use \u002Funikit-memory; for architecture decisions use ARCHITECTURE.md.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-rules\u002FSKILL.md",[211,214,217],{"categoryNo":212,"categoryName":213,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000002","文档处理",{"categoryNo":215,"categoryName":216,"taxonomyType":21,"taxonomyTypeDesc":22},"01JBSEEDCAT000000000000021","资料检索与研究",{"categoryNo":19,"categoryName":20,"taxonomyType":21,"taxonomyTypeDesc":22},[219,220,221,222,130,223,224,225,226,227,135,228,201,229,136,183,43,42,41,230],"Rules","unikit rules","quick","PDF","clean","knowledge","files","URL","migrate","batch","knowledge base","prune",{"skillNo":232,"name":233,"nameZh":6,"description":234,"descriptionZh":6,"repositoryFullName":8,"ownerLogin":9,"ownerAvatarUrl":10,"ownerAccountNo":11,"ownerDisplayName":12,"repositoryNo":13,"starsCount":14,"licenseSpdxId":15,"licenseFileUrl":6,"sourceHtmlUrl":235,"categories":236,"keywords":237,"publishedAt":49},"01M71BP02S49HHD4R5X6N12C9Q","unikit-rules-registry","Orchestrate the remote rules registry — the shared registry (often connected as a local folder or git repo) that the project's rules are published to and pulled from. Three modes, picked from the user's wording: create scaffolds a new local rules registry (\"create a local rules registry\", \"init a rules registry\"); update migrates\u002Fpromotes local knowledge-base rules from .unikit\u002Fmemory\u002F into the remote registry with automatic semver bumps (\"migrate local rules to the remote registry\", \"promote my rules to the registry\", \"push local rules\", \"publish local rules\", \"update the rules registry\"); sync pulls registry updates back into memory (\"sync the rules registry\", \"pull registry updates\"). Pass \"--module \u003Cid>\" to scope to one knowledge-base module. This skill ONLY orchestrates the CLI (`unikit-ai rules *`) — it never edits .unikit.json or .unikit\u002Fmemory\u002F sources directly.","https:\u002F\u002Fgithub.com\u002FNintendaDev\u002Funikit-ai\u002Fblob\u002Fmain\u002Fskills\u002Funikit-rules-registry\u002FSKILL.md",[],[238,219,239,240,130,241,224,242,227,46,137,43,42,40,243,244,245,246,247,248],"registry","unikit rules registry","shared","local","remote","ai rules","automatic","semver","knowledge-base","as","three"]