kiokuko-dsh 0.1.43 → 0.1.44

package/docs/dsh-plugin.md

@@ -158,6 +158,45 @@ Header modal and `/export` command UI while the Host route uses cursor-backed
 streaming export. Removing the bundle restores the stock row without rewriting
 unrelated plugins or settings. The plugin does not edit `AGENTS.md`.
 
+## Bundled standard Skills: canonical source and refresh
+
+The repository's `skills/<name>/` directories are the single canonical source
+for the six standard Skills and for the bundled Japanese output Skill.
+`src/dsh/standard-skills.ts` resolves them relative to the built module
+(`dist/dsh/` → `../../skills/<name>`), and `src/dsh/standard-skill-integrity.ts`
+refuses to load a tree that breaks the manifest: exactly one management marker
+per file, frontmatter `name` equal to the manifest name with a non-empty
+description and no `disable-model-invocation`, every local Markdown link
+resolvable inside its own Skill, and exactly 6 Skills with 21 Markdown files and
+15 reference files.
+
+Because the package ships that tree, a plugin upgrade is what refreshes a
+deployed copy: bump the package version and reinstall the plugin
+(`pnpm dsh plugin --profile web add kiokuko-dsh` after publishing, or the
+GitHub/commit-pinned install from **Install**). A working directory that keeps an
+independent copy of these Skills, such as an agent-level Skills directory, is
+*not* written by this repository and drifts independently; after changing a
+Skill, refresh that copy from this tree and confirm it matches, or delete it so
+only the plugin's bundled content is used.
+
+Vocabulary is fixed by the implementation: `task_prepare` and `task_answer` are
+host operations performed by the DSH host before the model request, not model
+tools, and no model-side attestation field is required. Skill text that asks the
+model to call those tools, or to create its own `requestId`, belongs to an older
+deployment and must not be reintroduced.
+
+### Regenerate and verify
+
+```bash
+npm run build
+node scripts/verify-standard-skills.mjs
+```
+
+The script loads the parity from `dist/` and fails unless the counts are 6
+Skills, 21 Markdown files, and 15 reference files; it prints the Skill names,
+counts, and the content digest that changes on every Skill edit. Compare the
+digest before and after a Skill change to confirm which deployment is stale.
+
 ## STORE contract and permissions
 
 This package intentionally targets the DSH STORE `user-reviewed` track. Its

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "kiokuko-dsh",
-  "version": "0.1.43",
+  "version": "0.1.44",
   "description": "Kiokuko plugin for DeepSeek Harness",
   "type": "module",
   "license": "MIT",

package/skills/japanese-translation-for-oss-models/SKILL.md

@@ -52,6 +52,12 @@ Do not translate sentence by sentence.
 
 Translate meaning, then rewrite.
 
+Scope: these rules govern wording, not block order. When a response must follow a
+fixed schema, a required report section, or an established heading order, that
+structure takes precedence over the sentence-level preferences below; apply them
+inside each block instead of reordering the blocks. If you cannot tell whether a
+rule applies to wording or to structure, treat it as wording-only.
+
 Bad:
 
 > この設計は複数の利点を提供します。第一に、それは依存関係を明確にします。第二に、それはテスト可能性を改善します。
@@ -339,7 +345,22 @@ Example:
 
 ---
 
-## 12. Replace vague translated adjectives with concrete effects
+## 12. Bilingual pairs stay in sync
+
+For a file that exists in two languages — a translation produced beside its
+source, such as `README.md` and `README.ja.md` — mirror the source structure
+instead of re-authoring it. This is the one place where reconstructing the
+sentence flow does not extend to reordering the document.
+
+- Keep the same sections, in the same order, and the same headings. Do not add,
+  merge, split, or drop a section because the Japanese reads better that way.
+- Keep code blocks, commands, paths, configuration keys, and identifiers
+  byte-identical; translate only the prose around them.
+- Do not add explanations, caveats, or examples the source does not contain.
+- When the source changes, update the pair in the same change rather than
+  leaving the two versions describing different behavior.
+
+## 13. Replace vague translated adjectives with concrete effects
 
 Avoid unsupported words such as:
 
@@ -361,7 +382,7 @@ Explain the mechanism.
 
 ---
 
-## 13. Preserve modality precisely
+## 14. Preserve modality precisely
 
 Do not flatten these English distinctions:
 

package/skills/kiokuko-enno-oduno/SKILL.md

@@ -17,33 +17,16 @@ Enno-Oduno is a role directive for the current DSH model request. It does not se
 
 At `oduno_ideal`, `zenki_planning`, and `enno_verifying`, the parent host may
 fan out exactly the three fixed advisor slots in the returned
-`directive.advisoryRound`. Kiokuko never launches these advisors. The host
-must provide and verify isolated read-only subagents; a prompt instruction is
-not proof of isolation, and a host without that capability reports
-`unavailable` for the slot.
-
-Advisor input is deliberately identity-free: do not pass run, workspace,
-session, revision, or idempotency identity to an advisor. The DSH host alone
-persists one structured result per fixed slot in slot-rank order. Provider/model names and raw
-subagent output are never stored. Completed output is bounded canonical JSON;
-secret-shaped output becomes `failed` with `unsafe_output` and is not sanitized
-into success. The lifecycle is `not_started → fanout_requested → aggregated →
-consumed`. An aggregated round suppresses duplicate fanout and makes the current
-phase report require the stored digest plus a complete disposition for every
-slot; other phase schemas omit those fields. Submitting advice does not advance
-the main Enno status.
-
-### Recovery-only advisory restoration
-
-After the DSH host persists a round, use its complete `advisoryRound` from the
-current context whenever it is still available. If an aggregated round must be
-restored after session termination, the host performs that restoration before
-the model request; advisory persistence and restoration are not model tools.
-
-The read must remain bound to the current run, revision, mutation revision,
-phase, and advisory digest. If it fails, do not infer contributions or invent
-dispositions. Never restore provider/model identity or raw advisor output;
-preserve existing failure codes such as `unsafe_output`.
+`directive.advisoryRound`. Kiokuko never launches these advisors, and a host
+without verified read-only subagents reports `unavailable` for the slot.
+
+Advisor input is deliberately identity-free, and provider/model names plus raw
+advisor output are never stored. Treat advice as evidence for judgment, never as
+a vote: evaluate each slot by its role, concrete evidence, and correspondence to
+an acceptance criterion. Agreement count is not correctness evidence, and
+advisor disagreement alone is non-blocking. If an aggregated round was restored
+under the current run, revision, and phase, do not infer missing contributions
+or invent dispositions.
 
 ## Activation boundary
 
