@gong-ym/ai-spec-auto 0.2.3

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

@@ -0,0 +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 问题" **不代表**可以跳过工作流。仍需检查并使用适用的技能来执行。

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

@@ -0,0 +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`。

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

@@ -0,0 +1,19 @@
+# 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

@@ -0,0 +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`(设计稿分析) 补充的内容

package/.agents/skills/domains/web/design-analysis/SKILL.md

@@ -0,0 +1,89 @@
+---
+name: design-analysis
+description: 当用户提供设计稿、UI 描述或页面还原需求时，分析界面结构与交互细节，输出可执行的 UI 分析清单供开发和验收使用。
+compatibility: Requires access to design artifacts and the local repository output path docs/样式还原/; may reference sibling skills and local .agents/rules.
+---
+
+# 设计稿分析
+
+## 使用时机
+
+当满足以下任一情况时使用本技能：
+
+- 需要**分析设计稿**（`.pen`、Figma 链接、其它设计图或标注等），把界面结构、样式、元素梳理成可执行的前端任务
+- 需要产出一份**UI 分析清单**文档，供后续开发按清单实现、或供验收时对照
+
+不限定阶段：可在写提案前、写提案中、或单独做一次「只分析不写提案」时使用。
+
+## 环境依赖
+
+- 默认将分析清单落到 `docs/样式还原/`
+- 若涉及复杂交互，会引用本仓库内的交互摘要模板与提案 skill
+
+---
+
+## 核心原则
+
+**必须按「从上到下、从左到右、从外到里」的顺序分析，并逐条准确记录文字、图片、布局、层级四类重中之重。**详见 `rules/analysis-order.md` 和 `rules/analysis-priorities.md`。
+
+---
+
+## 目标产出
+
+| 产出物 | 路径 | 用途 |
+|--------|------|------|
+| UI 分析清单 | `docs/样式还原/<名称>-UI分析清单.md` | 开发时按此文档精确还原；验收时作为对照基准 |
+
+---
+
+## 工作流程（4步）
+
+1. **建立布局 Map**：获取设计稿结构，记录页面状态、整体尺寸、区域划分。详见 `rules/workflow-layout-map.md`
+2. **区域与元素提取**：对每个区域按「从外到里」逐项提取，确保文字、图片、布局、层级四者均准确记录。详见 `rules/workflow-element-extraction.md`
+3. **样式规范汇总**：汇总颜色、字体、圆角、间距、阴影等样式规范。详见 `rules/workflow-style-summary.md`
+4. **复杂交互补充**：若页面含搜索、表单、弹窗、批量操作或复杂状态切换，补一段交互说明摘要。可参考 `../create-proposal/references/interaction-spec-template.md`
+5. **输出 UI 分析清单文档**：将分析结果输出为文档。详见 `rules/workflow-output-checklist.md` 和 `rules/output-analysis-checklist.md`
+
+---
+
+## 快速参考
+
+### Analysis Rules（分析原则与顺序）
+- `rules/analysis-order.md` - 分析顺序（必守）
+- `rules/analysis-priorities.md` - 文字、图片、布局、层级四类重中之重
+
+### Workflow Rules（工作流程步骤）
+- `rules/workflow-layout-map.md` - 第一步：建立布局 Map
+- `rules/workflow-element-extraction.md` - 第二步：区域与元素提取
+- `rules/workflow-style-summary.md` - 第三步：样式规范汇总
+- `rules/workflow-output-checklist.md` - 第四步：输出文档要求
+
+### Output Rules（输出文档模板）
+- `rules/output-analysis-checklist.md` - UI 分析清单文档完整模板
+
+### Implementation Rules（实现建议）
+- `rules/implementation-guidelines.md` - 主流网页设计常识
+- `rules/implementation-common-errors.md` - 常见错误模式与避免方法
+
+### Checklist Rules（检查清单）
+- `rules/checklist-common-misses.md` - 常见遗漏检查点
+
+### Tools Rules（工具使用指南）
+- `rules/tools-design-guidelines.md` - 设计稿工具使用（Pencil MCP / Figma MCP）
+
+---
+
+## 与其它技能的关系
+
+- **create-proposal**：提案前置分析时，若涉及「有设计稿或 UI 描述」的页面/组件，可先或同步使用本技能产出分析清单，再委托 `/opsx:propose` 生成提案
+- **复杂交互说明**：若页面包含搜索、表单、弹窗、批量操作等复杂交互，可先按 `../create-proposal/references/interaction-spec-template.md` 整理摘要，再回写到 proposal / design / tasks
+- **ui-verification**：以本分析清单为基准做 UI 验收时使用；验收若发现「分析遗漏」或「描述不清」，应将结论反哺本技能
+- **create-route / create-component**：开发时若涉及样式还原，应引用本分析清单中的区域与样式规范
+
+---
+
+## 相关规范
+
+- `.agents/rules/09-样式规范.md` - 设计稿颜色、圆角等提取规范
+- `.agents/skills/create-proposal/SKILL.md` - 提案前置分析与 OpenSpec 增强层（有设计稿时可先或同步使用本技能）
+- `.agents/skills/ui-verification/SKILL.md` - UI 验收（以分析清单为基准做验收）

