.cursor/rules/common/baserule.mdc

@@ -25,8 +25,12 @@ Agent回复时使用简体中文。
 
 | 位置 | 用途 | 示例 |
 |------|------|------|
-| `~/.cursor/skills/` | 跨项目通用 Skill，全局可用 | epee-orchestrator、deferred-decisions |
-| `.cursor/skills/` | 当前项目专属 Skill | 项目特定的代码生成、配置管理等 |
+| `.cursor/skills/` | **所有 Skill 的主存储位置**（含通用和项目专属） | epee-orchestrator、deferred-decisions、项目特定 Skill |
+| `~/.cursor/skills/` | 跨项目通用 Skill 的全局副本（可选，方便其他项目复用） | epee-orchestrator、deferred-decisions |
+
+> **重要**：无论 Skill 是通用还是项目专属，都**必须**在项目的 `.cursor/skills/` 下保留一份，
+> 以确保能被 Git 管理和版本控制。全局目录 `~/.cursor/skills/` 仅作为跨项目共享的便利副本，
+> 不作为唯一存储位置。
 
 ### Agent 创建 Rule 或 Skill 时必须遵守
 
@@ -35,5 +39,5 @@ Agent回复时使用简体中文。
 3. 确认后放入对应目录：
    - 通用 Rule → `.cursor/rules/common/`
    - 项目专属 Rule → `.cursor/rules/project/`
-   - 通用 Skill → `~/.cursor/skills/`
-   - 项目专属 Skill → `.cursor/skills/`
+   - **所有 Skill（含通用）→ `.cursor/skills/`**（必须，确保 Git 可管理）
+   - 通用 Skill 额外同步 → `~/.cursor/skills/`（可选，方便其他项目使用）

.cursor/rules/common/profile-recall.mdc

@@ -0,0 +1,25 @@
+---
+description: 每次会话开始时读取用户画像和项目画像，将精简 Profile 注入上下文以指导 Agent 行为
+alwaysApply: true
+---
+
+## 画像上下文注入
+
+每次会话处理用户第一个任务前，执行以下操作：
+
+1. 读取 `~/.cursor/profile/user-profile.md`（不存在则跳过）
+2. 读取 `.cursor/profile/project-profile.md`（不存在则跳过）
+3. 如文件存在且有实质内容（非空模板），将其内容作为背景知识纳入考量
+4. 在后续回复中，Agent 应自然地参考画像信息，无需显式引用
+
+### 注意
+
+- 画像信息是背景参考，不是硬性约束——当用户当前指令与画像冲突时，以当前指令为准
+- 不要在回复中提及"根据你的画像"之类的措辞，自然融入即可
+- 画像的记录和管理由 `profile-memory` Skill 负责，本 Rule 只负责读取和注入
+
+## 被动检测提醒
+
+Agent 在整个对话过程中应保持对画像信号的被动感知。
+当对话结束、用户的主线任务完成后，如果检测到了新的画像信息，
+应读取 `profile-memory` Skill 并执行其"操作 A"的确认流程。

.cursor/skills/deferred-decisions/SKILL.md