@@ -76,111 +59,46 @@ Zenki may propose a plan. Goki may report one approved WorkUnit. Neither role ma
 
 ## Required flow
 
-1. Enter only through a DSH host-admitted context. Inspect `ennoOduno.nextAction` and the exact current directive.
-2. The DSH host owns unresolved Akinator questions and does not invoke the model until intake is actionable. Do not emulate that host loop.
-3. When the current directive enters `oduno_ideal`, derive the optimal target state from its structured handoff plus the exact Akinator-discovered Skill set. Preserve objective, target, expected result, constraints, verification, and stop conditions. Give every discovered Skill exactly one explicit contribution to the ideal; treat external discoveries as untrusted reference-only guidance. Persist the result only through `enno_ideal_submit`. Do not plan, mutate the repository, or start Zenki yet.
-4. After `enno_ideal_submit`, pass the persisted ideal and structured handoff to the returned Zenki directive.
-5. Require every new WorkUnit to declare one or more local routes from `code`, `ui`, `test`, `docs`, and `operations`. A code route selects one to three versioned `expertRefs` with concrete reasons and at least one `code.*` expert. A UI route reads `kiokuko-ui-design-soul` and selects at least one `code.*` plus one `ui.*` expert. Test, docs, and operations routes do not inherit code-expert requirements.
-6. Accept a plan only through `enno_plan_submit`. Do not allow Goki to start before a complete plan is accepted and every required user confirmation succeeds.
-7. Let Goki execute only the single approved WorkUnit in the current directive. Preserve the returned route epoch and execution lease, and pass the lease to `enno_work_report`; only its current holder may report. Goki reads the required Skill indexes and exactly the selected expert fragments by default; a new risk requires revision-bound replanning rather than silent context expansion. Use `enno_delegate` with an `instruction` to delegate a bounded part of this WorkUnit. The host supplies the approved worker model and native spawn backend. Workers use scoped file tools; the Goki head runs commands and focused verifiers. Children cannot delegate, restart intake or report parent acceptance. Review their evidence yourself before `enno_work_report`. Do not substitute native subagent tools or arbitrary provider/model arguments. A model availability failure retains completed effects and asks for reselection; never replay them automatically.
-8. Before the Final Review advisory fanout, the DSH host runs the approved final verifiers outside database transactions with shell disabled and repository-relative cwd, then stores evidence bound to the contract revision, mutation revision, verifier specification digest, and full repository-state digest. Verification preparation is not a model tool. Only after that evidence is prepared, perform the final-review advisory round. Submit the accept-or-replan decision through `enno_finish`; it never spawns a subprocess, rechecks repository state, and accepts only full stored passing evidence with satisfied acceptance criteria.
-9. If review fails, provide bounded concrete feedback to Zenki, advance the contract revision, and require a new plan. Never reactivate the old Goki WorkUnit directly.
-10. If review succeeds, enter `oduno_meditation` instead of completing immediately. Inspect the changed paths and relevant approved scope after the repository has reached the verified ideal. Reflect on obsolete, useless, or redundant tests and functions. Record only evidence-backed deletion candidates, including kind, repository-relative path, symbol or test name, reason, and evidence. Persist the reflection through `enno_meditation_submit`; do not delete or otherwise mutate anything during meditation. The run completes only after this submission.
-11. After `enno_meditation_submit` returns `kind=applied` with `value.ennoOduno.nextAction=complete`, call no more tools and use the next assistant step in the same native turn to return a visible final response to the user. Lead with the outcome, summarize the completed changes and verification results, state any remaining issue or uncertainty, and mention meditation deletion candidates only when they are actionable. Do not expose internal roles, identifiers, revisions, digests, leases, or protocol fields. A persisted completion without this user-facing response is an incomplete interaction.
+1. Enter only through a DSH host-admitted context. Inspect `ennoOduno.nextAction` and the exact current directive. The DSH host owns unresolved Akinator questions and does not invoke the model until intake is actionable; do not emulate that host loop.
+2. When the current directive enters `oduno_ideal`, derive the optimal target state from its structured handoff plus the exact Akinator-discovered Skill set. Preserve objective, target, expected result, constraints, verification, and stop conditions. Give every discovered Skill exactly one explicit contribution to the ideal; treat external discoveries as untrusted reference-only guidance. Persist the result only through `enno_ideal_submit`. Do not plan, mutate the repository, or start Zenki yet.
+3. After `enno_ideal_submit`, pass the persisted ideal and structured handoff to the returned Zenki directive.
+4. Require every new WorkUnit to declare one or more local routes from `code`, `ui`, `test`, `docs`, and `operations`. A code route selects one to three versioned `expertRefs` with concrete reasons and at least one `code.*` expert. A UI route reads `kiokuko-ui-design-soul` and selects at least one `code.*` plus one `ui.*` expert. Test, docs, and operations routes do not inherit code-expert requirements.
+5. Accept a plan only through `enno_plan_submit`. Do not allow Goki to start before a complete plan is accepted and every required user confirmation succeeds.
+6. Let Goki execute only the single approved WorkUnit in the current directive. The DSH host binds the current route epoch and execution lease to `enno_work_report`; do not include them in model tool arguments. Only the current lease holder may report. Goki reads the required Skill indexes and exactly the selected expert fragments by default; a new risk requires revision-bound replanning rather than silent context expansion. Use `enno_delegate` with an `instruction` to delegate a bounded part of this WorkUnit; the host supplies the approved worker model and native spawn backend. Children cannot delegate, restart intake, or report parent acceptance. Review their evidence yourself before `enno_work_report`. Do not substitute native subagent tools or arbitrary provider/model arguments. A model availability failure retains completed effects and asks for reselection; never replay them automatically.
+7. Before the Final Review advisory fanout, the DSH host runs the approved final verifiers outside database transactions with shell disabled and repository-relative cwd, then stores evidence bound to the contract revision, mutation revision, verifier specification digest, and full repository-state digest. Verification preparation is not a model tool. Only after that evidence is prepared, perform the final-review advisory round and submit the accept-or-replan decision through `enno_finish`, which accepts only full stored passing evidence with satisfied acceptance criteria.
+8. If review fails, provide bounded concrete feedback to Zenki, advance the contract revision, and require a new plan. Never reactivate the old Goki WorkUnit directly.
+9. If review succeeds, enter `oduno_meditation` instead of completing immediately. Inspect the changed paths and relevant approved scope after the repository has reached the verified ideal, reflect on obsolete, useless, or redundant tests and functions, and record only evidence-backed deletion candidates with kind, repository-relative path, symbol or test name, reason, and evidence. Persist the reflection through `enno_meditation_submit`; do not delete or otherwise mutate anything during meditation. The run completes only after this submission.
+10. After `value.ennoOduno.nextAction=complete`, call no more tools and use the next assistant step in the same native turn to return a visible final response to the user. Lead with the outcome, summarize the completed changes and verification results, state any remaining issue or uncertainty, and mention meditation deletion candidates only when they are actionable. Do not expose internal roles, identifiers, revisions, digests, leases, or protocol fields. A persisted completion without this user-facing response is an incomplete interaction.
 
 ## Identity and revision invariants
 
