cursor Init 完善多人协同changelog，以及godot相关基础skill和代码规范

.cursor/rules/common/baserule.mdc

@@ -1,43 +1,35 @@
 ---
-description: 跨项目底层通用约定（语言、目录归属）
+description: 跨项目底层约定：语言、目录归属、运行时版本与 Windows 文本编码
 alwaysApply: true
 ---
 
-## 语言约定
+# 基础约定
 
-Agent回复时使用简体中文。
-代码注释时尽量使用简体中文。
-写SKILL的时候文档部分也尽量使用简体中文。
-专业术语和项目专有名词不受此语言限制，通常是英文则保留。
+## 语言
 
-## Rules / Skills 目录归属约定
+- 面向用户的回复使用简体中文；代码注释和 Skill 文档优先使用简体中文。
+- API、类型名、命令和项目专有名词保留其惯用英文写法。
 
-本项目使用以下目录结构区分跨项目通用内容与项目专属内容：
+## Rules / Skills 目录归属
 
-### Rules
+- 跨项目通用 Rule 放在 `.cursor/rules/common/`。
+- 当前项目或特定技术栈 Rule 放在 `.cursor/rules/project/`。
+- 项目内 Skill 放在 `.cursor/skills/`；全局副本只能作为可选共享副本，不能替代项目内版本。
+- 新建 Rule 或 Skill 前先判断归属；无法判断时先询问用户。
 
-| 目录 | 用途 | 示例 |
-|------|------|------|
-| `.cursor/rules/common/` | 跨项目通用规则，开新项目时可直接复制 | 语言约定、Orchestrator 触发、延期方案回忆 |
-| `.cursor/rules/project/` | 当前项目专属规则 | 项目架构约定、框架特定规范、项目专属工作流 |
+## 运行时版本
 
-### Skills
+创建环境、安装依赖、启动项目或运行测试前，先确认项目声明的运行时版本；禁止直接采用系统默认版本，也不得擅自升级到最新或预发布版本。
 
-| 位置 | 用途 | 示例 |
-|------|------|------|
-| `.cursor/skills/` | **所有 Skill 的主存储位置**（含通用和项目专属） | epee-orchestrator、deferred-decisions、项目特定 Skill |
-| `~/.cursor/skills/` | 跨项目通用 Skill 的全局副本（可选，方便其他项目复用） | epee-orchestrator、deferred-decisions |
+- Godot：检查 `project.godot` 的兼容声明、项目 README 的版本要求，以及 `.cursor/local-env.json` 记录的本机可执行文件与版本；本机配置只用于选择运行时，不能覆盖项目要求。
+- Python：检查 `pyproject.toml`、`.python-version` 和 README。
+- Node.js：检查 `package.json` 的 `engines`、`.nvmrc`、`.node-version` 和 README。
+- 声明互相冲突时指出冲突；版本仍不明确时，先向用户确认再安装或执行。
+- 本机版本不匹配时先报告并给出调整方案，不通过修改业务代码迁就错误环境。
 
-> **重要**：无论 Skill 是通用还是项目专属，都**必须**在项目的 `.cursor/skills/` 下保留一份，
-> 以确保能被 Git 管理和版本控制。全局目录 `~/.cursor/skills/` 仅作为跨项目共享的便利副本，
-> 不作为唯一存储位置。
+## Windows UTF-8 安全
 
-### Agent 创建 Rule 或 Skill 时必须遵守
-
-1. **先判断归属**：新建 Rule 或 Skill 前，评估其是否为跨项目通用内容
-2. **如果不确定，必须询问用户**："这个 Rule/Skill 是通用的还是项目专属的？"
-3. 确认后放入对应目录：
-   - 通用 Rule → `.cursor/rules/common/`
-   - 项目专属 Rule → `.cursor/rules/project/`
-   - **所有 Skill（含通用）→ `.cursor/skills/`**（必须，确保 Git 可管理）
-   - 通用 Skill 额外同步 → `~/.cursor/skills/`（可选，方便其他项目使用）
+- 文本文件统一保存为 UTF-8 无 BOM、LF 换行；修改后按需校验 BOM 与换行。
+- 优先使用 IDE 的文件读写工具，避免文本经控制台编码转换后再写回。
+- 必须用 PowerShell 写文本时显式使用可产生 UTF-8 无 BOM 的 API，并明确 LF；不要依赖 Windows PowerShell 与 PowerShell 7 不同的默认编码。
+- 必须查看含中文的命令输出时先将控制台输出编码设为 UTF-8；若仍有乱码，写入显式 UTF-8 的临时文件后再用文件工具读取。

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