@@ -0,0 +1,151 @@
+---
+name: deferred-decisions
+description: >-
+  记录开发中被延期的技术方案/决策，并在关联任务出现时主动提醒用户。
+  当对话中出现"以后再做"、"先不做"、"defer"、"延期方案"、"备选方案"、
+  "递进方案"等语义时触发。也用于浏览、管理已有的 deferred items。
+---
+
+# Deferred Decisions Skill
+
+追踪开发中被延期的技术方案，在合适时机主动提醒用户。
+
+## 存储
+
+**数据文件**: `.cursor/deferred/registry.md`
+
+该文件是 Agent 的结构化记忆，不是面向人类的文档。每个 deferred item 是一个 H3 级标题块。
+
+## 操作 A：记录延期方案
+
+### 触发识别
+
+当对话中出现以下模式时，Agent 应主动提议记录：
+- 讨论了多种方案，选择了一种，明确说其余"以后再做"
+- 实现了基础版本，提到了可递进升级的高级版本
+- 发现了可以改进的点，但当前优先级不够
+
+### 流程
+
+```
+1. 从对话中提炼：
+   - 选择了什么方案（chosen_alternative）
+   - 延期了什么（标题 + context）
+   - 为什么延期（deferred_reason）
+   - 什么时候可以做（prerequisite）
+   - 涉及哪些领域（tags）和文件（related_files）
+2. 生成 slug 形式的唯一 ID（如 ecosystem-lod-switching）
+3. 读取 .cursor/deferred/registry.md（不存在则用模板创建）
+4. 在 "## Active Items" 区域末尾、"---" 分隔线之前追加新条目
+5. 向用户确认已记录，展示条目摘要
+```
+
+### 条目模板
+
+```markdown
+### [item-slug] 简短标题
+- **status**: deferred
+- **tags**: tag1, tag2, tag3
+- **recorded**: YYYY-MM-DD
+- **source_chat**: [简短描述](chat-uuid)
+- **prerequisite**: 实施前提条件（可选，无则写 "无"）
+- **related_files**:
+  - path/to/file1
+  - path/to/file2
+- **context**: |
+    延期方案的具体内容，2-5 行描述。
+    包含方案的要点和实施思路。
+- **chosen_alternative**: 当时选择的方案简述
+- **deferred_reason**: 延期的原因
+```
+
+### 字段说明
+
+| 字段 | 必填 | 说明 |
+|---|---|---|
+| ID（方括号内） | 是 | slug 形式，全局唯一 |
+| status | 是 | `deferred` / `reminded` / `in_progress` / `done` / `cancelled` |
+| tags | 是 | 逗号分隔的领域标签，用于关联匹配 |
+| recorded | 是 | 记录日期 |
+| source_chat | 否 | 来源对话标识 |
+| prerequisite | 否 | 实施前提条件 |
+| related_files | 否 | 关联代码文件路径 |
+| context | 是 | 延期方案的具体内容 |
+| chosen_alternative | 是 | 当时选择了什么 |
+| deferred_reason | 是 | 延期原因 |
+
+## 操作 B：关联提醒
+
+### 触发条件
+
+由 `.cursor/rules/common/deferred-recall.mdc` 触发，或当用户任务涉及已有 deferred item 的领域时自动触发。
+
+### 流程
+
+```
+1. 读取 .cursor/deferred/registry.md
+2. 提取当前任务的关键词和涉及文件
+3. 匹配 status=deferred 的 items：
+   - tags 与当前任务关键词有交集
+   - related_files 与当前任务涉及文件有重叠
+   - prerequisite 描述的条件可能已满足
+4. 如匹配到，在回复开头简要提醒：
+   "提醒：你之前有一个延期方案 [item-title] 与当前任务相关。要一并处理吗？"
+5. 如用户同意，将该 item 的 status 改为 in_progress
+```
+
+### 提醒原则
+
+- 每个 item 在同一会话中最多提醒一次
+- 只提醒 status=deferred 的 items（reminded/in_progress 不重复提醒）
+- 提醒应简洁，不打断用户的主线任务
+
+## 操作 C：状态管理
+
+| 用户动作 | 状态变更 | 额外操作 |
+|---|---|---|
+| "开始做 X" | deferred → in_progress | 无 |
+| "X 完成了" | in_progress → done | 移到 "Completed / Cancelled Items" 区域 |
+| "X 不需要了" | any → cancelled | 移到 "Completed / Cancelled Items" 区域 |
+| Agent 提醒后用户确认 | deferred → in_progress | 无 |
+
+### 移动条目
+
+将条目从 "Active Items" 剪切到 "Completed / Cancelled Items" 区域时，保留完整内容，仅修改 status。
+
+## 操作 D：浏览/回顾
+
+当用户问"有哪些延期方案"、"deferred list"、"待办方案"等时：
+
+```
+1. 读取 registry.md
+2. 列出所有 status=deferred 的 items 摘要表：
+   | ID | 标题 | Tags | 记录日期 | 前提条件 |
+3. 如用户要求按 tag 过滤，只展示匹配项
+```
+
+## Registry 文件模板
+
+当 `.cursor/deferred/registry.md` 不存在时，用此模板创建：
+
+```markdown
+# Deferred Decisions Registry
+
+## Active Items
+
+（暂无延期方案）
+
+---
+
+## Completed / Cancelled Items
+
+（暂无已完成或已废弃的方案）
+```
+
+## 自迭代日志
+
+本节记录使用本 Skill 过程中发现的必要检查项。
+
+### 已知必要检查
+
+（暂无）