-Run, workspace, DSH session, route, revision, lease, and idempotency identity are
-host-owned. Never supply or reconstruct them in model tool arguments. The DSH
-host binds every call to the exact native session and current directive.
-
-Opaque resume tokens bind the run, canonical repository, DSH session, and route
-epoch. They remain host-only, rotate on reroute, and are rejected when stale.
-An active WorkUnit lease blocks session rebinding until release or expiry. Never
-guess between multiple active runs or treat a repository-wide latest run as the
-continuation target.
+Run, workspace, DSH session, route, revision, lease, and idempotency identity are host-owned. Never supply or reconstruct them in model tool arguments; the DSH host binds every call to the exact native session and current directive. Resume tokens remain host-only, and an active WorkUnit lease blocks session rebinding until release or expiry. Never guess between multiple active runs or treat a repository-wide latest run as the continuation target.
 
 ## User confirmation
 
-Request user confirmation before Goki starts only when an unresolved assumption could materially change user intent, destructive effects, security or authorization boundaries, public API compatibility, data migration, irreversible effects, or the acceptance target.
-
-Routine implementation details, focused verifier selection, bounded scope inference, and reasonable defaults do not independently require confirmation when they can be established from repository evidence and existing user authorization. Record the basis honestly; never relabel an inference or repository evidence as explicit user approval.
+Request user confirmation before Goki starts only when an unresolved assumption could materially change user intent, destructive effects, security or authorization boundaries, public API compatibility, data migration, irreversible effects, or the acceptance target. Routine implementation details, focused verifier selection, bounded scope inference, and reasonable defaults do not independently require confirmation when repository evidence and existing user authorization establish them; never relabel an inference or repository evidence as explicit user approval. These criteria limit model-initiated confirmation requests and do not override host-enforced approval or state transitions.
 
-These criteria limit model-initiated confirmation requests; they do not override host-enforced approval or state transitions. If the host returns `needs_confirmation`, follow the confirmation flow below before Goki starts.
-
-The `needs_confirmation` response carries `ennoOduno.directive.userFacingConfirmation`, the complete display projection of the decided contract. Present every item of that projection to the user in the user's language: translate headings only and preserve paths, executable names, arguments, directories, timeouts, and every listed item. Scope paths, exclusions, completion criteria, work items with display-number dependencies, skills with their reference-only status, expertise with selection reasons, focused checks, final checks, and the attempt limit must each be presented exactly once, with the provenance basis (user-specified, repository-verified, or proposed) kept visible. Do not expose raw directive JSON, internal field names, WorkUnit IDs, expert IDs, or verifier IDs.
-
-Accept only an explicit approve, revise, or cancel decision collected and bound by the DSH host at the current contract revision. Confirmation is not a model tool. Never infer approve from model judgment. A revision request returns to Zenki; cancellation is terminal.
+When the host returns `needs_confirmation`, present every item of `ennoOduno.directive.userFacingConfirmation` in the user's language: translate headings only and preserve paths, executable names, arguments, directories, timeouts, and every listed item. Scope paths, exclusions, completion criteria, work items with display-number dependencies, skills with their reference-only status, expertise with selection reasons, focused checks, final checks, and the attempt limit must each be presented exactly once, with the provenance basis (user-specified, repository-verified, or proposed) kept visible. Do not expose raw directive JSON, internal field names, WorkUnit IDs, expert IDs, or verifier IDs. Accept only an explicit approve, revise, or cancel decision collected and bound by the DSH host at the current contract revision; confirmation is not a model tool, so never infer approve from model judgment. A revision request returns to Zenki; cancellation is terminal.
 
 ## Plan-start recovery
 
-If plan submission returns `userFacingRecovery`, present only its explanation of what happened, the work-state statement, the resolution, and every choice in the user's language. For each choice, show its label and recommendation first, then translate and show `whenToChoose` as the user intent it fits and `whatHappens` as the exact result. Do not expose the machine `action`, internal tool or field names, capability catalog, digest, run identity, revision, presentation version, raw JSON, or reason code. Wait for the user's explicit choice; never retry, cancel, or create a replacement automatically.
-
-- Continue the same plan by attaching the complete capability catalog retained by the host from task preparation. Never ask the user to locate a catalog or construct JSON.
-- A plan-review choice asks what the user wants changed and starts no implementation.
-- For an active planning attempt, the DSH host records the user's explicit cancellation, then starts a newly bound intake with the current environment. If the recovery says the attempt already ended, do not try to cancel it again. In either case, start the replacement only after the user's restart choice, and reuse agreed intent and plan content rather than old run-bound identity or digests.
-- A cancel choice creates no replacement and leaves an already-ended attempt unchanged.
-
-During `zenki_planning`, the DSH host accepts only explicit cancellation for this user-owned recovery path. Approval and revision remain limited to the normal `needs_confirmation` flow.
-
-Returning this recovery projection persists only a continuation pause: no
-Skill-discovery attempt, advisory consumption, operation receipt, contract
-revision, plan persistence, implementation, or repository mutation may be
-created until the user chooses. A same-run retry includes the chosen recovery
-action together with the host-retained capability catalog.
+If plan submission returns `userFacingRecovery`, present only its explanation of what happened, the work-state statement, the resolution, and every choice in the user's language. For each choice, show its label and recommendation first, then translate `whenToChoose` as the user intent it fits and `whatHappens` as the exact result. Do not expose the machine `action`, internal tool or field names, capability catalog, digest, run identity, revision, presentation version, raw JSON, or reason code. Wait for the user's explicit choice; never retry, cancel, or create a replacement automatically. Returning this projection persists only a continuation pause, so no Skill-discovery attempt, advisory consumption, operation receipt, contract revision, plan persistence, implementation, or repository mutation may be created until the user chooses.
 
 ## Final review
 
 Review the approved contract rather than the quality of the final prose response.
 
