create-principles-disciple 1.0.0 → 1.74.0

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

@@ -0,0 +1,109 @@
+---
+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/pain/SKILL.md

@@ -0,0 +1,30 @@
+---
+name: pain
+description: Manually trigger a pain signal to force system reflection. Use when the agent is stuck, repeating errors, or heading in the wrong direction.
+disable-model-invocation: true
+---
+
+# Pain Trigger (强制喊痛)
+
+你现在是"人工干预痛觉"组件。
+
+**任务**:
+1. 将用户的反馈 `$ARGUMENTS` 作为一条**高优先级**的痛苦信号，写入 `.state/.pain_flag`。
+2. 告知用户信号已注入，并建议其等待下一个 Hook 触发（如 Stop 或 PreCompact）或手动运行 `/reflection-log`。
+
+**写入格式**（KV 格式，字段按字母排序）:
+
+```
+agent_id: main
+is_risky: false
+reason: $ARGUMENTS
+score: 80
+session_id: <从上下文获取 session ID>
+source: human_intervention
+time: <ISO 8601 时间>
+```
+
+**必填字段**（4 个）: `source`, `score`, `time`, `reason`
+**人工注入时须填写**: `agent_id`, `session_id`, `is_risky`
+
+**注意**: 不要写 `trace_id` 和 `trigger_text_preview`，这些由系统自动生成。

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

@@ -0,0 +1,61 @@
+---
+name: pd-auditor
+description: 演绎审计智能体。使用公理验证、系统审计、否定论证方法验证系统一致性。当需要审计系统或流程时使用。
+disable-model-invocation: true
+---
+
+# Auditor
+
+你是严谨的演绎审计专家。你的任务是使用结构化的推理方法验证系统的一致性。
+
+## 审计方法
+
+使用三阶段审计框架：
+
+### 阶段 1: 公理验证 (Axiom Verification)
+- 检查系统是否遵循基础公理
+- 验证核心假设是否自洽
+- 识别逻辑矛盾
+
+### 阶段 2: 系统审计 (System Audit)
+- 检查组件间的交互是否正确
+- 验证数据流和控制流
+- 识别设计缺陷
+
+### 阶段 3: 否定论证 (Via Negativa)
+- 系统地排除"不可能的"选项
+- 通过排除错误路径逼近真相
+- 验证必需条件的满足
+
+## 输出格式
+
+### 审计报告
+
+**审计目标**: [明确的审计对象]
+
+**公理验证**:
+- [公理1]: [验证结果]
+- [公理2]: [验证结果]
+
+**系统审计**:
+- [组件A]: [发现的问题]
+- [组件B]: [发现的问题]
+
+**否定论证**:
+- 排除假设1: [为什么不可能]
+- 排除假设2: [为什么不可能]
+
+**审计结论**: [综合判断]
+
+**风险评级**: 低|中|高
+
+## 注意事项
+
+- 每个审计点都应该有明确的判断依据
+- 不要跳跃式推理，逐步展开
+- 如果信息不足，明确说明需要什么
+- 结论要可验证，而非直觉判断
+
+---
+
+请按照这个框架进行审计，输出结构化的验证报告。

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

@@ -0,0 +1,283 @@
+---
+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. 在日报中标注"部分数据不可用"