@gong-ym/ai-spec-auto 0.2.13 → 0.2.15

package/.agents/skills/common/using-superpowers/SKILL.md

@@ -1,151 +1,151 @@
----
-name: using-superpowers
-description: 当开始新对话、准备分派任务或尚未进入协议驱动执行轮次时，先检查适用 skill；若已进入 ai-spec-auto 协议轮次，则按轻量豁免模式避免重复调度。
-compatibility: Requires the ai-spec-auto skill/runtime environment, local skill registry, and protocol-step/protocol-advance style turn metadata for protocol-aware bypass.
-metadata:
-  version: "1.0.0"
----
-
-# Superpowers 技能调度规范
-
-> 核心原则：**在执行任何操作之前，先检查是否有适用的技能。**
-
-## 环境依赖
-
-- 依赖本仓库的 `.agents/skills/` 目录与协议运行时约定
-- 不适合作为与仓库无关的通用“永远先扫技能”模板
-
-## 注意事项
-
-- 一旦进入协议驱动轮次，不要再把本技能当成新的主流程
-- 子代理和协议回合都属于明确豁免场景，不能重复抢控制权
-
-## 协议驱动轮次的轻量豁免
-
-当满足以下任一条件时，立即进入**轻量豁免模式**，不要再把本技能当作重型总规范展开：
-
-- 用户触发了 `/spec-start`
-- 用户触发了 `/spec-continue`
-- 用户触发了 `/spec-orchestrate`
-- 当前上下文已经拿到了 `protocol-step / protocol-advance` 返回的 `turn`
-- 当前上下文已经存在 `turn.enforcement`、`turn.guidance`、`turn.execution_contract`、`turn.finalize_contract`
-
-进入轻量豁免模式后，必须遵守：
-
-1. **协议优先**
-   - 当前 `turn` 就是最终执行契约
-   - 先执行当前轮次命令，再决定后续动作
-   - 不要在协议轮次开始前再做一轮完整技能扫描
-
-2. **不重复展开本技能**
-   - 不要再长篇复述“先检查技能、再看上下文”这套总流程
-   - 不要因为本技能被自动加载，就额外宣布或重复读取大量技能规则
-
-3. **只消费协议明确给出的技能**
-   - 仅在 `turn.preferred_skills`、`turn.guidance.skills`、`turn.enforcement.forbidden_skills` 范围内做最小技能判断
-   - 若协议未显式要求，不要主动扩展读取其它技能
-
-4. **禁止抢协议控制权**
-   - 不要把协议轮次改写成“自由任务”
-   - 不要在 `task-orchestrator` 或审批门禁阶段提前调用实现技能
-   - 不要因为本技能存在，就跳过 `protocol-step / protocol-advance / protocol-update`
-
-一句话：
-
-> **通用对话靠 using-superpowers 调度；协议驱动任务靠 turn 执行。**
-
-## 子代理豁免
-
-如果你是被派遣执行特定任务的子代理（subagent），跳过本技能，直接执行任务。
-
-## 强制约束（NON-NEGOTIABLE）
-
-如果你认为哪怕有 1% 的可能性某个技能适用于当前任务，你**必须**先读取并调用该技能。
-
-这不是建议，是强制要求。不可协商，不可跳过，不可自我合理化地绕过。
-
-## 指令优先级
-
-1. **用户显式指令**（AGENTS.md、直接请求）— 最高优先级
-2. **Superpowers 技能** — 覆盖默认行为
-3. **系统默认提示** — 最低优先级
-
-如果用户指令与技能冲突，以用户指令为准。**但规范中标注为 NON-NEGOTIABLE 的条款除外**——当用户的请求违反 NON-NEGOTIABLE 规则时，必须拒绝执行并向用户解释原因和规范依据。
-
-## 如何使用技能
-
-在不同 AI IDE 中，技能的加载方式不同，但核心原则一致：
-
-| 环境 | 技能加载方式 |
-|------|-------------|
-| **Cursor** | 通过 `.cursor/skills/` 目录下的 `SKILL.md` 描述自动匹配触发，或用户通过 `@` 显式引用 |
-| **Claude Code** | 使用 `Skill` tool 调用，技能内容自动加载 |
-| **Gemini CLI** | 通过 `activate_skill` tool 激活 |
-| **其他环境** | 使用 Read 工具读取 `.agents/skills/<name>/SKILL.md` 文件并遵循其指令 |
-
-## 技能检查流程
-
-若当前不属于“协议驱动轮次的轻量豁免”，再执行下面的完整技能检查流程：
-
-收到用户消息后，按以下流程执行：
-
-```
-1. 收到用户消息
-   │
-2. 判断：是否有任何技能可能适用？（哪怕 1% 的可能性）
-   │
-   ├─ 否 → 直接回复（包括澄清问题）
-   │
-   └─ 是 → 读取对应技能文件
-            │
-3. 宣告："使用 [技能名] 来 [目的]"
-   │
-4. 技能中是否包含检查清单？
-   │
-   ├─ 是 → 为每项创建 TODO，逐项执行
-   │
-   └─ 否 → 严格遵循技能指令执行
-```
-
-## 自我检查：危险信号
-
-当你产生以下想法时，**立即停下** — 你正在合理化跳过技能：
-
-| 你的想法 | 事实 |
-|---------|------|
-| "这只是一个简单问题" | 问题也是任务，检查技能 |
-| "我需要先了解上下文" | 技能检查在了解上下文**之前** |
-| "让我先看看代码" | 技能会告诉你**怎么看** |
-| "这个任务不需要正式技能" | 如果技能存在，就用它 |
-| "我记得这个技能的内容" | 技能会迭代更新，读取最新版本 |
-| "这不算一个任务" | 有操作就是任务，检查技能 |
-| "技能太重了" | 简单任务也会变复杂，先用技能 |
-| "我先做这一件事" | 做任何事之前先检查技能 |
-| "我知道该怎么做" | 知道概念 ≠ 使用技能，调用它 |
-| "这次不需要写审计报告" | 只要产出了代码变更，就必须附审计报告（见 `14-审计汇报规范.md`） |
-
-## 技能优先级
-
-当多个技能可能适用时，按以下顺序：
-
-1. **流程类技能优先**（头脑风暴、调试）— 决定「怎么做」
-2. **实现类技能其次**（组件创建、API 封装）— 指导「做什么」
-
-示例：
-- "开发 X 功能" / "创建提案" → 先 `create-proposal`（前置分析后委托 `/opsx:propose` 生成提案），再按 tasks 执行
-- "执行 tasks.md" → 先 `execute-task`（Superpowers Loop）
-- "修复这个 bug" → 先调试定位，再读对应领域技能
-
-## 技能类型
-
-**刚性技能**（如 `execute-task`、调试流程）：严格遵循，不可简化步骤。
-
-**柔性技能**（如设计模式、最佳实践）：适配当前上下文，灵活应用原则。
-
-技能文件本身会标明属于哪种类型。
-
-## 用户指令的解读
-
-用户指令说明的是「做什么」，不是「怎么做」。
-
-"新增 X 功能" 或 "修复 Y 问题" **不代表**可以跳过工作流。仍需检查并使用适用的技能来执行。
+---
+name: using-superpowers
+description: 当开始新对话、准备分派任务或尚未进入协议驱动执行轮次时，先检查适用 skill；若已进入 ai-spec-auto 协议轮次，则按轻量豁免模式避免重复调度。
+compatibility: Requires the ai-spec-auto skill/runtime environment, local skill registry, and protocol-step/protocol-advance style turn metadata for protocol-aware bypass.
+metadata:
+  version: "1.0.0"
+---
+
+# Superpowers 技能调度规范
+
+> 核心原则：**在执行任何操作之前，先检查是否有适用的技能。**
+
+## 环境依赖
+
+- 依赖本仓库的 `.agents/skills/` 目录与协议运行时约定
+- 不适合作为与仓库无关的通用“永远先扫技能”模板
+
+## 注意事项
+
+- 一旦进入协议驱动轮次，不要再把本技能当成新的主流程
+- 子代理和协议回合都属于明确豁免场景，不能重复抢控制权
+
+## 协议驱动轮次的轻量豁免
+
+当满足以下任一条件时，立即进入**轻量豁免模式**，不要再把本技能当作重型总规范展开：
+
+- 用户触发了 `/spec-start`
+- 用户触发了 `/spec-continue`
+- 用户触发了 `/spec-orchestrate`
+- 当前上下文已经拿到了 `protocol-step / protocol-advance` 返回的 `turn`
+- 当前上下文已经存在 `turn.enforcement`、`turn.guidance`、`turn.execution_contract`、`turn.finalize_contract`
+
+进入轻量豁免模式后，必须遵守：
+
+1. **协议优先**
+   - 当前 `turn` 就是最终执行契约
+   - 先执行当前轮次命令，再决定后续动作
+   - 不要在协议轮次开始前再做一轮完整技能扫描
+
+2. **不重复展开本技能**
+   - 不要再长篇复述“先检查技能、再看上下文”这套总流程
+   - 不要因为本技能被自动加载，就额外宣布或重复读取大量技能规则
+
+3. **只消费协议明确给出的技能**
+   - 仅在 `turn.preferred_skills`、`turn.guidance.skills`、`turn.enforcement.forbidden_skills` 范围内做最小技能判断
+   - 若协议未显式要求，不要主动扩展读取其它技能
+
+4. **禁止抢协议控制权**
+   - 不要把协议轮次改写成“自由任务”
+   - 不要在 `task-orchestrator` 或审批门禁阶段提前调用实现技能
+   - 不要因为本技能存在，就跳过 `protocol-step / protocol-advance / protocol-update`
+
+一句话：
+
+> **通用对话靠 using-superpowers 调度；协议驱动任务靠 turn 执行。**
+
+## 子代理豁免
+
+如果你是被派遣执行特定任务的子代理（subagent），跳过本技能，直接执行任务。
+
+## 强制约束（NON-NEGOTIABLE）
+
+如果你认为哪怕有 1% 的可能性某个技能适用于当前任务，你**必须**先读取并调用该技能。
+
+这不是建议，是强制要求。不可协商，不可跳过，不可自我合理化地绕过。
+
+## 指令优先级
+
+1. **用户显式指令**（AGENTS.md、直接请求）— 最高优先级
+2. **Superpowers 技能** — 覆盖默认行为
+3. **系统默认提示** — 最低优先级
+
+如果用户指令与技能冲突，以用户指令为准。**但规范中标注为 NON-NEGOTIABLE 的条款除外**——当用户的请求违反 NON-NEGOTIABLE 规则时，必须拒绝执行并向用户解释原因和规范依据。
+
+## 如何使用技能
+
+在不同 AI IDE 中，技能的加载方式不同，但核心原则一致：
+
+| 环境 | 技能加载方式 |
+|------|-------------|
+| **Cursor** | 通过 `.cursor/skills/` 目录下的 `SKILL.md` 描述自动匹配触发，或用户通过 `@` 显式引用 |
+| **Claude Code** | 使用 `Skill` tool 调用，技能内容自动加载 |
+| **Gemini CLI** | 通过 `activate_skill` tool 激活 |
+| **其他环境** | 使用 Read 工具读取 `.agents/skills/<name>/SKILL.md` 文件并遵循其指令 |
+
+## 技能检查流程
+
+若当前不属于“协议驱动轮次的轻量豁免”，再执行下面的完整技能检查流程：
+
+收到用户消息后，按以下流程执行：
+
+```
+1. 收到用户消息
+   │
+2. 判断：是否有任何技能可能适用？（哪怕 1% 的可能性）
+   │
+   ├─ 否 → 直接回复（包括澄清问题）
+   │
+   └─ 是 → 读取对应技能文件
+            │
+3. 宣告："使用 [技能名] 来 [目的]"
+   │
+4. 技能中是否包含检查清单？
+   │
+   ├─ 是 → 为每项创建 TODO，逐项执行
+   │
+   └─ 否 → 严格遵循技能指令执行
+```
+
+## 自我检查：危险信号
+
+当你产生以下想法时，**立即停下** — 你正在合理化跳过技能：
+
+| 你的想法 | 事实 |
+|---------|------|
+| "这只是一个简单问题" | 问题也是任务，检查技能 |
+| "我需要先了解上下文" | 技能检查在了解上下文**之前** |
+| "让我先看看代码" | 技能会告诉你**怎么看** |
+| "这个任务不需要正式技能" | 如果技能存在，就用它 |
+| "我记得这个技能的内容" | 技能会迭代更新，读取最新版本 |
+| "这不算一个任务" | 有操作就是任务，检查技能 |
+| "技能太重了" | 简单任务也会变复杂，先用技能 |
+| "我先做这一件事" | 做任何事之前先检查技能 |
+| "我知道该怎么做" | 知道概念 ≠ 使用技能，调用它 |
+| "这次不需要写审计报告" | 只要产出了代码变更，就必须附审计报告（见 `14-审计汇报规范.md`） |
+
+## 技能优先级
+
+当多个技能可能适用时，按以下顺序：
+
+1. **流程类技能优先**（头脑风暴、调试）— 决定「怎么做」
+2. **实现类技能其次**（组件创建、API 封装）— 指导「做什么」
+
+示例：
+- "开发 X 功能" / "创建提案" → 先 `create-proposal`（前置分析后委托 `/opsx:propose` 生成提案），再按 tasks 执行
+- "执行 tasks.md" → 先 `execute-task`（Superpowers Loop）
+- "修复这个 bug" → 先调试定位，再读对应领域技能
+
+## 技能类型
+
+**刚性技能**（如 `execute-task`、调试流程）：严格遵循，不可简化步骤。
+
+**柔性技能**（如设计模式、最佳实践）：适配当前上下文，灵活应用原则。
+
+技能文件本身会标明属于哪种类型。
+
+## 用户指令的解读
+
+用户指令说明的是「做什么」，不是「怎么做」。
+
+"新增 X 功能" 或 "修复 Y 问题" **不代表**可以跳过工作流。仍需检查并使用适用的技能来执行。