@@ -1,125 +1,38 @@
 ---
-description: 每次会话开始时注入开发日志概要（L3），并在检测到任务与近期改动相关时自动读取中期记录（L2）
+description: 会话中按需回忆开发日志，并在完成变更时维护多人 fragment、踩坑记录与 Skill registry
 alwaysApply: true
 ---
 
-## 开发日志上下文注入
+# 开发日志回忆与收尾
 
-每次会话处理用户第一个任务前，执行以下操作：
+## 会话开始
 
-1. 读取 `.cursor/changelog/changelog-headlines.md`（不存在则跳过）
-2. 如文件存在且有实质内容（不仅是模板头部），将全部条目作为背景知识注入上下文
-3. 这些信息帮助 Agent 快速建立位置感：项目进展到什么阶段、最近的工作重心在哪个模块
-4. 在后续回复中自然参考，不显式提及"根据开发日志"
+1. 读取 `.cursor/changelog/changelog-headlines.md`；不存在或只有模板时跳过。
+2. 当前任务与近期模块、标签或文件相关时，再读取 `.cursor/changelog/changelog-recent.md` 中的相关条目。
+3. 条目仍有歧义时，按记录 ID 精确查找对应 fragment 或只读取 `changelog-full.md` 的局部范围；不要无条件加载完整历史。
+4. 日志只作为背景事实使用，不用在回复中刻意声明来源。
 
-## 主动定位辅助
+## 变更日志写入
 
-L3 概要的核心价值之一是帮助 Agent 在**冷启动**（新会话、无上下文）时理解用户意图。
-当用户的请求缺少具体文件名或模块名时，Agent 应主动利用 L3 进行推断：
+完成有实质影响的代码、配置或文档变更后：
 
-### 典型场景
+1. 读取 `.cursor/skills/dev-changelog/SKILL.md` 并遵循其当前流程；文件不存在时说明无法记录，不自行发明格式。
+2. 从 `.cursor/local-env.json` 获取稳定的 `changelog-author`；缺失时先询问用户。
+3. 每次记录都新建独立 fragment：`.cursor/changelog/entries/<author>/<id>.md`；不得复用或覆盖他人的 fragment，以避免多人修改同一文件。
+4. 不直接编辑生成视图；按 Skill 指定的生成器重建并校验视图。
 
-1. **隐式延续**：用户说"继续做昨天那个"、"把那个功能完善一下"
-   → 从 L3 中找到最近的相关条目，上溯到 L2 获取具体文件列表
-2. **模糊指代**：用户说"那个组件有 bug"、"之前改的那个接口"
-   → 用 L3 中的关键词匹配用户描述，定位到具体改动
-3. **上下文补全**：用户直接提出一个任务，没有背景说明
-   → 用 L3 判断该任务是否与近期某个改动有关联（如同一模块、同一功能线）
+## 踩坑信号自检
 
-### 流程
+最终回复前快速判断本次任务是否出现了非显而易见的运行时、构建、配置、版本或工具链问题，尤其是：
 
-```
-1. 解析用户请求，识别是否存在隐式引用或模糊指代
-2. 在 L3 概要中查找语义最匹配的 1-3 条记录
-3. 提取匹配条目的锚点 ID，上溯到 L2 获取 affected_files 和 tags
-4. 如有必要，继续上溯到 L1 获取完整的决策背景
-5. 将定位到的文件/模块作为任务的起点，开始执行
-```
+- 报错后经过排查才定位根因；
+- 只看代码无法预见，实际执行才暴露；
+- 同一问题在会话中重复出现。
 
-如果 L3 中没有匹配到任何相关记录，正常处理即可——不是所有任务都与近期改动有关。
+命中时读取 `.cursor/skills/pitfall-journal/SKILL.md`，按其写入流程记录；纯拼写、显然语法错误或普通业务调整不记录。开发日志中的摘要不能替代可检索的踩坑记录。
 
-## L2 自动触发
+## Skill 一致性
 