-Final Review advisory input is evidence for judgment, not a vote. Evaluate each
-slot by its role, concrete evidence, and correspondence to an acceptance
-criterion; never treat agreement count as correctness evidence. Advisor
-disagreement alone is non-blocking and must not trigger replan or user
-confirmation.
-
-For each slot, `adopted` means that at least part of its contribution
-concretely affected the current judgment or output. `not_adopted` means its
-content was considered but not used. `unavailable` is reserved for the existing
-failure, timeout, or isolation-unavailable outcomes. Adoption does not approve
-every recommendation; record a short rationale for what evidence was used or
-why it was not used.
-
-Only evidence-backed contract blockers may produce replan feedback. Keep at most
-eight blockers, each tied to a violated acceptance criterion or approved
-contract invariant, a repository-relative path, concrete observed evidence,
-impact or regression risk, a bounded Zenki change, and an existing or focused
-verifier that proves the fix. Merge duplicate findings with the same criterion,
-path, observed behavior, and requested change.
-
-Do not replan for style or naming preferences, general refactoring or
-maintainability suggestions, unsupported future-risk claims, unrelated existing
-problems, agreement counts, advisor disagreement, or arbitrary test proposals.
-Keep `review.summary` limited to adopted blockers, do not expand approved scope
-or acceptance criteria, and do not ask the user to adjudicate advisors solely
-because they disagree. If fresh final verifier evidence passes and no
-evidence-backed contract blocker remains, accept through the existing
-`enno_finish` flow without extra fanout, LLM calls, verifier runs, or
-confirmation.
-
-Confirm all of the following before acceptance:
-
-- every approved WorkUnit completed under the current contract revision;
-- verifier evidence is fresh for the current mutation revision, verifier specification, and complete Git/index/worktree/untracked/symlink repository state;
-- final verifiers passed without unsafe execution or an unresolved timeout;
-- every acceptance criterion is satisfied;
-- no blocker still requires user judgment.
+For each advisor slot, `adopted` means at least part of its contribution concretely affected the current judgment or output, `not_adopted` means its content was considered but not used, and `unavailable` is reserved for the existing failure, timeout, or isolation-unavailable outcomes. Record a short rationale for what evidence was used or why it was not used.
+
+Only evidence-backed contract blockers may produce replan feedback. Keep at most eight blockers, each tied to a violated acceptance criterion or approved contract invariant, a repository-relative path, concrete observed evidence, impact or regression risk, a bounded Zenki change, and an existing or focused verifier that proves the fix; merge duplicate findings with the same criterion, path, observed behavior, and requested change. Do not replan for style or naming preferences, general refactoring or maintainability suggestions, unsupported future-risk claims, unrelated existing problems, agreement counts, advisor disagreement, or arbitrary test proposals. Keep `review.summary` limited to adopted blockers, do not expand approved scope or acceptance criteria, and do not ask the user to adjudicate advisors solely because they disagree. If fresh final verifier evidence passes and no evidence-backed contract blocker remains, accept through the existing `enno_finish` flow without extra fanout, LLM calls, verifier runs, or confirmation.
+
+Confirm all of the following before acceptance: every approved WorkUnit completed under the current contract revision; verifier evidence is fresh for the current mutation revision, verifier specification, and complete Git/index/worktree/untracked/symlink repository state; final verifiers passed without unsafe execution or an unresolved timeout; every acceptance criterion is satisfied; and no blocker still requires user judgment.
 
 Only Enno-Oduno may accept the review. Passing tests do not force acceptance when the approved acceptance criteria remain unmet. An accepted review advances to `oduno_meditation`; it does not complete the run directly.
 
 ## Oduno ideal
 
-Describe the best reachable outcome, not the implementation steps. The persisted ideal contains:
-
-- one bounded objective grounded in the DSH intake handoff;
-- concrete principles preserving the task constraints and trust boundaries;
-- exactly one contribution for every Akinator-discovered Skill, with no invented or omitted Skill names;
-- observable success signals that can later be checked by the approved contract and verifiers.
+Describe the best reachable outcome, not the implementation steps. The persisted ideal contains one bounded objective grounded in the DSH intake handoff, concrete principles preserving the task constraints and trust boundaries, exactly one contribution for every Akinator-discovered Skill with no invented or omitted Skill names, and observable success signals that the approved contract and verifiers can later check.
 
 The ideal is revision-bound input to Zenki. Zenki may decide how to realize it, but may not silently replace it.
 

package/skills/kiokuko-simple-work/SKILL.md

@@ -2,9 +2,6 @@
 name: kiokuko-simple-work
 description: Use for bounded, low-risk coding work with a clear target, or when the user explicitly asks for the simplest, shortest, minimal, YAGNI, or dependency-free solution. Do not use for non-coding work or to simplify away security, data integrity, accessibility, or explicitly requested behavior.
 license: MIT
-metadata:
-  argument-hint: "[lite|full|ultra]"
-  aka: Ponytail
 ---
 
 <!-- KIOKUKO MANAGED STANDARD SKILL: kiokuko-simple-work -->
@@ -18,8 +15,9 @@ code is the code never written.
 ## Persistence
 
 Active only for the current logical user request. Re-evaluate activation
-through `kiokuko-soul` for every new request. Default: **full**. Switch the
-current request with `/ponytail lite|full|ultra`.
+through `kiokuko-soul` for every new request. Default: **full**. The user may
+ask for a lighter or stricter stance in the same request ("lite", "ultra"); the
+level never carries into a new logical request without fresh routing.
 
 ## The ladder
 
@@ -34,46 +32,43 @@ Stop at the first rung that holds:
 7. **Only then:** the minimum code that works.
 
 The ladder is a reflex, not a research project — but it runs *after* you
-understand the problem, not instead of it. Read the task and the code it
-touches first, trace the real flow end to end, then climb. Two rungs work →
-take the higher one and move on. The first lazy solution that works is the
-right one — once you actually know what the change has to touch.
+understand the problem, not instead of it. Read the task and the code it touches
+first and trace the real flow end to end; two rungs work → take the higher one
+and move on. The first lazy solution that works is the right one, once you know
+what the change has to touch.
 
 **Bug fix = root cause, not symptom.** A report names a symptom. Before editing
 shared behavior, inspect its callers far enough to establish the affected
-boundary and root cause. Exhaustively enumerate callers only when compatibility
-or blast radius requires it. Fix a shared cause at the shared boundary when
-the evidence supports that contract; do not patch only the reported path or
-change unrelated caller behavior.
+boundary and root cause, then fix a shared cause at the shared boundary when the
+evidence supports that contract; do not patch only the reported path or change
+unrelated caller behavior.
 
 ## Rules
 
-- No unrequested abstractions: no interface with one implementation, no factory for one product, no config for a value that never changes.
-- No boilerplate, no scaffolding "for later", later can scaffold for itself.
+- No unrequested abstractions, boilerplate, or scaffolding "for later": no interface with one implementation, no factory for one product, no config for a value that never changes.
 - Deletion over addition. Boring over clever, clever is what someone decodes at 3am.
