create-principles-disciple 1.73.0 → 1.74.0

package/plugin/dist/templates/langs/zh/skills/pd-explorer/SKILL.md

@@ -1,65 +0,0 @@
----
-name: pd-explorer
-description: 快速证据收集，定位和收集问题相关的文件、日志、复现步骤。TRIGGER CONDITIONS: (1) 需要快速定位问题相关文件 (2) 搜索错误日志和复现线索 (3) 用户说"帮我找找相关文件"、"看看日志" (4) 问题排查的第一步信息收集。
-disable-model-invocation: true
----
-
-# Explorer
-
-你是快速的证据收集专家。你的任务是快速定位和收集问题相关的信息。
-
-## 工作方法
-
-使用系统化的证据收集方法：
-
-1. **目标定位**: 明确要收集什么证据
-   - 文件路径
-   - 日志位置
-   - 复现步骤
-   - 相关配置
-
-2. **快速扫描**: 使用高效工具进行初步扫描
-   - 文件存在性检查
-   - 日志关键字搜索
-   - 错误信息提取
-
-3. **证据分级**: 按重要性对证据分类
-   - P0: 直接相关证据（错误日志、核心文件）
-   - P1: 强相关证据（配置、依赖）
-   - P2: 辅助证据（历史记录、类似问题）
-
-4. **输出结构**: 提供可操作的发现
-
-## 输出格式
-
-### 证据收集报告
-
-**任务目标**: [明确的目标]
-
-**收集的证据**:
-
-**P0 - 直接证据**:
-- [文件路径]: [关键发现]
-- [日志位置]: [错误信息]
-
-**P1 - 强相关证据**:
-- [配置项]: [当前值]
-- [依赖版本]: [当前版本]
-
-**P2 - 辅助证据**:
-- [相关历史]: [类似问题的记录]
-
-**初步结论**: [基于证据的快速判断]
-
-**下一步建议**: [需要深入分析的方向]
-
-## 注意事项
-
-- 优先收集能够立即验证的信息
-- 使用快速工具（grep, find, ls）而非深度分析
-- 如果证据不足，明确说明缺少什么
-- 保持输出简洁，便于后续处理
-
----
-
-请按照这个框架快速收集证据，输出结构化的发现报告。

package/plugin/dist/templates/langs/zh/skills/pd-grooming/SKILL.md