.cursor/skills/epee-orchestrator/SKILL.md

@@ -0,0 +1,125 @@
+---
+name: epee-orchestrator
+description: >-
+  EPEE Skill Orchestrator：元层调度系统。检测任务是否可由已有 Skill 处理并分流，
+  或发现 Skill 缺口并引导创建新 Skill。当 Agent 遇到手动配置密集、重复模式明确、
+  手工指引过长的任务时触发。也用于 Skill Registry 的维护和同步。
+---
+
+# EPEE Skill Orchestrator
+
+元层调度系统，负责 Skill 分流、缺口发现和 Registry 维护。
+
+## 操作 A：Skill 分流（匹配已有 Skill）
+
+### 流程
+
+```
+1. 读取 registry.md 获取所有已注册 Skill 的摘要
+2. 将当前任务特征与每个 Skill 的"触发场景"关键词匹配
+3. 如果匹配到：
+   a. 告知用户"此任务可以通过 [Skill名] 高效完成"
+   b. 简述该 Skill 的能力及与当前任务的契合点
+   c. 用户确认后，读取并激活对应 Skill 的 SKILL.md
+```
+
+### 匹配规则
+
+- 优先匹配触发场景关键词与当前任务描述的交集
+- 如有多个 Skill 匹配，按相关度排序推荐，由用户选择
+- `deferred-decisions` 等标记为"基础设施"类型的 Skill 不参与任务分流匹配，
+  仅作为 Orchestrator 的下游工具使用
+
+## 操作 B：Skill 缺口发现 + 创建引导
+
+### 触发条件
+
+操作 A 未找到匹配的 Skill，且当前任务满足"Skill 创建价值判断标准"中至少 2 条。
+
+### 流程
+
+```
+1. 向用户提出建议：
+   "这类任务可以通过创建一个 [建议 Skill 名] 来自动化"
+2. 给出 1-3 句方案概要：
+   - 这个 Skill 会做什么
+   - 核心工作机制（如 DSL 生成、YAML 直写、MCP 调用等）
+   - 预估能节省的重复劳动
+3. 询问用户选择：
+   a) "继续讨论并创建" → 进入创建流程
+   b) "以后再说" → 进入延期记录流程
+   c) "不需要" → 结束，正常执行当前任务
+```
+
+### a) 创建流程
+
+```
+1. 委托给 create-skill Skill（路径: ~/.cursor/skills-cursor/create-skill/SKILL.md）
+2. 将以下上下文传递给 create-skill 流程：
+   - 触发创建的原始任务描述
+   - Orchestrator 的方案概要
+   - 建议的 Skill 名称
+3. 按 create-skill 的标准流程完成 Discovery → Design → Implementation → Verification
+4. 创建完成后，要求用户对新 Skill 进行实际测试
+5. 测试通过后，执行操作 C 同步 Registry
+```
+
+### b) 延期记录流程
+
+```
+1. 读取 deferred-decisions Skill
+2. 按其"操作 A：记录延期方案"流程，将 Skill 创建建议记录为 deferred item
+3. tags 中包含 "skill-creation" 和相关领域标签
+4. context 中记录方案概要，便于未来回忆
+```
+
+## 操作 C：Registry 同步
+
+### 触发条件
+
+- 新 Skill 被创建后
+- 已有 Skill 的 SKILL.md 被实质性修改后（如能力范围变化、触发场景变化）
+
+### 流程
+
+```
+1. 读取目标 Skill 的 SKILL.md
+2. 从 frontmatter 提取 name 和 description
+3. 从正文提取核心能力和触发场景关键词
+4. 读取 registry.md
+5. 新增或更新对应条目，遵循 registry.md 中定义的条目格式
+6. 写回 registry.md
+```
+
+### 条目格式
+
+参见 [registry.md](registry.md) 中的条目结构。
+
+## Skill 创建价值判断标准
+
+当操作 A 无匹配时，Agent 使用以下标准评估是否建议创建新 Skill。
+满足 **2 条及以上** 即认为值得建议：
+
+1. **频次**：该类任务预计会出现 3 次以上
+2. **模式明确**：任务有明确的输入/输出模式（输入 X → 产出 Y）
+3. **步骤繁多**：手动操作步骤 >= 5 步，或涉及 >= 3 个文件的协调修改
+4. **易错**：存在容易出错的重复性操作（如 GUID 填写、格式对齐等）
+5. **可自动化**：可以通过生成代码、配置文件、脚本或 MCP 调用来替代手动操作
+
+不满足标准时，Agent 正常执行任务，不提出创建建议。
+
+## 与其他系统的协作
+
+| 系统 | 关系 | 说明 |
+|------|------|------|
+| `create-skill` Skill | 下游委托 | 操作 B 创建流程的执行者 |
+| `deferred-decisions` Skill | 下游工具 | 操作 B 延期记录的执行者 |
+| `deferred-recall` Rule | 协同 | Orchestrator 延期的建议通过 deferred-recall 在未来自动提醒 |
+
+## 自迭代日志
+
+本节记录使用本 Skill 过程中发现的必要检查项。
+
+### 已知必要检查
+
+（暂无）

