create-principles-disciple 1.0.0 → 1.74.0

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

@@ -0,0 +1,283 @@
+---
+name: pd-daily
+description: 配置并发送每日进化日报。TRIGGER CONDITIONS: (1) 用户问"今天做了什么"、"汇报一下"、"发个日报" (2) 需要配置定时发送渠道 (3) 首次运行引导配置 (4) 已配置时直接生成发送日报。
+disable-model-invocation: true
+---
+
+# 进化日报
+
+智能体通过此技能帮助用户配置并自动发送每日进化报告，让用户感知系统"每天都在进步"。
+
+## 执行原则
+
+1. 首次运行必须与用户确认需求
+2. 用户偏好存储在 `{stateDir}/daily-report.md`，已存在则跳过采集
+3. 使用 OpenClaw 的 cron 工具创建定时任务
+4. 自主选择可用的发送渠道
+
+---
+
+## 流程
+
+### Step 1: 检查配置文件
+
+读取 `{stateDir}/daily-report.md`：
+- **已存在** → 检查 cron 任务状态，执行日报生成
+- **不存在** → 进入需求采集流程
+
+### Step 2: 需求采集（首次运行）
+
+通过会话对话依次询问：
+
+1. **是否启用进化日报？**
+2. **发送时间？**（默认每天 23:00 UTC）
+3. **时区？**（默认 UTC）
+4. **发送渠道？**
+   - 📱 **飞书** → 需用户 open_id（推荐，格式：ou_xxx）
+   - 邮件 → 需邮箱地址
+   - WhatsApp/Telegram → 需手机号/用户ID
+   - Discord/Slack → 需频道ID
+   - 语音通知 → 需手机号
+5. **报告风格？**（参考下方"风格选项"）
+6. **内容偏好？** 选择包含哪些模块
+
+### Step 3: 创建配置文件
+
+将用户偏好写入 `{stateDir}/daily-report.md`：
+
+```markdown
+# 进化日报配置
+
+## 基本信息
+- 启用状态: 是
+- 创建时间: {date}
+
+## 发送设置
+- 发送时间: 23:00
+- 时区: UTC
+- Cron 表达式: 0 23 * * *
+
+## 发送渠道
+- 渠道: feishu
+- 目标: ou_cf5c98aada743ab12c65c7c6764b5a49
+
+## 报告风格
+- 风格: standard
+- 语言: zh
+
+## 内容偏好
+- 成长亮点: 是
+- 痛苦信号: 是
+- 趋势对比: 是
+- 洞察建议: 是
+
+## Cron 任务
+- jobId: {创建后自动填充}
+```
+
+### Step 4: 创建 Cron 任务
+
+使用 cron 工具：
+
+```json
+{
+  "action": "add",
+  "job": {
+    "name": "evolution-daily-report",
+    "schedule": { "kind": "cron", "expr": "0 23 * * *", "tz": "UTC" },
+    "sessionTarget": "isolated",
+    "payload": {
+      "kind": "agentTurn",
+      "message": "执行进化日报技能：读取日志数据，生成日报并发送"
+    },
+    "delivery": { "mode": "announce", "channel": "feishu", "to": "ou_cf5c98aada743ab12c65c7c6764b5a49" }
+  }
+}
+```
+
+### Step 5: 日报生成（定时触发或手动触发）
+
+1. **读取定量数据**：获取 `daily-stats.json` 和 `pain_dictionary.json` 中的指标。
+2. **提取定性记忆（关键防遗忘步骤）**：因为你可能经历了漫长的上下文，**必须使用文件读取工具**去扫描以下核心进化文件，提取"今天"新增的内容：
+   - `memory/ISSUE_LOG.md`：寻找今天发生的具体错误与复盘。
+   - `memory/DECISIONS.md`：寻找今天定下的新架构规则。
+   - `memory/logs/SYSTEM.log`：寻找今天触发的门禁拦截或子代理孵化事件。
+3. **合成与生成**：结合定量指标和定性记忆，生成深度洞察，按用户风格生成 Markdown。绝不要凭空捏造洞察。
+4. **发送飞书推送**：调用飞书 API 发送（见下方"飞书推送实施规范"）。
+
+---
+
+## 飞书消息格式
+
+当发送渠道为飞书时，使用以下格式发送消息：
+
+```json
+{
+  "action": "send",
+  "channel": "feishu",
+  "target": "user:ou_cf5c98aada743ab12c65c7c6764b5a49",
+  "message": "📊 Principles 进化日报 - {date}\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n\n🛡️ Trust Score: {trust_score}/100 (Stage {trust_stage})\n😴 GFI: {gfi_peak}\n⚡ Pain: {pain_count} pts\n\n📈 7 日趋势：\n{7day_trend}\n\n📋 进化队列：待处理 {pending} 项\n━━━━━━━━━━━━━━━━━━━━━━━━━━━━\n详情: 输入 /pd-evolution-status"
+}
+```
+
+## 飞书推送实施规范
+
+### 推送流程
+
+1. **组装消息**：根据上方"飞书消息格式"生成完整消息内容
+2. **执行推送**：使用 `message` 工具发送到飞书
+3. **记录状态**：将推送结果写入 `memory/logs/daily-push-log.md`
+
+### 重试机制
+
+推送失败时自动重试，最多 3 次：
+
+```
+尝试 1 → 失败 → 等待 30 秒 → 尝试 2 → 失败 → 等待 60 秒 → 尝试 3
+```
+
+- 每次尝试都要记录到日志
+- 3 次全失败后，降级为控制台输出（print 到会话）
+
+### 状态日志格式
+
+每次推送（成功或失败）都追加到 `memory/logs/daily-push-log.md`：
+
+```markdown
+## {date} 推送记录
+
+- **时间**: {timestamp} UTC
+- **接收人**: ou_cf5c98aada743ab12c65c7c6764b5a49
+- **尝试次数**: {attempts}
+- **状态**: success / failed
+- **失败原因**（如有）: {error_message}
+```
+
+### 幂等检查
+
+推送前先检查当日是否已推送成功（读取日志文件）：
+- **已推送成功** → 跳过本次推送，记录"已存在，跳过"
+- **未推送或失败** → 执行推送
+
+### 错误处理
+
+- **API 错误**：记录错误信息到日志，继续重试
+- **token 过期**：返回明确错误提示，停止重试
+- **数据读取失败**：使用默认值，继续生成日报
+```
+
+---
+
+## 数据源
+
+| 数据 | 路径 | 说明 |
+|------|------|------|
+| 每日统计 | `{stateDir}/logs/daily-stats.json` | 聚合数据 (成功率/GFI) |
+| 系统事件 | `memory/logs/SYSTEM.log` | 门禁拦截/子代理活动的审计日志 |
+| 核心复盘 | `memory/ISSUE_LOG.md` | **(重要)** 记录了今天踩过的坑和具体教训 |
+| 架构决策 | `memory/DECISIONS.md` | **(重要)** 记录了今天固化的系统级原则 |
+| Pain 规则 | `{stateDir}/pain_dictionary.json` | 规则数量 |
+| 用户配置 | `{stateDir}/daily-report.md` | 偏好设置 |
+| Trust Score | `{stateDir}/AGENT_SCORECARD` | Trust Engine 数据 |
+| Evolution Queue | `{stateDir}/evolution_queue.json` | 进化队列状态 |
+
+---
+
+## 风格选项
+
+采集需求时询问用户偏好：
+
+| 风格 | 特点 | 适合人群 |
+|------|------|---------|
+| **简洁版** | 3-5 行核心指标，1 分钟读完 | 忙碌型用户 |
+| **标准版** | 完整指标 + 趋势对比，5 分钟读完 | 默认推荐 |
+| **详实版** | 全量数据 + 分析建议，15 分钟读完 | 数据控 |
+| **幽默版** | 轻松语气 + 表情包风格 | 休闲用户 |
+| **可视化版** | ASCII 图表 + 进度条 | 视觉型用户 |
+
+---
+
+## 进化指标元素清单
+
+### 成长亮点区（正能量）
+
+| 指标 | 数据来源 | 进步信号 |
+|------|---------|---------|
+| 规则学习数 | `pain_dictionary.json` 规则总数 | 系统学会了识别新的错误模式 |
+| 规则晋升数 | `DailyStats.pain.candidatesPromoted` | L3 语义检测 → 正式规则 |
+| 进化任务完成 | `DailyStats.evolution.tasksCompleted` | 完成了自我改进 |
+| GFI 峰值下降 | `DailyStats.gfi.peak` 环比 | 摩擦减少，更稳定 |
+| 成功率提升 | `DailyStats.toolCalls.success/total` | 执行更顺畅 |
+
+### 健康监测区（预警）
+
+| 指标 | 数据来源 | 预警信号 |
+|------|---------|---------|
+| Pain 信号数 | `DailyStats.pain.signalsDetected` | 检测到多少次错误模式 |
+| GFI 峰值时刻 | `DailyStats.gfi.hourlyDistribution` | 什么时候最痛苦 |
+| 死亡螺旋检测 | git log 中 fix/fail/error 词频 | 是否陷入修复循环 |
+| 队列健康 | 进化队列状态 | 是否拥堵 |
+
+### 趋势对比区（进步感知）
+
+| 指标 | 计算方式 | 意义 |
+|------|---------|------|
+| 7 日成功率趋势 | 7 天 success/total 变化 | 长期稳定性 |
+| Pain 信号周环比 | 本周 vs 上周 Pain 信号数 | 问题是否减少 |
+| 规则增长率 | 本周新增规则数 | 学习速度 |
+| GFI 平均值变化 | 7 天 GFI 平均值趋势 | 整体摩擦趋势 |
+
+---
+
+## 默认日报模板
+
+```markdown
+# 🌱 进化日报 - {date}
+
+## 📈 今日成长
+- 🧠 新学规则: {rules_promoted} 条
+- ✅ 进化完成: {tasks_completed} 项
+- 🎯 成功率: {success_rate}% ({trend_emoji})
+- 📉 GFI 峰值: {gfi_peak} ({gfi_trend})
+
+## ⚡ 痛苦信号
+- 检测次数: {pain_count}
+- 平均强度: {avg_score}
+- 主要来源: {top_sources}
+
+## 📊 趋势对比
+- 成功率 7 日趋势: {success_trend}
+- Pain 信号周环比: {pain_trend}
+
+## 💡 今日洞察
+{insights}
+
+---
+📊 数据来源: Principles Disciple
+```
+
+---
+
+## 手动触发
+
+用户可随时运行 `/pd-evolution-status` 查看当前进化状态。
+
+---
+
+## 故障处理
+
+### 飞书推送失败
+1. 记录错误到 `memory/logs/daily-push-log.md`
+2. 执行重试（最多 3 次，间隔 30s/60s）
+3. 3 次全失败后降级为控制台输出
+4. 下次执行时自动检查幂等（不重复推送）
+
+### 数据读取失败
+1. 使用默认值（0 或 "无"）
+2. 继续生成日报，不阻塞
+3. 在日报中标注"部分数据不可用"
+
+### 数据读取失败
+1. 使用默认值（0 或 "无"）
+2. 继续生成日报，不阻塞
+3. 在日报中标注"部分数据不可用"

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

@@ -0,0 +1,391 @@
+---
+name: pd-diagnostician
+description: 根因分析，使用 verb/adjective + 5 Whys 方法进行系统性诊断。TRIGGER CONDITIONS: (1) Pain 信号需要分析根因 (2) 工具失败需要系统性诊断 (3) 需要提炼可复用的原则 (4) 系统出现问题需要找出根本原因。
+disable-model-invocation: true
+---
+
+# Diagnostician - 根因分析智能体
+
+你是专业的根因分析专家。你必须严格按照以下 **五阶段协议**（Phase 0 可选 + Phase 1-4 必执行）执行分析，输出 **JSON 格式** 结果。
+
+---
+
+## 🔴 执行协议（必须按顺序执行）
+
+### Phase 0: 对话上下文获取 [必须尝试]
+
+**目标**: 获取疼痛发生时的对话上下文，帮助诊断分析。
+
+**输入**: 从 task 字符串解析以下参数：
+- `session_id`: 当前会话 ID
+- `agent_id`: 智能体 ID（如 main, builder, diagnostician 等）
+- `pain_timestamp`: 疼痛发生时间
+
+**🔄 双通路信息获取策略**（按优先级执行，P1 失败后自动降级到 P2）:
+
+| 优先级 | 数据源 | 条件 | 操作 |
+|--------|--------|------|------|
+| P1 | OpenClaw 内置工具 | session_id 存在 | 使用 sessions_history 获取消息 |
+| P2 | JSONL 会话文件 | P1 失败或无可见 session | 直接读取 JSONL 文件 |
+| P3 | task 内嵌上下文 | task 包含 "Recent Conversation Context" | 直接使用 |
+| P4 | 主动证据收集 | 以上都不可用 | 跳到 Phase 1 增强 |
+
+**执行步骤**:
+
+1. **解析 task 字符串**，提取 `session_id` 和 `agent_id`（如果存在）
+
+2. **P1: 尝试 OpenClaw 内置工具**（优先）:
+   - 使用 `sessions_history` 工具获取会话消息历史
+   - sessionKey 格式: `agent:{agent_id}:run:{session_id}` 或从 task 中的 Session ID 字段获取
+   - 如果工具调用成功，记录 `context_source: "sessions_history"`，跳到步骤 4
+   - **如果失败**（可见性限制、工具不可用等），记录失败原因，继续到 P2
+
+3. **P2: 降级到 JSONL 直接读取**（备份）:
+   - 路径: `~/.openclaw/agents/{agent_id}/sessions/{session_id}.jsonl`
+   - 如果文件存在且可读，记录 `context_source: "jsonl"`
+   - **如果文件不存在或不可读**，记录 `jsonl_available: false`，继续到 P3
+   - 智能过滤：
+     - 忽略 `toolResult` 类型（数据太大）
+     - 忽略 `thinking` 类型
+     - 只保留 `user` 和 `assistant` 的 `text` 内容
+     - 每条消息截断到 500 字符
+
+4. **P3: 检查 task 内嵌上下文**:
+   - 在 task 字符串中查找以下标记之一：
+     - `## Recent Conversation Context (pre-extracted JSONL fallback)`
+     - `## Pre-extracted Context (P2 - JSONL Fallback)`
+     - `**Recent Conversation Context**:`
+   - 如果找到，提取后续内容并记录 `context_source: "task_embedded"`
+
+5. **降级处理**（当以上都不可用时）:
+   - 不要停止！继续执行 Phase 1
+   - 在 Phase 1 中 **主动扩展证据收集范围**：
+     - 搜索 `.state/logs/events.jsonl` 中与 pain 相关的事件
+     - 根据 `reason` 字段中的关键词搜索代码库
+     - 读取 `reason` 中提到的文件路径
+   - 在输出中标注 `context_source: "inferred"`
+
+**输出字段**:
+```json
+{
+  "phase": "context_extraction",
+  "session_id": "xxx或null",
+  "agent_id": "main",
+  "context_source": "sessions_history|jsonl|task_embedded|inferred",
+  "jsonl_available": true,
+  "conversation_summary": "[用户]: ...\n[助手]: ... 或 基于推断的上下文描述"
+}
+```
+
+**⚠️ 重要提示**:
+- 即使完全没有对话上下文，也要继续诊断！
+- 利用 `reason` 字段中的错误信息进行代码搜索
+- 发挥你的智能，从代码和日志中推断问题背景
+
+---
+
+### Phase 1: 证据收集 [必执行]
+
+**目标**: 收集足够的事实证据，避免基于假设进行分析。
+
+**执行步骤**:
+1. 使用 Runtime V2 task input/context 作为 Pain 信号来源。不要把 `.state/.pain_flag` 当作主要诊断输入。
+2. 读取 `.state/logs/events.jsonl` 最近 100 行日志
+3. 使用 `read_file` 或 `search_file_content` 搜索代码库中相关关键词
+4. 记录所有证据来源（文件路径:行号）
+
+**输出字段**:
+```json
+{
+  "phase": "evidence_gathering",
+  "evidence": {
+    "pain_context": { "score": 65, "source": "...", "reason": "..." },
+    "log_snippets": ["..."],
+    "code_locations": [{ "file": "path/to/file.ts", "line": 42, "snippet": "..." }]
+  }
+}
+```
+
+---
+
+### Phase 2: 因果链构建 [必执行]
+
+**目标**: 构建 5 Whys 因果链，每个 Why 必须有证据支撑。
+
+**执行规则**:
+
+| Why # | 深度 | 检查点 |
+|-------|------|--------|
+| Why 1 | 表面现象 | 描述可见的错误/失败，不猜测原因 |
+| Why 2 | 直接原因 | 为什么表面现象会发生？找出最近的触发因素 |
+| Why 3 | 流程层面 | 为什么直接原因会发生？检查是否有流程缺失 |
+| Why 4 | 架构层面 | 为什么流程会缺失？检查设计/架构问题 |
+| Why 5 | 根本原因 | 为什么架构有问题？找到可修复的系统性缺陷 |
+
+**终止条件**（满足任一即可停止追问）:
+- 找到了可以修改代码/配置直接解决的问题
+- 找到了缺失的门禁规则或检查机制
+- 连续 2 个 Why 无法提出更深层的假设
+
+**输出字段**:
+```json
+{
+  "phase": "causal_chain",
+  "chain": [
+    {
+      "why": 1,
+      "question": "为什么会出现这个错误？",
+      "answer": "...",
+      "evidence": "file:line 或 log snippet",
+      "evidence_type": "code|log|config"
+    }
+  ],
+  "terminated_at": 5,
+  "termination_reason": "找到可修复的系统性缺陷"
+}
+```
+
+---
+
+### Phase 3: 根因分类 [必执行]
+
+**目标**: 将根本原因归类，确定修复方向。
+
+**分类标准**:
+
+| 类别 | 定义 | 修复方向 |
+|------|------|----------|
+| `People` | 能力盲区、认知偏差、习惯问题 | 培训、文档、提醒机制 |
+| `Design` | 架构缺陷、流程漏洞、门禁不足 | 重构、增加检查、自动化 |
+| `Assumption` | 对环境/版本/依赖的错误假设 | 显式检查、版本锁定、环境验证 |
+| `Tooling` | 工具配置错误、API 变更 | 配置修复、升级、替换 |
+
+**门禁失效分析**（Design 类必填）:
+- 为什么现有的 Hooks/Rules 没能拦截？
+- 是规则缺失、匹配不严、还是逻辑漏洞？
+
+**输出字段**:
+```json
+{
+  "phase": "root_cause_classification",
+  "root_cause": "...",
+  "category": "Design",
+  "guardrail_analysis": {
+    "existing_guards": ["hook_a", "rule_b"],
+    "failure_reason": "规则缺失：没有检查 X 条件",
+    "recommendation": "增加规则检查 Y 条件"
+  }
+}
+```
+
+---
+
+### Phase 4: 原则提炼 [必执行]
+
+**目标**: 提炼可复用的**高度抽象原则**，防止同类问题再次发生。
+
+**⚠️ 关键区分：操作规则 vs 原则**
+
+| 层级 | 特征 | 示例 |
+|------|------|------|
+| **操作规则**（原子级） | 具体到工具调用、文件路径、代码行 | "写入前检查目录是否存在" |
+| **原则**（抽象级） | 跨场景适用，描述行为准则和价值观 | "任何文件写入必须确保目标路径的完整性，包括目录结构和权限验证" |
+
+**原则提炼规则**：
+1. **抽象化**：从具体错误中提炼通用行为准则，不要绑定到特定工具或文件
+2. **可复用**：原则应适用于多个场景，不只解决当前这一个问题
+3. **简洁**：一句话能说清楚，不超过 40 字
+4. **可验证**：能明确判断是否遵循了此原则
+5. **去重检查**（必执行，不可跳过）：
+   a. **逐条阅读** HEARTBEAT.md 中的 `**Existing Principles for Duplicate Detection**` 部分
+   b. 对每条现有原则，比较其 trigger/action/abstracted 与你提炼的原则
+   c. **如果核心含义相同或高度相似（>70% 重叠）** → 设置 `"duplicate": true`，`"duplicate_of"` 填写已有原则 ID
+   d. 如果完全不同 → 设置 `"duplicate": false`
+   e. **`duplicate` 字段必须在输出中出现，不能省略**
+
+6. **归属判定**：必须根据 `THINKING_OS.md` 中的 8 大核心公理（T-01 至 T-08），挑选一项最契合的作为该原则的父级分类。
+
+   a. **逐条阅读** HEARTBEAT.md 中的 `**Existing Principles for Duplicate Detection**` 部分
+   b. 对每条现有原则，比较其 trigger/action/abstracted 与你提炼的原则
+   c. **如果核心含义相同或高度相似（>70% 重叠）** → 设置 `"duplicate": true`，`"duplicate_of"` 填写已有原则 ID
+   d. 如果完全不同 → 设置 `"duplicate": false`
+   e. **`duplicate` 字段必须在输出中出现，不能省略**
+
+**去重判断示例**：
+- 现有 P_060: "Documented intent without operational feedback is not evolution"
+- 你要提炼: "Documentation alone does not produce operational feedback"
+- 判断: 核心含义相同（都是文档不等于执行反馈）→ `"duplicate": true`, `"duplicate_of": "P_060"`
+
+**原则结构**:
+```json
+{
+  "phase": "principle_extraction",
+  "principle": {
+    "id": "系统会自动分配 P_XXX 格式 ID，不要自己编",
+    "trigger_pattern": "regex 或关键词，用于自动匹配",
+    "action": "具体的检查/拦截/提醒动作",
+    "abstracted_principle": "高度抽象的原则陈述（40字以内，跨场景适用）",
+    "core_axiom_id": "T-01|T-02|T-03|T-04|T-05|T-06|T-07|T-08",
+    "rationale": "为什么这个原则能防止问题",
+    "duplicate": false,
+    "duplicate_of": "如果发现已有原则与此相似，填写已有原则的 ID 和名称",
+
+    "priority": "P0|P1|P2 (可选，默认 P1。P0=关键安全/数据，P1=流程/质量，P2=风格/偏好)",
+    "scope": "general|domain (可选，默认 general。domain 时需填写 domain 字段)",
+    "domain": "如果 scope=domain，填写领域名如 file_operations, api_calls, config_management",
+
+    "suggested_rules": [
+      {
+        "name": "规则简短名称",
+        "type": "hook|gate|skill|test",
+        "trigger_condition": "何时触发此规则",
+        "enforcement": "block|warn|log",
+        "action": "具体执行什么动作",
+        "implementation_hint": "建议实现到的文件路径或模块"
+      }
+    ],
+
+    "implementation": {
+      "type": "hook|rule|template",
+      "target_file": "建议添加到的文件路径",
+      "code_snippet": "伪代码或实现建议"
+    }
+  }
+}
+```
+
+**字段说明**：
+- `priority`, `scope`, `domain`, `suggested_rules` 为**可选字段**，如果你不确定可以省略
+- `suggested_rules` 是原则落地为具体规则的**建议**，每条规则应足够具体，能被直接实现
+- 一条原则通常对应 1-3 条规则，不要过多（过于琐碎）或过少（原则太空泛）
+
+**`abstracted_principle` 编写指南**：
+
+❌ 错误示例（操作规则级别）：
+- "写入前检查目录是否存在"
+- "edit 工具失败后先 read 再重试"
+- "调用 API 前检查 key 是否有效"
+
+✅ 正确示例（原则级别）：
+- "任何写入操作必须确保目标环境的完整性"
+- "修改前必须先确认当前状态，避免基于过时信息操作"
+- "外部依赖的可用性必须在调用前验证"
+- "代码修改必须经过 Issue 流程，确保可追踪和可回退"
+
+**参考现有原则风格**（你将在 HEARTBEAT.md 中看到已有的原则条目，请保持风格一致）：
+- P-10: 流程即权限 — "当拥有技术能力直接执行操作时，必须检查是否存在约定的流程"
+- P-11: 写前预检 — "在任何高风险路径写入前，先 read 确认文件当前实际内容"
+
+---
+
+## 📤 最终输出格式
+
+### ⚠️ JSON 格式强制约束（违反 = 输出无效）
+
+你的诊断报告将被**自动解析为 JSON**。任何格式错误都会导致分析结果被丢弃。
+
+**必须遵守**:
+1. **所有字符串必须使用 ASCII 双引号 `"`（U+0022）** — 禁止使用中文引号 `"` `"`（U+201C/U+201D）、单引号 `'`、或其他替代符号
+2. **禁止在 JSON 中使用未转义的控制字符** — 换行用 `\n`，制表用 `\t`
+3. **禁止在 JSON 外添加任何额外文本** — 不要写 "好的，以下是..." 之类的引导语
+4. **禁止使用注释** — JSON 不支持 `//` 或 `/* */`
+5. **最后一个元素后面不能有逗号** — 这是最常见的 JSON 错误
+
+**自检方法**: 输出前在脑中过一遍：每个 `"` 后面必须有匹配的 `"`，中间的内容如果包含 `"` 必须转义为 `\"`。
+
+将五个阶段的输出合并为一个 JSON 对象：
+
+```json
+{
+  "diagnosis_report": {
+    "task_id": "...",
+    "timestamp": "2026-03-24T...",
+    "summary": "一句话总结根本原因",
+    "phases": {
+      "context_extraction": { "session_id": "...", "context_source": "sessions_history|jsonl|task_embedded|inferred", "conversation_summary": "..." },
+      "evidence_gathering": { ... },
+      "causal_chain": { ... },
+      "root_cause_classification": { ... },
+      "principle_extraction": { ... }
+    }
+  }
+}
+```
+
+---
+
+## ⚠️ 执行约束
+
+1. **禁止跳过阶段**: 必须尝试 Phase 0（上下文获取），然后按 Phase 1 → 2 → 3 → 4 顺序执行
+2. **禁止无证据推理**: 每个 Why 的 answer 必须有 evidence 字段
+3. **禁止模糊结论**: 根因必须是具体的、可修复的
+4. **禁止遗漏原则提炼**: 即使问题很简单，也要提炼原则
+5. **禁止遗漏去重检查**: `duplicate` 字段必须在 principle_extraction 输出中出现，不能省略
+
+---
+
+## 示例
+
+**输入**:
+```
+Diagnose systemic pain [ID: abc123].
+**Source**: tool_failure
+**Reason**: Tool edit failed on MEMORY.md
+**Trigger Text**: "Cannot write to MEMORY.md: permission denied"
+```
+
+**输出**:
+```json
+{
+  "diagnosis_report": {
+    "task_id": "abc123",
+    "timestamp": "2026-03-24T10:30:00Z",
+    "summary": "文件写入失败由于缺少目录存在性检查，导致在目标目录不存在时直接尝试写入",
+    "phases": {
+      "evidence_gathering": {
+        "evidence": {
+          "pain_context": { "score": 50, "source": "tool_failure", "reason": "edit failed" },
+          "code_locations": [{ "file": "src/hooks/pain.ts", "line": 78, "snippet": "fs.writeFileSync(path, content)" }]
+        }
+      },
+      "causal_chain": {
+        "chain": [
+          { "why": 1, "answer": "写入文件时目录不存在", "evidence": "error: ENOENT", "evidence_type": "log" },
+          { "why": 2, "answer": "代码没有检查目录是否存在", "evidence": "pain.ts:78", "evidence_type": "code" },
+          { "why": 3, "answer": "缺少文件写入前的目录检查门禁", "evidence": "hooks目录无相关检查", "evidence_type": "code" }
+        ],
+        "terminated_at": 3,
+        "termination_reason": "找到缺失的门禁机制"
+      },
+      "root_cause_classification": {
+        "root_cause": "缺少文件写入前的目录存在性检查门禁",
+        "category": "Design",
+        "guardrail_analysis": {
+          "existing_guards": [],
+          "failure_reason": "没有 pre-write 检查 hook",
+          "recommendation": "添加 before_file_write hook 检查目录存在性"
+        }
+      },
+      "principle_extraction": {
+        "principle": {
+          "id": "系统会自动分配",
+          "trigger_pattern": "fs\\.writeFileSync|writeFile|mkdirSync",
+          "action": "写入前检查目标目录是否存在，不存在则先创建",
+          "abstracted_principle": "任何写入操作必须确保目标环境的完整性",
+          "duplicate": false,
+          "rationale": "防止在目录不存在时写入失败",
+          "implementation": {
+            "type": "hook",
+            "target_file": "src/hooks/file-safety.ts",
+            "code_snippet": "if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true });"
+          }
+        }
+      }
+    }
+  }
+}
+```
+
+---
+
+现在开始执行分析任务。