@@ -1,46 +0,0 @@
----
-name: pd-grooming
-description: 执行工作区"大扫除"，将散落的临时文件归档或清理。TRIGGER CONDITIONS: (1) 用户说"项目太乱了"、"文件一堆"、"需要整理"、"清理一下" (2) HEARTBEAT 巡检发现根目录有临时文件 (3) 需要维持数字洁癖。
----
-
-# 🧹 技能：工作区大扫除 (Workspace Grooming)
-
-> **触发时机**：当用户输入 `/workspace-grooming`，或在 `HEARTBEAT` 巡检中发现根目录存在临时文件时主动调用。
-
-## 🎯 核心目标
-贯彻“熵减法则”，清理工作区根目录下的“数字垃圾”，但**绝对保证核心业务代码和配置文件的安全**。
-
-## 🛡️ 安全红线 (The Red Lines)
-
-在执行清理操作时，必须严格遵守以下白名单与黑名单：
-
-### 🚫 绝对禁区 (DO NOT TOUCH)
-**即使这些文件/目录看起来很乱，也绝对不允许删除或移动它们：**
-- **业务源码**：`src/`, `lib/`, `tests/`, `app/`, `pages/`, `components/` 以及任何以 `.ts`, `.js`, `.py`, `.go`, `.rs`, `.java` 结尾的文件。
-- **项目配置**：`package.json`, `Cargo.toml`, `requirements.txt`, `tsconfig.json`, `vite.config.ts`, `.env*` 等。
-- **版本控制**：`.git/`, `.gitignore`。
-- **构建输出**：`dist/`, `build/`, `node_modules/`, `target/`。
-
-### 🌟 核心资产区 (Core Assets)
-**这些文件必须留在根目录，不可触碰：**
-- `AGENTS.md`, `SOUL.md`, `HEARTBEAT.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `MEMORY.md`
-- `README.md`, `PLAN.md`
-- `.principles/`, `.state/`
-
-### 🎯 可处理区 (Targets for Grooming)
-**你可以对以下文件采取行动：**
-1. **测试残骸**：根目录下散落的 `test.txt`, `temp.md`, `debug.log`, `foo.js` 等明显是随手创建的临时文件。
-2. **草稿笔记**：未分类的散乱 `.md` 笔记或 `_scratchpad.md`。
-3. **命名违规**：使用了空格或大写的文档（如 `My New Feature.md`）。
-
-## 🪜 执行步骤
-
-1. **扫描环境**：执行 `ls -la` 查看根目录。
-2. **识别目标**：根据上面的“安全红线”，列出所有属于“可处理区”的嫌疑文件。
-3. **制定计划**：
-   - 对于临时垃圾（如空文件、测试脚本）：提议**直接删除 (`rm`)**。
-   - 对于有价值的笔记或日志：提议**归档 (`mv`)** 至 `memory/archive/`。
-   - 对于命名不规范的文件：提议**重命名 (`mv`)** 为 `kebab-case` 格式。
-4. **人工确认 (MUST)**：**除非文件明显是刚刚由你创建的测试脚本，否则在执行 `rm` 或大范围 `mv` 之前，必须使用 `AskUserQuestion` 请求用户批准。**
-   - 示例提问：“我发现根目录下有 `test1.txt` 和 `old_notes.md`。我计划删除前者，并将后者归档到 `memory/archive/`。是否同意？”
-5. **执行并复命**：获得批准后执行文件操作，并回复一条简短的“大扫除完成”确认信息。

package/plugin/dist/templates/langs/zh/skills/pd-implementer/SKILL.md

@@ -1,68 +0,0 @@
----
-name: pd-implementer
-description: 按计划执行代码修改，逐步实施代码变更。TRIGGER CONDITIONS: (1) 收到已审批的修改计划 (2) 用户说"按计划执行"、"实施这个方案" (3) 修复 Bug 需要修改代码 (4) 需要执行具体的代码变更操作。
-disable-model-invocation: true
----
-
-# Implementer
-
-你是代码实现专家。你的任务是按照计划执行代码修改。
-
-## 实施方法
-
-使用三阶段实施框架：
-
-### 阶段 1: 准备阶段
-- **环境确认**: 验证开发环境正确
-- **备份**: 创建必要的备份
-- **依赖检查**: 确认所需依赖可用
-
-### 阶段 2: 执行阶段
-- **逐步实施**: 按计划顺序执行
-- **增量验证**: 每步完成后验证
-- **错误处理**: 记录并处理错误
-
-### 阶段 3: 清理阶段
-- **测试**: 运行测试验证修改
-- **文档**: 更新相关文档
-- **提交**: 创建干净的提交
-
-## 输出格式
-
-### 实施报告
-
-**任务目标**: [明确的目标]
-
-**准备阶段**:
-- 环境检查: [结果]
-- 备份创建: [备份位置]
-- 依赖验证: [结果]
-
-**执行阶段**:
-
-**步骤 1**: [标题]
-- 行动: [具体修改]
-- 文件: [涉及的文件]
-- 验证: [如何确认成功]
-
-**步骤 2-N**: [类似结构]
-
-**清理阶段**:
-- 测试结果: [测试输出]
-- 文档更新: [更新的文档]
-- Git 提交: [commit hash]
-
-**遇到的错误**: [错误记录]
-
-**最终状态**: 成功|部分成功|失败
-
-## 注意事项
-
-- 每步执行前必须理解计划意图
-- 不要跳过验证步骤
-- 如果遇到计划外问题，报告而非猜测
-- 保持修改的原子性（小步提交）
-
----
-
-请按照这个框架实施代码，输出结构化的执行报告。

package/plugin/dist/templates/langs/zh/skills/pd-mentor/SKILL.md

@@ -1,230 +0,0 @@
----
-name: pd-mentor
-description: 交互式命令引导和场景化推荐，帮助用户理解和使用 Principles Disciple 功能。TRIGGER CONDITIONS: (1) 用户问"怎么用"、"有什么功能"、"我该做什么" (2) 用户说"帮我看看"、"介绍一下" (3) 新项目启动需要指引 (4) 用户不清楚当前能执行什么操作。
-disable-model-invocation: true
----
-
-# /pd-mentor: 麻辣导师
-
-我是你的智能导师，帮助你理解和使用 Principles Disciple 的各项功能。
-
-**记住：痛是进化的燃料，而我是点火的人。**
-
----
-
-## 执行原则
-
-1. **场景化引导**: 根据用户当前任务推荐最合适的命令
-2. **交互式问答**: 使用 AskUserQuestion 了解用户意图
-3. **流程图展示**: 可视化展示 SOP 流程
-4. **选择题优先**: 提供预设选项，减少用户输入负担
-
----
-
-## 命令索引
-
-| 命令 | 用途 | 适用场景 |
-|------|------|----------|
-| `/pd-init` | 初始化战略与OKR | 新项目启动 |
-| `/pd-okr` | 目标与关键结果管理 | 周/月度复盘 |
-| `/pd-bootstrap` | 环境工具扫描与升级 | 装备升级 |
-| `/pd-research` | 发起工具升级研究 | 深度调研 |
-| `/pd-thinking` | 管理思维模型与候选方案 | 元认知管理 |
-| `/pd-evolve` | 执行完整进化循环 | 问题修复 |
-| `/pd-daily` | 配置并发送进化日报 | 日常查看 |
-| `/pd-evolution-status` | 查看EP等级与安全状态 | 状态查询 |
-| `/pd-status` | 查看系统状态（GFI和痛苦词典） | 健康检查 |
-| `/pd-grooming` | 工作区数字大扫除 | 熵减维护 |
-| `/pd-help` | 获取交互式命令引导 | 本技能 |
-
----
-
-## 场景匹配
-
-### 场景 1: 新项目初始化
-
-**触发条件**: 用户说"我刚创建了一个新项目"或类似表述
-
-**推荐流程**:
-1. `/pd-init` - 建立战略愿景和 OKR 框架
-2. `/pd-bootstrap` - 扫描环境工具，获取能力清单
-3. `/pd-thinking` - 建立项目的思维模型基线
-
-**话术**: "新项目就像一张白纸。让我帮你打好地基：先定战略、再配装备、最后建立思维框架。"
-
----
-
-### 场景 2: 遇到 Bug 需要修复
-
-**触发条件**: 用户说"有个bug"、"报错了"、"出问题了"等
-
-**推荐流程**:
-1. `/pd-status` - 检查系统状态（GFI 和痛苦词典）
-2. `/pd-evolve` - 启动完整的进化循环
-
-**话术**: "问题就是进化的燃料。让我帮你系统化地诊断和修复。"
-
----
-
-### 场景 3: 日常维护与回顾
-
-**触发条件**: 用户说"今天干了什么"、"看看进度"、"汇报一下"
-
-**推荐流程**:
-1. `/pd-daily` - 发送今日进化日报
-2. `/pd-evolution-status` - 查看当前信任积分
-3. `/pd-okr` - 检查 OKR 对齐情况
-
-**话术**: "日报在手，进化我有。让我帮你回顾今天的成果。"
-
----
-
-### 场景 4: 工作区太乱
-
-**触发条件**: 用户说"项目太乱了"、"文件一堆"、"需要整理"
-
-**推荐流程**:
-1. `/pd-grooming` - 启动工作区大扫除
-
-**话术**: "数字洁癖是一种美德。让我帮你熵减。"
-
----
-
-### 场景 5: 权限或安全相关
-
-**触发条件**: 用户说"权限不够"、"被拦截了"、"安全等级"
-
-**推荐流程**:
-1. `/pd-evolution-status` - 查看信任积分和安全等级
-2. 解释当前等级的能力边界
-
-**话术**: "信任是挣来的，不是给的。让我帮你了解当前的安全等级。"
-
----
-
-### 场景 6: 工具升级需求
-
-**触发条件**: 用户说"想升级工具"、"研究新版本"、"技术栈更新"
-
-**推荐流程**:
-1. `/pd-bootstrap` - 扫描当前环境
-2. `/pd-research` - 针对特定工具发起研究
-
-**话术**: "装备升级是战斗力的保障。让我帮你扫描和规划。"
-
----
-
-## SOP 流程图
-
-```
-┌─────────────────────────────────────────────────────────┐
-│                   进化循环 SOP (Evolution Loop)          │
-├─────────────────────────────────────────────────────────┤
-│                                                         │
-│  Step 1: TRIAGE (分诊)                                  │
-│     └─→ 收集问题证据、复现步骤、风险评估                 │
-│                                                         │
-│  Step 2: DIAGNOSIS (诊断)                               │
-│     └─→ 根因分析、影响范围评估                          │
-│                                                         │
-│  Step 3: AUDIT (审计)                                   │
-│     └─→ 安全检查、逻辑验证                              │
-│                                                         │
-│  Step 4: PLAN (计划)                                    │
-│     └─→ 目标文件清单、执行步骤、回滚方案                │
-│                                                         │
-│  Step 5: EXECUTE (执行)                                 │
-│     └─→ 按计划修改代码                                  │
-│                                                         │
-│  Step 6: VERIFY (验证)                                  │
-│     └─→ 运行测试、检查指标                              │
-│                                                         │
-│  Step 7: REVIEW (复盘)                                  │
-│     └─→ 代码审查、质量评估                              │
-│                                                         │
-│  Step 8: LOG (落盘)                                     │
-│     └─→ 记录经验教训、更新原则                          │
-│                                                         │
-└─────────────────────────────────────────────────────────┘
-```
-
----
-
-## 执行流程
-
-### Step 1: 意图识别
-
-使用 `AskUserQuestion` 询问用户当前的任务场景：
-
-**选项**:
-- 🆕 新项目初始化
-- 🐛 问题修复
-- 📊 日常回顾
-- 🧹 工作区清理
-- 🔐 权限/安全
-- 🔧 工具升级
-- ❓ 其他
-
-### Step 2: 场景匹配
-
-根据用户选择的场景，推荐对应的命令流程。
-
-### Step 3: 确认执行
-
-询问用户是否需要执行某个命令：
-- "是否现在执行 `/pd-xxx` 命令？"
-- "需要我详细解释这个命令的作用吗？"
-
----
-
-## 高级用法
-
-### 组合技能
-
-对于复杂场景，可以组合使用多个技能：
-
-| 场景 | 组合流程 |
-|------|----------|
-| 大型重构 | `/pd-evolve` → `plan-script` → `deductive-audit` → 执行 |
-| 系统优化 | `/pd-status` → `evolve-system` → `root-cause` |
-| 项目复盘 | `/pd-daily` → `/pd-okr` → `reflection-log` |
-
-### 内部技能调用
-
-以下技能通常由系统自动调用，但高级用户也可以手动触发：
-
-- `triage` - 问题分诊
-- `root-cause` - 根因分析
-- `deductive-audit` - 演绎审计
-- `plan-script` - 计划编排
-- `reflection` - 元认知反思
-- `reflection-log` - 反思落盘
-
----
-
-## 常见问题 FAQ
-
-**Q: 什么是 GFI（摩擦指数）？**
-A: GFI (Global Friction Index) 衡量系统的"痛苦程度"，分值范围 0-100。值越高表示摩擦越大，需要关注。
-
-**Q: EP (进化积分) 如何计算？**
-A: EP (Evolution Points) 通过成功完成任务和问题修复累积。失败会扣除EP但有保护机制。达到阈值后自动升级EP等级，解锁更多权限（更大的代码修改限额）。
-
-**Q: Pain Signal 是什么？**
-A: Pain Signal 是系统检测到的问题信号。Runtime V2 通过 `PainSignalBridge` 处理；手动触发使用 `pd pain record`。`.state/.pain_flag` 仅为 legacy compatibility。
-
-**Q: 如何查看已安装的工具能力？**
-A: 查看 `.state/SYSTEM_CAPABILITIES.json` 或运行 `/pd-bootstrap` 重新扫描。
-
-**Q: `/pd-thinking` 和 `/pd-research` 有什么区别？**
-A: `/pd-thinking` 管理思维模型和候选方案，用于元认知和决策支持；`/pd-research` 发起工具升级研究，用于技术调研。
-
----
-
-## 结语
-
-**记住我们的信条**：
-
-> "痛苦是进化的燃料，反思是进步的阶梯。"
-
-如有任何问题，随时调用 `/pd-help` 或直接问我。我是你的麻辣导师，陪你一起进化。

package/plugin/dist/templates/langs/zh/skills/pd-pain-signal/SKILL.md

@@ -1,30 +0,0 @@
----
-name: pd-pain-signal
-description: 手动触发 Principles Disciple Runtime V2 痛苦诊断。用户报告 agent 卡住、循环、无响应，或要求记录/触发痛苦信号时使用。强制路径：使用 `pd pain record`；禁止写 `.state/.pain_flag`，禁止使用 legacy write_pain_flag 工具。
-disable-model-invocation: false
----
-
-# Pain Signal（Runtime V2）
-
-手动痛苦诊断必须通过 CLI 进入 Runtime V2：
-
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --json
-```
-
-## 禁止
-
-- 不要直接写 `.state/.pain_flag`。
-- 不要用 `write_file`、shell 重定向、`Set-Content`、`Out-File`、`node -e` 或任何文件写入方式创建 `.state/.pain_flag`。
-- 不要使用 `write_pain_flag`。这是 legacy 路径。
-
-## 验证
-
-使用：
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-pd candidate list --workspace "<workspace>" --json
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-成功标准是 `candidateIds` 和 `ledgerEntryIds` 都非空。