.cursor/skills/epee-orchestrator/registry.md

@@ -0,0 +1,34 @@
+# EPEE Skill Registry
+
+> 本文件由 EPEE Skill Orchestrator 维护，记录所有已实现 Skill 的摘要信息。
+> 每次创建/修改 Skill 后必须同步更新（参见 `epee-orchestrator.mdc` Rule）。
+
+## 条目格式说明
+
+每个条目包含以下字段：
+- **类型**：项目级 / 个人级 / 基础设施
+- **能力**：1 句话核心能力描述
+- **触发场景**：逗号分隔的关键词/短语，用于与任务特征匹配
+- **输出**：该 Skill 的产出物
+- **路径**：SKILL.md 的路径（统一使用 `.cursor/skills/...`）
+- **备注**（可选）：特殊说明
+
+---
+
+## 已注册 Skill
+
+### deferred-decisions
+- **类型**: 基础设施
+- **能力**: 记录和追踪延期的技术方案/决策，在关联任务出现时主动提醒
+- **触发场景**: "以后再做"、"先不做"、"defer"、延期方案管理、延期回顾
+- **输出**: .cursor/deferred/registry.md 条目
+- **路径**: .cursor/skills/deferred-decisions/SKILL.md
+- **备注**: 不参与任务分流匹配，仅作为 Orchestrator 的下游工具
+
+### profile-memory
+- **类型**: 个人级
+- **能力**: 在对话中被动检测用户个人特质和项目信息，经确认后持久化为精简画像和详细日志
+- **触发场景**: "画像"、"profile"、"我的偏好"、"查看画像"、"项目信息"、"查看项目画像"、用户主动管理画像
+- **输出**: ~/.cursor/profile/user-profile.md、.cursor/profile/project-profile.md 及对应 log 文件
+- **路径**: .cursor/skills/profile-memory/SKILL.md
+- **备注**: 被动检测由 profile-recall Rule 触发；精简 Profile 每次会话自动注入上下文

.cursor/skills/profile-memory/SKILL.md