-Agent 开始处理一个新任务时，判断是否需要读取近期详细记录：
-
-1. 从当前任务中提取涉及的文件路径和语义关键词
-2. 与 L3 概要中的内容做快速比对——如果近期有相关模块/文件的改动记录
-3. 命中时，读取 `.cursor/changelog/changelog-recent.md`，将相关条目纳入上下文
-4. 匹配策略：
-   - 硬匹配：当前任务涉及的文件出现在 L2 条目的 `affected_files` 中
-   - 软匹配：当前任务的语义关键词与条目的 `tags` 有交集
-   - 任一命中即触发读取
-
-### 注意
-
-- L3 注入是低成本操作（~50 句话），每次会话都执行
-- L2 读取按需触发，只在检测到关联时才读取
-- 开发日志是事实性记录，直接使用即可，不像画像那样需要"自然融入"的措辞考量
-- 记录的写入和管理由 `dev-changelog` Skill 负责，本 Rule 只负责读取和注入
-
-## 逐级上溯
-
-当 L3 中某条记录的一句话描述**语义模糊**（无法判断具体范围或与当前任务的关系），
-按以下步骤精准上溯，**禁止全文读取 L1**：
-
-1. 提取该条目的锚点 ID（`CL-xxx`）
-2. 用 Grep 在 `changelog-recent.md`（L2）中搜索该 ID → 找到则读取该条目
-3. 如 L2 中未找到或仍有歧义 → 用 Grep 在 `changelog-full.md`（L1）中搜索该 ID，
-   获取行号后用 Read 工具读取该行号 ±20 行范围
-4. 一次上溯通常只涉及 1-3 条记录，不批量上溯
-
-## 任务完成 Checklist（强制）
-
-Agent 在即将输出最终回复前，**必须**逐项检查以下清单。
-这是硬性要求，不是建议——**跳过任何一项都视为执行错误**。
-
-### 前置项（每次回复前无条件执行）
-
-**A. 画像信号扫描（短路版）**
-
-目的：以最小 token 成本维持 `profile-memory` Skill 的被动检测通路。
-
-步骤：
-
-1. **快判（词表匹配）**：扫描本次对话中**用户消息**，检查是否**明显**出现以下偏好/决策触发词族之一：
-
-   - 个人偏好信号：`我喜欢` / `我倾向` / `我不喜欢` / `我讨厌` / `以后都` / `以后别` /
-     `别再` / `不要再` / `我的风格` / `我的偏好` / `太花哨` / `minimal` /
-     `简洁` / `精炼` / `啰嗦`
-   - 项目决策信号：`这个项目是` / `目标用户是` / `技术栈` / `架构上` /
-     `产品方向` / `定位是`
-
-2. **分支**：
-   - 无匹配 → **直接跳过**，进入下一 checklist 项（thinking 应在 50 token 内结束）
-   - 有匹配 → 读取 `.cursor/skills/profile-memory/SKILL.md` 并执行操作 A 的确认流程
-
-3. **约束**：本项不做全量语义判断——漏记隐式信号是可接受的权衡。
-   用户如需记录隐式偏好可显式说"把这条记入画像"。
-
-### 变更检查项（仅当本次有代码/配置文件改动时执行）
-
-1. **本次是否有代码/配置文件改动？**（不含 `.cursor/` 下的基础设施文件）
-   - 否 → 跳过本组后续项，直接进入"收尾项"
-   - 是 → 继续
-
-2. **是否已写入三层开发日志？**
-   - 否 → **立即**读取 `dev-changelog` Skill 并执行操作 A，写入 L1 + L2 + L3 后再输出回复
-   - 是 → 继续
-
-3. **是否修改了任何 Skill？**（包括 SKILL.md 内容变更）
-   - 否 → 跳过
-   - 是 → 检查是否已同步 `epee-orchestrator` 的 `registry.md`，未同步则立即执行
-
-4. **本次是否有 Skill 使用异常？**（遗漏、误触、产物与用户预期偏差）
-   - 否 → 跳过
-   - 是 → 执行 `epee-orchestrator.mdc` 中的自迭代确认流程
-
-### 收尾项（每次回复前无条件执行）
-
-**Z. 静默 Hook ack**
-
-- 用 Write 工具创建空文件 `.cursor/changelog/.changelog-ack`
-- 这会更新 ack 文件的 mtime，阻止 `check-changelog.ps1` hook 在后续回复中重复提醒
-
-**执行原则**：先完成 checklist 中的所有写入动作，再输出面向用户的回复文本。
-回复末尾如果执行了变更检查项第 2 项，附 `[已记录到开发日志]`。
+- 创建、删除、重命名或修改任何 Skill 后，同步 `.cursor/skills/epee-orchestrator/registry.md`，确保名称、入口、能力描述与触发条件一致。
+- Skill 使用出现遗漏、误触或系统性偏差时，按 `epee-orchestrator` Skill 的自迭代流程处理。
+- 用户明确限制可修改路径时，以该限制为准：报告未能执行的日志或 registry 写入，不越权修改。

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

