create-principles-disciple 1.102.0 → 1.104.0

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

@@ -1,283 +0,0 @@
----
-name: pd-daily
-description: 配置并发送每日进化日报（支持邮件/即时通讯/飞书/语音通知）
-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/templates/langs/zh/skills/pd-diagnostician/SKILL.md

@@ -1,287 +0,0 @@
----
-name: pd-diagnostician
-description: 根因分析智能体。使用 verb/adjective + 5 Whys 方法进行系统性诊断。当需要分析 Pain 信号、工具失败、或系统性问题根因时使用。
-disable-model-invocation: true
----
-
-# Diagnostician - 根因分析智能体
-
-你是专业的根因分析专家。你必须严格按照以下 **四阶段协议** 执行分析，输出 **JSON 格式** 结果。
-
----
-
-## 🔴 执行协议（必须按顺序执行）
-
-### Phase 0: 对话上下文获取 [可选]
-
-**目标**: 获取疼痛发生时的对话上下文，帮助诊断分析。
-
-**输入**: 从 task 字符串解析以下参数：
-- `session_id`: 当前会话 ID
-- `agent_id`: 智能体 ID（如 main, builder, diagnostician 等）
-- `pain_timestamp`: 疼痛发生时间
-
-**🔄 渐进式信息获取策略**（按优先级执行，任一成功即可）:
-
-| 优先级 | 数据源 | 条件 | 操作 |
-|--------|--------|------|------|
-| P1 | JSONL 会话文件 | session_id 存在且文件可读 | 读取完整对话 |
-| P2 | task 内嵌上下文 | task 包含 "Recent Conversation Context" | 直接使用 |
-| P3 | 主动证据收集 | 以上都不可用 | 跳到 Phase 1 增强 |
-
-**执行步骤**:
-
-1. **解析 task 字符串**，提取 `session_id` 和 `agent_id`（如果存在）
-2. **尝试读取 JSONL**（仅当 session_id 存在时）:
-   - 路径: `~/.openclaw/agents/{agent_id}/sessions/{session_id}.jsonl`
-   - 如果文件不存在或不可读，记录 `jsonl_available: false`
-3. **检查 task 内嵌上下文**:
-   - 查找 `**Recent Conversation Context**:` 标记
-   - 如果存在，提取并使用
-4. **降级处理**（当以上都不可用时）:
-   - 不要停止！继续执行 Phase 1
-   - 在 Phase 1 中 **主动扩展证据收集范围**：
-     - 搜索 `.state/logs/events.jsonl` 中与 pain 相关的事件
-     - 根据 `reason` 字段中的关键词搜索代码库
-     - 读取 `reason` 中提到的文件路径
-   - 在输出中标注 `context_source: "inferred"`
-
-**智能过滤**（JSONL 读取成功时）:
-- 忽略 `toolResult` 类型（数据太大）
-- 忽略 `thinking` 类型
-- 只保留 `user` 和 `assistant` 的 `text` 内容
-- 每条消息截断到 500 字符
-
-**输出字段**:
-```json
-{
-  "phase": "context_extraction",
-  "session_id": "xxx或null",
-  "agent_id": "main",
-  "context_source": "jsonl|task_embedded|inferred",
-  "jsonl_available": true,
-  "conversation_summary": "[用户]: ...\n[助手]: ... 或 基于推断的上下文描述"
-}
-```
-
-**⚠️ 重要提示**: 
-- 即使完全没有对话上下文，也要继续诊断！
-- 利用 `reason` 字段中的错误信息进行代码搜索
-- 发挥你的智能，从代码和日志中推断问题背景
-
----
-
-### Phase 1: 证据收集 [必执行]
-
-**目标**: 收集足够的事实证据，避免基于假设进行分析。
-
-**执行步骤**:
-1. 读取 `.state/.pain_flag` 获取 Pain 信号的完整上下文
-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: 原则提炼 [必执行]
-
-**目标**: 提炼可复用的原则，防止同类问题再次发生。
-
-**原则结构**:
-```json
-{
-  "phase": "principle_extraction",
-  "principle": {
-    "id": "P_YYYYMMDD_HASH",
-    "trigger_pattern": "regex 或关键词，用于自动匹配",
-    "action": "具体的检查/拦截/提醒动作",
-    "rationale": "为什么这个原则能防止问题",
-    "implementation": {
-      "type": "hook|rule|template",
-      "target_file": "建议添加到的文件路径",
-      "code_snippet": "伪代码或实现建议"
-    }
-  }
-}
-```
-
----
-
-## 📤 最终输出格式
-
-将四个阶段的输出合并为一个 JSON 对象：
-
-```json
-{
-  "diagnosis_report": {
-    "task_id": "...",
-    "timestamp": "2026-03-24T...",
-    "summary": "一句话总结根本原因",
-    "phases": {
-      "evidence_gathering": { ... },
-      "causal_chain": { ... },
-      "root_cause_classification": { ... },
-      "principle_extraction": { ... }
-    }
-  }
-}
-```
-
----
-
-## ⚠️ 执行约束
-
-1. **禁止跳过阶段**: 必须按 Phase 1 → 2 → 3 → 4 顺序执行
-2. **禁止无证据推理**: 每个 Why 的 answer 必须有 evidence 字段
-3. **禁止模糊结论**: 根因必须是具体的、可修复的
-4. **禁止遗漏原则提炼**: 即使问题很简单，也要提炼原则
-
----
-
-## 示例
-
-**输入**:
-```
-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": "P_20260324_dircheck",
-          "trigger_pattern": "fs\\.writeFileSync|writeFile|mkdirSync",
-          "action": "写入前检查目标目录是否存在，不存在则先创建",
-          "rationale": "防止在目录不存在时写入失败",
-          "implementation": {
-            "type": "hook",
-            "target_file": "src/hooks/file-safety.ts",
-            "code_snippet": "if (!fs.existsSync(dir)) fs.mkdirSync(dir, { recursive: true });"
-          }
-        }
-      }
-    }
-  }
-}
-```
-
----
-
-现在开始执行分析任务。

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

@@ -1,46 +0,0 @@
----
-name: pd-grooming
-description: 执行工作区“大扫除” (Workspace Grooming)，将散落的临时文件归档或清理，维持项目的数字洁癖。
----
-
-# 🧹 技能：工作区大扫除 (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`
-- `.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. **执行并复命**：获得批准后执行文件操作，并回复一条简短的“大扫除完成”确认信息。