@@ -0,0 +1,239 @@
+---
+name: profile-memory
+description: >-
+  渐进式用户/项目画像系统。在对话中被动检测用户个人特质（审美、技术偏好、做事风格等）
+  和项目信息（定位、技术栈、产品方向等），对话结束前统一总结并经用户确认后记录。
+  当用户提到"画像"、"profile"、"我的偏好"、"查看画像"、"项目信息"等时触发。
+---
+
+# Profile Memory
+
+渐进式画像系统，被动收集并持久化用户个人特质与项目信息。
+
+## 存储结构
+
+| 文件 | 位置 | 用途 | 注入上下文 |
+|------|------|------|-----------|
+| user-profile.md | `~/.cursor/profile/` | 个人画像精简版 | 是（每次会话） |
+| user-profile-log.md | `~/.cursor/profile/` | 个人画像详细日志 | 否 |
+| project-profile.md | `.cursor/profile/` | 项目画像精简版 | 是（每次会话） |
+| project-profile-log.md | `.cursor/profile/` | 项目画像详细日志 | 否 |
+
+精简版 Profile 是 Agent 每次会话的上下文输入，必须极度精简。
+详细 Log 保留完整上下文，供用户主动查阅和溯源。
+
+## 硬上限
+
+- user-profile.md：不超过 **50 行**
+- project-profile.md：不超过 **30 行**
+- 每条信息一行，`- ` 开头，措辞客观中立
+
+## 操作 A：被动检测 + 对话结束前确认
+
+### 检测范围
+
+在正常对话中被动检测以下信号（**不主动询问**）：
+
+**个人特质**：
+- 审美/设计偏好（"太花哨了"、"我喜欢 minimal"）
+- 技术偏好（"以后都用 X"、"我不喜欢 class 写法"）
+- 做事风格（"先讨论再动手"、"不要自作主张"）
+- 沟通偏好（"给我简短的回答"、"多解释一下原理"）
+- 产品理解/思维方式
+
+**项目信息**：
+- 项目定位和目标（"这个项目是做 X 的"）
+- 技术栈与架构决策
+- 设计约定和规范
+- 产品方向和目标用户
+
+### 检测原则
+
+- **保守而非激进**：宁可漏记也不误记
+- 只记录**持久性**的偏好/特质，忽略一次性的临时需求
+- 区分"个人"和"项目"两个维度
+
+### 变更分类
+
+检测到的新信息与已有条目的关系分为三类，处理方式不同：
+
+| 类型 | 定义 | 示例 | 提示强度 |
+|------|------|------|---------|
+| **新增** | 全新维度，无已有条目 | 首次提到审美偏好 | 常规 |
+| **演进** | 已有条目的深化、细化或自然发展 | "偏好 React" → "偏好 React + Next.js 全栈" | 常规，展示前后对比 |
+| **转向** | 与已有条目方向性矛盾或根本性变化 | "偏好 React" → "想转 Vue"；项目方向从 B2C 转 B2B | **加强提醒**，展示前后对比 |
+
+### 确认流程
+
+```
+1. 在对话过程中将检测到的信息在内部缓存，分类为"个人"或"项目"
+2. 对每条缓存信息，与已有 Profile 比对，标记变更类型（新增/演进/转向）
+3. 当用户的主线任务完成后，统一提出，格式如下：
+
+   "本次对话中我注意到以下可记录的画像信息："
+
+   **个人画像：**
+   - [新增][分类] 条目内容
+   - [演进][分类] 旧：xxx → 新：yyy
+   - [转向][分类] 旧：xxx → 新：yyy ⚠️
+
+   **项目画像：**
+   - （同上格式）
+
+   转向类条目额外标注 ⚠️ 并附一句说明：
+   "⚠️ 以下条目与已有记录存在方向性变化，请特别关注："
+
+   "是否记录？你可以全部确认、逐条修改或跳过。"
+
+4. 用户确认后执行写入流程
+5. 如本次对话未检测到任何画像信息，则不触发此流程
+```
+
+### 写入流程
+
+```
+1. 读取对应的精简 Profile 和详细 Log（不存在则用模板创建）
+2. 按变更类型执行：
+   - 新增：在对应分类下追加条目
+   - 演进：替换对应旧条目为新措辞
+   - 转向：替换对应旧条目为新措辞（用户已在确认流程中审核）
+3. 写入精简 Profile
+4. 追加详细 Log，其中：
+   - 新增条目：操作记为"新增"
+   - 演进条目：操作记为"更新（旧值 → 新值）"
+   - 转向条目：操作记为"转向（旧值 → 新值）"，便于溯源重大变化
+5. 检查精简 Profile 是否超过硬上限，超过则提醒用户精简
+```
+
+## 操作 B：用户主动管理
+
+当用户说"查看我的画像"、"profile"、"查看项目画像"、"我的偏好"等：
+
+```
+1. 读取对应的精简 Profile，展示给用户
+2. 如用户要看详细版或溯源，读取对应 Log 展示
+3. 用户可要求：
+   - 删除某条记录（同步删除精简版条目，Log 中标记为已删除）
+   - 修改某条记录的措辞
+   - 合并/重组分类
+   - 新增分类
+```
+
+## 操作 C：变更比对与冲突处理
+
+### 比对逻辑
+
+```
+对每条新检测到的信息，在同分类下的已有条目中查找语义相近项：
+1. 无相近条目 → 标记为"新增"
+2. 有相近条目且方向一致（深化/细化/补充） → 标记为"演进"
+3. 有相近条目且方向矛盾（替代/转向/否定） → 标记为"转向"
+```
+
+### 前后对比格式
+
+演进和转向类条目在确认流程中必须展示前后对比：
+
+```
+- [演进][技术偏好] 旧：偏好 React → 新：偏好 React + Next.js 全栈开发
+- [转向][产品方向] 旧：面向 C 端个人用户 → 新：转向 B 端企业客户 ⚠️
+```
+
+### 用户选择
+
+对每条演进/转向条目，用户可以：
+- **确认更新**：用新条目替换旧条目
+- **保留两者**：旧条目不动，新条目作为补充追加（适用于不同细分维度）
+- **放弃**：不记录本条
+
+## 数据文件模板
+
+首次使用时，如对应文件不存在，按以下模板创建。
+
+### user-profile.md
+
+```markdown
+# User Profile
+
+## 审美与设计
+
+## 技术偏好
+
+## 做事风格
+
+## 沟通偏好
+
+## 产品理解
+```
+
+### user-profile-log.md
+
+```markdown
+# User Profile Log
+
+详细记录每次画像更新的完整上下文，按时间正序追加。
+
+## 记录
+```
+
+### project-profile.md
+
+```markdown
+# Project Profile
+
+## 项目定位
+
+## 技术栈与架构
+
+## 设计约定
+
+## 产品方向
+```
+
+### project-profile-log.md
+
+```markdown
+# Project Profile Log
+
+详细记录每次项目画像更新的完整上下文，按时间正序追加。
+
+## 记录
+```
+
+### Log 条目格式
+
+每次写入 Log 时，追加以下格式的条目：
+
+```markdown
+### YYYY-MM-DD — 简短标题
+- **分类**: 对应的精简 Profile 分类名
+- **精简版**: 写入精简 Profile 的那一行内容
+- **原始上下文**: 用户原话或对话中的关键语句
+- **来源对话**: [对话简述](chat-uuid)
+- **操作**: 新增 / 演进（旧值 → 新值）/ 转向（旧值 → 新值）/ 删除
+```
+
+## 分类扩展
+
+预设的分类列表可以扩展。当检测到的信息不属于任何现有分类时：
+
+```
+1. 在确认流程中标注"建议新增分类: [分类名]"
+2. 用户确认后在精简 Profile 中新增该分类的 H2 标题
+3. 注意硬上限，新增分类会占用行数
+```
+
+## 与其他系统的协作
+
+| 系统 | 关系 | 说明 |
+|------|------|------|
+| `profile-recall` Rule | 下游消费者 | 每次会话读取精简 Profile 并注入上下文 |
+| `epee-orchestrator` | 注册 | 在 registry.md 中注册本 Skill |
+
+## 自迭代日志
+
+本节记录使用本 Skill 过程中发现的必要检查项。
+
+### 已知必要检查
+
+（暂无）