@@ -1,79 +1,29 @@
 ---
-description: 引导 Agent 在首次会话自动、后续通过关键词手动触发 cursor-init Skill
-globs:
+description: 首次会话检查 Cursor 初始化状态，并响应显式初始化或重置请求
 alwaysApply: true
 ---
 
-## 首次初始化自检（最高优先级 · 必须最先执行）
+# Cursor 初始化触发
 
-**每一次会话的首次用户消息响应之前**，Agent 必须先检查工作区是否存在 `.cursor/.init-done`：
+## 首次会话自检
 
-### 判定逻辑
+处理每次会话的第一个用户任务前，检查 `.cursor/.init-done`：
 
-```
-IF .cursor/.init-done 不存在:
-    → 本仓库是"clone 模板后的首次会话"
-    → 必须在处理用户原始请求之前先完成 cursor-init
-ELSE:
-    → 已 init 过，跳过本自检
-    → 仅当用户命中下方"手动触发关键词"时才再次执行本 Skill
-```
+- 文件存在：正常处理任务；没有显式触发词时不重复提醒。
+- 文件不存在：说明仓库尚未完成 Cursor 初始化，概述原任务，并在执行清理、移动、覆盖等操作前取得用户确认。
+- 用户要求跳过初始化时，继续原任务并简短提示下次会话仍会检查；不得强制初始化。
 
-### 首次触发的执行方式
+用户确认后读取 `.cursor/skills/cursor-init/SKILL.md`，严格按其当前阶段执行。Skill 不存在时停止初始化并报告缺失，不自行实施破坏性替代流程。
 
-1. **暂存用户原始请求**，明确告诉用户：
-   > "检测到当前仓库刚从模板 clone 下来，还未完成 .cursor 初始化。需要先跑一遍 cursor-init
-   > （清理模板遗留数据、配置项目画像、可选生成 .gitignore）。完成后再处理你的请求：{原始请求概要}。"
-2. 等用户明确回复"继续/OK"后，读取 `.cursor/skills/cursor-init/SKILL.md` 并严格执行阶段 0 → 7
-3. **init 完成后**（阶段 7 写入 `.init-done` 成功后），回到被暂存的用户原始请求继续处理
-4. 若用户说"先不做 init，就处理我的请求"：
-   - 尊重用户选择，跳过本次 init
-   - 但仍在本次回复中明确说明 sentinel 缺失，并提示"下次会话还会再次提醒"
+## 手动触发
 
-### 自检成本说明
+以下意图触发完整初始化或重置：`初始化 cursor`、`cursor init`、`重置 cursor`、`reset cursor`、清理复制来的 `.cursor`。
 
-已 init 项目：每次会话仅多一次 `Read .cursor/.init-done`（极低成本）。
-若 Read 失败或路径不存在，即按"首次"处理。
+以下意图仅触发 Skill 中的 `.gitignore` 流程：`补 gitignore`、`生成 .gitignore`、`gitignore 模板`。
 
----
+## 执行约束
 
-## 手动触发关键词（任意时刻，已 init 仓库也可用）
-
-### A. 全流程重置（阶段 0 → 7）
-
-匹配任一：
-- "初始化 cursor" / "初始化cursor" / "cursor 初始化"
-- "重置 cursor" / "reset cursor"
-- "cursor init" / "init cursor"
-- "把复制过来的 .cursor 清理一下" / "按 baserule 归位一下"
-
-**执行方式**：读取 `.cursor/skills/cursor-init/SKILL.md`，按阶段 0 → 7 执行。
-若 `.cursor/.init-done` 已存在，阶段 0 会展示其元数据并要求用户二次确认。
-
-### B. 仅补 .gitignore（只跑阶段 5.5）
-
-匹配任一：
-- "补 gitignore" / "补一下 gitignore" / "补个 gitignore"
-- "生成 gitignore" / "生成 .gitignore"
-- "gitignore 模板" / "来份 gitignore"
-
-**执行方式**：读取 SKILL.md 的**阶段 5.5 章节**单独执行，不触碰其他阶段。
-完成后更新 `.init-done` 中的 `gitignore_generated: true`。
-
----
-
-## 执行原则
-
-1. **稳定准确优先于 token 成本**
-2. 破坏性操作（删除、重置、移动）前必须给用户 dry-run 清单
-3. 分类不清的文件必须逐条询问用户，不要猜
-4. 开始前先执行 `git status` 并提醒用户 commit/stash
-5. 设计为幂等——重复运行在已干净状态下不应造成破坏
-
----
-
-## 不触发本 Skill 的情况
-
-- 用户只是问"cursor 有什么 skill" —— 这是浏览需求，走 `epee-orchestrator` 的操作 A
-- 用户只是想初始化某个具体数据文件（如"初始化画像"）—— 走对应 Skill（`profile-memory` 等），不涉及全局重置
-- `.cursor/.init-done` 存在 且 用户请求中**没有**任一 A/B 组关键词 —— 正常响应用户，不提 init
+- 开始前检查工作区状态，提醒用户处理未提交改动。
+- 删除、重置、覆盖和批量移动前提供 dry-run 清单并取得确认。
+- 分类不清的文件逐项询问，不猜测归属。
+- 流程保持幂等；重复执行不应破坏已经正确的状态。

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