package/.agents/skills/common/wait-for-gate-signal/SKILL.md

@@ -1,85 +1,85 @@
----
-name: wait-for-gate-signal
-description: Use when runtime-state.status is "waiting-approval" and visual-bridge is enabled — poll `.ai-spec/gate-signal.json` every 3s for up to 60s, auto-continue on approval/resume, stop on rejection, default-continue on timeout. Keeps the same conversation; never opens a new session.
----
-
-# Visual 门禁信号等待（切面 skill，所有 profile 通用）
-
-> 与 `.agents/rules/common/15-visual-gate-wait.md` 等价，但以 Claude Code
-> skill 形式暴露，便于 Claude 端通过技能目录发现并调用。两者逻辑必须保持一致，
-> 如需调整参数，优先改规则文件，本 skill 同步更新。
-
-## 触发条件
-
-仅在同时满足以下两条时才应调用本 skill：
-
-1. `.ai-spec/current-run.json` 中 `status === "waiting-approval"` 且 `pending_gate` 非空
-2. `.ai-spec/visual-bridge.json` 存在且 `enabled !== false`
-
-否则按项目原有"人工审核"流程处理。
-
-## 执行步骤
-
-### Step 1 — 读取当前门禁上下文
-
-```text
-state := readJSON(".ai-spec/current-run.json")
-currentRunId := state.run_id
-currentGate  := state.pending_gate
-waitStartedAt := Date.now()
-```
-
-若读取失败，退出 skill 并请求用户人工确认。
-
-### Step 2 — 轮询信号文件（3s × 最多 20 次）
-
-每 3 秒：
-
-1. 在对话中输出一行可见进度：`[T+{i*3}s] 等待 Visual 审批（run=<id> gate=<gate>）...`
-2. 尝试读 `.ai-spec/gate-signal.json`（不存在/损坏 → 本轮视为无信号，跳到下一轮）
-3. 对解析到的 signal 做**全部**以下校验：
-   - `signal.schema_version === 1`
-   - `signal.run_id === currentRunId`
-   - `signal.gate === currentGate`
-   - `signal.ts_ms > waitStartedAt`（防陈旧信号误触发）
-4. 校验通过后按 `signal.decision` 分流：
-   - `approved` 或 `resumed` → 退出循环，立即执行 `/spec-continue`
-   - `rejected` → 退出循环，在对话中汇报 `signal.reason`，**不** 继续推进
-
-### Step 3 — 超时默认放行
-
-20 轮（约 60 秒）仍未命中任何信号：
-- 在对话中明确说明："60 秒内未收到 Visual 审批决定，按默认策略自动放行"
-- 执行 `/spec-continue`
-
-## 行为约束
-
-- **必须在原对话里完成**（本 skill 不会新开会话）
-- **不得**读到任意 gate-signal 就直接继续；必须完成 4 项校验
-- **不得**省略 60 秒超时判定
-- **不得**在等待期间主动询问用户（循环本身就是等待机制；用户随时可打断）
-
-## 异常兜底
-
-| 情况 | 动作 |
-|---|---|
-| `current-run.json` 读失败 | 退出 skill，请求用户人工确认 |
-| `gate-signal.json` JSON 损坏 | 本轮视为无信号，继续下一轮 |
-| 循环中意外异常 | 捕获 + 记录 + 继续下一轮；连续 3 次异常 → 按超时路径放行 |
-| 用户主动发送新消息 | 视为人工接管，立即终止循环 |
-
-## 排障
-
-- 确认 `.ai-spec/visual-bridge.json` 的 `enabled`、`server_url`、`workspace_id` 正确
-- 确认 `cli.js visual watch` 守护正在运行（负责把 Visual 侧 outbox 应用为本地 gate-signal）
-- 手动写测试信号：
-  ```bash
-  node -e "require('/path/to/br-ai-spec/internal/visual-hooks/gate-signal').writeGateSignal({
-    targetDir: process.cwd(),
-    runId: '<当前 run_id>',
-    gate: '<当前 gate>',
-    decision: 'approved',
-    actorId: 'manual-test'
-  })"
-  ```
-  写入后 3 秒内 AI 应命中并 `/spec-continue`。
+---
+name: wait-for-gate-signal
+description: Use when runtime-state.status is "waiting-approval" and visual-bridge is enabled — poll `.ai-spec/gate-signal.json` every 3s for up to 60s, auto-continue on approval/resume, stop on rejection, default-continue on timeout. Keeps the same conversation; never opens a new session.
+---
+
+# Visual 门禁信号等待（切面 skill，所有 profile 通用）
+
+> 与 `.agents/rules/common/15-visual-gate-wait.md` 等价，但以 Claude Code
+> skill 形式暴露，便于 Claude 端通过技能目录发现并调用。两者逻辑必须保持一致，
+> 如需调整参数，优先改规则文件，本 skill 同步更新。
+
+## 触发条件
+
+仅在同时满足以下两条时才应调用本 skill：
+
+1. `.ai-spec/current-run.json` 中 `status === "waiting-approval"` 且 `pending_gate` 非空
+2. `.ai-spec/visual-bridge.json` 存在且 `enabled !== false`
+
+否则按项目原有"人工审核"流程处理。
+
+## 执行步骤
+
+### Step 1 — 读取当前门禁上下文
+
+```text
+state := readJSON(".ai-spec/current-run.json")
+currentRunId := state.run_id
+currentGate  := state.pending_gate
+waitStartedAt := Date.now()
+```
+
+若读取失败，退出 skill 并请求用户人工确认。
+
+### Step 2 — 轮询信号文件（3s × 最多 20 次）
+
+每 3 秒：
+
+1. 在对话中输出一行可见进度：`[T+{i*3}s] 等待 Visual 审批（run=<id> gate=<gate>）...`
+2. 尝试读 `.ai-spec/gate-signal.json`（不存在/损坏 → 本轮视为无信号，跳到下一轮）
+3. 对解析到的 signal 做**全部**以下校验：
+   - `signal.schema_version === 1`
+   - `signal.run_id === currentRunId`
+   - `signal.gate === currentGate`
+   - `signal.ts_ms > waitStartedAt`（防陈旧信号误触发）
+4. 校验通过后按 `signal.decision` 分流：
+   - `approved` 或 `resumed` → 退出循环，立即执行 `/spec-continue`
+   - `rejected` → 退出循环，在对话中汇报 `signal.reason`，**不** 继续推进
+
+### Step 3 — 超时默认放行
+
+20 轮（约 60 秒）仍未命中任何信号：
+- 在对话中明确说明："60 秒内未收到 Visual 审批决定，按默认策略自动放行"
+- 执行 `/spec-continue`
+
+## 行为约束
+
+- **必须在原对话里完成**（本 skill 不会新开会话）
+- **不得**读到任意 gate-signal 就直接继续；必须完成 4 项校验
+- **不得**省略 60 秒超时判定
+- **不得**在等待期间主动询问用户（循环本身就是等待机制；用户随时可打断）
+
+## 异常兜底
+
+| 情况 | 动作 |
+|---|---|
+| `current-run.json` 读失败 | 退出 skill，请求用户人工确认 |
+| `gate-signal.json` JSON 损坏 | 本轮视为无信号，继续下一轮 |
+| 循环中意外异常 | 捕获 + 记录 + 继续下一轮；连续 3 次异常 → 按超时路径放行 |
+| 用户主动发送新消息 | 视为人工接管，立即终止循环 |
+
+## 排障
+
+- 确认 `.ai-spec/visual-bridge.json` 的 `enabled`、`server_url`、`workspace_id` 正确
+- 确认 `cli.js visual watch` 守护正在运行（负责把 Visual 侧 outbox 应用为本地 gate-signal）
+- 手动写测试信号：
+  ```bash
+  node -e "require('/path/to/br-ai-spec/internal/visual-hooks/gate-signal').writeGateSignal({
+    targetDir: process.cwd(),
+    runId: '<当前 run_id>',
+    gate: '<当前 gate>',
+    decision: 'approved',
+    actorId: 'manual-test'
+  })"
+  ```
+  写入后 3 秒内 AI 应命中并 `/spec-continue`。

