diff --git a/.github/ISSUE_TEMPLATE/bug-report.yml b/.github/ISSUE_TEMPLATE/bug-report.yml
index ade8450..8c32ee2 100644
--- a/.github/ISSUE_TEMPLATE/bug-report.yml
+++ b/.github/ISSUE_TEMPLATE/bug-report.yml
@@ -9,7 +9,7 @@ body:
     id: version
     attributes:
       label: Package version
-      placeholder: "@cynos-ai/engineer 0.28.0"
+      placeholder: "@cynos-ai/engineer x.y.z"
     validations:
       required: true
   - type: input
diff --git a/CHANGELOG.md b/CHANGELOG.md
index f49392d..ef0293c 100644
--- a/CHANGELOG.md
+++ b/CHANGELOG.md
@@ -2,6 +2,13 @@
 
 All notable public changes to Cynos Engineer are documented here.
 
+## 0.28.3
+
+- Refresh the bundled `ui-design` methodology and reference library from upstream v1.3.0 while preserving the Cynos evidence contract.
+- Remove references to demos that are not bundled in the npm package.
+- Correct the Engineer configuration path and clarify `PROJECT.md` limits in both README languages.
+- Use bilingual release-note categories and remove internal planning references from public comments.
+
 ## 0.28.2
 
 - Document Node.js and pi prerequisites.
diff --git a/README-zh-CN.md b/README-zh-CN.md
index d7cb4fe..4923979 100644
--- a/README-zh-CN.md
+++ b/README-zh-CN.md
@@ -113,10 +113,10 @@ Cynos 当前包含 12 个实践：
 用户配置存放在：
 
 ```text
-~/.pi/agent/cynos-config.json
+~/.pi/agent/cynos-engineer.json
 ```
 
-`/cynos-config` 命令可编辑常用设置：语言、onboard 模式、子代理超时、工作感知的 compaction。搜索 API key、视觉模型、浏览器选项由 `@cynos-ai/tools` 提供——请用 `/cynos-tools-config` 编辑。
+`/cynos-config` 命令可编辑常用设置：语言、onboard 模式、子代理超时、`PROJECT.md` 注入限制、工作感知的 compaction。搜索 API key、视觉模型、浏览器选项由 `@cynos-ai/tools` 提供——请用 `/cynos-tools-config` 编辑。
 
 ## 文档与维护
 
diff --git a/README.md b/README.md
index 91a9f41..e2ad5bd 100644
--- a/README.md
+++ b/README.md
@@ -115,10 +115,10 @@ Project state lives in the target project:
 User configuration lives in:
 
 ```text
-~/.pi/agent/cynos-config.json
+~/.pi/agent/cynos-engineer.json
 ```
 
-The `/cynos-config` command edits common settings: language, onboard mode, subagent timeout, and work-aware compaction. Search API keys, vision model, and browser options live in `@cynos-ai/tools` — edit them via `/cynos-tools-config`.
+The `/cynos-config` command edits common settings: language, onboard mode, subagent timeout, `PROJECT.md` injection limits, and work-aware compaction. Search API keys, vision model, and browser options live in `@cynos-ai/tools` — edit them via `/cynos-tools-config`.
 
 ## Documentation and maintenance
 