package/.agents/skills/domains/web/design-analysis/rules/analysis-order.md

@@ -0,0 +1,61 @@
+---
+title: 分析顺序（必守）
+impact: CRITICAL
+impactDescription: 不按顺序分析是遗漏与还原错误的主要来源，必须严格按从上到下、从左到右、从外到里
+tags: analysis, order, workflow, critical
+---
+
+# 分析顺序（必守）
+
+## 重要性
+
+**必须按以下顺序阅读与记录设计稿，否则容易产生疏漏。**
+
+不按顺序分析是分析遗漏与还原错误的主要来源之一。严格按顺序分析，才能保证分析完整且实现不出错。
+
+## 分析顺序
+
+### 1. 从上到下
+
+先按垂直方向，从页面最上方扫到最下方，确定所有横向「带」与区块的先后顺序（与前端布局的从上至下一致）。
+
+**为什么重要**：
+- 与前端布局顺序一致，避免实现时顺序颠倒
+- 确保顶部或首屏的大字号文案（如欢迎语）不被遗漏
+- 避免只关注页面下方内容而漏掉顶部区域
+
+### 2. 从左到右
+
+在同一行或同一层级内，再按从左到右依次记录，不跳过、不凭印象合并。
+
+**为什么重要**：
+- 避免只记录左侧内容而漏掉右侧或对称区域
+- 确保同一层级内的元素顺序正确
+- 避免凭印象合并相似元素，导致细节丢失
+
+### 3. 从外到里
+
+在每个区块内部，按「外层容器 → 内层容器 → 叶子元素」逐层进入，先轮廓后细节。
+
+**为什么重要**：
+- 确保层级嵌套关系正确，不丢层或顺序颠倒
+- 先理解整体结构，再深入细节
+- 避免只关注细节而忽略整体布局
+
+## 扫描顺序示例
+
+**设计稿扫描**：
+1. 先按 y 坐标从 0 起向下（或从大到小）确定所有横向区域顺序
+2. 再在同一行内按 x 坐标从左到右读取
+3. 使用 Pencil MCP 或 Figma MCP 时也按此顺序逐层获取布局与节点信息
+
+**记录顺序**：
+- 区域列表：按从上到下（y）排序
+- 同层元素：从左到右（x）排序
+- 嵌套结构：从外到里逐层进入
+
+## 相关规则
+
+- `analysis-priorities.md` - 文字、图片、布局、层级四类重中之重
+- `workflow-layout-map.md` - 建立布局 Map 时应用此顺序
+- `workflow-element-extraction.md` - 区域与元素提取时应用此顺序

package/.agents/skills/domains/web/design-analysis/rules/analysis-priorities.md