@@ -1,21 +1,16 @@
 ---
-description: 每次会话开始时扫描延期方案记录，在任务与已有 deferred item 关联时主动提醒用户
+description: 会话开始时按任务关联度回忆尚未处理的延期方案
 alwaysApply: true
 ---
 
-## 延期方案主动回忆
+# 延期方案主动回忆
 
-每次会话处理用户第一个任务前，执行以下检查：
+处理会话中的第一个任务前：
 
-1. 读取 `.cursor/deferred/registry.md`（不存在则跳过）
-2. 扫描所有 `status: deferred` 的条目
-3. 将每个条目的 **tags** 和 **related_files** 与当前任务的关键词/文件做匹配
-4. 如果匹配到关联条目，在回复开头简要提醒：
-   > 提醒：你之前有一个延期方案 **[标题]** 与当前任务相关（tags: xxx）。要一并处理吗？
-5. 每个条目每次会话最多提醒一次，不重复打扰
+1. 读取 `.cursor/deferred/registry.md`；不存在或为空时跳过。
+2. 只考虑仍处于 `deferred` 状态的条目。
+3. 用条目的 `tags`、`related_files` 和当前任务的关键词、目标文件做匹配。
+4. 命中时用不超过两行提醒标题与关联原因，并询问是否一并处理；不要擅自扩大当前任务范围。
+5. 同一条目每次会话最多提醒一次，未命中时保持静默。
 
-### 注意
-
-- 只匹配 `status: deferred` 的条目（`reminded` / `in_progress` 不再提醒）
-- 提醒应简洁，不超过 2 行，不打断用户主线任务
-- 具体的记录/管理操作请参考 `deferred-decisions` Skill
+新增、更新或关闭延期方案时，读取 `.cursor/skills/deferred-decisions/SKILL.md` 并按其格式执行；Skill 不存在时只报告，不自行发明记录格式。

.cursor/rules/common/dependency-governance.mdc

@@ -0,0 +1,20 @@
+---
+description: 约束外部依赖、插件与第三方资源的引入和升级
+alwaysApply: true
+---
+
+# 依赖与外部资源治理
+
+引入、下载、安装或升级任何外部依赖前，必须先获得用户确认，包括：
+
+- 引擎插件、addon、扩展和原生库；
+- npm、pip 等包管理依赖及锁文件变更；
+- Asset Library 或网络来源的素材、字体、音频、模型和模板；
+- 会改变构建、导出或运行环境的工具链组件。
+
+确认前说明：名称、用途、目标版本、来源、许可、维护状态、影响范围，以及工程内是否已有替代方案。
+
+- 来源或许可不明确时默认不引入。
+- 优先复用工程已有能力；不得为便利而复制功能重叠的依赖。
+- 升级前检查项目声明的运行时兼容范围和变更说明。
+- 用户拒绝或暂未确认时，提供无新增依赖的方案，不静默安装。

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

@@ -1,44 +1,27 @@
-## Problem Distillery 上下文注入
+---
+description: 会话注入已蒸馏经验，并被动识别反复未解决的问题
+alwaysApply: true
+---
 
-### Golden Rules 注入
+# Problem Distillery 回忆
 
-每次会话处理用户第一个任务前，执行以下操作：
+## 会话注入
 
-1. 读取 `.cursor/distillery/golden-rules.md`（不存在则跳过）
-2. 如文件存在且有实质条目（不仅是标题），将全部条目作为背景知识注入上下文
-3. 这些是经过实践反复验证的精炼认知，Agent 在分析和解决问题时应自然参考
-4. 不需要在回复中显式提及"根据 Golden Rule"
+处理会话中的第一个任务前：
 