diff --git a/THIRD_PARTY_NOTICES.md b/THIRD_PARTY_NOTICES.md
index f2dc09f..0bcf239 100644
--- a/THIRD_PARTY_NOTICES.md
+++ b/THIRD_PARTY_NOTICES.md
@@ -7,7 +7,7 @@ are retained alongside bundled content where applicable.
 ## `skills/ui-design/`
 
 - Upstream project: [ConardLi/garden-skills](https://github.com/ConardLi/garden-skills)
-- Upstream content: `web-design-engineer` skill, bundled version v1.2.2
+- Upstream content: `web-design-engineer` skill, bundled version v1.3.0
 - License: MIT
 - Local notice: [`skills/ui-design/LICENSE`](./skills/ui-design/LICENSE)
 - Source record: [`skills/ui-design/SOURCE.md`](./skills/ui-design/SOURCE.md)
diff --git a/extensions/core/types.ts b/extensions/core/types.ts
index 52e79cf..d7ce3e2 100644
--- a/extensions/core/types.ts
+++ b/extensions/core/types.ts
@@ -133,9 +133,8 @@ export interface Checkpoint {
 //
 // Runs mid-work (injected via the prompt hook, computed from
 // capturedToolResults). It never decides completion and never archives a
-// work. Pilot period: concerns and checkpoints are two parallel sets kept
-// consistent by hand; a later `condition` unification is planned (see
-// docs/v2/cross-project-constraint-architecture-research-2026-07.md §3.3).
+// work. Concerns and checkpoints are deliberately separate: concerns coach
+// the next action, while checkpoints make the final completion decision.
 // ============================================================
 
 export type ConcernStatus = "active" | "drift" | "satisfied";
diff --git a/extensions/infra/paths.ts b/extensions/infra/paths.ts
index 4d5eb77..a953cc1 100644
--- a/extensions/infra/paths.ts
+++ b/extensions/infra/paths.ts
@@ -5,7 +5,7 @@ import * as path from "node:path";
 // ============================================================
 // Centralized path management
 //
-// Project-level .cynos/ state files + user-level ~/.pi/agent/cynos-config.json config
+// Project-level .cynos/ state files + user-level ~/.pi/agent/cynos-engineer.json config
 // are all exported from here. Other modules always go through these functions.
 // ============================================================
 
diff --git a/extensions/infra/project-context.ts b/extensions/infra/project-context.ts
index b02beea..1b80457 100644
--- a/extensions/infra/project-context.ts
+++ b/extensions/infra/project-context.ts
@@ -11,7 +11,7 @@ export interface ProjectContext {
 }
 
 // best-effort read of PROJECT.md.
-// Missing file, permission errors, or encoding issues do not block start — only return a warning (§25).
+// Missing file, permission errors, or encoding issues do not block start; return a warning instead.
 // Truncation is per-line (default 600 lines), overridable via config.projectMdMaxLines.
 export async function readProjectMd(cwd: string): Promise<ProjectContext> {
   const filePath = projectMdPath(cwd);
diff --git a/extensions/infra/tools-config-reader.ts b/extensions/infra/tools-config-reader.ts
index cab5661..bdeade8 100644
--- a/extensions/infra/tools-config-reader.ts
+++ b/extensions/infra/tools-config-reader.ts
@@ -9,10 +9,11 @@ import { cynosToolsConfigPath, legacyCynosConfigPath } from "./paths";
 //
 // Fallback chain:
 //   1. ~/.pi/agent/cynos-tools.json -> visionModel
-//   2. ~/.pi/agent/cynos-config.json -> visionModel   (legacy, kept for one or two versions)
+//   2. ~/.pi/agent/cynos-config.json -> visionModel   (legacy fallback)
 //
-// This keeps looker working for users who have not re-run /cynos-tools-config since
-// the split, without Engineer reaching into Tools internals.
+// The fallback keeps looker working for users upgrading from a pre-split release
+// who have not yet run /cynos-tools-config, without Engineer reaching into Tools
+// internals. Remove it only in a planned breaking change after a deprecation period.
 
 export async function readToolsVisionModel(): Promise<string | undefined> {
   const tools = await readJsonFileOptional<{ visionModel?: unknown }>(cynosToolsConfigPath());
diff --git a/extensions/practices/helpers.ts b/extensions/practices/helpers.ts
index d99bced..8693e77 100644
--- a/extensions/practices/helpers.ts
+++ b/extensions/practices/helpers.ts
@@ -1010,7 +1010,7 @@ export function mentionsOriginalPromptAuthorization(summary: string): boolean {
 // unknown agent -> exitCode:1 + isError. So a successful subagent call's input.agent is
 // guaranteed to be exactly one of the 5 fixed names. No outputSummary fallback is needed or
 // wanted (scanning it caused false positives, e.g. an explorer mentioning 'review' counted as
-// reviewer). See principles §3.8 criterion C (gate trigger on deterministic field, not text scan).
+// reviewer). Use the deterministic agent field rather than scanning result text.
 export function isSubagentResult(result: CapturedToolResult, expectedAgent: "reviewer" | "challenger"): boolean {
   if (result.toolName !== "cynos_subagent" || result.isError) return false;
   const agent = stringAt(result.input.agent);
diff --git a/extensions/subagent/runner.ts b/extensions/subagent/runner.ts
index 85e1f33..c717ce4 100644
--- a/extensions/subagent/runner.ts
+++ b/extensions/subagent/runner.ts
@@ -4,7 +4,7 @@
 // Uses --mode json to capture structured event stream (message_end, tool_result_end),
 // rather than --print plain text, to capture metadata like usage, stopReason.
 //
-// Permission boundary (§34): child processes flag themselves via PE_CHILD=1 env var;
+// Permission boundary: child processes flag themselves via PE_CHILD=1 env var;
 // main-agent-only tools (e.g. cynos_subagent itself, vision guard) are not registered in children.
 
 import { spawn } from "node:child_process";
diff --git a/package-lock.json b/package-lock.json
index a46d629..95fdcd9 100644
--- a/package-lock.json
+++ b/package-lock.json
@@ -1,12 +1,12 @@
 {
   "name": "@cynos-ai/engineer",
-  "version": "0.28.2",
+  "version": "0.28.3",
   "lockfileVersion": 3,
   "requires": true,
   "packages": {
     "": {
       "name": "@cynos-ai/engineer",
-      "version": "0.28.2",
+      "version": "0.28.3",
       "bundleDependencies": [
         "@cynos-ai/tools"
       ],
diff --git a/package.json b/package.json
index 215d111..672e7a9 100644
--- a/package.json
+++ b/package.json
@@ -1,6 +1,6 @@
 {
   "name": "@cynos-ai/engineer",
-  "version": "0.28.2",
+  "version": "0.28.3",
   "description": "Cynos — an autonomous AI engineering runtime with evidence-based completion verification.",
   "keywords": [
     "pi-package",
diff --git a/scripts/generate-changelog.mjs b/scripts/generate-changelog.mjs
index 82aaa76..e148665 100644
--- a/scripts/generate-changelog.mjs
+++ b/scripts/generate-changelog.mjs
@@ -38,42 +38,51 @@ function commitsSince(tag) {
 }
 
 function groupFor(subject) {
-  if (/^(feat|feature)(\(.+\))?:/i.test(subject)) return "新增";
-  if (/^(fix|bugfix)(\(.+\))?:/i.test(subject)) return "修复";
-  if (/^docs(\(.+\))?:/i.test(subject)) return "文档";
-  if (/^test(s)?(\(.+\))?:/i.test(subject)) return "测试";
-  if (/^(build|ci|chore|refactor)(\(.+\))?:/i.test(subject)) return "工程";
-  return "其他";
+  if (/^(feat|feature)(\(.+\))?:/i.test(subject)) return "Added";
+  if (/^(fix|bugfix)(\(.+\))?:/i.test(subject)) return "Fixed";
+  if (/^docs(\(.+\))?:/i.test(subject)) return "Documentation";
+  if (/^test(s)?(\(.+\))?:/i.test(subject)) return "Tests";
+  if (/^(build|ci|chore|refactor)(\(.+\))?:/i.test(subject)) return "Engineering";
+  return "Other";
 }
 
 function cleanSubject(subject) {
   return subject.replace(/^[a-z]+(\(.+\))?:\s*/i, "").trim();
 }
 
-// 发版元数据提交不算用户可见变更，不应进入 changelog：
-// - "docs: update changelog [skip ci]"（旧 CI 自动提交）
-// - "release vX.Y.Z"（新原子发版脚本）
-// - 裸版本号 "0.1.1"（旧 `npm version` 风格）
+// Release metadata commits are not user-visible changes and should not enter
+// the changelog:
+// - "docs: update changelog [skip ci]" (legacy CI commit)
+// - "release vX.Y.Z" or "release: package X.Y.Z" (release scripts)
+// - bare versions such as "0.1.1" (legacy `npm version` style)
 function isReleaseMetadata(subject) {
   return /update changelog/i.test(subject)
-    || /^release\s+v?\d/i.test(subject)
+    || /^release(?:\s+|:\s+)(?:[^\s]+\s+)?v?\d/i.test(subject)
     || /^\d+\.\d+\.\d+$/.test(subject);
 }
 
 function renderReleaseNotes(tag, commits) {
   const lines = [`## v${version} - ${today}`, ""];
-  if (tag) lines.push(`范围：${tag}..HEAD`, "");
-  else lines.push("范围：项目首次发布以来的全部提交。", "");
+  if (tag) lines.push(`Range: ${tag}..HEAD / 范围：${tag}..HEAD`, "");
+  else lines.push("Range: all commits since the first public release / 范围：项目首次公开发布以来的全部提交。", "");
 
   if (commits.length === 0) {
-    lines.push("- 无新的提交。");
+    lines.push("- No new commits. / 无新的提交。");
     return `${lines.join("\n")}\n`;
   }
 
-  for (const group of ["新增", "修复", "文档", "测试", "工程", "其他"]) {
-    const items = commits.filter((commit) => groupFor(commit.subject) === group);
+  const groups = [
+    ["Added", "新增"],
+    ["Fixed", "修复"],
+    ["Documentation", "文档"],
+    ["Tests", "测试"],
+    ["Engineering", "工程"],
+    ["Other", "其他"],
+  ];
+  for (const [english, chinese] of groups) {
+    const items = commits.filter((commit) => groupFor(commit.subject) === english);
     if (items.length === 0) continue;
-    lines.push(`### ${group}`, "");
+    lines.push(`### ${english} / ${chinese}`, "");
     for (const item of items) {
       lines.push(`- ${cleanSubject(item.subject)} (${item.hash}, ${item.author})`);
     }
@@ -106,10 +115,10 @@ if (args.has("--release-notes")) {
   const expected = mergeChangelog(entry);
   const current = readFileSync(resolve(root, "CHANGELOG.md"), "utf8");
   if (current !== expected) {
-    console.error("CHANGELOG.md 不是最新。请运行 npm run changelog。");
+    console.error("CHANGELOG.md is out of date. Run npm run changelog.");
     process.exit(1);
   }
 } else {
   writeFileSync(resolve(root, "CHANGELOG.md"), mergeChangelog(entry), "utf8");
-  process.stdout.write("CHANGELOG.md 已更新。\n");
+  process.stdout.write("CHANGELOG.md updated.\n");
 }
diff --git a/scripts/release.mjs b/scripts/release.mjs
index 0a30455..7a805c5 100644
--- a/scripts/release.mjs
+++ b/scripts/release.mjs
@@ -1,22 +1,15 @@
 #!/usr/bin/env node
 // ============================================================
-// 原子发版脚本
+// Atomic local release helper.
 //
-// 一次调用完成：校验 → 版本 bump → 重生成 CHANGELOG → 单次提交 → 打 tag。
-// 关键不变量：CHANGELOG 与版本号、tag 必须落在同一个 commit 里，
-// tag 指向的提交必须已经包含正确的 CHANGELOG。
+// One invocation verifies the tree, bumps version metadata, regenerates the
+// changelog, creates one release commit, and creates the annotated tag. The tag
+// must point at the commit containing the version and changelog.
 //
-// 这取代了旧的 `npm version` + CI 自动补 changelog 提交的两步流程——
-// 旧流程会让 tag 指向「只有版本号、没有 CHANGELOG」的提交，
-// 且 CI 的自动提交会与本地分叉。
+// Usage:
+//   npm run release -- patch | minor | major | <x.y.z>
 //
-// 用法：
-//   npm run release -- patch     # 0.1.1 → 0.1.2
-//   npm run release -- minor     # 0.1.1 → 0.2.0
-//   npm run release -- major     # 0.1.1 → 1.0.0
-//   npm run release -- 1.2.3     # 显式版本号
-//
-// 完成后手动推送：
+// Push after review with:
 //   git push origin main --follow-tags
 // ============================================================
 import { execFileSync } from "node:child_process";
@@ -28,7 +21,7 @@ const root = resolve(dirname(fileURLToPath(import.meta.url)), "..");
 const kind = process.argv[2];
 
 if (!kind) {
-  console.error("用法: npm run release -- patch | minor | major | <x.y.z>");
+  console.error("Usage: npm run release -- patch | minor | major | <x.y.z>");
   process.exit(1);
 }
 
@@ -53,49 +46,49 @@ function run(args) {
   execFileSync(process.platform === "win32" ? "npm.cmd" : "npm", args, { cwd: root, stdio: "inherit" });
 }
 
-// 1. 工作树必须干净，避免把无关改动混进 release commit。
+// 1. The working tree must be clean so unrelated changes cannot enter the release commit.
 const status = git(["status", "--porcelain"]);
 if (status) {
-  console.error("工作树不干净，请先提交或 stash：\n" + status);
+  console.error("Working tree is not clean. Commit or stash first:\n" + status);
   process.exit(1);
 }
 
-// 2. 发布只从 main 分支发起；先同步远端引用，避免本地基于过期 main 打 tag。
+// 2. Release only from main and refresh remote refs before creating a tag.
 const branch = git(["branch", "--show-current"]);
 if (branch !== "main") {
-  console.error(`当前分支是 ${branch || "detached HEAD"}，请切到 main 后再发版。`);
+  console.error(`Release must start from main; current branch is ${branch || "detached HEAD"}.`);
   process.exit(1);
 }
 console.log("→ git fetch origin main --tags …");
 gitInherit(["fetch", "origin", "main", "--tags"]);
 if (!gitOk(["merge-base", "--is-ancestor", "origin/main", "HEAD"])) {
-  console.error("本地 main 不包含 origin/main 的最新提交。请先 rebase/merge 远端 main，再发版。");
+  console.error("Local main does not contain origin/main. Rebase or merge the remote main before releasing.");
   process.exit(1);
 }
 
-// 3. 读当前版本，计算下一版本。
+// 3. Read the current version and calculate the next version.
 const pkgPath = resolve(root, "package.json");
 const lockPath = resolve(root, "package-lock.json");
 const pkg = JSON.parse(readFileSync(pkgPath, "utf8"));
 const current = pkg.version;
 const next = resolveVersion(current, kind);
 if (!next) {
-  console.error(`无法解析目标版本，输入为: ${kind}（当前 ${current}）`);
+  console.error(`Cannot resolve target version: ${kind} (current ${current}).`);
   process.exit(1);
 }
 if (next === current) {
-  console.error(`目标版本与当前相同: ${current}`);
+  console.error(`Target version is unchanged: ${current}.`);
   process.exit(1);
 }
 const tag = `v${next}`;
 if (gitOk(["rev-parse", "--verify", `refs/tags/${tag}`])) {
-  console.error(`tag 已存在: ${tag}`);
+  console.error(`Tag already exists: ${tag}`);
   process.exit(1);
 }
 
-console.log(`准备发版: ${current} → ${next}`);
+console.log(`Preparing release: ${current} → ${next}`);
 
-// 4. 先跑完整校验，失败则中止（不产生任何改动）。
+// 4. Run the full verification before making any file changes.
 console.log("→ npm run verify …");
 run(["run", "verify"]);
 
@@ -104,18 +97,18 @@ pkg.version = next;
 writeFileSync(pkgPath, JSON.stringify(pkg, null, 2) + "\n", "utf8");
 bumpLockfile(lockPath, next);
 
-// 6. 重生成 CHANGELOG（此时新 tag 尚未创建，脚本以上一个可达 tag 为分界，
-//    生成新版本段）。必须在提交前完成，让 CHANGELOG 进入同一个 commit。
+// 6. Regenerate CHANGELOG before creating the tag so the new section is part
+//    of the same commit.
 console.log("→ npm run changelog …");
 run(["run", "changelog"]);
 
-// 7. 单次提交 + 打 tag。
+// 7. Create one release commit and tag it.
 git(["add", "package.json", "package-lock.json", "CHANGELOG.md"]);
 git(["commit", "-m", `release ${tag}`]);
 git(["tag", "-a", tag, "-m", tag]);
 
-console.log(`\n✓ 已发版 ${tag}（commit 含版本号 + CHANGELOG + tag）`);
-console.log("推送：");
+console.log(`\n✓ Released ${tag} (version, CHANGELOG, and tag share one commit).`);
+console.log("Push:");
 console.log("  git push origin main --follow-tags");
 
 function resolveVersion(currentSemver, input) {
@@ -133,7 +126,7 @@ function resolveVersion(currentSemver, input) {
 function bumpLockfile(path, version) {
   const lock = JSON.parse(readFileSync(path, "utf8"));
   lock.version = version;
-  // lockfile v3：根 packages[""] 也记录版本。
+  // Lockfile v3 also records the version in the root packages[""] entry.
   if (lock.packages && lock.packages[""]) lock.packages[""].version = version;
   writeFileSync(path, JSON.stringify(lock, null, 2) + "\n", "utf8");
 }
diff --git a/skills/cynos/SKILL.md b/skills/cynos/SKILL.md
index 014a74a..03c898a 100644
--- a/skills/cynos/SKILL.md
+++ b/skills/cynos/SKILL.md
@@ -51,7 +51,7 @@ Select the most specific applicable practice. Do not use `default` just because
 
 Review boundary examples: “review/find problems/assess correctness/security/maintainability of this existing code/design/PR/diff” means `review`, even when the report is only in chat. Test boundary examples: “run smoke and tell me the result” means `test`; “run smoke and write docs/smoke-report.md” means `docs`; “found a bug, fix it” means `debug`/`develop` after the test verdict. Refactor boundary examples: “give me a refactor plan, do not change code” means no practice for chat-only advice, or docs for a persisted plan. Frontend routing examples: “input is too short / long email is hard to see / button is too small / mobile layout overflows” means `usability`; “button click does nothing / valid email cannot save / page throws an error” means `debug`; “add a clear-email button / add a new visible control or action / support a new validation rule / change API or data flow” means `develop` even when framed as usability; “redesign the page style / brand colors / design system” means `ui-design`. “Explain what this code does”, “summarize this file”, “teach me this concept”, or future-oriented advice with no audited judgment means no practice.
 
-**Project-external config ≠ practice.** Editing files outside the current project — `~/.pi/...`, `~/.config/...`, `~/.gitconfig`, `~/.npmrc`, switching the default model, deleting an old provider/extension, managing the agent’s own settings — do these directly without `cynos_start_work`. If you wrap such a tweak in a practice anyway it may still complete, but you are adding unnecessary ceremony — prefer doing it directly. To change Cynos preferences (including `onboardMode`), use the `/cynos-config` menu — practices never write `~/.pi/agent/cynos-config.json`.
+**Project-external config ≠ practice.** Editing files outside the current project — `~/.pi/...`, `~/.config/...`, `~/.gitconfig`, `~/.npmrc`, switching the default model, deleting an old provider/extension, managing the agent’s own settings — do these directly without `cynos_start_work`. If you wrap such a tweak in a practice anyway it may still complete, but you are adding unnecessary ceremony — prefer doing it directly. To change Cynos preferences (including `onboardMode`), use the `/cynos-config` menu — practices never write `~/.pi/agent/cynos-engineer.json`.
 
 If the user only asks a generic question, chat-only advice, or follows up on a completed work without new exploration, audited judgment, file output, or modification, answer normally without starting project practice.
 
diff --git a/skills/onboard/SKILL.md b/skills/onboard/SKILL.md
index 55aabd7..edfdfeb 100644
--- a/skills/onboard/SKILL.md
+++ b/skills/onboard/SKILL.md
@@ -7,13 +7,13 @@ description: "Use when onboarding an unfamiliar existing project or refreshing i
 
 Goal: build or refresh the project's **maintenance baseline** — accurate, high-signal understanding plus the conventions future agents need to work correctly in this project. Onboard is the agent understanding the project and固化 the result; it is not primarily a human-facing tutorial.
 
-Follow the configured onboard mode from `~/.pi/agent/cynos-config.json` (set via `/cynos-config`):
+Follow the configured onboard mode from `~/.pi/agent/cynos-engineer.json` (set via `/cynos-config`):
 
 - Read config first when possible. Missing/invalid `onboardMode` defaults to `human-assisted`.
 - Start the auditable work with `cynos_start_work(practice="onboard")` before asking scope questions.
 - `human-assisted` (default): ask only for facts code cannot determine, but always use real `cynos_ask_user`/`cynos_resume_work` for scope confirmation before deep reading and for final baseline approval before writing.
 - `auto`: do not wait for user confirmation; make conservative decisions from code/CI/docs evidence and record `automationDecision` plus unresolved questions.
-- Do **not** write `~/.pi/agent/cynos-config.json` during onboard. Mode is a user preference owned by the config layer; users change it via `/cynos-config`, not via the practice.
+- Do **not** write `~/.pi/agent/cynos-engineer.json` during onboard. Mode is a user preference owned by the config layer; users change it via `/cynos-config`, not via the practice.
 
 ## How onboard work is organized: shared preamble + four dimensions
 
diff --git a/skills/ui-design/LICENSE b/skills/ui-design/LICENSE
index 99cc1fb..4c8f88f 100644
--- a/skills/ui-design/LICENSE
+++ b/skills/ui-design/LICENSE
@@ -4,7 +4,7 @@ Copyright (c) 2026 ConardLi (https://github.com/ConardLi)
 
 This license applies to the bundled content in this directory, which originates
 from the web-design-engineer skill in the ConardLi/garden-skills repository
-(https://github.com/ConardLi/garden-skills), bundled at upstream version v1.2.2.
+(https://github.com/ConardLi/garden-skills), bundled at upstream version v1.3.0.
 
 Permission is hereby granted, free of charge, to any person obtaining a copy
 of this software and associated documentation files (the "Software"), to deal
diff --git a/skills/ui-design/README.md b/skills/ui-design/README.md
index dcf32f3..342c9a3 100644
--- a/skills/ui-design/README.md
+++ b/skills/ui-design/README.md
@@ -2,7 +2,7 @@
 
 **An AI agent skill that transforms AI-generated web pages from "functional" to "stunning."**
 
-[简体中文](./README.zh-CN.md) · [Back to collection root](../../README.md)
+[中文文档](./README.zh-CN.md) · [Back to collection root](../../README.md)
 
 ![Web Design Skill](https://cdn.jsdelivr.net/gh/ConardLi/assets@main/imgs/web-design-skill.webp)
 
@@ -27,7 +27,11 @@ This skill injects **design taste** into the AI's decision-making process throug
 - **oklch color theory** — perceptually uniform color derivation instead of random hex guessing
 - **Curated font & color pairings** — high-quality starting points that replace the default Inter + #3b82f6
 - **Placeholder philosophy** — honest `[icon]` markers instead of poorly drawn SVG fakes
-- **Structured workflow** — six-step process from requirements → context → design system → v0 draft → full build → verification
+- **Five-dial Design Read** — turns audience, artifact, brand, and constraints into visible variance / motion / density / asset / fidelity decisions
+- **Preservation-aware redesigns** — separates extension, preserve, and overhaul modes before touching an existing product
+- **Contextual failure patterns** — detects recurring layout, content, imagery, motion, and dashboard failures without turning taste into universal bans
+- **Structured workflow** — requirements → context → calibrated design system → v0 draft → full build → verification
+- **Opt-in browser acceptance** — executable responsive / interaction / runtime QA only when the user explicitly requests acceptance or browser testing
 
 ---
 
@@ -39,19 +43,22 @@ Copy this skill folder into your project:
 
 ```
 your-project/
-├── .agents/skills/web-design-engineer/   # or .claude/skills/web-design-engineer/
+├── .agents/skills/ui-design/             # or .claude/skills/ui-design/
 │   ├── SKILL.md                          # Main skill file
 │   └── references/
-│       ├── advanced-patterns.md          # Code template library (slide engine, device frames, motion timelines, data viz)
-│       ├── design-directions.md          # Design Direction Advisor (6 schools, differentiated 3-pick recommendation)
-│       ├── style-recipes/                # 25 anchored style recipes — one .md file per anchor, loaded on demand
-│       │   ├── INDEX.md                   #   Catalog index + 3 cross-indexes + cross-cutting anti-patterns
-│       │   ├── linear.md / aesop.md / pentagram.md / ...    #   25 single-recipe files
-│       └── critique-guide.md             # 5-dimension scoring rubric + common issues catalog
+│       ├── design-calibration.md         # Design Read and five-dial calibration
+│       ├── redesign-protocol.md           # Extension / Preserve / Overhaul contracts
+│       ├── failure-patterns.md            # Contextual AI-design failure patterns
+│       ├── browser-acceptance.md          # Explicit-request browser acceptance harness
+│       ├── block-library.md               # Reusable UI block index
+│       ├── advanced-patterns.md           # Code templates and reusable UI patterns
+│       ├── design-directions.md           # Design Direction Advisor
+│       ├── style-recipes/                 # 25 anchored style recipes, loaded on demand
+│       └── critique-guide.md              # 5-dimension scoring rubric and issue catalog
 └── ...
 ```
 
-Or use the Claude Code plugin marketplace from the collection root — see the [top-level README](../../README.md#install).
+When installed through Cynos Engineer, pi automatically loads this skill for the `ui-design` practice. See the [Cynos Engineer quick start](../../README.md#quick-start).
 
 The agent will automatically pick up the skill when your request involves visual/interactive front-end work.
 
@@ -70,15 +77,16 @@ The agent will automatically pick up the skill when your request involves visual
 
 ## How It Works
 
-### The Six-Step Workflow
+### The Calibrated Workflow
 
 ```
 1. Understand requirements  →  Ask only when information is insufficient
-2. Gather design context    →  Code > screenshots; never start from nothing
-3. Declare design system    →  Colors, fonts, spacing, motion — in Markdown, before code
-4. Show v0 draft early      →  Placeholders + layout + tokens; let the user course-correct
-5. Full build               →  Components, states, motion; pause at key decision points
-6. Verify                   →  Pre-delivery checklist; no console errors, no rogue hues
+2. Gather design context    →  Code > screenshots; classify existing-work mode
+3. Produce a Design Read    →  Five dials connect the brief to visible decisions
+4. Declare design system    →  Colors, fonts, spacing, motion — in Markdown, before code
+5. Show v0 draft early      →  Placeholders + layout + tokens; let the user course-correct
+6. Full build               →  Components, states, motion; pause at key decision points
+7. Verify                   →  Lightweight self-check; browser harness only on explicit request
 ```
 
 ### Key Design Principles
@@ -119,9 +127,7 @@ The agent will automatically pick up the skill when your request involves visual
 
 ## Style Recipe Gallery
 
-The skill ships **25 named recipes**, each tied to a real brand, studio, or designer. Every recipe has a working, full-page artefact in the demo gallery — not a shared template, not a thumbnail mood-board, but the form each recipe was actually designed for: an apothecary product page for Aesop, a trading workstation for Bloomberg Terminal, a Saul-Bass poster for Mid-Century, a Y2K portal for Retrofuturism. Browse by school below, pick the one whose vibe matches your brief, or read the spec file at `references/style-recipes/<recipe>.md`. Click any preview to open the full-resolution 2:1 frame.
-
-> Frames are real artefacts rendered by the live React + Vite gallery at [`demo/web-design-engineer-demo`](../../demo/web-design-engineer-demo/) — same fonts, same palettes, same signature moves as the recipe spec. Each demo is in `src/recipes/<id>.tsx`.
+The skill ships **25 named recipes**, each tied to a real brand, studio, or designer. Read the matching specification at `references/style-recipes/<recipe>.md` when an anchor is named; the package does not bundle the upstream demo gallery.
 
 ### Editorial / Minimalist · 5 recipes
 
@@ -392,50 +398,6 @@ The skill ships **25 named recipes**, each tied to a real brand, studio, or desi
 </tr>
 </table>
 
-### Run the gallery yourself
-
-```bash
-cd demo/web-design-engineer-demo
-npm install && npm run dev    # http://localhost:5181/
-```
-
-Hash-routed URLs (`#/linear`, `#/aesop`, …) deep-link to any recipe. Press `H` to toggle the recipe HUD, `Esc` to return to the gallery. See the demo's own [README](../../demo/web-design-engineer-demo/README.md) for layout details.
-
----
-
-## Before & after: skill on / off
-
-The repository's [`demo/web-design-demo/`](../../demo/web-design-demo) directory contains side-by-side comparisons of pages generated with and without this skill, using identical prompts. Open [`demo/web-design-demo/demo2/index.html`](../../demo/web-design-demo/demo2/index.html) for a side-by-side viewer.
-
-### Demo 1: Space Exploration Museum
-
-**Prompt:** *"Build a homepage for a fictional 'Space Exploration Museum' — full-screen hero, 4 exhibition sections, a timeline with 6+ milestones, a booking CTA, and a footer. Deep, immersive, cosmic feel."*
-
-| | Without Skill | With Skill |
-|---|---|---|
-| **File** | `demo/web-design-demo/demo2/demo1.html` | `demo/web-design-demo/demo2/demo1-with-skill.html` |
-| **Color system** | Hardcoded hex values (#7cf0ff, #b388ff) | oklch-based token system with CSS custom properties |
-| **Typography** | Orbitron + Noto Serif SC | Instrument Serif + Space Grotesk + JetBrains Mono |
-| **Layout** | Standard landing-page structure | Editorial magazine-style layout with grid compositions |
-| **Details** | Heavy glow effects, neon gradients | Restrained palette, typographic hierarchy, decorative data elements |
-| **Overall feel** | Enthusiastic junior designer | Experienced design director |
-
-### Demo 2: Photographer Portfolio
-
-**Prompt:** *"Build a homepage for an independent photographer's portfolio."*
-
-| | With Skill |
-|---|---|
-| **File** | `demo/web-design-demo/demo2/demo2-with-skill.html` |
-| **Character** | Creates a fictional Nordic photographer "Mira Høst" with a complete visual identity |
-| **Color** | Paper-warm light (#f2efe8) + ink-dark (#161513) — extremely restrained two-tone palette |
-| **Typography** | Instrument Serif (display) + Space Grotesk (UI) with extensive italic usage |
-| **Layout** | Magazine-editorial structure with numbered sections, asymmetric grids, side rails |
-| **Motion** | Slow Ken Burns on hero image (24s cycle), film-grain texture overlay |
-| **Navigation** | `mix-blend-mode: difference` masthead — seamless across light/dark sections |
-
-> The original Claude Design system prompt that inspired this skill is preserved in the upstream [ConardLi/garden-skills](https://github.com/ConardLi/garden-skills) repo at [`dist/prompts/claude-design-system-prompt.md`](https://github.com/ConardLi/garden-skills/blob/main/dist/prompts/claude-design-system-prompt.md).
-
 ---
 
 ## Background
diff --git a/skills/ui-design/README.zh-CN.md b/skills/ui-design/README.zh-CN.md
index 341eeff..4f7d90f 100644
--- a/skills/ui-design/README.zh-CN.md
+++ b/skills/ui-design/README.zh-CN.md
@@ -2,7 +2,7 @@
 
 **一个让 AI 生成网页从"能用"进阶到"惊艳"的 Agent 技能。**
 
-[English](./README.md) · [返回集合首页](../../README.zh-CN.md)
+[English](./README.md) · [返回 Engineer 根目录](../../README-zh-CN.md)
 
 ![Web Design Skill](https://cdn.jsdelivr.net/gh/ConardLi/assets@main/imgs/web-design-skill.webp)
 
@@ -27,7 +27,11 @@
 - **oklch 色彩理论** —— 基于感知均匀色彩空间的配色派生，取代随机 hex 值
 - **精选字体 × 配色组合** —— 高品质起点，替代默认的 Inter + #3b82f6
 - **占位符哲学** —— 用诚实的 `[icon]` 标记代替拙劣的 SVG 假图
-- **结构化工作流** —— 从需求理解 → 上下文获取 → 设计系统宣告 → v0 草稿 → 完整构建 → 验证的六步流程
+- **五旋钮 Design Read** —— 把受众、产物、品牌和约束转成可见的构图变化 / 动效 / 密度 / 素材 / 品牌保真决策
+- **保留契约的改版协议** —— 动手前区分 Extension、Preserve 与 Overhaul
+- **上下文化失败模式** —— 识别布局、内容、素材、动效与 Dashboard 的常见 AI 问题，同时保留合理例外
+- **结构化工作流** —— 需求 → 上下文 → 校准后的设计系统 → v0 草稿 → 完整构建 → 验证
+- **按需浏览器验收** —— 只有用户明确提出验收或浏览器测试时，才运行响应式 / 交互 / 运行时 QA harness
 
 ---
 
@@ -39,19 +43,22 @@
 
 ```
 your-project/
-├── .agents/skills/web-design-engineer/   # 或 .claude/skills/web-design-engineer/
+├── .agents/skills/ui-design/             # 或 .claude/skills/ui-design/
 │   ├── SKILL.md                          # 主技能文件
 │   └── references/
-│       ├── advanced-patterns.md          # 代码模板库（slide engine / 设备框架 / 动效时间线 / 数据可视化）
-│       ├── design-directions.md          # 设计方向顾问（6 学派，差异化 3 选 1 推荐）
-│       ├── style-recipes/                # 25 套有 anchor 的风格配方（按需读单文件，每个 anchor 一个 .md）
-│       │   ├── INDEX.md                   #   目录索引 + 3 张索引表 + 跨配方反模式
-│       │   ├── linear.md / aesop.md / pentagram.md / ...    #   25 个独立 recipe 文件
-│       └── critique-guide.md             # 5 维评分细则 + 常见问题清单
+│       ├── design-calibration.md         # Design Read 与五个旋钮校准
+│       ├── redesign-protocol.md           # Extension / Preserve / Overhaul 契约
+│       ├── failure-patterns.md            # 上下文化的 AI 设计失败模式
+│       ├── browser-acceptance.md          # 仅在明确要求时使用的浏览器验收 harness
+│       ├── block-library.md               # 可复用 UI Block 索引
+│       ├── advanced-patterns.md           # 代码模板库与可复用 UI 模式
+│       ├── design-directions.md           # 设计方向顾问
+│       ├── style-recipes/                 # 25 套按需加载的 anchor 风格配方
+│       └── critique-guide.md              # 5 维评分细则与问题目录
 └── ...
 ```
 
-也可以从集合首页通过 Claude Code 插件市场一键安装 —— 参见[根目录 README](../../README.zh-CN.md#%E5%AE%89%E8%A3%85)。
+通过 Cynos Engineer 安装后，pi 会在 `ui-design` 实践中自动加载此技能。参见 [Cynos Engineer 快速开始](../../README-zh-CN.md#快速开始)。
 
 当你的请求涉及可视化/交互式前端工作时，Agent 会自动启用此技能。
 
@@ -70,15 +77,16 @@ your-project/
 
 ## 工作原理
 
-### 六步工作流
+### 校准式工作流
 
 ```
 1. 理解需求          →  信息充足就干活，信息不足才提问
-2. 获取设计上下文    →  代码 > 截图；不要从空气中开始
-3. 宣告设计系统      →  配色、字体、间距、动效 —— 用 Markdown 说明，写代码之前
-4. 尽早展示 v0       →  占位符 + 布局 + token；让用户提前纠偏
-5. 完整构建          →  组件、状态、动效；在关键决策点暂停确认
-6. 验证              →  交付前清单；无控制台错误，无私自新增色相
+2. 获取设计上下文    →  代码 > 截图；现有项目先判断改动模式
+3. 产出 Design Read  →  五个旋钮把 brief 映射为可见决策
+4. 宣告设计系统      →  配色、字体、间距、动效 —— 用 Markdown 说明，写代码之前
+5. 尽早展示 v0       →  占位符 + 布局 + token；让用户提前纠偏
+6. 完整构建          →  组件、状态、动效；在关键决策点暂停确认
+7. 验证              →  默认轻量自检；仅在用户明确要求时运行浏览器 harness
 ```
 
 ### 核心设计原则
@@ -119,9 +127,7 @@ your-project/
 
 ## 风格配方画廊
 
-Skill 自带 **25 套有名字的配方**，每套都对应到真实的品牌、工作室或设计师。目录中的每个配方都在 demo 画廊里有一个完整的整页作品 —— 不是共用模板、不是缩略图情绪板，而是每套配方本来就该长成的那种东西：Aesop 是药剂师产品页、Bloomberg Terminal 是交易工作站、Mid-Century 是 Saul Bass 海报、Y2K 是世纪之交的门户网站。按学派浏览下方卡片，挑一套气质契合你 brief 的配方，或者直接读 `references/style-recipes/<recipe>.md` 的 spec 文件。点击任意预览图打开完整分辨率的 2:1 大图。
-
-> 所有截图都是来自 [`demo/web-design-engineer-demo`](../../demo/web-design-engineer-demo/) 这个 React + Vite 画廊的真实渲染 —— 字体、配色、签名手法都和 spec 文件里一致。每个 demo 位于 `src/recipes/<id>.tsx`。
+Skill 自带 **25 套有名字的配方**，每套都对应到真实的品牌、工作室或设计师。用户点名风格时，读取 `references/style-recipes/<id>.md` 中对应的规格文件；本 npm 包不捆绑上游 demo 画廊。
 
 ### Editorial / 极简 · 5 套
 
@@ -392,51 +398,7 @@ Skill 自带 **25 套有名字的配方**，每套都对应到真实的品牌、
 </tr>
 </table>
 
-### 自己跑画廊
-
-```bash
-cd demo/web-design-engineer-demo
-npm install && npm run dev    # http://localhost:5181/
-```
-
-Hash 路由 URL（`#/linear`、`#/aesop`、…）可深链到任意配方。按 `H` 切换配方 HUD，`Esc` 返回画廊。布局细节见 demo 自己的 [README](../../demo/web-design-engineer-demo/README.md)。
-
----
-
-## 启用前后对比：Skill 开 / 关
-
-仓库的 [`demo/web-design-demo/`](../../demo/web-design-demo) 目录包含使用相同提示词、分别在有 Skill 和无 Skill 条件下生成的页面对比。打开 [`demo/web-design-demo/demo2/index.html`](../../demo/web-design-demo/demo2/index.html) 查看对比展示页。
-
-### Demo 1：太空探索博物馆
 
-**提示词：** *"帮我做一个'太空探索博物馆'的线上展览首页——全屏 Hero、4 个核心展览介绍、一个至少 6 个节点的时间线、参观预约 CTA、页脚。整体风格要沉浸感强、有宇宙的深邃感。"*
-
-| | 无 Skill | 有 Skill |
-|---|---|---|
-| **文件** | `demo/web-design-demo/demo2/demo1.html` | `demo/web-design-demo/demo2/demo1-with-skill.html` |
-| **色彩系统** | 硬编码 hex 值（#7cf0ff, #b388ff） | 基于 oklch 的 token 系统，使用 CSS 自定义属性 |
-| **字体** | Orbitron + Noto Serif SC | Instrument Serif + Space Grotesk + JetBrains Mono |
-| **布局** | 标准落地页结构 | 杂志编辑式布局，grid 组合排版 |
-| **细节** | 大量发光效果、霓虹渐变 | 克制的色彩方案、字体层级、装饰性数据元素 |
-| **整体感受** | 热情的初级设计师 | 有经验的设计总监 |
-
-### Demo 2：摄影师作品集
-
-**提示词：** *"帮我做一个独立摄影师的个人作品集网站首页。"*
-
-| | 有 Skill |
-|---|---|
-| **文件** | `demo/web-design-demo/demo2/demo2-with-skill.html` |
-| **角色塑造** | 虚构了北欧摄影师 "Mira Høst"，设计了一整套视觉身份 |
-| **配色** | 暖纸色浅底（#f2efe8）+ 墨色深文（#161513）—— 极度克制的双色调 |
-| **字体** | Instrument Serif（展示标题）+ Space Grotesk（界面）, 大量使用斜体 |
-| **布局** | 杂志编排式结构，编号分节、不对称网格、侧边竖排文字 |
-| **动效** | Hero 图片的慢速 Ken Burns 动画（24秒周期），胶片噪点纹理叠加 |
-| **导航** | `mix-blend-mode: difference` 顶栏 —— 在深浅背景间无缝过渡 |
-
-> 启发本 Skill 的 Claude Design 原始系统提示词保留在上游 [ConardLi/garden-skills](https://github.com/ConardLi/garden-skills) 仓库的 [`dist/prompts/claude-design-system-prompt.md`](https://github.com/ConardLi/garden-skills/blob/main/dist/prompts/claude-design-system-prompt.md)。
-
----
 
 ## 背景
 
diff --git a/skills/ui-design/SKILL.md b/skills/ui-design/SKILL.md
index f6e8ab3..e50a77e 100644
--- a/skills/ui-design/SKILL.md
+++ b/skills/ui-design/SKILL.md
@@ -28,9 +28,9 @@ When this skill is used by the `ui-design` practice, keep the upstream web-desig
 
 ## Scope
 
-✅ **Applicable**: Visual front-end deliverables (pages / prototypes / slide decks / visualizations / animations / UI mockups / design systems)
+✅ **Applicable**: Visual front-end deliverables and redesigns (pages / dashboards / prototypes / slide decks / visualizations / animations / UI mockups / design systems)
 
-❌ **Not applicable**: Back-end APIs, CLI tools, data-processing scripts, pure logic development with no visual requirements, performance tuning, and other terminal tasks
+❌ **Not applicable**: Back-end APIs, CLI tools, data-processing scripts, pure logic development, source material → long-form HTML article conversion, or narration-beat → recordable web-video presentation. Route the last two to their dedicated skills when available.
 
 ---
 
@@ -40,17 +40,15 @@ When this skill is used by the `ui-design` practice, keep the upstream web-desig
 
 **Highest priority — runs before clarifying questions.**
 
-When the request mentions a specific product, brand, technology, SDK, or event you're not 100% sure about, the **first** action is `WebSearch` to verify existence, release status, latest version, and key specs from authoritative sources. Never assert from training data.
+When the request mentions a specific product, brand, technology, SDK, or event you're not sure about, use `cynos_search` to verify the current facts from authoritative sources before designing around them. Never assert unstable facts from memory.
 
 **Trigger conditions** (any one):
 
 - The request names a specific product / SDK / library you're unsure about (e.g., a new device, a recently announced model)
-- Anything dated 2024 or later (release timeline / version / specs)
+- Any time-sensitive release timeline / version / specification
 - You catch yourself thinking "I think it's…" / "should still be…" / "probably not released yet" / "I don't think that exists"
 - The user asks you to design materials for a specific company or product
 
-**Why this is Step 0**: clarifying questions only work if your understanding of the facts is correct. If the facts are wrong, every later question is crooked. Cost comparison: 10 seconds of search vs. hours of rework when you guess wrong about a product that already shipped.
-
 If search returns nothing or is ambiguous → ask the user. Don't guess. Forbidden phrases without prior search: *"I think X hasn't released yet" / "X is currently version N" / "X probably doesn't exist" / "As I recall, X's specs are…"*
 
 ### Step 1: Understand the Requirements (decide whether to ask based on context)
@@ -112,15 +110,26 @@ When analyzing reference materials, focus on: color system, typography scheme, s
 
 #### When Adding to an Existing UI
 
-This is more common than designing from scratch. **Understand the visual vocabulary first, then act** — think out loud about your observations so the user can validate your reading:
+Classify the task as **Extension**, **Redesign · Preserve**, or **Redesign · Overhaul** before editing. Read `references/redesign-protocol.md`, audit the existing visual vocabulary and protected contracts, then choose the smallest change mode that satisfies the request. New elements in Extension mode should be indistinguishable from the originals.
+
+### Step 2b: Produce a Design Read and Calibrate Five Dials
 
-- **Color & tone**: The actual usage ratio of primary / neutral / accent colors? Does the copy feel engineer-oriented, marketing-oriented, or neutral?
-- **Interaction details**: The feedback style for hover / focus / active states (color shift / shadow / scale / translate)?
-- **Motion language**: Easing function preferences? Duration? Are transitions handled with CSS transition, CSS animation, or JS?
-- **Structural language**: How many elevation levels? Card density — sparse or dense? Border-radius uniform or hierarchical? Common layout patterns (split pane / cards / timeline / table)?
-- **Graphics & iconography**: Icon library in use? Illustration style? Image treatment?
+Before choosing tokens, summarize the brief in one concise block. Infer rather than interrogate when context is sufficient:
 
-Matching the existing visual vocabulary is the prerequisite for seamless integration; newly added elements should be **indistinguishable from the originals**.
+```yaml
+Design Read:
+  artifact: [landing / dashboard / prototype / slides / visualization / ...]
+  audience: [primary audience]
+  visual-language: [specific family, not "modern / clean"]
+  mode: [greenfield / extension / preserve / overhaul]
+  visual-variance: [1-10]
+  motion-intensity: [1-10]
+  information-density: [1-10]
+  asset-dependence: [1-10]
+  brand-fidelity: [1-10]
+```
+
+Use the dials as decision variables, not decorative scores. They must affect layout variation, motion, content per viewport, real-asset effort, and preservation strictness. Read `references/design-calibration.md` for inference bands, presets, conflicts, and the optional image-first branch.
 
 ### Step 3a: Position Four Questions Before Picking a System
 
@@ -139,6 +148,7 @@ The system that follows must serve these answers. Picking aesthetics in a vacuum
 
 ```markdown
 Design Decisions:
+- Design Read: [one-line synthesis + five dials]
 - Anchor / recipe (if any): [e.g., "linear" → `references/style-recipes/linear.md`, or "custom"]
 - Color palette: [primary / secondary / neutral / accent]
 - Typography: [heading font / body font / code font]
@@ -172,11 +182,13 @@ After v0 is approved, write full components, add states, and implement motion. F
 
 ### Step 6: Verification
 
-Walk through the "Pre-delivery Checklist" item by item.
+Always run the lightweight **Pre-delivery Checklist** as a code/design self-check.
+
+Run an executable browser acceptance harness **only when the user explicitly asks for acceptance / 验收, QA, browser testing / 浏览器测试, visual regression, responsive testing / 响应式检查, cross-viewport verification, or equivalent hands-on validation**. Do not infer this request merely from “build,” “finish,” “polish,” or “verify your work.” When triggered, read and follow `references/browser-acceptance.md`; report evidence and repair failures before delivery. When this skill runs through Cynos's `ui-design` practice, the practice contract additionally requires lightweight direct browser evidence after the final UI-like write; the full acceptance harness remains opt-in.
 
 ### Step 7: Critique on Request (or as Self-Check Before Delivery)
 
-When the user asks "review this", "is it good?", "score this", "how does it look?", or you want to do a self-check before declaring done, run a **5-dimension critique**:
+When the user asks "review this", "is it good?", "score this", "好不好看", or you want to do a self-check before declaring done, run a **5-dimension critique**:
 
 | Dimension | What to evaluate |
 |---|---|
@@ -186,31 +198,7 @@ When the user asks "review this", "is it good?", "score this", "how does it look
 | **Functionality** | Does each element earn its place? "If I delete this, does the design get worse?" If no → delete |
 | **Originality** | Avoids clichés while staying coherent? Any "unexpected but right" decisions, or pure template? |
 
-Score each 0–10. Output format:
-
-```markdown
-## Design Critique
-
-**Overall: X.X / 10** [Excellent (8+) / Good (6–7.9) / Needs work (4–5.9) / Failing (<4)]
-
-**By dimension**: Philosophy X / Hierarchy X / Craft X / Functionality X / Originality X
-
-### Keep
-- [Specific things done well, in design language]
-
-### Fix (sorted by severity)
-1. **[Issue name]** — ⚠️ Critical / ⚡ Important / 💡 Polish
-   - Current: [what it looks like now]
-   - Why: [why it's a problem]
-   - Fix: [concrete change with values]
-
-### Quick Wins (top 3 if you only have 5 minutes)
-- [ ] [Highest-impact fix]
-- [ ] [Second]
-- [ ] [Third]
-```
-
-**Critique the design, not the designer.** For per-output-type weighting, common-issue catalog, and detailed scoring rubrics → see `references/critique-guide.md`.
+Score each 0–10; report overall score, dimension scores, Keep, severity-sorted Fixes, and three Quick Wins. **Critique the design, not the designer.** Read `references/critique-guide.md` for the exact format, weighting, issue catalog, and detailed rubrics.
 
 ---
 
@@ -318,6 +306,8 @@ This is why the only legitimate exception to every anti-cliché rule below is **
 | Cyber-neon on `#0D1117` dark | GitHub-dark cosplay; baseline noise in dev-tool clones | The brand actually lives in this aesthetic |
 | Fabricated stats, fake logo walls, dummy testimonials | Damages credibility; users notice when numbers don't match reality | **Never** — use placeholders that say "real data needed" |
 
+These are baseline examples, not the whole taxonomy. When designing a multi-section marketing page, redesign, dashboard, or motion-heavy artifact, read only the matching parts of `references/failure-patterns.md`. Treat each pattern as **default → reason → exceptions → detection → repair**, not as an unconditional aesthetic ban.
+
 ### Emoji Rules
 
 **No emoji by default.** Only use emoji when the target design system/brand itself uses them (e.g., Notion, early Linear, certain consumer brands), and match their density and context precisely.
@@ -428,7 +418,7 @@ Explore "atomic variants" across at least these dimensions — mixing conservati
 3. **Interaction**: motion, feedback, navigation patterns
 4. **Creative**: convention-breaking metaphors, novel UX, strong visual concepts
 
-Strategy: **Start the first few variants safely within the design system; then progressively push boundaries.** Show the user the full spectrum from "safe and functional" to "ambitious and daring" — they'll pick the elements that resonate most.
+Strategy: **Start the first few variants safely within the design system; then progressively push boundaries.** Vary the calibrated dials intentionally rather than producing cosmetic recolors. Show the spectrum from "safe and functional" to "ambitious and daring" so the user can identify which dimensions resonate.
 
 ---
 
@@ -466,12 +456,14 @@ Design guidelines:
 
 ## Pre-delivery Checklist
 
-Complete the following before considering the work delivered (all items must pass):
+Complete this lightweight self-check before delivery. In Cynos's `ui-design` practice, also capture direct browser evidence after the final UI-like write; the full acceptance harness remains opt-in unless the user explicitly requests it:
 
-- [ ] **Step 0 ran** if any specific product/brand was named — facts verified via WebSearch, not assumed
+- [ ] **Step 0 ran** if any specific product/brand was named — facts verified via `cynos_search`, not assumed
+- [ ] **Design Read** exists; five dials influenced real decisions instead of being decorative labels
+- [ ] Existing-work mode was classified correctly; preserve/extension contracts were not changed silently
 - [ ] **If the task is branded**: `brand-spec.md` exists; logo is real (not a colored rectangle); product imagery is real (not a CSS silhouette) for hardware; UI screenshots are real for digital products
-- [ ] Browser console shows **no errors, no warnings** (use `browser-automation` / `npx --yes @playwright/cli console`)
-- [ ] Renders correctly on **target devices/viewports** (use `browser-automation` snapshots/screenshots; responsive web → mobile / tablet / desktop; mobile prototype → target device; slide decks/video with fixed dimensions → scaling container adapts without distortion)
+- [ ] Code inspection finds no obvious missing imports, broken local asset paths, invalid markup, or unhandled primary interactions
+- [ ] Responsive rules exist for the target viewports; fixed-canvas artifacts define a non-distorting scale strategy
 - [ ] **Interactive components** (buttons, links, inputs, cards, etc.) include states as appropriate: hover / focus / active / disabled / loading; empty/error states added where the scenario warrants them
 - [ ] No text overflow or truncation; `text-wrap: pretty` applied
 - [ ] All colors come from the design system declared in Step 3 — **no rogue hues introduced**
@@ -479,8 +471,10 @@ Complete the following before considering the work delivered (all items must pas
 - [ ] In React projects, no `const styles = {...}`; cross-file components exported via `Object.assign(window, {...})`
 - [ ] No AI clichés (purple-pink gradients, emoji abuse, left-border accent cards, Inter/Roboto) — unless the brand spec explicitly uses them
 - [ ] No filler content, no fabricated data
+- [ ] Relevant failure patterns were checked; repeated layouts and decorative UI do not overpower the brief
 - [ ] Semantic naming, clean structure, easy to modify later
 - [ ] Visual quality at Dribbble / Behance showcase level
+- [ ] **Only if executable acceptance was requested**: `references/browser-acceptance.md` was run, evidence was recorded, and discovered failures were repaired or disclosed
 
 ---
 
@@ -501,6 +495,11 @@ Read on demand based on task type — don't preload everything:
 
 | Task | Read |
 |---|---|
+| Infer Design Read + five dials; resolve dial conflicts; decide whether image-first exploration is justified | `references/design-calibration.md` |
+| Extend or redesign an existing project; classify Extension / Preserve / Overhaul; protect routes, IA, analytics, forms, accessibility, and brand | `references/redesign-protocol.md` |
+| Check recurring AI-design failure modes by artifact type; apply contextual detection and repairs | `references/failure-patterns.md` |
+| User explicitly asks for browser acceptance / 验收 / QA / responsive verification / visual regression | `references/browser-acceptance.md` |
+| Reuse a known working component pattern before inventing a new implementation | `references/block-library.md` → targeted section in `references/advanced-patterns.md` |
 | Slide engine, device frames, Tweaks panel, animation timeline, design canvas, dark mode, data viz, oklch color system, font recommendations | `references/advanced-patterns.md` |
 | Vague request → recommend 3 design directions; extended philosophy library + per-direction visual recipes + AI-prompt templates | `references/design-directions.md` |
 | User named an anchor ("Linear-style" / "Aesop feeling") → load **only that one file** | `references/style-recipes/<anchor>.md` (e.g., `linear.md`, `aesop.md`) |
@@ -508,8 +507,6 @@ Read on demand based on task type — don't preload everything:
 | Critique mode — detailed scoring rubrics, per-output-type weighting, common-issue catalog (top 10) | `references/critique-guide.md` |
 
 
----
-
 ## Cynos Integration
 
 This skill is used by the `ui-design` practice. Keep the upstream workflow intact. Cynos does **not** replace the web-design-engineer workflow with a second checklist; it only checks the final engineering evidence.
@@ -593,5 +590,3 @@ If browser startup fails because of missing system dependencies:
 After successful verification, follow the Cynos local commit policy: commit this UI change locally unless the user explicitly opted out. Never push/tag/publish/deploy in ui-design. If `git commit` fails, record `commit.status='failed'` with the real reason; do not bypass hooks or retry blindly.
 
 Finish with `cynos_check_completion({ completionEvidence })`; do not claim the UI work is complete until it passes.
-
-
diff --git a/skills/ui-design/SOURCE.md b/skills/ui-design/SOURCE.md
index 22e4430..a5458ad 100644
--- a/skills/ui-design/SOURCE.md
+++ b/skills/ui-design/SOURCE.md
@@ -2,16 +2,21 @@
 
 The material in this directory originates from the `web-design-engineer` skill
 in [ConardLi/garden-skills](https://github.com/ConardLi/garden-skills), bundled at
-upstream version v1.2.2.
+upstream version v1.3.0.
 
 - Bundled path upstream: `skills/web-design-engineer/`
 - Local path: `skills/ui-design/`
 - Upstream license: MIT
 - Local license: [`LICENSE`](./LICENSE)
 
-The upstream `README.md` and `README.zh-CN.md` are retained. The upstream
-copyright and permission notice must remain with the bundled material.
+The upstream methodology and reference material are refreshed from v1.3.0.
+The local `SKILL.md` keeps the upstream workflow but adapts the skill name to
+`ui-design` and appends the Cynos practice/evidence contract. The local README
+files also remove references to demos that are not bundled in this repository.
+The upstream copyright and permission notice must remain with the bundled
+material.
 
 Cynos-specific integration is implemented in the Engineer practice registry,
-checkpoints, and evidence schema. Those files are original integration code;
-they are separate from the upstream material described above.
+checkpoints, evidence schema, and the appended skill contract. Those files are
+original integration code; they are separate from the upstream material
+described above.
diff --git a/skills/ui-design/manifest.json b/skills/ui-design/manifest.json
index e56757e..49a30cb 100644
--- a/skills/ui-design/manifest.json
+++ b/skills/ui-design/manifest.json
@@ -1,15 +1,10 @@
 {
-  "name": "web-design-engineer",
-  "version": "1.2.2",
+  "name": "ui-design",
+  "version": "1.3.0",
   "category": "Design / Frontend",
-  "description": "Build high-quality visual Web artifacts using HTML/CSS/JavaScript/React — landing pages, dashboards, interactive prototypes, slide decks, animations, UI mockups, and data visualizations — with a six-step design workflow and an anti-cliché design system.",
-  "homepage": "https://github.com/ConardLi/garden-skills/tree/main/skills/web-design-engineer",
+  "description": "Build and refine polished browser-rendered visual experiences with Cynos evidence-based completion checks.",
+  "homepage": "https://github.com/cynos-ai/engineer/tree/main/skills/ui-design",
   "compat": [
-    "claude-code",
-    "claude-ai",
-    "cursor",
-    "codex-cli",
-    "gemini-cli",
-    "opencode"
+    "pi"
   ]
 }
diff --git a/skills/ui-design/references/block-library.md b/skills/ui-design/references/block-library.md
new file mode 100644
index 0000000..b557cc4
--- /dev/null
+++ b/skills/ui-design/references/block-library.md
@@ -0,0 +1,38 @@
+# Implemented Block Library
+
+Use this index to reach an existing working pattern before inventing a new implementation. The implementations currently live in `advanced-patterns.md`; load only the targeted section.
+
+| Need | Implemented block | Source section |
+|---|---|---|
+| Fixed 16:9 presentation | Responsive Slide Engine | `advanced-patterns.md#responsive-slide-engine` |
+| Phone or browser framing | Device Simulation Frames | `advanced-patterns.md#device-simulation-frames` |
+| Live visual controls | Tweaks Panel | `advanced-patterns.md#tweaks-panel-implementation` |
+| Timeline-driven motion | Animation Timeline Engine | `advanced-patterns.md#animation-timeline-engine` |
+| Side-by-side option review | Design Canvas | `advanced-patterns.md#design-canvas` |
+| Theme switching | Dark Mode Toggle | `advanced-patterns.md#dark-mode-toggle` |
+| Charts and analytical views | Data Visualization Templates | `advanced-patterns.md#data-visualization-templates` |
+
+## Reuse Contract
+
+Before copying a block:
+
+1. Confirm it matches the artifact, stack, and calibrated dials.
+2. Preserve its accessibility and responsive behavior.
+3. Adapt tokens to the declared design system.
+4. Remove features that do not serve the request.
+5. Verify dependency availability before importing anything.
+
+## Adding a New Block
+
+Add a reusable block only after it has solved a real task. Document:
+
+- when to use and when not to use it;
+- visual structure and props/data contract;
+- minimum working implementation;
+- mobile/fixed-canvas behavior;
+- interaction and motion variants where relevant;
+- reduced-motion and accessibility behavior;
+- dark/light theme notes where relevant;
+- common failures and repairs.
+
+Prefer one implemented block over a catalog of names without code.
diff --git a/skills/ui-design/references/browser-acceptance.md b/skills/ui-design/references/browser-acceptance.md
new file mode 100644
index 0000000..c400d07
--- /dev/null
+++ b/skills/ui-design/references/browser-acceptance.md
@@ -0,0 +1,132 @@
+# Executable Browser Acceptance
+
+When this skill runs through Cynos's `ui-design` practice, the practice contract
+requires lightweight direct browser evidence after the final UI-like write even
+when this full acceptance harness is not requested. Use this document only for
+an explicit acceptance/QA request.
+
+## Contents
+
+1. Trigger Gate
+2. Resolve the Acceptance Contract
+3. Start Safely
+4. Automated Pass
+5. Visual Pass
+6. Repair Loop
+7. Acceptance Report
+
+## 1. Trigger Gate
+
+Run this harness only when the user explicitly requests acceptance / 验收, browser QA/testing / 浏览器测试, responsive verification / 响应式检查, cross-browser inspection, visual regression, interaction testing, or equivalent executable validation.
+
+Do **not** run it merely because the user says build, implement, polish, finish, review the code, or verify your work. Those requests receive the lightweight pre-delivery self-check unless browser execution is explicitly named or unmistakably requested.
+
+If the user asks only for a design critique, inspect the supplied render or artifact and use `critique-guide.md`; do not silently expand into browser acceptance.
+
+## 2. Resolve the Acceptance Contract
+
+Infer from the request and project before asking questions:
+
+- Entry URL or local command
+- Critical routes / screens
+- Primary interaction path
+- Required viewport(s)
+- Target browser(s), if specified
+- Whether the user wants evidence, repairs, or report-only QA
+
+Use the project's existing dev command and dependencies. Do not replace the stack or install a new test framework unless necessary and authorized.
+
+Default viewports only when the user asked for responsive acceptance but did not provide targets:
+
+| Name | Viewport |
+|---|---|
+| Small mobile | 390 × 844 |
+| Tablet | 768 × 1024 |
+| Small laptop | 1280 × 720 |
+| Desktop | 1440 × 900 |
+
+For fixed 16:9 artifacts, test the intended internal canvas plus at least one smaller outer viewport to verify non-distorting scale behavior.
+
+## 3. Start Safely
+
+1. Inspect `package.json` and project docs for the intended command.
+2. Reuse an already-running server when available.
+3. Start the minimum required local process and wait for a real ready signal.
+4. Record the actual URL and build/dev mode.
+5. Do not modify production services or external data.
+
+## 4. Automated Pass
+
+Use the environment's available browser-control or test tooling. Check the agreed scope:
+
+### Runtime
+
+- Page loads without fatal errors.
+- Console contains no new actionable errors; classify unrelated third-party noise rather than hiding it.
+- Local assets, fonts, images, and primary network requests succeed.
+- No hydration or framework mismatch appears.
+
+### Layout
+
+- No unintended horizontal overflow.
+- Navigation, primary CTA, key content, dialogs, and controls remain reachable.
+- Text does not clip, collide, or become unreadably narrow.
+- Images preserve intended crop and focal point.
+- Fixed-canvas artifacts scale without distortion.
+
+### Interaction
+
+- Primary links and buttons perform the intended action.
+- Keyboard focus is visible and follows a sensible order.
+- Forms expose labels, validation, errors, and submission feedback as applicable.
+- Overlays can be opened and closed without trapping or losing the user.
+- Loading, empty, error, and disabled states are exercised when they are in scope and safely reachable.
+
+### Motion and preferences
+
+- Animations complete and do not block interaction.
+- Reduced-motion behavior preserves content and task completion.
+- Auto-playing or looping motion can be paused when required by the artifact.
+
+## 5. Visual Pass
+
+Capture evidence at each requested viewport and critical state. Inspect screenshots for:
+
+- hierarchy and focal order;
+- spacing rhythm and alignment;
+- design-token drift;
+- repeated layout formulas;
+- contrast and legibility;
+- awkward folds, orphaned controls, and large accidental voids;
+- visual differences from supplied references or baselines.
+
+If a formal baseline exists, compare against it. If not, call the pass “visual acceptance,” not “visual regression.”
+
+## 6. Repair Loop
+
+When the user authorized implementation or asked to fix acceptance failures:
+
+1. Record the failure and reproduction condition.
+2. Make the smallest causal repair.
+3. Re-run the failed check at the same viewport/state.
+4. Re-run a nearby smoke path when the change could regress another area.
+5. Stop after the contract passes or report the concrete blocker.
+
+For report-only QA, do not edit files. Provide evidence-backed findings ordered by severity.
+
+## 7. Acceptance Report
+
+Keep the report concise and reproducible:
+
+```text
+Acceptance scope:
+Environment / URL:
+Viewports / browsers:
+Paths exercised:
+Passed:
+Repaired:
+Remaining issues:
+Evidence:
+```
+
+Never claim browser acceptance from code inspection alone. If the executable harness could not run, say exactly what was and was not verified.
diff --git a/skills/ui-design/references/design-calibration.md b/skills/ui-design/references/design-calibration.md
new file mode 100644
index 0000000..f02089f
--- /dev/null
+++ b/skills/ui-design/references/design-calibration.md
@@ -0,0 +1,136 @@
+# Design Calibration
+
+Use this reference after gathering context and before declaring the design system. Its purpose is to turn a brief into visible decisions, not to decorate the response with scores.
+
+## Contents
+
+1. Design Read
+2. Five Dials
+3. Presets
+4. Resolve Conflicts
+5. Optional Image-First Branch
+6. Completion Test
+
+## 1. Design Read
+
+Write a compact read containing:
+
+- **Artifact**: landing page, dashboard, prototype, slide deck, visualization, campaign page, and so on.
+- **Audience**: who must understand, trust, or act.
+- **Visual language**: a specific family such as restrained builder SaaS, kinetic editorial, warm humanist, or institutional data-first. Avoid empty labels such as “modern” or “clean.”
+- **Mode**: greenfield, extension, redesign-preserve, or redesign-overhaul.
+- **Constraints**: brand, accessibility, platform, viewport, content, deadline, and supplied assets.
+
+If two plausible readings would produce materially different work, ask one focused question. Otherwise state the read and proceed.
+
+## 2. Five Dials
+
+Use whole numbers from 1 to 10.
+
+### Visual Variance
+
+Controls compositional departure from familiar patterns.
+
+| Band | Behavior |
+|---|---|
+| 1–3 | Stable grids, symmetry, familiar navigation, low surprise |
+| 4–6 | One or two asymmetric moves, varied section rhythm, controlled novelty |
+| 7–8 | Strong art direction, off-grid moments, multiple layout families |
+| 9–10 | Experimental composition; use only when comprehension and brand permit |
+
+### Motion Intensity
+
+Controls how much meaning is carried through time.
+
+| Band | Behavior |
+|---|---|
+| 1–2 | Static; state feedback only |
+| 3–4 | Hover, focus, short entry transitions |
+| 5–7 | Sequenced reveals, state choreography, restrained scroll response |
+| 8–10 | Cinematic transitions, pinning, scrubbing, spatial storytelling |
+
+Every animation must communicate hierarchy, feedback, causality, or narrative. Honor reduced motion whenever motion exceeds simple state feedback.
+
+### Information Density
+
+Controls useful information per viewport, not visual clutter.
+
+| Band | Behavior |
+|---|---|
+| 1–3 | Gallery-like, one dominant idea, generous pauses |
+| 4–6 | Balanced marketing/product density |
+| 7–8 | Analytical, operational, comparison-heavy |
+| 9–10 | Cockpit-like; requires strong grouping, scanning, and progressive disclosure |
+
+### Asset Dependence
+
+Controls how much the result relies on real imagery, screenshots, illustration, identity assets, or generated visual references.
+
+| Band | Behavior |
+|---|---|
+| 1–3 | Typography, data, or interface structure can carry the artifact |
+| 4–6 | A few key visuals materially improve recognition or explanation |
+| 7–10 | The product, brand, campaign, or story fails without high-fidelity assets |
+
+At 7+, inventory assets before layout. Do not hide missing assets with decorative CSS.
+
+### Brand Fidelity
+
+Controls how strictly existing identity and interaction language must be preserved.
+
+| Band | Behavior |
+|---|---|
+| 1–3 | New or intentionally exploratory identity |
+| 4–6 | Adapt recognizable cues while allowing meaningful evolution |
+| 7–8 | Preserve core assets, tokens, voice, and signature patterns |
+| 9–10 | Extension-level fidelity; new work should appear native to the existing system |
+
+## 3. Presets
+
+Treat these as starting points, not mandatory values.
+
+| Brief | Variance | Motion | Density | Assets | Fidelity |
+|---|---:|---:|---:|---:|---:|
+| Mainstream SaaS landing | 6 | 5 | 4 | 6 | 5 |
+| Creative studio / campaign | 8 | 7 | 3 | 8 | 4 |
+| Developer tool landing | 6 | 5 | 5 | 6 | 6 |
+| Data dashboard | 4 | 3 | 8 | 3 | 7 |
+| Public-sector service | 3 | 2 | 6 | 3 | 9 |
+| Editorial presentation | 7 | 5 | 4 | 7 | 5 |
+| Existing-product extension | match | match | match | match | 10 |
+| Redesign · Preserve | current + 1 max | current + 1 max | match | match | 9 |
+| Redesign · Overhaul | 6–8 | 4–7 | match content | 6–9 | 5–7 |
+
+## 4. Resolve Conflicts
+
+- **High variance + high density**: preserve a stable navigation and grid spine; concentrate experimentation in one layer.
+- **High motion + high density**: animate transitions or focus, not every element.
+- **High assets + low fidelity**: establish a new visual bible before generating or sourcing a set.
+- **High assets + high fidelity**: source official assets first; generation may extend the world but must not replace identity-critical material.
+- **High fidelity + overhaul request**: explicitly identify which brand invariants survive before changing the visual language.
+- **Accessibility constraints** override aesthetic scores. Reduce motion, clarify hierarchy, and preserve contrast without asking permission.
+
+## 5. Optional Image-First Branch
+
+Use image-first exploration only when it materially improves a visually important greenfield or overhaul task, such as a campaign landing page, brand launch, product hero, or highly art-directed portfolio.
+
+Skip it when:
+
+- the user supplied Figma, screenshots, or a mature design system;
+- the task is an extension, repair, dashboard, form, or data table;
+- the main uncertainty is behavior rather than visual direction;
+- image generation would add cost without reducing design risk.
+
+When used:
+
+1. Define a visual bible: palette, typography character, radius, material, image treatment, and forbidden drift.
+2. Generate only the critical references needed to resolve uncertainty; one image per section is not a requirement.
+3. Prefer fresh, readable section references over cropping tiny details from a compressed full-page board.
+4. Extract implementation decisions from the references.
+5. Treat code and supplied brand assets as higher-authority sources when they conflict with generated pixels.
+
+Use `gpt-image-2` when available for structured generation; otherwise follow the host's image workflow or leave honest asset requirements.
+
+## 6. Completion Test
+
+The calibration is successful only if someone can point from each dial to concrete consequences in the artifact. If changing a score would not change the plan, remove the score or make the mapping explicit.
diff --git a/skills/ui-design/references/failure-patterns.md b/skills/ui-design/references/failure-patterns.md
new file mode 100644
index 0000000..2690002
--- /dev/null
+++ b/skills/ui-design/references/failure-patterns.md
@@ -0,0 +1,159 @@
+# Contextual Failure Patterns
+
+Use this catalog to catch recurring AI-generated design failures. Read only the sections relevant to the artifact. These are strong defaults with explicit exceptions, not universal taste laws.
+
+## Contents
+
+- Marketing and Multi-section Pages
+- Layout and Components
+- Typography and Content
+- Imagery and Brand
+- Motion and Interaction
+- Dashboards and Product UI
+- Final Use
+
+## Marketing and Multi-section Pages
+
+### Repeated section header formula
+
+- **Default**: Do not put a tiny uppercase eyebrow above every heading.
+- **Why**: It creates a mechanically templated rhythm.
+- **Detect**: The same label + headline + paragraph stack appears in most sections.
+- **Exceptions**: Manuals, intentionally indexed editorial systems, or an established brand pattern.
+- **Repair**: Remove low-information labels; vary hierarchy using a lead sentence, image, number, quote, or direct headline.
+
+### Zigzag monotony
+
+- **Default**: Avoid three or more consecutive left/right image-text splits.
+- **Why**: Alternation alone is not composition.
+- **Detect**: Mirroring is the only difference between adjacent sections.
+- **Repair**: Introduce a full-width proof point, vertical narrative, comparison, gallery, diagram, or focused text break.
+
+### Default centered hero
+
+- **Default**: Do not choose centered headline + gradient + two CTAs without brief support.
+- **Why**: It is a statistical default, not a design decision.
+- **Exceptions**: Manifestos, launch statements, search-first utilities, and deliberately ceremonial pages.
+- **Repair**: Re-evaluate content hierarchy, asset role, audience, and viewport; choose the composition that makes those constraints clearest.
+
+### Decorative trust theater
+
+- **Default**: No fabricated metrics, testimonials, logos, security badges, or “used by” claims.
+- **Why**: False credibility is worse than an honest gap.
+- **Repair**: Use a labeled placeholder or request real proof.
+
+### CTA duplication
+
+- **Default**: Keep labels for the same intent consistent.
+- **Detect**: “Get started,” “Try free,” and “Create account” all route to the same action without a meaningful distinction.
+- **Exceptions**: Tested funnel copy or different commitment levels.
+- **Repair**: Normalize the label or clarify the distinct outcomes.
+
+## Layout and Components
+
+### Cardification
+
+- **Default**: Use containers only when grouping, selection, or elevation carries meaning.
+- **Detect**: Every paragraph, metric, and icon lives in a rounded card.
+- **Repair**: Use whitespace, alignment, dividers, typography, or one shared surface.
+
+### Bento without rhythm
+
+- **Default**: Every cell needs content and a compositional role.
+- **Detect**: Blank filler cells, uniform text-only tiles, or arbitrary spans.
+- **Repair**: Match cell count to content; create hierarchy through size, media, data, or interaction rather than empty geometry.
+
+### Shape drift
+
+- **Default**: Define a radius grammar and follow it.
+- **Detect**: Pills, sharp cards, soft cards, and circular controls appear without semantic rules.
+- **Repair**: Assign radius by component role and consolidate tokens.
+
+### Split-header filler
+
+- **Default**: Avoid a large left headline paired with a small floating right paragraph when the split communicates nothing.
+- **Repair**: Stack the content or give the second column a real visual, action, or evidence role.
+
+## Typography and Content
+
+### Generic display typography
+
+- **Default**: Do not reach automatically for Inter, Roboto, Arial, system-ui, Fraunces, or Instrument Serif as the identity-bearing display choice.
+- **Exceptions**: Existing brand/system requirements, accessibility contexts, or intentional platform neutrality.
+- **Repair**: Use the chosen recipe, supplied brand font, or a justified pairing.
+
+### Micro-label noise
+
+- **Detect**: Decorative version numbers, fake coordinates, weather, status dots, section numbers, or metadata that does not help the user.
+- **Repair**: Delete it or connect it to real state/content.
+
+### Copy-shaped decoration
+
+- **Detect**: Vague claims, fake precision, agency slogans, or captions written only to fill space.
+- **Repair**: Replace with user-provided truth, a clear placeholder, or fewer words.
+
+### Unreadable hero
+
+- **Detect**: CTA falls below the intended initial viewport, display text clips, or copy/image competition destroys hierarchy.
+- **Repair**: Recompose; do not enforce a universal word or line cap when the artifact needs a different reading experience.
+
+## Imagery and Brand
+
+### CSS as counterfeit asset
+
+- **Default**: Do not replace a recognizable product, logo, or interface with decorative CSS shapes.
+- **Repair**: Source official material, generate a clearly non-identity-critical extension, or expose an honest asset slot.
+
+### Image-label clutter
+
+- **Default**: Do not overlay pills and captions on imagery unless they identify, control, or explain it.
+- **Repair**: Move necessary metadata into a stable caption or remove it.
+
+### Generated-world drift
+
+- **Detect**: Multi-image output changes palette, material, lighting, typography character, device treatment, or brand symbols.
+- **Repair**: Reuse a visual bible and regenerate the divergent frame rather than patching it with unrelated decoration.
+
+## Motion and Interaction
+
+### Motion for spectacle only
+
+- **Default**: Every animation needs a hierarchy, feedback, causality, or narrative purpose.
+- **Detect**: Removing the animation changes no understanding or feedback.
+- **Repair**: Remove it, lower the Motion dial, or tie it to meaningful state.
+
+### Scroll-state rendering
+
+- **Default**: Do not update broad React state on every scroll or pointer frame.
+- **Repair**: Use CSS, motion values, IntersectionObserver, or an animation library appropriate to the stack.
+
+### Repeated spectacle
+
+- **Default**: Avoid multiple marquees, pinned chapters, magnetic controls, or competing ambient loops on one surface.
+- **Repair**: Select one signature moment and make other transitions quieter.
+
+### Missing reduced-motion path
+
+- **Default**: Motion beyond simple state feedback must collapse cleanly under reduced motion.
+- **Repair**: Preserve content order and interaction completion without relying on animation.
+
+## Dashboards and Product UI
+
+### Marketing styling on operational UI
+
+- **Detect**: Giant headlines, excessive whitespace, cinematic cards, and low-density gestures impede scanning.
+- **Repair**: Raise density, stabilize the grid, clarify state, and prioritize task completion.
+
+### Decorative data visualization
+
+- **Detect**: Gradients, 3D, shadows, or animation obscure comparison and scale.
+- **Repair**: Improve data-ink ratio, labels, semantic color, and accessible alternatives.
+
+### Happy-path-only components
+
+- **Detect**: Only populated success states exist.
+- **Repair**: Add relevant loading, empty, error, permission, disabled, and overflow states.
+
+## Final Use
+
+Report only consequential failures. Do not dump the whole catalog into the user-facing response. Fix safe in-scope problems directly; surface exceptions and tradeoffs when they affect intent.
diff --git a/skills/ui-design/references/redesign-protocol.md b/skills/ui-design/references/redesign-protocol.md
new file mode 100644
index 0000000..1040b84
--- /dev/null
+++ b/skills/ui-design/references/redesign-protocol.md
@@ -0,0 +1,123 @@
+# Existing UI and Redesign Protocol
+
+Read this reference before modifying an existing visual product.
+
+## Contents
+
+1. Classify the Mode
+2. Audit Before Editing
+3. Protected Contracts
+4. Modernization Order
+5. Dial Guidance
+6. Before-and-After Plan
+7. Verification
+
+## 1. Classify the Mode
+
+### Extension
+
+Add or change a bounded element inside the current system. Match the existing vocabulary. Do not “improve” unrelated surfaces.
+
+### Redesign · Preserve
+
+Modernize while retaining identity, information architecture, content voice, and behavioral contracts. Prefer targeted evolution.
+
+### Redesign · Overhaul
+
+Introduce a new visual language while retaining the agreed product, content, and technical contracts. Overhaul is not permission to rewrite everything.
+
+If preserve versus overhaul would materially change the result and the request is ambiguous, ask one focused question.
+
+## 2. Audit Before Editing
+
+Record the current state in project notes or a concise redesign brief.
+
+### Visual system
+
+- Color roles and actual usage ratios
+- Type families, scale, weights, and line lengths
+- Spacing rhythm and container widths
+- Radius, border, shadow, and elevation rules
+- Icons, illustration, photography, and image treatment
+- Motion durations, easing, triggers, and feedback style
+
+### Product and content
+
+- Page tree, navigation, key journeys, and conversion paths
+- Existing content blocks and their purpose
+- Brand voice, legal copy, localization, and real data
+- Loading, empty, error, disabled, and permission states
+
+### Technical contracts
+
+- Routes, slugs, anchors, and deep links
+- Form field names, order, validation, and autofill expectations
+- Analytics events, data attributes, test selectors, and experiment hooks
+- Component APIs and downstream consumers
+- Accessibility semantics, keyboard behavior, focus order, and announcements
+- SEO metadata, canonical URLs, structured data, and social cards
+
+### Quality debt
+
+Separate observations into:
+
+- **Preserve**: recognizable or contract-critical strengths
+- **Improve**: weak hierarchy, spacing, contrast, responsiveness, or craft
+- **Remove**: unsupported clutter, broken patterns, dead interactions, or fabricated content
+
+## 3. Protected Contracts
+
+Never change these silently:
+
+- Route structure, slugs, anchor IDs, or primary navigation labels
+- Brand logo, wordmark, or identity-critical assets
+- Form field names/order or submission behavior
+- Legal, consent, privacy, pricing, or compliance copy
+- Analytics events, selectors, and experiment identifiers
+- Existing accessibility wins
+- Public component APIs or persistent-state keys
+- User-provided content and real data
+
+Ask for authorization when the requested outcome genuinely requires a protected-contract change.
+
+## 4. Modernization Order
+
+Apply the lowest-risk lever that solves the problem, then reassess:
+
+1. Correct functional and accessibility failures.
+2. Repair hierarchy and typography.
+3. Normalize spacing, alignment, and responsive behavior.
+4. Consolidate tokens and remove rogue styling.
+5. Improve states and interaction feedback.
+6. Add justified motion.
+7. Recompose hero or key sections.
+8. Replace full blocks only when they cannot be repaired.
+
+In Preserve mode, stop once the brief is satisfied. Do not turn incremental work into a portfolio redesign.
+
+## 5. Dial Guidance
+
+- **Extension**: match all existing dials; set Brand Fidelity to 10.
+- **Preserve**: keep density and assets stable; change variance/motion by at most one point unless requested.
+- **Overhaul**: derive new variance/motion from the brief, but retain a content-density map so information is not lost.
+
+## 6. Before-and-After Plan
+
+For non-trivial redesigns, state:
+
+```text
+Mode:
+Preserve:
+Improve:
+Remove:
+Protected contracts:
+Design Read + dials:
+Highest-risk change:
+Rollback / fallback:
+```
+
+This is a decision record, not a long design essay.
+
+## 7. Verification
+
+The default pre-delivery self-check confirms the requested scope and protected contracts by inspection. Run executable browser acceptance only when the user explicitly asks for it; then use `browser-acceptance.md` and include regression checks for the preserved journeys.
diff --git a/tests/subagent.test.ts b/tests/subagent.test.ts
index b3c6643..ccd752f 100644
--- a/tests/subagent.test.ts
+++ b/tests/subagent.test.ts
@@ -21,11 +21,10 @@ import {
 } from "../extensions/subagent/runner";
 
 // ============================================================
-// §42.9 Subagent tests
+// Subagent tests
 //
-// The plan requires 10 test dimensions. This file uses pure unit tests to cover agent discovery,
-// runner utility functions, and permission boundary validation. Child process spawn behavior
-// is not tested here.
+// These pure unit tests cover agent discovery, runner utilities, and permission
+// boundary validation. Child process spawn behavior is not tested here.
 // ============================================================
 
 // ---- Agent Discovery ----