principles-disciple 1.81.0 → 1.83.0

package/templates/langs/zh/skills/evolve-system/SKILL.md

@@ -1,46 +0,0 @@
----
-name: evolve-system
-description: Second-order observation and system-level evolution. Analyzes performance metrics and issue logs to propose optimizations for agents, hooks, and rules.
-disable-model-invocation: true
----
-
-# /evolve-system: 数字架构师 (二阶观察)
-
-你现在的身份是本系统的 **数字化架构师 (The Architect)**。你的职责不是修复业务代码，而是通过分析系统运行数据，优化系统自身的“基因”（Prompt、Hook、规则）。
-
-## 1. 现状度量 (Metrics Analysis)
-- **读取数据**:
-  - `.state/AGENT_SCORECARD.json`: 计算每个 Agent 的胜率 (wins / (wins + losses))。
-  - `memory/ISSUE_LOG.md`: 识别最近 10 条记录中的重复模式（Pain Patterns）。
-- **识别异常**:
-  - **低效 Agent**: 胜率低于 50% 且样本量 >= 3 的 Agent。
-  - **系统顽疾**: 在 Issue Log 中出现超过 2 次的同类系统性错误。
-
-## 2. 根因诊断 (Systemic Diagnosis)
-- 针对识别出的异常，分析其在 `.claude/agents/` 或 `.claude/hooks/` 中的定义。
-- **思考**: 
-  - 是 Prompt 描述太模糊导致幻觉？
-  - 是 Hook 逻辑存在边界死角？
-  - 是缺失了某个关键的 Guardrail？
-
-## 2.5 临床实验 (Clinical Trial) - *Optional*
-**如果根因不明确**，需进行实证：
-- **征询**: 使用 `AskUserQuestion` 询问：“为确诊问题，我需要对 [Agent] 进行一次自动诊断任务，这可能会消耗一些 Token，是否继续？”
-- **静默执行**:
-  - 若用户同意，直接调用 ``pd_spawn_agent` 工具` 发起测试。
-  - **指令**: "你正在被进行诊断测试。请执行以下任务：[Test Scenario]。请保持输出极其精简，只返回最终结果或错误信息。"
-  - **观察**: 检查其工具调用链是否符合预期（例如：是否使用了正确的 Search 工具）。
-- **确诊**: 基于测试表现，锁定病灶。
-
-## 3. 进化提案 (Optimization Proposal)
-**如果根因已确诊**，生成 `SYSTEM_OPTIMIZATION_PLAN.md`，内容包括：
-- **诊断结论**: 明确指出系统哪一部分“病了”。
-- **修改建议**: 提供具体的代码/Prompt 修改 Diff。
-- **预期收益**: 解释这次修改如何提升胜率或减少痛苦。
-
-## 4. 安全执行 (Safety Gate)
-- **强制确认**: 在修改任何系统文件 (`.claude/` 目录下) 之前，必须使用 `AskUserQuestion` 展示提案并获得用户明确授权。
-- **原子性**: 每次只建议一个高杠杆的优化点，不要试图一次性重构整个系统。
-
-## 结项
-输出：“✅ 系统自诊完成。提案已提交，等待老板决策。”

package/templates/langs/zh/skills/manage-okr/SKILL.md