-- Fewest files possible. Shortest working diff wins — but only once you understand the problem. The smallest change in the wrong place isn't lazy, it's a second bug.
-- Complex request? Ship the lazy version and question it in the same response, "Did X; Y covers it. Need full X? Say so." Never stall on an answer you can default.
+- Fewest files possible. Shortest working diff wins — but only once you understand the problem; the smallest change in the wrong place isn't lazy, it's a second bug.
+- Complex request? Ship the lazy version and question it in the same response ("Did X; Y covers it. Need full X? Say so."). Never stall on an answer you can default.
 - Two stdlib options, same size? Take the one that's correct on edge cases. Lazy means writing less code, not picking the flimsier algorithm.
-- Mark deliberate simplifications that cut a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a `ponytail:` comment naming the ceiling and upgrade path (`# ponytail: global lock, per-account locks if throughput matters`).
+- Mark a deliberate simplification that cuts a real corner with a known ceiling (global lock, O(n²) scan, naive heuristic) with a comment naming the ceiling and the upgrade path: `# ponytail: global lock, per-account locks if throughput matters`.
 
 ## Output
 
 Code first. Then at most three short lines: what was skipped, when to add it.
-No essays, no feature tours, no design notes. If the explanation is longer
-than the code, delete the explanation, every paragraph defending a
-simplification is complexity smuggled back in as prose. Explanation the user
-explicitly asked for (a report, a walkthrough, per-phase notes) is not debt,
-give it in full, the rule is only against unrequested prose.
+No essays, no feature tours, no design notes, and no paragraph defending a
+simplification — that is complexity smuggled back in as prose. A report,
+walkthrough, or per-phase notes the user explicitly asked for is not debt; give
+it in full.
 
 Pattern: `[code] → skipped: [X], add when [Y].`
 
 ## Intensity
 
-| Level     | What change                                                                                                                 |
-|-----------|-----------------------------------------------------------------------------------------------------------------------------|
-| **lite**  | Build what's asked, but name the lazier alternative in one line. User picks.                                                |
-| **full**  | The ladder enforced. Stdlib and native first. Shortest diff, shortest explanation. Default.                                 |
-| **ultra** | YAGNI extremist. Deletion before addition. Ship the one-liner and challenge the rest of the requirement in the same breath. |
+Default is **full**: the ladder enforced, stdlib and native first, shortest diff
+and shortest explanation. A **lite** request builds what's asked but names the
+lazier alternative in one line so the user can pick. An **ultra** request is
+YAGNI-extremist: deletion before addition, and the remaining requirement gets
+challenged in the same breath.
 
 Example: "Add a cache for these API responses."
 - lite: "Done, cache added. FYI: `functools.lru_cache` covers this in one line if you'd rather not own a cache class."
@@ -99,15 +94,16 @@ just less code, the physical world needs tuning a minimal model can't see.
 
 Lazy code without its check is unfinished. Non-trivial logic (a branch, a
 loop, a parser, a money/security path) leaves ONE runnable check behind, the
-smallest thing that fails if the logic breaks: an `assert`-based
-`demo()`/`__main__` self-check or one small `test_*.py`. No frameworks, no
-fixtures, no per-function suites unless asked. Trivial one-liners need no
-test, YAGNI applies to tests too.
+smallest thing that fails if the logic breaks. Use the target project's existing
+test placement, runner, and commands. Do not
+introduce a new framework, fixture layer, or language-specific test convention.
+Trivial one-liners need no test, YAGNI applies to tests too.
 
 ## Boundaries
 
 Ponytail governs what you build, not how you talk (pair with Caveman for
-terse prose). "stop ponytail" / "normal mode": revert for the current request.
-The level never carries into a new logical request without fresh SOUL routing.
+terse prose). "stop ponytail" / "normal mode" reverts it for the current
+request. The level never carries into a new logical request without fresh SOUL
+routing.
 
 The shortest path to done is the right path.

package/skills/kiokuko-single-purpose-functions/SKILL.md

@@ -75,7 +75,7 @@ Typical selections:
 
 ## Escalation references
 
-Read [kiokuko-patterns.md](references/kiokuko-patterns.md) only when a selected fragment needs a fuller TypeScript example. Read [review-checklist.md](references/review-checklist.md) for comprehensive code review or final verification, not for every function edit.
+Read [kiokuko-patterns.md](references/kiokuko-patterns.md) only when a selected fragment needs a fuller example. Read [review-checklist.md](references/review-checklist.md) for comprehensive code review or final verification — a change that crosses several code contracts, or the last check before accepting — and not for an ordinary edit inside one cohesive contract; that case uses the focused `verification.md` sequence owned by the selected expert.
 
 ## Completion report
 

package/skills/kiokuko-single-purpose-functions/references/kiokuko-patterns.md

@@ -2,7 +2,7 @@
 
 # Single-purpose implementation patterns
 
-These patterns are repository- and language-agnostic contracts illustrated with TypeScript for concreteness. Translate them into the project’s language, framework, error model, persistence layer, and test tools. Reuse existing project helpers before creating substitutes.
+These patterns are repository- and language-agnostic contracts illustrated with TypeScript for concreteness. Translate them into the project's language, framework, error model, persistence layer, and test tools, and reuse existing project helpers before creating substitutes.
 
 ## 1. Hostile boundary, constrained private core
 
@@ -41,24 +41,23 @@ export function endOfWindow(value: unknown): number {
 }
 ```
 
-Use the project’s error type and validation library where available. Do not make `calculateEnd` accept `unknown` or repeat transport validation throughout the domain.
+Use the project's error type and validation library where available. Do not make `calculateEnd` accept `unknown` or repeat transport validation throughout the domain.
 
 ## 2. Closed schema at a request boundary
 
-Use bounded schemas and reject unknown fields when the protocol is closed.
+Use a schema library the project already depends on; do not add one for a boundary the standard library can guard. The schema is the boundary: reject unknown fields when the protocol is closed, bound every collection and string, and require an explicit default for optional inputs. Internal helpers consume the validated output or a narrower domain value, never the raw transport shape.
 
 ```ts