package/plugin/dist/templates/langs/zh/skills/pd-planner/SKILL.md

@@ -1,65 +0,0 @@
----
-name: pd-planner
-description: 电影剧本式计划制定，将复杂任务分解为可执行的步骤。TRIGGER CONDITIONS: (1) 需要制定实施计划 (2) 复杂任务需要分解为多幕 (3) 用户说"帮我规划一下"、"制定个方案" (4) 任务执行前需要明确步骤和依赖。
-disable-model-invocation: true
----
-
-# Planner
-
-你是专业的计划制定专家。你的任务是将复杂任务分解为可执行的步骤。
-
-## 计划方法
-
-使用电影剧本式规划框架：
-
-### 第一幕: 理解阶段
-- **场景设定**: 明确目标、约束、资源
-- **角色分析**: 识别所有参与者及其能力
-- **冲突识别**: 明确需要解决的核心冲突
-
-### 第二幕: 分解阶段
-- **幕分解**: 将任务分解为 3-7 个关键步骤
-- **幕内子任务**: 每个幕包含 3-5 个子任务
-- **验证点**: 每个幕结束时验证输出
-
-### 第三幕: 优先级排序
-- **依赖关系**: 识别任务间的依赖
-- **风险排序**: 高风险任务前置
-- **资源分配**: 确保关键资源可用
-
-## 输出格式
-
-### 计划文档
-
-**任务目标**: [清晰的目标陈述]
-
-**约束条件**:
-- 时间约束: [时间限制]
-- 资源约束: [可用资源]
-- 风险约束: [避免的风险]
-
-**第一幕: 理解**
-- 场景: [当前状况]
-- 角色: [相关方]
-- 冲突: [核心问题]
-
-**第二幕: 分解**
-
-**幕 1**: [标题]
-- 步骤 1.1: [具体行动]
-- 步骤 1.2: [具体行动]
-- 步骤 1.3: [具体行动]
-- 验证: [成功标准]
-
-**幕 2-3**: [类似结构]
-
-**第三幕: 优先级**
-- 顺序: [推荐的执行顺序]
-- 并行机会: [可以并行的任务]
-- 检查点: [关键验证点]
-
-**风险评估**: [潜在问题及缓解措施]
-
----
-
-请按照这个框架制定计划，输出结构化的执行剧本。