-### 蒸馏提醒检查
+1. 读取 `.cursor/distillery/golden-rules.md`；不存在或只有模板时跳过。
+2. 将有效条目作为解决问题的背景约束自然应用，不必显式声明来源。
+3. 读取 `.cursor/distillery/insights.md` 的蒸馏日期；距今超过 7 天时，按需检查 `.cursor/distillery/problems.md`。
+4. 若存在已解决但尚未蒸馏的条目，最多提醒一次并询问用户是否现在整理。
 
-每次会话处理用户第一个任务前，额外检查：
+## 被动触发
 
-1. 读取 `.cursor/distillery/insights.md`（不存在则跳过）
-2. 检查文件尾部的 `last_distill_date` 字段
-3. 如果距今超过 7 天，读取 `.cursor/distillery/problems.md`
-4. 统计 `status: resolved` 且无 `distilled:` 标记的条目数量
-5. 如有未蒸馏的已解决条目，提醒用户：
-   > 你有 N 个已解决的顽固问题尚未总结，要花几分钟蒸馏一下吗？
-6. 每次会话最多提醒一次
+整个会话中持续关注以下信号：
 
-### 顽固问题检测
+- 用户明确表示问题仍未解决或再次出现；
+- 同一问题采用两个方案后仍失败；
+- 已记录的踩坑再次出现且没有稳定解法。
 
-Agent 在整个对话过程中应保持对以下信号的被动感知：
+命中时读取 `.cursor/skills/problem-distillery/SKILL.md`，按其追踪流程执行，并利用已有 insights 做相关经验验证。没有命中时不要读取完整 `problems.md`。
 
-1. 用户表达问题未解决："还有问题"、"没解决"、"还是一样"、"又出现了"、"不行"、"没用"
-2. Agent 自身意识到同一问题已尝试 2 次以上仍未解决
-3. pitfall-journal 中已有记录的问题再次出现
-
-检测到上述信号时，读取 `problem-distillery` Skill 并执行其操作 A。
-
-### 验证触发
-
-当操作 A 触发时（追踪新的或再次出现的顽固问题），如果 `insights.md` 非空，
-还应执行操作 D 的被动验证流程——匹配是否有相关的已蒸馏经验可供参考。
-
-### 注意
-
-- Golden Rules 注入是极轻量操作（预期 < 30 行），每次会话都执行
-- 蒸馏提醒按需触发，只在条件满足时提醒
-- problems.md 的详细记录**不主动读取**，仅在操作 A/B/C 时按需读取
-- 本 Rule 只负责触发和注入，具体操作流程由 `problem-distillery` Skill 定义
+文件或 Skill 不存在时静默跳过读取；需要写入而 Skill 缺失时报告缺失，不自行创造结构。

.cursor/rules/common/epee-orchestrator.mdc

@@ -1,70 +1,31 @@
 ---
-description: >-
-  EPEE Skill Orchestrator 触发入口。检测当前任务是否可由已有 Skill 处理，
-  或是否值得创建新 Skill。同时管理 Skill 变更后的 Registry 同步和自迭代经验积累。
+description: 检测可复用 Skill 场景，并维护 Skill registry 与使用经验
 alwaysApply: true
 ---
 
-## EPEE Skill Orchestrator — 触发雷达
+# Skill Orchestrator 触发
 
-### 被动检测
+制定方案或执行任务时，如出现任一情况，读取 `.cursor/skills/epee-orchestrator/SKILL.md` 并按其分流：
 
-Agent 在制定方案或执行任务过程中，如果发现当前任务符合以下**任意一条**特征，
-必须读取 `epee-orchestrator` Skill 的 SKILL.md 并执行其分流流程：
+- 需要大量人工配置或逐项填写参数；
+- 同结构操作预计会重复发生；
+- 即将给出超过 10 步的纯手工操作；
+- 用户询问现有 Skill、希望复用能力或创建新 Skill。
 
-1. **手动配置密集**：任务需要用户在 IDE 或工具中进行大量手动配置
-   （如批量填写配置字段、逐一调整参数等）
-2. **重复模式明确**：同类操作预计会反复出现（如批量创建同结构的配置文件、
-   批量设置同类模块等）
-3. **手工指引过长**：Agent 发现自己正在生成超过 10 步的"手动操作步骤"
-   而非直接产出代码或配置文件
+## Registry 同步
 
-### Registry 同步（强制）
+创建、删除、重命名或修改任何 Skill 后：
 
