create-principles-disciple 1.145.12 → 1.145.15

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

@@ -1,185 +0,0 @@
----
-name: pd-mentor
-description: 交互式命令引导和场景化推荐，帮助用户理解和使用 Principles Disciple 本身，包括 PD 引导的工作区清理与健康检查等日常维护。TRIGGER CONDITIONS: (1) 用户明确询问 Principles Disciple / PD 的用法、命令、配置或工作流 (2) 用户明确要求使用 PD 内置能力完成当前治理目标 (3) 用户要求 PD 引导的工作区清理或日常维护。一般编程、调试、项目介绍、文件查找请求不属于本技能。
-disable-model-invocation: true
----
-
-# /pd-mentor: 麻辣导师
-
-我是你的智能导师，帮助你理解和使用 Principles Disciple 的各项功能。
-
-**记住：痛是进化的燃料，而我是点火的人。**
-
----
-
-## 执行原则
-
-1. **场景化引导**: 根据用户当前任务推荐最合适的命令
-2. **交互式问答**: 使用 AskUserQuestion 了解用户意图
-3. **流程图展示**: 可视化展示 SOP 流程
-4. **选择题优先**: 提供预设选项，减少用户输入负担
-
----
-
-## 命令索引
-
-| 命令 | 用途 | 适用场景 |
-|------|------|----------|
-| `/pd-init` | 初始化战略 | 新项目启动 |
-| `/pd-bootstrap` | 环境工具扫描与升级 | 装备升级 |
-| `/pd-research` | 发起工具升级研究 | 深度调研 |
-| `/pd-status` | 查看系统状态（GFI和痛苦词典） | 健康检查 |
-| `/pd-help` | 获取交互式命令引导 | 本技能 |
-
----
-
-## 场景匹配
-
-### 场景 1: 新项目初始化
-
-**触发条件**: 用户明确提到要为新建项目启用 Principles Disciple，并要求 PD 初始化指引
-
-**推荐流程**:
-1. `/pd-init` - 建立战略愿景和 OKR 框架
-2. `/pd-bootstrap` - 扫描环境工具，获取能力清单
-3. `/pd-context thinking on` - 开启 Thinking OS 指引注入
-
-**话术**: "新项目就像一张白纸。让我帮你打好地基：先定战略、再配装备、最后建立思维框架。"
-
----
-
-### 场景 2: 遇到 Bug 需要修复
-
-**触发条件**: 用户明确报告 Principles Disciple / PD 本身的问题（PD 命令失败、runtime 状态异常、安全等级疑问）
-
-**推荐流程**:
-1. `/pd-status` - 检查系统状态（GFI 和痛苦词典）
-
-**话术**: "问题就是进化的燃料。让我帮你系统化地诊断和修复。"
-
----
-
-### 场景 3: 日常维护与回顾
-
-**触发条件**: 用户明确要求 Principles Disciple 的进度或健康回顾（提及 PD、EP、GFI、系统状态）
-
-**推荐流程**:
-1. `/pd-status` - 查看 GFI 和痛苦词典状态
-
-**话术**: "让我帮你回顾一下系统状态。"
-
----
-
-### 场景 4: 权限或安全相关
-
-**触发条件**: 用户询问 Principles Disciple 的权限、拦截或安全等级
-
-**推荐流程**:
-1. `/pd-status` - 查看系统状态
-2. 解释当前等级的能力边界
-
-**话术**: "信任是挣来的，不是给的。让我帮你了解当前的安全等级。"
-
----
-
-### 场景 6: 工具升级需求
-
-**触发条件**: 用户明确要求使用 PD 的环境扫描或工具研究能力
-
-**推荐流程**:
-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` 命令？"
-- "需要我详细解释这个命令的作用吗？"
-
----
-
-## 常见问题 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: Thinking OS 和 `/pd-research` 有什么区别？**
-A: Thinking OS 是注入的指引（通过 `/pd-context thinking on/off` 管理）；`/pd-research` 发起工具升级研究，用于技术调研。
-
----
-
-## 结语
-
-**记住我们的信条**：
-
-> "痛苦是进化的燃料，反思是进步的阶梯。"
-
-如有任何问题，随时调用 `/pd-help` 或直接问我。我是你的麻辣导师，陪你一起进化。

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

@@ -1,81 +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 调用 `SplitDiagnosticianRunner`，提交 candidate，并 intake 到 ledger。
-
-手动入口：
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
-`--session` 把报告绑定到已记录的会话（先校验），让诊断携带真实轨迹
-证据；会话验证通过但轨迹证据为空或不可读时，按 bound + 证据不可用诚实
-降级提交，由 admission gate 评判；不带 `--session` 则是无证据的 unbound
-Owner 报告（合法），候选大概率被拦。
-
-禁止入口：
-- 不要写 `.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
-```
-
-追踪痛苦到原则链（PRI-455 提升）：
-```bash
-pd trace show --pain-id "<painId>" --workspace "<workspace>" --json
-```
-
-激活状态（PRI-455 提升）：
-```bash
-pd activation list --workspace "<workspace>" --json
-```
-
-候选原则：
-```bash
-pd candidate list --workspace "<workspace>" --json
-pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
-```
-
-## 成功标准
-
-一条痛苦的完整链路分四个阶段：记录回执（`painId`）→ 诊断（产出候选）→
-准入（`admitted`，进入 ledger）→ Owner 批准与激活（activation）。
-
-一次诊断只有在同时满足以下条件时才算成功：
-- `status` 是 `succeeded`
-- `candidateIds` 非空
-- `admissionResults` 中出现 `admitted` 决策，且对应 `ledgerEntryIds` 非空
-
-只创建 task、只生成候选或只有 ledger entry 都不算成功——没有 `admitted`
-决策的候选并未被准入。激活是 Owner 决策之后的独立阶段，`pd pain record`
-不会直接产生激活。
-
-## 需要手动诊断时
-
-1. 使用 `pd pain record`。
-2. 检查 JSON 输出。
-3. 如果 `candidateIds` 或 `ledgerEntryIds` 为空，或候选被拦为
-   `needs_evidence` / `deferred`，视为未完成（未内化）。
-4. 用 `pd candidate list/show` 和 `pd runtime flow show` 继续排查。

package/workbuddy-adapter/plugin/skills/pd-disable/SKILL.md

@@ -1,18 +0,0 @@
----
-name: pd-disable
-description: 当 Owner 要求停止或关闭 WorkBuddy 的 Principles Disciple 行为时，关闭此宿主治理开关并保留数据。
----
-
-# 关闭 WorkBuddy PD
-
-Owner 的关闭请求已经授权这次操作。根据本技能文件的路径定位同一插件根目录（`skills/pd-disable/SKILL.md` 的上三级目录），运行随插件交付的控制脚本：
-
-```text
-node "<插件根目录>/scripts/pd-control.cjs" disable
-```
-
-脚本调用正式安装器的 `setWorkbuddyGovernanceFlag` API，在用户固定工作区 `~/.workbuddy/pd-workspace` 关闭 `host.workbuddy` 并读回验证。它保留治理数据和其他宿主配置，不手工修改数据库或已安装运行时代码。
-
-只有退出码为 0 且 JSON 回执 `ok=true`、`enabled=false`、`host=workbuddy` 时才确认开关已关闭。报告回执中的工作区和状态；新 Hook 调用将读取该配置。已运行中的任务是否停止须另查证。
-
-如果正式安装器 API 或工作区缺失，脚本明确失败；按回执使用官方安装/修复流程恢复能力。不要搜索 npm 缓存、拼装第二套写开关逻辑或用删除文件替代关闭。

package/workbuddy-adapter/plugin/skills/pd-record-pain/SKILL.md

@@ -1,21 +0,0 @@
----
-name: pd-record-pain
-description: 记录 WorkBuddy 行为失误或痛苦反馈。当 Owner 要求登记痛苦、记录错误或留下行为改进证据时使用。
----
-
-# WorkBuddy 痛苦登记
-
-入口是 Owner 在当前 WorkBuddy 会话提交的一条消息：
-
-```text
-PD记录痛苦：<Owner 原文>
-```
-
-1. 仅使用当前 Owner 明确提供的陈述，正文须为 1–500 个字符。保留原文，不补写技术根因、评分或模型自述；超长时请 Owner 提供较短原文，不静默截断。
-2. 若当前消息已以 `PD记录痛苦：` 开头，检查本次 UserPromptSubmit Hook 的真实回执。Hook 使用宿主的会话标识登记到 `~/.workbuddy/pd-workspace`。
-3. 若 Owner 仅要求登记而消息没有该前缀，给出带前缀和 Owner 原文的完整消息，请 Owner 在当前会话提交。代理输出、引用和工具输出不构成新的 Owner 提交。不要代发或模拟宿主事件。
-4. 只有回执包含真实 `painId`、`taskId`、`host=workbuddy` 和状态时才报告登记成功；原样呈现这些字段。缺失回执或返回拒绝时，说明尚未确认登记并报告真实原因，使用 `pd-status` 检查运行状态。
-
-Owner 陈述是未经独立验证的 `owner_statement`。登记成功只证明痛苦和任务已登记；诊断、准入、原则审批和生效须分别查证。Owner 审批沿用 `pd-review`，不得自动批准或激活。
-
-此入口不要求模型猜测 session/turn 标识或扫描最新会话。不要改用 OpenClaw `/pd-pain` 或 CLI `pd pain record --host workbuddy`，也不要通过省略宿主参数绕过限制。

package/workbuddy-adapter/plugin/skills/pd-status/SKILL.md

@@ -1,17 +0,0 @@
----
-name: pd-status
-description: 检查 WorkBuddy 的 Principles Disciple 运行状态、治理开关或诊断 worker 状态。
----
-
-# WorkBuddy PD 状态
-
-使用当前用户固定治理工作区 `~/.workbuddy/pd-workspace`，将 `~` 解析为操作系统用户主目录的绝对路径，再运行：
-
-```text
-pd runtime features --workspace "<用户主目录>/.workbuddy/pd-workspace" --json
-pd workbuddy worker --status --workspace "<用户主目录>/.workbuddy/pd-workspace" --json
-```
-
-报告实际命令结果、`host.workbuddy` 有效开关和 worker 模式；命令失败或安装缺失时如实报告错误，建议通过正式安装器修复。不要初始化项目目录或切换到其他宿主的治理库。
-
-worker 状态不证明当前痛苦已完成诊断，插件存在也不证明技能已加载或原则已生效。核对具体任务应使用真实登记回执中的 ID，在 `pd-review` 指向的同一工作区审阅。