package/.agents/skills/domains/README.md

@@ -1,19 +1,19 @@
-# domains skills
-
-本目录预留给“按能力域沉淀、且可被多个专家复用”的 skill。
-
-当前不建议一开始就塞很多内容进来，只有在下面两种情况同时满足时再新增：
-
-- 这个 skill 明显属于某个能力域，例如性能、安全、可观测性
-- 这个 skill 会被多个专家复用，而不是只被一个专家调用
-
-当前阶段建议优先继续使用：
-
-- `common/` 里的通用 skill
-- `profiles/react/` 和 `profiles/vue/` 里的技术栈 skill
-
-后续如果需要，再在本目录下增加如：
-
-- `performance/`
-- `observability/`
-- `security-a11y/`
+# domains skills
+
+本目录预留给“按能力域沉淀、且可被多个专家复用”的 skill。
+
+当前不建议一开始就塞很多内容进来，只有在下面两种情况同时满足时再新增：
+
+- 这个 skill 明显属于某个能力域，例如性能、安全、可观测性
+- 这个 skill 会被多个专家复用，而不是只被一个专家调用
+
+当前阶段建议优先继续使用：
+
+- `common/` 里的通用 skill
+- `profiles/react/` 和 `profiles/vue/` 里的技术栈 skill
+
+后续如果需要，再在本目录下增加如：
+
+- `performance/`
+- `observability/`
+- `security-a11y/`