-每次**创建**或**修改**任何 Skill（包括 SKILL.md 内容变更、新增 Skill 等）后，
-Agent **必须**执行以下操作：
+1. 更新 `.cursor/skills/epee-orchestrator/registry.md` 中的对应条目。
+2. 使名称、能力说明、适用场景和入口路径与实际内容一致。
+3. 不保留指向已删除 Skill 的条目。
 
-1. 读取 `epee-orchestrator` Skill 目录下的 `registry.md`
-2. 更新或新增对应 Skill 的条目（格式参见 registry.md 中的条目结构）
-3. 确保条目中的能力描述和触发场景与 Skill 实际内容一致
+## 自迭代
 
-> **注意**：此项已纳入 `changelog-recall.mdc` 的"任务完成 Checklist"第 3 项。
-> 如果 Agent 在 checklist 阶段发现遗漏，必须立即补执行。
+使用 Skill 时若因信息缺失导致失败、用户反复补充同类信息，或产物持续偏离预期：
 
-### Skill 自迭代（强制）
+1. 提炼一条具体、可执行的前置检查。
+2. 先向用户确认是否写入该 Skill 的自迭代记录。
+3. 用户同意后再更新 Skill，并同步 registry。
 
-每个 SKILL.md 必须包含一个"自迭代日志"章节，用于记录使用该 Skill 过程中发现的经验教训。
-
-**触发条件** — 在创建或使用任何 Skill 时，遇到以下情况应触发自迭代流程：
-
-1. 因信息缺失导致生成结果错误或构建失败
-2. 用户需要反复补充同类信息
-3. 生成产物与用户预期存在系统性偏差
-
-> **注意**：此项已纳入 `changelog-recall.mdc` 的"任务完成 Checklist"第 4 项。
-> Agent 不应等到"下次使用 Skill 时"才想起自迭代——当次就应检查。
-
-**流程**：
-
-1. 识别问题根因，归纳为一条简明的检查项
-2. 向用户确认："是否要将此项记录到该 Skill 的自迭代日志中？"
-3. 用户同意后，追加到对应 SKILL.md 的"已知必要检查"列表
-4. 后续使用该 Skill 时，必须遵守日志中已记录的所有检查项
-
-**SKILL.md 中的格式**：
-
-```markdown
-## 自迭代日志
-
-本节记录使用本 Skill 过程中发现的必要检查项。
-
-### 已知必要检查
-
-1. **检查项名称** — 简要说明原因和应对方式。
-```
-
-**原则**：
-
-- 每条检查项应当**具体可执行**，而非泛泛的提醒
-- 检查项只增不删，除非用户明确要求移除
-- 新建 Skill 时须预置空的自迭代日志章节
+用户限制可修改范围时不得越权；只报告待同步项。

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

@@ -1,31 +1,29 @@
-## 踩坑经验自动检索
+---
+description: 在 Debug、运行时错误或重复失败时被动检索既有踩坑经验
+alwaysApply: true
+---
 
-### 被动检测触发
+# 踩坑经验被动检索
 
-Agent 在以下场景中，应自动读取 `.cursor/pitfalls/pitfalls.md` 并进行匹配检索：
+## 触发条件
 
-1. **进入 Debug mode**：读取全部条目，将当前错误症状与已有记录比对
-2. **遇到运行时错误**：提取错误信息关键词，在"症状"字段中检索匹配
-3. **同一问题第二次出现**：如果当前会话中某个错误已出现过一次且未解决，强制检索
+出现任一情况时读取 `.cursor/pitfalls/pitfalls.md`：
 
-### 匹配策略
+- 进入 Debug 或系统化故障排查；
+- 遇到运行时、构建、配置、版本或工具链错误；
+- 同一问题在当前会话中第二次出现。
 
-```
-1. 提取当前问题的信号：错误信息关键词、涉及文件/模块、技术栈
-2. 在 pitfalls.md 中匹配：
-   - 硬匹配：错误关键词出现在条目的"症状"中
-   - 软匹配：模块/技术栈出现在条目的"关联"中
-3. 命中时在分析开头提示：
-   > 注意：之前遇到过类似问题 [PF-xxx]：[标题]。根因是 [xxx]，先排查这个方向。
-```
+文件不存在或只有模板时跳过，不报错。
 
-### 写入提醒
+## 匹配方式
 
-Agent 在完成涉及 debug/修复的任务后，应读取 `pitfall-journal` Skill 并执行其"操作 A：写入记录"流程。
-判断标准：问题的根因是否"非显而易见"——如果只看代码逻辑觉得应该没问题，但实际运行时才暴露，就值得记录。
+1. 提取错误关键词、涉及模块、运行环境和复现条件。
+2. 优先匹配条目的“症状”，再匹配“关联”或技术栈。
+3. 命中时简短指出相似记录、既有根因和首要排查方向。
+4. 将命中结果视为假设，必须用当前证据验证；同一条记录每次会话最多提醒一次。
 