@@ -0,0 +1,136 @@
+---
+title: 文字、图片、布局、层级四类重中之重
+impact: CRITICAL
+impactDescription: 四者均不允许出错或遗漏，分析时必须逐条准确记录
+tags: analysis, priorities, text, image, layout, hierarchy, critical
+---
+
+# 文字、图片、布局、层级四类重中之重
+
+## 核心原则
+
+**文字、图片、布局、层级是页面元素的四类重中之重，均不允许出错或遗漏。**
+
+不按顺序分析，或漏记、错记文字/图片/布局/层级，是分析遗漏与还原错误的主要来源。**严格按「从上到下、从左到右、从外到里」并逐条准确记录这四者，才能保证分析完整且实现不出错。**
+
+## 一、文字
+
+### 记录要求
+
+**所有可见文案都必须记录**，包括：
+- 欢迎语、标题、副标题、说明文字
+- 按钮/链接文案
+- 占位文案
+- Tab 文字
+- 标签文字
+- 任何可见的文字内容
+
+### 记录项
+
+每处文字需记录：
+- **内容**：完整或典型示例
+- **字体**：fontFamily
+- **字号**：fontSize
+- **字重**：fontWeight
+- **颜色**：color（含透明度）
+- **行高**：lineHeight
+- **字间距**：letterSpacing（若有）
+
+### 易漏点
+
+- 页面最上方的欢迎语/大标题（最容易在「只记了下面小字」时被漏掉）
+- 副标题
+- 按钮/链接文案
+- 占位提示文字
+- Tab 或标签文字
+
+**检查方法**：按「从上到下」扫到时立即记下，不要等到后面再补。
+
+## 二、图片
+
+### 记录要求
+
+**所有图片、占位图、图标区域都必须记录**，包括：
+- 图片
+- 占位图
+- 图标区域
+- 任何可见的图像内容
+
+### 记录项
+
+每处图片需记录：
+- **尺寸**：宽×高（width × height）
+- **位置**：相对父级或相邻元素的 x, y
+- **比例**：宽高比
+- **圆角**：cornerRadius（如有）
+- **与相邻元素的间距**：margin 或 gap
+- **多图拼接时的布局关系**：左右/上下/网格，以及每张的占比
+
+### 易漏点
+
+- 小图标
+- 占位图
+- 多图拼接时的布局关系
+- 图片的圆角和比例
+
+**检查方法**：逐区域扫描，确保每张图片都有记录。
+
+## 三、布局
+
+### 记录要求
+
+**区域与元素的位置、尺寸、间距、对齐方式、排列方向、多图拼接方式等必须准确记录，与设计稿一致，不可错位或比例失调。**
+
+### 记录项
+
+- **位置**：x, y（相对父级）
+- **尺寸**：width, height
+- **间距**：padding, gap, margin（含方向）
+- **对齐方式**：align-items, justifyContent
+- **排列方向**：横向/纵向/网格
+- **多图拼接方式**：左右/上下/网格布局
+
+### 易漏点
+
+- 间距（padding/gap/margin）的方向性
+- 对齐方式（左对齐/居中/右对齐）
+- 排列方向（横向/纵向/网格）
+- 多图拼接时的布局方式
+
+**检查方法**：对照设计稿，确保布局参数与设计稿一致。
+
+## 四、层级
+
+### 记录要求
+
+**从外到里的嵌套关系（谁包谁、父子/兄弟）、区块的先后顺序与叠放关系必须写清，保证实现时结构正确、不丢层或顺序颠倒。**
+
+### 记录项
+
+- **嵌套关系**：谁包谁、父子/兄弟关系
+- **先后顺序**：区块的显示顺序
+- **叠放关系**：z-index 或层叠顺序
+
+### 易漏点
+
+- 外层容器被忽略
+- 嵌套层级丢失
+- 顺序颠倒
+- 叠放关系不明确
+
+**检查方法**：按「从外到里」逐层分析，确保每层都有记录。
+
+## 检查清单
+
+分析时必过一遍：
+
+- [ ] **所有可见文字**：欢迎语、大标题、副标题、说明、按钮/链接/占位/Tab 文案等，按从上到下逐条核对
+- [ ] **所有图片/占位图**：尺寸、位置、比例、多图拼接布局，无遗漏
+- [ ] **布局**：位置、尺寸、间距、对齐、排列方向、多图拼接方式与设计稿一致，无错位或比例失调
+- [ ] **层级**：从外到里的嵌套与先后顺序正确，无丢层或顺序颠倒
+
+## 相关规则
+
+- `analysis-order.md` - 分析顺序（必守）
+- `workflow-element-extraction.md` - 区域与元素提取时应用这些优先级
+- `checklist-common-misses.md` - 常见遗漏检查点（详细版）