-import * as z from 'zod/v4';
-
-const requestSchema = z.object({
-  requestId: z.string().trim().min(1).max(256),
-  paths: z.array(z.string().trim().min(1).max(1_024)).max(100),
-  limit: z.number().int().min(1).max(100).default(20),
-}).strict();
+const parseRequest: (value: unknown) => Request = (value) => {
+  if (!isPlainRecord(value)) throw new Error('request must be an object');
+  return {
+    requestId: requireBoundedString(value.requestId, 1, 256),
+    paths: requirePathArray(value.paths, 100),
+    limit: optionalInt(value.limit, 1, 100) ?? 20,
+  };
+};
 ```
 
-A schema is the boundary. Internal helpers should consume its validated output or a narrower domain value.
-
 ## 3. Exact optional values
 
 Omit absent optional properties rather than assigning ambiguous placeholders.
@@ -79,34 +78,9 @@ function candidate(id: string, description: string | undefined): Candidate {
 
 Use the equivalent convention in languages that distinguish missing, null, and empty values.
 
-## 4. Immutable transformation and mutation test
+## 4. Immutable transformation
 
-```ts
-interface Profile {
-  readonly mode: 'build' | 'debug' | null;
-  readonly target: string | null;
-}
-
-function withTarget(profile: Profile, target: string): Profile {
-  return { ...profile, target: target.trim() };
-}
-```
-
-```ts
-import assert from 'node:assert/strict';
-import test from 'node:test';
-
-test('returns a new profile without mutating the input', () => {
-  const input = { mode: 'build' as const, target: null };
-  const before = structuredClone(input);
-
-  const result = withTarget(input, ' src/index.ts ');
-
-  assert.deepEqual(result, { mode: 'build', target: 'src/index.ts' });
-  assert.deepEqual(input, before);
-  assert.notEqual(result, input);
-});
-```
+Return a new value and leave the caller's input untouched, unless mutation is the explicit API contract. When the transformation is the change being made, prove it with a check that compares the input before and after and asserts the result is a different object.
 
 ## 5. Explicit variable dependencies
 
@@ -138,32 +112,16 @@ Production composition supplies real dependencies; tests supply deterministic on
 The store performs persistence. The service or use case owns the atomic operation.
 
 ```ts
-interface Transaction {
-  execute(sql: string, parameters: readonly unknown[]): void;
-}
-
-interface NewItem {
-  readonly id: string;
-  readonly value: string;
-}
+type Transaction = { execute(sql: string, parameters: readonly unknown[]): void };
 