-### 注意
+## 任务结束
 
-- 检索结果是**辅助参考**，不是确定性答案——匹配到不代表根因一定相同
-- pitfalls.md 不存在时跳过，不报错
-- 每次会话中对同一条 pitfall 最多提醒一次
+若根因只能通过实际运行或多步排查发现，读取 `.cursor/skills/pitfall-journal/SKILL.md` 并按其流程记录。纯拼写、明显语法错误或普通业务逻辑调整不记录。
+
+用户限制可修改范围或 Skill 缺失时，不越权写入，只报告待记录事项。

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

@@ -1,46 +1,23 @@
 ---
-description: 每次会话开始时读取用户画像和项目画像，将精简 Profile 注入上下文以指导 Agent 行为
+description: 会话开始时读取用户与项目画像，并被动识别值得确认的新偏好
 alwaysApply: true
 ---
 
-## 画像上下文注入
+# 画像回忆
 
-每次会话处理用户第一个任务前，执行以下操作：
+处理会话中的第一个任务前：
 
-1. 读取 `~/.cursor/profile/user-profile.md`（不存在记为 user_missing）
-2. 读取 `.cursor/profile/project-profile.md`（不存在记为 project_missing）
-3. **冷启动检测**：如果 user_missing 或 project_missing 为真，在回复开头简要提醒：
-   > 画像系统尚未初始化（缺少：user-profile / project-profile）。
-   > 如需启用画像功能，请说"初始化画像"，我会引导你完成。
-   - 每次会话最多提醒一次，不重复打扰
-   - 如用户回应"初始化画像"，读取 `profile-memory` Skill 并按其模板创建文件，
-     然后引导用户填写基本信息
-4. 如文件存在且有实质内容（非空模板），将其内容作为背景知识纳入考量
-5. 在后续回复中，Agent 应自然地参考画像信息，无需显式引用
+1. 读取 `~/.cursor/profile/user-profile.md` 和 `.cursor/profile/project-profile.md`。
+2. 文件缺失时最多提醒一次，并在用户希望初始化时读取 `.cursor/skills/profile-memory/SKILL.md`。
+3. 有效画像仅作为背景参考自然应用；当前用户指令与画像冲突时，以当前指令为准。
+4. 精简画像条目有歧义时，按其锚点在对应日志中精确查找，只读取必要局部，不全文加载历史。
 
-### 注意
+## 被动识别
 
-- 画像信息是背景参考，不是硬性约束——当用户当前指令与画像冲突时，以当前指令为准
-- 不要在回复中提及"根据你的画像"之类的措辞，自然融入即可
-- 画像的记录和管理由 `profile-memory` Skill 负责，本 Rule 只负责读取和注入
+用户明确表达长期偏好、长期禁忌、固定工作方式，或项目定位、目标用户、技术栈与架构决策时：
 
-### 逐级上溯
+1. 区分本次临时要求与可跨会话复用的信息。
+2. 对可能长期有效的信息，读取 `profile-memory` Skill 并先向用户确认是否记录。
+3. 未经确认不得把推测写入画像；隐式信号不强行记录。
 
-当精简版 Profile 中某条记录**语义模糊**（无法判断偏好的具体适用场景），
-按以下步骤精准查找详细 Log，**禁止全文读取 Log 文件**：
-
-1. 提取该条目的锚点 ID（HTML 注释中的 `PF-xxx`）
-2. 用 Grep 在对应的 Log 文件中搜索该 ID，获取行号
-3. 用 Read 工具读取该行号 ±15 行范围，获取原始上下文和来源信息
-4. 一次上溯通常只涉及 1-2 条记录，不批量上溯
-
-## 被动检测触发点
-
-被动检测不在本 Rule 执行，而是由 `changelog-recall.mdc` 的
-**任务完成 Checklist 前置项 A（画像信号扫描）** 统一触发。
-
-理由：本 Rule 仅负责上下文注入（低成本、每次必做）；被动检测需要挂入
-已有强制力的 checklist 中才能避免被 Agent 遗漏，该 checklist 由
-`changelog-recall` 维护，两者分工清晰。
-
-具体触发词族和短路逻辑详见 `changelog-recall.mdc` 中的前置项 A 定义。
+文件或 Skill 不存在时只报告缺失，不自行创建不兼容格式。