package/.agents/skills/domains/ui-ux-pro-max/SKILL.md

@@ -1,58 +1,58 @@
----
-name: ui-ux-pro-max
-description: AI 设计智能技能，提供 67 种 UI 风格、161 套配色方案、57 组字体搭配、99 条 UX 准则。当设计协作专家需要基于 Figma、标注或复杂 UI 约束做设计决策、标注提取和视觉方案收口，或用户明确要求页面更好看、漂亮、美观、有高级感、更有设计感、更有质感、更现代、更高级、优化视觉/优化 UI 时使用。
-compatibility: Optional local assets may be installed at .agents/skills/domains/ui-ux-pro-max/data/ inside the target project. Without local data this package-level skill acts as a placeholder and only provides workflow guidance.
----
-
-# UI UX Pro Max
-
-## 使用时机
-
-当满足以下任一情况时使用本技能：
-
-- 需要由 `design-collaborator`(设计协作专家) 对 Figma、标注稿、高保真页面或交互稿做结构化解析
-- 需要在设计稿信息不完整的情况下，辅助做出 UI 风格、配色、字体和 UX 取舍
-- 需要把视觉约束、标注信息和设计歧义收口为可执行的设计结论，而不直接进入代码实现
-- 用户直接表达“页面想更好看、漂亮、美观、有高级感、更有设计感、更有质感、更现代、更高级、优化视觉/优化 UI/改漂亮点”，需要先收口设计方向而不是直接进入实现
-
-本技能不替代 `frontend-implementer`(前端实现专家)；实现阶段仍按页面、组件、路由和样式类技能推进。
-
-## 运行模式
-
-### 本地完整版
-
-若目标项目存在 `data/` 目录：
-
-- 优先读取目标项目下 `.agents/skills/domains/ui-ux-pro-max/data/`
-- 使用本地完整版资源完成 UI 风格、配色、字体和 UX 决策
-- 结合设计稿输入输出更细的视觉建议和设计收口结论
-
-### 包内占位版
-
-若当前只有本文件，没有本地 `data/` 目录：
-
-- 将本技能视为设计协作占位入口
-- 仅提供设计决策框架、使用边界和与其它技能的协作方式
-- 需要细粒度设计稿拆解时，继续配合 `design-analysis`(设计稿分析)
-
-## 核心任务
-
-1. 识别页面风格、信息层级和关键交互
-2. 提取设计稿中的标注约束、视觉重点和不明确项
-3. 在缺少完整标注时，补充合理的 UI 风格、配色和字体建议
-4. 把设计歧义整理成待确认问题或可执行约束，交回需求/实现链路
-
-## 与其它技能的关系
-
-- `design-analysis`(设计稿分析)：负责系统化拆解页面结构、区域元素和样式约束，是本技能的分析兜底
-- `create-proposal`(创建提案)：当设计约束会影响范围、交互或验收口径时，需要把结论回写到 proposal/specs/design/tasks
-- `ui-verification`(UI 验收)：实现完成后可用其对照设计稿和分析清单做验收
-
-## 占位版输出要求
-
-在未安装本地资源的情况下，至少输出：
-
-- 页面整体风格判断
-- 关键视觉约束
-- 需进一步确认的设计问题
-- 建议转交 `design-analysis`(设计稿分析) 补充的内容
+---
+name: ui-ux-pro-max
+description: AI 设计智能技能，提供 67 种 UI 风格、161 套配色方案、57 组字体搭配、99 条 UX 准则。当设计协作专家需要基于 Figma、标注或复杂 UI 约束做设计决策、标注提取和视觉方案收口，或用户明确要求页面更好看、漂亮、美观、有高级感、更有设计感、更有质感、更现代、更高级、优化视觉/优化 UI 时使用。
+compatibility: Optional local assets may be installed at .agents/skills/domains/ui-ux-pro-max/data/ inside the target project. Without local data this package-level skill acts as a placeholder and only provides workflow guidance.
+---
+
+# UI UX Pro Max
+
+## 使用时机
+
+当满足以下任一情况时使用本技能：
+
+- 需要由 `design-collaborator`(设计协作专家) 对 Figma、标注稿、高保真页面或交互稿做结构化解析
+- 需要在设计稿信息不完整的情况下，辅助做出 UI 风格、配色、字体和 UX 取舍
+- 需要把视觉约束、标注信息和设计歧义收口为可执行的设计结论，而不直接进入代码实现
+- 用户直接表达“页面想更好看、漂亮、美观、有高级感、更有设计感、更有质感、更现代、更高级、优化视觉/优化 UI/改漂亮点”，需要先收口设计方向而不是直接进入实现
+
+本技能不替代 `frontend-implementer`(前端实现专家)；实现阶段仍按页面、组件、路由和样式类技能推进。
+
+## 运行模式
+
+### 本地完整版
+
+若目标项目存在 `data/` 目录：
+
+- 优先读取目标项目下 `.agents/skills/domains/ui-ux-pro-max/data/`
+- 使用本地完整版资源完成 UI 风格、配色、字体和 UX 决策
+- 结合设计稿输入输出更细的视觉建议和设计收口结论
+
+### 包内占位版
+
+若当前只有本文件，没有本地 `data/` 目录：
+
+- 将本技能视为设计协作占位入口
+- 仅提供设计决策框架、使用边界和与其它技能的协作方式
+- 需要细粒度设计稿拆解时，继续配合 `design-analysis`(设计稿分析)
+
+## 核心任务
+
+1. 识别页面风格、信息层级和关键交互
+2. 提取设计稿中的标注约束、视觉重点和不明确项
+3. 在缺少完整标注时，补充合理的 UI 风格、配色和字体建议
+4. 把设计歧义整理成待确认问题或可执行约束，交回需求/实现链路
+
+## 与其它技能的关系
+
+- `design-analysis`(设计稿分析)：负责系统化拆解页面结构、区域元素和样式约束，是本技能的分析兜底
+- `create-proposal`(创建提案)：当设计约束会影响范围、交互或验收口径时，需要把结论回写到 proposal/specs/design/tasks
+- `ui-verification`(UI 验收)：实现完成后可用其对照设计稿和分析清单做验收
+
+## 占位版输出要求
+
+在未安装本地资源的情况下，至少输出：
+
+- 页面整体风格判断
+- 关键视觉约束
+- 需进一步确认的设计问题
+- 建议转交 `design-analysis`(设计稿分析) 补充的内容