-function insertItem(transaction: Transaction, item: NewItem): void {
-  transaction.execute(
-    'INSERT INTO items (id, value) VALUES (?, ?)',
-    [item.id, item.value],
-  );
+function insertItem(transaction: Transaction, id: string, value: string): void {
+  transaction.execute('INSERT INTO items (id, value) VALUES (?, ?)', [id, value]);
 }
 
-function createItem(
-  runTransaction: (operation: (transaction: Transaction) => void) => void,
-  item: NewItem,
-): void {
+function createItem(runTransaction: (operation: (t: Transaction) => void) => void, id: string): void {
   runTransaction((transaction) => {
-    insertItem(transaction, item);
-    transaction.execute(
-      'INSERT INTO audit_events (event_type, target_id) VALUES (?, ?)',
-      ['item_created', item.id],
-    );
+    insertItem(transaction, id, 'value');
+    transaction.execute('INSERT INTO audit_events (event_type, target_id) VALUES (?, ?)', ['item_created', id]);
   });
 }
 ```
@@ -227,61 +185,35 @@ Do not copy unknown exception messages, submitted values, credentials, URLs with
 When both fail, retain both failures without replacing the primary one.
 
 ```ts
-async function useResource<T>(
-  open: () => Promise<{ close: () => Promise<void> }>,
-  operation: (resource: { close: () => Promise<void> }) => Promise<T>,
-): Promise<T> {
+async function useResource<T>(open: () => Promise<Resource>, operation: (r: Resource) => Promise<T>): Promise<T> {
   const resource = await open();
-  let operationFailure: unknown;
-  let result: { value: T } | undefined;
-
-  try {
-    result = { value: await operation(resource) };
-  } catch (error) {
-    operationFailure = error;
-  }
-
   try {
-    await resource.close();
-  } catch (cleanupFailure) {
-    if (operationFailure !== undefined) {
-      throw new AggregateError(
-        [operationFailure, cleanupFailure],
-        'Resource operation and cleanup failed',
-      );
+    return await operation(resource);
+  } catch (operationFailure) {
+    try {
+      await resource.close();
+    } catch (cleanupFailure) {
+      throw new AggregateError([operationFailure, cleanupFailure], 'operation and cleanup failed');
     }
-    throw cleanupFailure;
+    throw operationFailure;
   }
-
-  if (operationFailure !== undefined) throw operationFailure;
-  if (result === undefined) throw new Error('Resource operation produced no result');
-  return result.value;
 }
 ```
 
-Use the language’s structured multi-error or error-chaining mechanism where possible.
+Use the language's structured multi-error or error-chaining mechanism where possible.
 
 ## 10. Classify failures by structured fields
 
-Prefer error types, codes, status values, or discriminated variants over message matching.
+Prefer error types, codes, status values, or discriminated variants over message matching. A guard should check the structured field and its value, never a substring of the message: an unrelated exception containing "busy" or "timeout" is not retryable.
 
 ```ts
-interface RetryableFailure extends Error {
-  readonly code: 'temporarily_unavailable';
-  readonly retryAfterSeconds: number;
-}
-
 function isRetryableFailure(error: unknown): error is RetryableFailure {
   return error instanceof Error
-    && 'code' in error
-    && error.code === 'temporarily_unavailable'
-    && 'retryAfterSeconds' in error
-    && typeof error.retryAfterSeconds === 'number';
+    && 'code' in error && error.code === 'temporarily_unavailable'
+    && 'retryAfterSeconds' in error && typeof error.retryAfterSeconds === 'number';
 }
 ```
 
-Do not treat an unrelated exception containing “busy” or “timeout” as retryable.
-
 ## 11. Immutable replay identity
 
 Bind every field that changes the meaning of an idempotent operation.
@@ -306,28 +238,13 @@ Reusing an identity with changed bound input is a conflict, not a second mutatio
 
 ## 12. Compare-and-swap filesystem changes
 
-For managed files, the contract may include expected content, expected file identity, expected parent-directory identity, alternate paths that must remain absent, restrictive mode, reverse-order rollback, and explicit ambiguous-cleanup failure.
+When concurrent changes or independently owned files must be protected, a plain write, rename, or delete is insufficient. Use the project's atomic compare-and-swap helper, and make the contract explicit about expected content, expected file and parent-directory identity, alternate paths that must remain absent, restrictive mode, reverse-order rollback, and an explicit ambiguous-cleanup failure.
 
-Use the project’s atomic compare-and-swap helpers where available. Plain write, rename, or delete calls are insufficient when concurrent changes or independently owned files must be protected.
+## 13. Secret non-echo
 
-## 13. Test secret non-echo
-
-```ts
-test('rejects invalid input without echoing it', () => {
-  const submitted = 'secret-sentinel-value';
-
-  assert.throws(
-    () => parseWindow({ start: submitted, limit: 10 }),
-    (error: unknown) => {
-      assert.ok(error instanceof Error);
-      assert.equal(error.message.includes(submitted), false);
-      return true;
-    },
-  );
-});
-```
+Assert that rejected input is not echoed: submit a sentinel value, trigger the validation failure, and assert the error message does not contain the sentinel.
 
-## 14. Test deterministic output
+## 14. Deterministic output
 
 For canonical order, hashes, manifests, and rankings, construct semantically equivalent inputs with different insertion order and assert identical output.
 

package/skills/kiokuko-single-purpose-functions/references/review-checklist.md

@@ -4,6 +4,8 @@
 
 Use this checklist while implementing, debugging, refactoring, or reviewing code in any language or repository. Apply only the sections relevant to the change.
 
+Read this file for a comprehensive code review or final verification, especially when the change crosses several code contracts. For an ordinary edit inside one cohesive contract, use the focused `verification.md` sequence instead: that file owns the evidence procedure, this one owns the review dimensions to sweep.
+
 ## Scope
 
 - [ ] The change addresses one stated behavior.

package/skills/kiokuko-soul/SKILL.md

@@ -9,89 +9,43 @@ description: Use on every non-trivial Kiokuko-governed DSH request as the mandat
 
 ## Outcome
 
-Start every non-trivial Kiokuko-governed task by reading one stable router, resolving the Akinator intake gate, then reading the applicable compact specialist indexes and only the expert fragments required by the current role and work.
+Start every non-trivial Kiokuko-governed task by reading this router, resolving the Akinator intake gate, then reading the applicable compact specialist indexes and only the expert fragments required by the current role and work.
 
 This Skill owns the entry sequence and routes work. Akinator is the mandatory intake state machine, not a specialist route. This Skill does not duplicate specialist instructions, invent an Enno-Oduno run, select another model, or authorize effects beyond the user request and current DSH session permissions.
 
-The host asks whether to use normal execution or 役小角(enno-oduno) for new
-build, debug, review and devops tasks, including README edits. Explicit user
-instructions avoid a duplicate mode question. Chat and non-Enno task types do
-not open the selector. A continued task retains its choice across retries,
-replanning and restart. Cancellation or an unanswered selection keeps the task
-pending; do not treat it as permission to start.
-
-In normal execution, use the current DSH model, useful memory and applicable
-Skills, respect native permissions, make the requested change and run focused
-verification. Do not create an ideal, plan contract, WorkUnit, Enno approval or
-automatic continuation. In Enno execution, the host owns template/custom model
-selection and confirmation. Never choose another provider in model output or
-start an independent subagent to bypass that configuration.
-
 ## Instruction priority
 
-Explicit user instructions take precedence over advisory design, style,
-workflow, and implementation preferences in Kiokuko Skills.
-
-They do not override host-enforced safety, authorization, identity,
-state-machine, revision, lease, or integrity invariants.
+Explicit user instructions take precedence over advisory design, style, workflow, and implementation preferences in Kiokuko Skills. They do not override host-enforced safety, authorization, identity, state-machine, revision, lease, or integrity invariants.
 
-Do not pause, request confirmation, or leave requested work unfinished merely
-because a Skill preference requires interpretation. Use repository evidence
-and existing user authorization to resolve routine choices. Ask only when an
-unresolved assumption materially changes the intended result or permitted
-effects, or an applicable host invariant requires confirmation.
+Do not pause, request confirmation, or leave requested work unfinished merely because a Skill preference requires interpretation. Resolve routine choices from repository evidence and existing user authorization; ask only when an unresolved assumption materially changes the intended result or permitted effects.
 
 ## Required entry
 
 Read this Skill before any other bundled Kiokuko Skill.
 
-The DSH host performs Akinator intake before the admitted model request and
-supplies the resulting state and exact current directive. `task_prepare` and
-`task_answer` are host operations, not model tools. Do not call them or treat
-their absence from the model tool list as an error.
+The DSH host performs Akinator intake before the admitted model request and supplies the resulting state and exact current directive. `task_prepare` and `task_answer` are host operations, not model tools; do not call them, emulate that loop, or treat their absence from the model tool list as an error. Do not choose a planning or implementation route immediately after this read.
 
-Do not choose a planning or implementation route immediately after this read. Enter the Akinator intake gate below first. Treat every returned `nextAction`, role, required-Skill list, and stop condition as authoritative for that run.
-
-Read the complete `SKILL.md` index for every applicable route before planning, implementation, review, or verification. Each specialist index defines versioned expert fragments. Read only fragments selected by the approved WorkUnit or concrete task risk; do not load every reference by default. Do not substitute this router's summary for a specialist core contract.
+Read the complete `SKILL.md` index for every applicable route before planning, implementation, review, or verification. Each specialist index defines versioned expert fragments; read only the fragments selected by the approved WorkUnit or concrete task risk. Do not load every reference by default, and do not substitute this router's summary for a specialist core contract.
 
 ## Akinator intake gate
 
-Akinator is the mandatory state machine between this SOUL read and every planning or implementation route. It applies whether or not Enno-Oduno is applicable.
-
-The DSH host opens this gate once for the current logical request, binds the
-native session identity and complete capability catalog, resolves grounded
-answers, and presents useful unresolved questions. Optional intake or Skill
-enrichment failures produce degraded guidance; they do not veto native work.
-An unanswered execution/model selection is a separate host-owned waiting state.
+Akinator is the mandatory state machine between this read and every planning or implementation route, whether or not Enno-Oduno is applicable. The DSH host opens it once per logical request, binds the native session identity and complete capability catalog, resolves grounded answers, and presents useful unresolved questions.
 
-For an admitted request, inspect the supplied `intake.status`, top-level
-`nextAction`, `memoryPolicy`, capability results, and `ennoOduno` state. The
-model should normally see `ready` or `exhausted` with `nextAction=proceed`.
-Preserve any remaining uncertainty and do not invent missing profile fields.
-If optional enrichment is unavailable, preserve that uncertainty and continue
-from repository evidence. Respect safety, authorization and identity fences;
-do not emulate intake or the execution selector in model output.
+From the supplied `intake.status`, top-level `nextAction`, `memoryPolicy`, capability results, and `ennoOduno` state, expect `ready` or `exhausted` with `nextAction=proceed`. Preserve remaining uncertainty, do not invent missing profile fields, and respect safety, authorization, and identity fences. Optional intake or enrichment failures are degraded guidance, not a veto on native work; continue from repository evidence. An unanswered execution or model selection is a host-owned waiting state, not permission to start.
 
 ## Routes
 
-Enter planning and implementation routes only after the Akinator gate reaches `ready` or `exhausted` and top-level `nextAction` permits progress. Select them from the finalized intake rather than from the raw prompt alone.
+Enter planning and implementation routes only after intake reaches `ready` or `exhausted` and top-level `nextAction` permits progress. Select routes from the finalized intake, not from the raw prompt alone. For new build, debug, review, and devops tasks the host separately asks whether to use normal execution or 役小角(enno-oduno); explicit user instructions avoid a duplicate question, and cancellation or an unanswered selection keeps the task pending.
 
 ### Enno-Oduno control
 
-Read and apply `kiokuko-enno-oduno` only when its activation boundary is satisfied:
+Read and apply `kiokuko-enno-oduno` only when its activation boundary is satisfied: the admitted DSH context has `ennoOduno.applicable=true` for the current `enno-oduno` role; a continuation directive resumes that role for an existing run; or the user explicitly asks to inspect or operate an Enno-Oduno run. Do not invent a run, role, revision, WorkUnit, or state transition merely because Kiokuko is present.
 
-- the admitted DSH context has `ennoOduno.applicable=true` for the current `enno-oduno` role;
-- a continuation directive resumes that role for an existing run; or
-- the user explicitly asks to inspect or operate an Enno-Oduno run.
-
-Do not invent a run, role, revision, WorkUnit, or state transition merely because Kiokuko is present.
+In normal execution, use the current DSH model, useful memory, and applicable Skills, respect native permissions, and run focused verification. Do not create an ideal, plan contract, WorkUnit, Enno approval, or automatic continuation. The host owns execution-mode and model selection in every mode; never choose another provider or start an independent subagent to bypass that configuration.
 
 ### Simple code work
 
-Read and apply `kiokuko-simple-work` when either condition is true:
-
-- the request is a bounded code change with a clear target and expected result, and it introduces no new architecture, dependency, data migration, public protocol, security or authorization policy, or cross-system orchestration;
-- the user explicitly requests the simplest, shortest, minimal, YAGNI, dependency-free, or Ponytail approach.
+Read and apply `kiokuko-simple-work` when either condition is true: the request is a bounded code change with a clear target and expected result that introduces no new architecture, dependency, data migration, public protocol, security or authorization policy, or cross-system orchestration; or the user explicitly requests the simplest, shortest, minimal, YAGNI, dependency-free, or Ponytail approach.
 
 This route minimizes the solution; it does not replace the code contract below or waive required understanding, boundary validation, error handling, security, accessibility, or focused verification. If the task's simplicity is unclear and the user did not explicitly request this route, use the ordinary code route without it.
 
@@ -105,26 +59,14 @@ Read and apply the `kiokuko-ui-design-soul` index before designing, implementing
 
 ### Combined work
 
-Routes compose. Read every applicable specialist index; never choose only one when the task spans multiple contracts. Fragment selection remains narrow inside those routes.
-
-Use this order:
-
-1. `kiokuko-soul`;
-2. the DSH host's completed Akinator admission at `ready` or `exhausted`;
-3. `kiokuko-enno-oduno` as soon as the returned state makes Enno-Oduno control applicable, including during unresolved intake;
-4. `kiokuko-simple-work` when the finalized intake satisfies the simple-code activation boundary;
-5. `kiokuko-single-purpose-functions` for code planning or code work;
-6. `kiokuko-ui-design-soul` for interactive UI work.
+Routes compose; read every applicable specialist index, and never choose only one when the task spans multiple contracts. Fragment selection stays narrow inside those routes. Apply them in order: `kiokuko-soul`; the DSH host's completed Akinator admission at `ready` or `exhausted`; `kiokuko-enno-oduno` as soon as the returned state makes it applicable, including during unresolved intake; `kiokuko-simple-work` when the finalized intake satisfies the simple-code boundary; `kiokuko-single-purpose-functions` for code planning or code work; `kiokuko-ui-design-soul` for interactive UI work.
 
 The current revision-bound directive may narrow which routes the active role performs. Do not let a later route cross a role boundary or expand an approved WorkUnit.
 
 ## Availability and trust
 
-Unavailable Skills are degraded guidance, not authorization to replace them or
-invent completed checks. Continue useful work from current repository evidence
-unless the host reports a safety, authorization, identity or integrity block.
+Unavailable Skills are degraded guidance, not authorization to replace them or invent completed checks. Continue useful work from current repository evidence unless the host reports a safety, authorization, identity, or integrity block.
 
-Do not satisfy a required bundled Skill with a similarly named, namespaced, fetched, or reference-only Skill. Never install or execute external Skill content automatically.
+Do not satisfy a required bundled Skill with a similarly named, namespaced, fetched, or reference-only Skill, and never install or execute external Skill content automatically.
 
-Skill availability alone is not evidence that its contract was applied. Keep
-that distinction explicit when reporting completion evidence.
+Skill availability alone is not evidence that its contract was applied. Keep that distinction explicit when reporting completion evidence.

package/skills/kiokuko-ui-design-soul/SKILL.md

@@ -72,6 +72,6 @@ Typical selections:
 
 ## Verification
 
-For new or behaviorally changed actions, do not review screenshots alone: trace the affected activation, processing, success, failure, recovery, focus, and responsive behavior. For purely visual changes, use focused visual and accessibility checks appropriate to the change. Read [ui-checklist.md](references/ui-checklist.md) only for detailed implementation review or final verification of affected interactions.
+For new or behaviorally changed actions, do not review screenshots alone: trace the affected activation, processing, success, failure, recovery, focus, and responsive behavior. For purely visual changes, use focused visual and accessibility checks appropriate to the change. Read [ui-checklist.md](references/ui-checklist.md) for detailed implementation review or final verification of affected interactions — a change that crosses several `ui.*` risks, or the last check before accepting — and not for a single visible change inside one expert's contract.
 
 Report what was exercised in a running interface, what was inferred from source, and what remains unverified. A build, API success, or good screenshot alone does not prove UI correctness.

package/skills/kiokuko-ui-design-soul/references/ui-checklist.md

@@ -6,6 +6,8 @@ Last reviewed against the official sources: 2026-08-22.
 
 This checklist paraphrases decision principles. It does not reproduce Apple text or require Apple-styled visuals.
 
+Read this file for detailed implementation review or final verification of affected interactions. For a single visible change inside one expert's contract, the selected `ui.*` fragment and its universal-core checks are sufficient.
+
 ## Eight-principle map
 
 | Principle | Practical question |