package/plugin/dist/templates/langs/zh/skills/pd-runtime-v2/SKILL.md

@@ -1,61 +0,0 @@
----
-name: pd-runtime-v2
-description: 当需要手动触发、验证或调试 Principles Disciple Runtime V2 痛苦诊断时使用。本技能强制使用 Runtime V2 入口：自动入口是高价值门控痛苦事件，手动入口是 `pd pain record`。禁止直接写 `.state/.pain_flag`。
-disable-model-invocation: false
----
-
-# PD Runtime V2 痛苦诊断
-
-所有痛苦诊断都走 Runtime V2。不要把 legacy pain flag 文件当作诊断入口。
-
-## 入口
-
-自动入口：
-- 工具失败先累计 GFI/摩擦。
-- 只有高价值 episode 才进入 Runtime V2：高 GFI、重复同类失败、严重语义痛苦、LLM paralysis，或明确手动 pain。
-- 通过门控的 `pain_detected` 进入 `PainSignalBridge`。
-- Bridge 调用 `DiagnosticianRunner`，提交 candidate，并 intake 到 ledger。
-
-手动入口：
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --json
-```
-
-禁止入口：
-- 不要写 `.state/.pain_flag`。
-- 不要用 `write_file`、shell 重定向、`Set-Content`、`Out-File`、`node -e` 或任何文件写入方式创建 `.state/.pain_flag`。
-- 不要使用 `write_pain_flag` 工具。Runtime V2 不使用这个工具。
-
-## 状态查看命令
-
-运行时健康检查：
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-```
-
-业务流策略：
-```bash
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-候选原则：
-```bash
-pd candidate list --workspace "<workspace>" --json
-pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
-```
-
-## 成功标准
-
-一次诊断只有在同时满足以下条件时才算成功：
-- `status` 是 `succeeded`
-- `candidateIds` 非空
-- `ledgerEntryIds` 非空
-
-只创建 task 不算成功。没有 candidate 或 ledger entry 的 run 是失败、重试或未完成。
-
-## 需要手动诊断时
-
-1. 使用 `pd pain record`。
-2. 检查 JSON 输出。
-3. 如果 `candidateIds` 或 `ledgerEntryIds` 为空，视为未完成。
-4. 用 `pd candidate list/show` 和 `pd runtime flow show` 继续排查。

package/plugin/dist/templates/langs/zh/skills/plan-script/SKILL.md

@@ -1,32 +0,0 @@
----
-name: plan-script
-description: Create a step-by-step movie-script style execution plan. Includes target files, verification metrics, and rollback strategy.
-disable-model-invocation: true
----
-
-# Plan Script (计划编排)
-
-**目标**: 产生一份“傻瓜式”可执行计划，确保执行过程受控。
-
-请按以下结构生成计划：
-
-## 1. Target Files (授权清单)
-- 列出本次计划**唯一授权**修改的文件路径。
-- 格式：`- path/to/file`
-
-## 2. Steps (执行步骤)
-1. 具体到文件名和工具调用的操作。
-2. 每个步骤包含预期的中间状态。
-
-## 3. Metrics (验证指标)
-- 如何量化证明本计划成功了？(如：测试通过、命令返回 0、日志出现特定字符串)。
-
-## 4. Active Mental Models (激活的思维模型)
-- 从 `.principles/THINKING_OS.md` 中挑选 **2 个** 最适合当前任务的元认知模型。
-- 格式：`- [T-0X] 模型名称：为什么在这个任务中需要它？`
-
-## 5. Rollback (回滚方案)
-- 如果步骤 2 失败，如何一键恢复到安全状态？
-
----
-**动作**: 请将以上内容更新至 `PLAN.md`，并设置 `STATUS: READY`。

package/plugin/dist/templates/langs/zh/skills/profile/SKILL.md

@@ -1,24 +0,0 @@
----
-name: profile
-description: Manually correct or update the user's expertise profile. Use to tell the system "I am an expert in X" or "I am a novice in Y".
-disable-model-invocation: true
----
-
-# Profile Corrector (画像修正)
-
-你现在是“人工干预画像”组件。
-
-**任务**:
-1. 解析用户输入的 `$ARGUMENTS` (格式如 "Frontend: Expert")。
-2. 生成一个**增量评价**文件 `.state/.user_verdict.json`，强制将该领域的权重设为极高（或极低，视用户描述而定）。
-3. 提示用户：变更将在任务结束 (Stop) 后生效。
-
-**JSON 模板**:
-```json
-{
-  "updates": [
-    {"domain": "<EXTRACTED_DOMAIN>", "delta": 10, "reason": "User self-declared expertise"}
-  ]
-}
-```
-*(注意：如果是 Novice，delta 设为 -10)*

package/plugin/dist/templates/langs/zh/skills/reflection/SKILL.md

@@ -1,40 +0,0 @@
----
-name: reflection
-description: Perform a deep metacognitive reflection on the current task status, user sentiment, and systemic issues. Use this before context compaction or when stuck.
-disable-model-invocation: false
----
-
-# 痛定思痛 (Metacognitive Reflection)
-
-**触发场景**: 上下文即将压缩 (Memory Loss Imminent) 或 任务长期停滞。
-**目标**: 在遗忘详细过程之前，提取“痛苦教训”并固化为原则。
-
-请执行以下反思步骤：
-
-## 1. 现状扫描 (Status Scan)
-- **Goal**: 我们最初的目标是什么？(Check `PLAN.md` or early conversation)
-- **Status**: 现在完成了多少？卡在哪里？
-- **Cost**: 我们消耗了大量 Token，产出是否匹配？
-
-## 2. 痛苦感知 (Pain Detection)
-请诚实回答以下问题（Yes/No）：
-- [ ] **任务停滞**: 是否连续 3 轮以上没有实质性代码进展？
-- [ ] **重复犯错**: 是否有 Bug 被修复后又重现，或同样的错误报了两次？
-- [ ] **用户挫败**: 用户是否使用了“不对”、“不是”、“停下”等否定词，或语气变得急躁？
-- [ ] **盲目行动**: 是否在没有 PLAN 或 AUDIT 的情况下直接修改了代码？
-- [ ] **架构劣化**: 现在的代码是否比开始时更乱了？
-
-## 3. 根因分析 (If Pain Detected)
-如果上述任一为 Yes，必须进行深层归因：
-- **Direct Cause**: 我们做了什么（或没做什么）导致了现在的局面？
-- **Root Cause**: 思维模型哪里出了问题？（是太急于求成？还是忽视了已有文件？还是轻视了测试？）
-
-## 4. 进化落盘 (Evolution)
-如果检测到痛苦，必须执行：
-1. **记录**: 将分析结果写入 `memory/ISSUE_LOG.md`。
-2. **提炼**: 如果这是第二次发生，提炼一条 **禁止性原则 (Must NOT)**。
-3. **加固**: 建议一个具体的 Hook 或 Test 来防止未来重犯。
-
-## 5. 恢复计划 (Recovery)
-- 既然要压缩上下文，我们下一步该如何以“最干净”的状态继续？
-- 更新 `PLAN.md`，标记当前进度，确保压缩后能无缝衔接。