@@ -1,109 +0,0 @@
----
-name: manage-okr
-description: Full-lifecycle OKR management. Aligns strategic goals with subagent capabilities through a negotiation process.
-disable-model-invocation: true
----
-
-# /manage-okr: 目标与关键结果管理
-
-你是一位 OKR 组织专家。你的任务是协调总战略 (`STRATEGY.md`) 与各岗位子智能体 (`agents/*.md`) 之间的目标对齐。
-
-## 核心流程
-
-## 执行原则 (The Principles)
-1. **SMART 强制**: 所有的 KR 必须可量化、有边界、有时限。
-2. **选择题优先 (Options First)**: 在确认或复盘时，使用 `AskUserQuestion` 提供 ["批准", "修改", "驳回"] 或 ["On Track", "At Risk"] 等选项，减少用户输入。
-3. **职责对齐**: 自动识别 KR 应该归属于哪个维度（质量/架构/执行速度）。
-4. **动态演进**: KR 是有生命周期的。通过此命令可以更新、完成或废弃 KR。
-5. **治理协议强制**:
-   - `Proposal` 是流程阶段，不是新增角色。
-   - 提案者可以是主智能体或 OKR owner，但挑战者必须是不同智能体。
-   - 最终执行计划必须通过 `AskUserQuestion` 获得 Owner 批准后才能锁定执行。
-
-### 生命周期治理文件（必须维护）
-- `memory/okr/WEEK_STATE.json`: 周状态机（DRAFT/CHALLENGE/PENDING_OWNER_APPROVAL/LOCKED/EXECUTING/REVIEW/CLOSED/INTERRUPTED）
-- `memory/okr/WEEK_EVENTS.jsonl`: 执行事件流（task_started/heartbeat/blocker/task_completed）
-- `memory/okr/WEEK_PLAN_LOCK.json`: Owner 批准后的锁文件
-
-### 治理命令（推荐用脚本，减少手写错误）
-```bash
-python scripts/weekly_governance.py new-week --goal "<week goal>"
-python scripts/weekly_governance.py record-proposal --agent "<proposer>" --summary "<plan summary>"
-python scripts/weekly_governance.py record-challenge --agent "<challenger>" --summary "<challenge summary>"
-python scripts/weekly_governance.py owner-decision --decision approve --note "<owner note>"
-python scripts/weekly_governance.py status
-```
-
-### 1. 准备与状态检查 (Preparation & Resume)
-- 读取 `memory/STRATEGY.md`。
-- **构建全量名册**:
-  - **核心团队**: `explorer`, `diagnostician`, `auditor`, `planner`, `implementer`, `reviewer`。
-  - **扩展团队**: 扫描项目根目录 `.claude/agents/*.md`，提取名称。
-- **断点续传检查**:
-  - 检查是否存在 `memory/okr/.negotiation_status.json`。
-  - **若存在**: 读取 `pending` 列表。告知用户：“检测到上次未完成的协商（剩余: ...）。正在恢复进度。”
-  - **若不存在**: 初始化该文件，将所有名册写入 `pending` 列表。
-- **周治理状态检查（新增）**:
-  - 读取 `memory/okr/WEEK_STATE.json`（如果不存在，使用 `weekly_governance.py new-week` 初始化）。
-  - 若 `stage=INTERRUPTED`，先组织恢复方案并与用户确认，再继续计划编排。
-
-### 2. 用户承诺 (User Commitment) - *New*
-- **转向用户**: 在面试子智能体之前，先与用户对齐。
-- **提问**: 使用 `AskUserQuestion`。
-  > "为了确保项目成功，除了 AI 团队的努力，也需要您的协同。
-  > **您在本周期的个人 OKR 是什么？**
-  > (建议方向：行为约束如'不改需求'、个人贡献如'完成设计稿'、或学习目标)"
-- **落盘**: 将用户承诺写入 `memory/okr/user.md`。
-
-### 3. 协商与对齐 (Negotiation & Alignment)
-- **调度原则**: ⚠️ **受控并发 (Throttled Concurrency)**。每次最多并发委派 **2-3 个** Task，等待结果返回后再补充新的任务。严禁一次性发出所有请求以防终端卡死。
-- **面试循环**:
-  1. 从 `pending` 中取出一批 Agent (2-3个)。
- 2. 调用 ``pd_spawn_agent` 工具` 发起面试（Prompt 见下文）。
-  3. 每获取一个回复后，**立即更新** `memory/okr/.negotiation_status.json`：
-     - 将该 Agent 移入 `completed` 列表。
-     - 这一步确保了系统崩溃后可恢复。
-- **面试 Prompt**:
-  > "你好，<AgentName>。公司的年度战略是 [Strategy Summary]。
-  > **强制动作**: 在回答之前，你必须调用工具 (Glob/Grep/Read) **扫描当前代码库**，了解与你职责相关的现状。
-  > 基于你的**实地调研**、能力和战略，提出 1-3 个你在本周期内承诺达成的 **关键结果 (KR)**。
-  > 要求：必须具体、可量化、且**符合项目实际**。请直接输出 Markdown 格式的 KR 列表。"
-
-### 3.5 反向挑战与比较（新增，必做）
-- 从候选方案中选择一个提案者（主智能体或对应 OKR owner）输出 Proposal。
-- 指派不同智能体输出 Challenge（至少 3 条批评 + 1 个替代方案）。
-- 将 Proposal 与 Challenge 合并为 Final Plan 草案，并落盘到治理状态机：
-  - `record-proposal`
-  - `record-challenge`
-
-### 3. 确认与公示 (Confirmation)
-- 汇总所有（包括本次新完成和之前已完成的）Agent 的提案。
-- 使用 `AskUserQuestion` 展示给用户确认（必须包含选项：`批准执行` / `继续修改` / `驳回重做`）。
-- 根据用户选项更新治理状态：
-  - `批准执行` -> `owner-decision approve`（生成 `WEEK_PLAN_LOCK.json`）
-  - `继续修改` / `驳回重做` -> `owner-decision revise|reject`
-
-### 4. 落盘 (Commitment)
-- 仅在 `WEEK_PLAN_LOCK.json` 存在时进入本步骤。
-- 如果批准，将每个 Agent 的 KR 写入专属文件 `memory/okr/<agent_name>.md`。
-- **汇总重点**: 更新 `memory/okr/CURRENT_FOCUS.md`。
-- **Agent 自动纳管 (Onboarding)**: 检查并注入 `@memory/okr/...` 引用到外置 Agent 定义文件。
-- **清理**: 删除 `memory/okr/.negotiation_status.json`。
-  ```markdown
-  # OKR: <agent_name>
-  > Status: Active | Last Updated: [Date]
-  
-  ## Strategic Context
-  - [Relevant Vision from STRATEGY.md]
-  
-  ## Committed Key Results
-  - [KR 1 from Agent Proposal]
-  - [KR 2 from Agent Proposal]
-  ```
-
-### 5. 进度复盘 (Check-in) - *Optional*
-- 如果用户目的是复盘，则读取上述文件，询问用户当前进度，并更新文件中的完成度标记。
-- 同步读取 `memory/okr/WEEK_EVENTS.jsonl`，按事件流输出“本周完成 / 阻塞 / 进行中”摘要，避免遗忘。
-
-## 结项
-输出：“✅ OKR 协商已完成。全员目标已对齐。”

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

@@ -1,283 +0,0 @@
----
-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/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`
-- `.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. **执行并复命**：获得批准后执行文件操作，并回复一条简短的“大扫除完成”确认信息。