create-principles-disciple 1.145.13 → 1.145.15

package/workbuddy-adapter/plugin/skills/pd-cli-operator/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: pd-cli-operator
+description: 检查 WorkBuddy 中 PD 的运行状态、治理开关、worker 活性，或只读查询痛苦、任务和证据链。使用 WorkBuddy 固定治理工作区，不负责登记痛苦、Owner 审阅或启停操作。
+---
+
+# PD CLI Operator（WorkBuddy）
+
+## 工作区
+
+始终使用 WorkBuddy 固定治理工作区 `~/.workbuddy/pd-workspace`，先将 `~` 解析为当前用户主目录的绝对路径。不得切换到当前项目目录、Codex 工作区或 OpenClaw 工作区。
+
+## 检查步骤
+
+1. 先运行以下只读命令，确认 Runtime 功能和 worker 状态：
+
+       pd runtime features --workspace "<用户主目录>/.workbuddy/pd-workspace" --json
+       pd workbuddy worker --status --workspace "<用户主目录>/.workbuddy/pd-workspace" --json
+
+2. 按需使用 CLI 帮助确认其他只读命令的可用性，再查询痛苦、任务、运行记录、候选或证据链，例如 `pd pain list --workspace "<workspace>" --json`、`pd task show "<taskId>" --workspace "<workspace>" --json`、`pd run show "<runId>" --workspace "<workspace>"`、`pd runtime trace show --pain-id "<painId>" --workspace "<workspace>" --json`。其中 `<workspace>` 必须替换为上面的 WorkBuddy 固定治理工作区，不能换成当前项目目录。
+3. 报告真实输出中的 `host.workbuddy` 开关、worker 模式和错误原因。worker 已注册不等于 worker 正在运行；插件存在不等于技能已加载；健康检查通过不等于某条痛苦已经完成诊断。
+4. 追踪具体问题时使用登记回执中的真实 ID，逐段核实登记、诊断、候选准入和治理状态。
+
+## 失败处理
+
+命令缺失、安装不完整或状态不可读取时，保留真实错误和下一步建议。需要停用时使用 `pd-control`；需要审阅候选时使用 `pd-review`；需要登记 Owner 反馈时使用 `pd-pain-signal`。
+
+## 禁止
+
+- 不初始化项目目录或切换到其他宿主的治理库。
+- 不手工修改配置、数据库或内部工件。
+- 不将 worker 注册/插件存在描述为真实运行或行为生效。
+- 不通过 CLI 或脚本批准、拒绝或激活原则。

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

@@ -0,0 +1,31 @@
+---
+name: pd-control
+description: 当 Owner 明确要求管理 WorkBuddy 的 PD 接入、停用或修复时使用。当前随插件交付的控制脚本只提供停用操作；不得猜测启用命令或手工修改配置。
+---
+
+# PD Control（WorkBuddy）
+
+## 前提
+
+只在 Owner 明确要求停用 WorkBuddy PD 时执行操作。WorkBuddy 的固定治理工作区是 `~/.workbuddy/pd-workspace`；安装/注册插件不等于启用治理，插件默认状态为关闭。
+
+## 停用
+
+根据当前技能文件所在位置定位同一插件根目录，运行随插件交付的控制脚本：
+
+    node "<plugin-root>/scripts/pd-control.cjs" disable
+
+不要搜索任意 npm 缓存，也不要使用其他宿主的脚本。
+
+只有退出码为 0 且 JSON 回执确认 `ok=true`、`enabled=false`、`host=workbuddy` 时，才能报告停用成功。报告真实回执中的工作区与状态。新 Hook 调用读取该开关；已运行中的任务是否停止必须另行核验。
+
+## 安装、启用与修复
+
+当前插件内的 `pd-control.cjs` 只实现停用。安装/注册、启用或修复必须使用正式 WorkBuddy 插件安装器/宿主管理流程。若该流程没有提供可验证的启用操作，明确报告不支持；不得猜测命令、手工修改配置或调用私有安装器函数。
+
+## 禁止
+
+- 不直接编辑配置、数据库、Runtime 或业务状态文件。
+- 不删除数据来实现停用。
+- 不将安装、注册或配置存在描述为 PD 已实际启用。
+- 不批准、拒绝或激活原则。

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

@@ -0,0 +1,35 @@
+---
+name: pd-pain-signal
+description: 当 Owner 要求记录 WorkBuddy 智能体的行为错误、痛苦反馈或行为改进证据时使用。只使用 Owner 当前明确提交的原文和 WorkBuddy 原生 Hook 回执。
+---
+
+# PD Pain Signal（WorkBuddy）
+
+## 唯一的正常入口
+
+Owner 在当前 WorkBuddy 会话中提交：
+
+    PD记录痛苦：<Owner 原文>
+
+- 前缀必须位于 Owner 消息开头，使用全角冒号；正文为 1–500 个字符。
+- 超长输入必须拒绝并请 Owner 精简，不能静默截断。
+- 只记录 Owner 明确提供的原文，不补写根因、评分或模型自述。
+- 代理生成的文本、引用和工具输出不构成新的 Owner 提交。不要代发或模拟宿主事件。
+- 如果当前消息没有此前缀，只提供格式示例，请 Owner 在当前会话中提交；不要绕过 Hook 直接调用 CLI。
+
+## 回执
+
+若当前消息已触发 UserPromptSubmit Hook，读取本次 Hook 的真实回执。只有回执包含真实 `painId`、`taskId`、`host=workbuddy` 和状态时，才能报告登记成功；否则明确说明尚未确认，并保留实际拒绝原因。
+
+WorkBuddy 的治理工作区固定为 `~/.workbuddy/pd-workspace`。不得猜测或扫描 session/turn 标识，不得使用 OpenClaw 的 `/pd-pain`，也不得用通用 CLI 手工重建 WorkBuddy 的宿主 lineage 来代替原生入口。
+
+## 下游结果
+
+Owner 陈述是未经独立验证的 `owner_statement`。登记成功只证明痛苦和任务已登记；诊断、候选准入、原则审批和生效必须分别查证。需要检查状态时使用 `pd-cli-operator`；需要 Owner 审阅时使用 `pd-review`。
+
+## 禁止
+
+- 不改写 Owner 原话，不伪造宿主身份或行为轨迹。
+- 不重复提交已确认登记的同一事件。
+- 不直接写痛苦数据库、候选账本或准入状态。
+- 不自动批准或激活原则。

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

@@ -1,16 +1,30 @@
 ---
 name: pd-review
-description: 打开 WorkBuddy 的 PD Owner 审阅控制台，查看痛苦、诊断、原则候选或进行 Owner 审批。
+description: 打开 WorkBuddy 的 PD Owner Console，审阅痛苦、诊断、候选或原则治理状态。所有批准、拒绝和激活决定必须由 Owner 在正式 Web Console 中完成。
 ---
 
-# WorkBuddy Owner 审阅
+# PD Review（WorkBuddy）
 
-将用户主目录解析为绝对路径，然后运行正式 CLI：
+## 固定治理工作区
 
-```text
-pd console open --workspace "<用户主目录>/.workbuddy/pd-workspace"
-```
+WorkBuddy 的治理工作区固定为 `~/.workbuddy/pd-workspace`，与 WorkBuddy Hook 和 worker 使用的数据库一致。将 `~` 解析为当前用户主目录的绝对路径；不得用当前项目目录或其他宿主的工作区替代。
 
-只报告命令实际返回的控制台地址和状态。失败时保留错误原因，不声称已打开。此工作区与 WorkBuddy Hook、worker 使用的治理库相同；当前项目目录不能替代它。
+## 打开 Console
 
-Owner 在控制台审阅证据并决定批准、拒绝或关闭。展示 Owner 原话、模型诊断和已核实证据之间的区别。打开控制台不构成审批或激活，代理不得自动代替 Owner 决策。
+运行正式 CLI：
+
+    pd console open --workspace "<用户主目录>/.workbuddy/pd-workspace"
+
+只报告命令真实返回的 Console 地址和状态。失败时保留错误原因，不声称已打开；需要排查安装/运行状态时使用 `pd-cli-operator`，需要修复宿主接入时使用 `pd-control`。
+
+## Owner 治理
+
+帮助 Owner 区分原始反馈、宿主证据、模型诊断和准入决定。Owner 在 Console 中审阅证据并亲自批准、拒绝或完成其他治理动作。
+
+打开 Console 不构成审批；候选存在不代表已批准；批准不自动证明原则已激活或后续行为已改变。
+
+## 强制禁止
+
+- 不通过 CLI、脚本、数据库或文件批准、拒绝或激活原则。
+- Console 不可用时，不得切换到 CLI 审批。
+- 不伪造 Owner 已经作出的决定。

package/plugin/dist/templates/langs/en/skills/pd-implementer/SKILL.md

@@ -1,68 +0,0 @@
----
-name: pd-implementer
-description: Execute code modifications according to an approved plan inside Principles Disciple workflows. TRIGGER CONDITIONS: (1) An approved modification plan from a PD workflow has been received (2) The user explicitly asks to implement the PD planning result. General bug fixes and routine code-change requests that do not mention PD are out of scope.
-disable-model-invocation: true
----
-
-# Implementer
-
-You are a code implementation expert. Your task is to execute code modifications according to a plan.
-
-## Implementation Method
-
-Use a three-phase implementation framework:
-
-### Phase 1: Preparation
-- **Environment Confirmation**: Verify development environment is correct
-- **Backup**: Create necessary backups
-- **Dependency Check**: Confirm required dependencies are available
-
-### Phase 2: Execution
-- **Step-by-Step Implementation**: Execute according to plan
-- **Incremental Verification**: Verify after each step
-- **Error Handling**: Record and handle errors
-
-### Phase 3: Cleanup
-- **Testing**: Run tests to verify modifications
-- **Documentation**: Update related documentation
-- **Commit**: Create clean commits
-
-## Output Format
-
-### Implementation Report
-
-**Task Objective**: [Clear objective]
-
-**Preparation Phase**:
-- Environment check: [Result]
-- Backup creation: [Backup location]
-- Dependency verification: [Result]
-
-**Execution Phase**:
-
-**Step 1**: [Title]
-- Action: [Specific modifications]
-- Files: [Files involved]
-- Verification: [How to confirm success]
-
-**Steps 2-N**: [Similar structure]
-
-**Cleanup Phase**:
-- Test results: [Test output]
-- Documentation updates: [Updated docs]
-- Git commit: [commit hash]
-
-**Errors Encountered**: [Error records]
-
-**Final Status**: Success|Partial Success|Failure
-
-## Notes
-
-- Must understand plan intent before each step
-- Do not skip verification steps
-- If encountering out-of-plan issues, report rather than guess
-- Keep modifications atomic (small step commits)
-
----
-
-Please follow this framework to implement code and output a structured execution report.

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

@@ -1,185 +0,0 @@
----
-name: pd-mentor
-description: Interactive command guidance and scenario-based recommendations for using Principles Disciple itself, including PD-guided workspace cleaning and routine maintenance. TRIGGER CONDITIONS: (1) The user explicitly asks about Principles Disciple / PD usage, commands, configuration, or workflows (2) The user explicitly asks to use PD built-in capabilities for a governance goal (3) The user asks for PD-guided workspace cleaning or routine maintenance. General programming, debugging, project-introduction, or file-finding requests are out of scope.
-disable-model-invocation: true
----
-
-# /pd-mentor: Spicy Mentor
-
-I'm your intelligent mentor, helping you understand and use all features of Principles Disciple.
-
-**Remember: Pain is the fuel of evolution, and I'm the one who lights the fire.**
-
----
-
-## Execution Principles
-
-1. **Scenario-based Guidance**: Recommend the most appropriate commands based on user's current task
-2. **Interactive Q&A**: Use AskUserQuestion to understand user intent
-3. **Flowchart Display**: Visualize SOP processes
-4. **Options First**: Provide preset options to reduce typing burden
-
----
-
-## Command Index
-
-| Command | Purpose | Use Case |
-|---------|---------|----------|
-| `/pd-init` | Initialize strategy | New project startup |
-| `/pd-bootstrap` | Environment tool scan and upgrade | Tool upgrade |
-| `/pd-research` | Initiate tool upgrade research | Deep research |
-| `/pd-status` | View system status (GFI and Pain Dictionary) | Health check |
-| `/pd-help` | Get interactive command guidance | This skill |
-
----
-
-## Scenario Matching
-
-### Scenario 1: New Project Initialization
-
-**Trigger**: The user explicitly mentions onboarding a new project with Principles Disciple and asks for PD setup guidance
-
-**Recommended Flow**:
-1. `/pd-init` - Establish strategic vision
-2. `/pd-bootstrap` - Scan environment tools, get capability list
-3. `/pd-context thinking on` - Enable Thinking OS guidance injection
-
-**Script**: "A new project is like a blank canvas. Let me help you lay the foundation: strategy first, then equipment, finally mental framework."
-
----
-
-### Scenario 2: Bug Fix Needed
-
-**Trigger**: The user explicitly reports a problem with Principles Disciple / PD itself (a PD command failing, runtime status issues, security-stage questions)
-
-**Recommended Flow**:
-1. `/pd-status` - Check system status (GFI and Pain Dictionary)
-
-**Script**: "Problems are the fuel of evolution. Let me help you diagnose and fix systematically."
-
----
-
-### Scenario 3: Daily Maintenance & Review
-
-**Trigger**: The user explicitly asks for a Principles Disciple progress or health review (mentioning PD, EP, GFI, or system status)
-
-**Recommended Flow**:
-1. `/pd-status` - Check GFI and Pain Dictionary status
-
-**Script**: "Let me help you review the current system status."
-
----
-
-### Scenario 4: Permission or Security Related
-
-**Trigger**: The user asks about Principles Disciple permissions, blocks, or security stages
-
-**Recommended Flow**:
-1. `/pd-status` - Check system status
-2. Explain current stage's capability boundaries
-
-**Script**: "Trust is earned, not given. Let me help you understand your current security level."
-
----
-
-### Scenario 6: Tool Upgrade Needs
-
-**Trigger**: The user explicitly asks to use PD's environment scan or tool-research capabilities
-
-**Recommended Flow**:
-1. `/pd-bootstrap` - Scan current environment
-2. `/pd-research` - Initiate research for specific tools
-
-**Script**: "Tool upgrades are the guarantee of combat capability. Let me help you scan and plan."
-
----
-
-## SOP Flowchart
-
-```
-┌─────────────────────────────────────────────────────────┐
-│              Evolution Loop SOP                         │
-├─────────────────────────────────────────────────────────┤
-│                                                         │
-│  Step 1: TRIAGE                                         │
-│     └─→ Collect evidence, reproduction steps, risk      │
-│                                                         │
-│  Step 2: DIAGNOSIS                                      │
-│     └─→ Root cause analysis, impact assessment          │
-│                                                         │
-│  Step 3: AUDIT                                          │
-│     └─→ Security check, logic verification             │
-│                                                         │
-│  Step 4: PLAN                                           │
-│     └─→ Target files, execution steps, rollback plan   │
-│                                                         │
-│  Step 5: EXECUTE                                        │
-│     └─→ Modify code according to plan                   │
-│                                                         │
-│  Step 6: VERIFY                                         │
-│     └─→ Run tests, check metrics                        │
-│                                                         │
-│  Step 7: REVIEW                                         │
-│     └─→ Code review, quality assessment                 │
-│                                                         │
-│  Step 8: LOG                                            │
-│     └─→ Record lessons learned, update principles       │
-│                                                         │
-└─────────────────────────────────────────────────────────┘
-```
-
----
-
-## Execution Flow
-
-### Step 1: Intent Recognition
-
-Use `AskUserQuestion` to ask user about current task scenario:
-
-**Options**:
-- 🆕 New project initialization
-- 🐛 Bug fix
-- 📊 Daily review
-- 🧹 Workspace cleanup
-- 🔐 Permission/Security
-- 🔧 Tool upgrade
-- ❓ Other
-
-### Step 2: Scenario Matching
-
-Based on user's selected scenario, recommend corresponding command flow.
-
-### Step 3: Confirm Execution
-
-Ask user if they want to execute a command:
-- "Execute `/pd-xxx` command now?"
-- "Need me to explain this command in detail?"
-
----
-
-## FAQ
-
-**Q: What is GFI (Friction Index)?**
-A: GFI (Global Friction Index) measures the system's "pain level", range 0-100. Higher values indicate more friction, requiring attention.
-
-**Q: How is EP (Evolution Points) calculated?**
-A: EP is earned through successful task completion and problem resolution. Failures may deduct EP but have protection mechanisms. Reaching EP thresholds automatically upgrades your tier, unlocking more permissions (larger code modification limits).
-
-**Q: What is Pain Signal?**
-A: Pain Signal is a problem signal detected by the system. Runtime V2 routes it through `PainSignalBridge`; manual triggers use `pd pain record`. `.state/.pain_flag` is legacy compatibility only.
-
-**Q: How to view installed tool capabilities?**
-A: Check `.state/SYSTEM_CAPABILITIES.json` or run `/pd-bootstrap` to rescan.
-
-**Q: What's the difference between Thinking OS and `/pd-research`?**
-A: Thinking OS is injected guidance (managed via `/pd-context thinking on/off`); `/pd-research` initiates tool upgrade research for technical investigation.
-
----
-
-## Closing
-
-**Remember our creed**:
-
-> "Pain is the fuel of evolution, reflection is the ladder of progress."
-
-For any questions, feel free to call `/pd-help` or ask me directly. I'm your Spicy Mentor, evolving with you.

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

@@ -1,86 +0,0 @@
----
-name: pd-runtime-v2
-description: Use this skill when manually triggering, verifying, or debugging Principles Disciple Runtime V2 pain diagnosis. It enforces the Runtime V2 entrypoints: high-value gated automatic pain events and `pd pain record` for manual diagnosis. It forbids writing `.state/.pain_flag` directly.
-disable-model-invocation: false
----
-
-# PD Runtime V2 Pain Diagnosis
-
-Use Runtime V2 for all pain diagnosis work. Do not use legacy pain flag files as an entrypoint.
-
-## Entry Points
-
-Automatic:
-- Tool failures first accumulate GFI/friction.
-- Only high-value episodes enter Runtime V2: high GFI, repeated same failure, severe semantic pain, LLM paralysis, or explicit manual pain.
-- Approved `pain_detected` events enter `PainSignalBridge`.
-- The bridge runs `SplitDiagnosticianRunner`, commits candidates, and intakes them into the ledger.
-
-Manual:
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
-`--session` binds the report to a recorded session (validated up front) so
-diagnosis carries real trajectory evidence; when the binding is verified but
-the trajectory evidence is empty or unreadable, the record degrades honestly
-to bound + evidence-unavailable and the admission gate decides; without
-`--session` the record is a legal unbound Owner report with no evidence and
-its candidates will likely be gated.
-
-Forbidden:
-- Do not write `.state/.pain_flag`.
-- Do not use `write_file`, shell redirection, `Set-Content`, `Out-File`, `node -e`, or any other file-writing method to create `.state/.pain_flag`.
-- Do not use a `write_pain_flag` tool. Runtime V2 does not use that tool.
-
-## Status Commands
-
-Runtime health:
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-```
-
-Flow policy:
-```bash
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-Trace pain-to-ledger chain (PRI-455 promoted):
-```bash
-pd trace show --pain-id "<painId>" --workspace "<workspace>" --json
-```
-
-Activation status (PRI-455 promoted):
-```bash
-pd activation list --workspace "<workspace>" --json
-```
-
-Candidates:
-```bash
-pd candidate list --workspace "<workspace>" --json
-pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
-```
-
-## Success Criteria
-
-A pain travels through four stages: record receipt (`painId`) → diagnosis
-(produces candidates) → admission (`admitted`, into the ledger) → Owner
-approval and activation.
-
-A diagnosis is successful only when:
-- `status` is `succeeded`
-- `candidateIds` is non-empty
-- `admissionResults` contains `admitted` decisions with non-empty
-  `ledgerEntryIds`
-
-Task creation alone, candidate generation alone, or a ledger entry alone is
-not success — candidates without an `admitted` decision were never admitted.
-Activation is a separate stage that follows Owner approval; `pd pain record`
-never activates anything by itself.
-
-## If Manual Diagnosis Is Needed
-
-1. Use `pd pain record`.
-2. Inspect JSON output.
-3. If `candidateIds` or `ledgerEntryIds` is empty, or candidates are gated as
-   `needs_evidence` / `deferred`, treat it as not completed (not internalized).
-4. Use `pd candidate list/show` and `pd runtime flow show` for follow-up.

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

@@ -1,68 +0,0 @@
----
-name: pd-implementer
-description: 在 Principles Disciple 工作流中，按已审批的计划执行代码修改。TRIGGER CONDITIONS: (1) 收到 PD 流程中已审批的修改计划 (2) 用户明确要求按 PD 规划结果实施。一般 Bug 修复、未提及 PD 的常规代码修改请求不属于本技能。
-disable-model-invocation: true
----
-
-# Implementer
-
-你是代码实现专家。你的任务是按照计划执行代码修改。
-
-## 实施方法
-
-使用三阶段实施框架：
-
-### 阶段 1: 准备阶段
-- **环境确认**: 验证开发环境正确
-- **备份**: 创建必要的备份
-- **依赖检查**: 确认所需依赖可用
-
-### 阶段 2: 执行阶段
-- **逐步实施**: 按计划顺序执行
-- **增量验证**: 每步完成后验证
-- **错误处理**: 记录并处理错误
-
-### 阶段 3: 清理阶段
-- **测试**: 运行测试验证修改
-- **文档**: 更新相关文档
-- **提交**: 创建干净的提交
-
-## 输出格式
-
-### 实施报告
-
-**任务目标**: [明确的目标]
-
-**准备阶段**:
-- 环境检查: [结果]
-- 备份创建: [备份位置]
-- 依赖验证: [结果]
-
-**执行阶段**:
-
-**步骤 1**: [标题]
-- 行动: [具体修改]
-- 文件: [涉及的文件]
-- 验证: [如何确认成功]
-
-**步骤 2-N**: [类似结构]
-
-**清理阶段**:
-- 测试结果: [测试输出]
-- 文档更新: [更新的文档]
-- Git 提交: [commit hash]
-
-**遇到的错误**: [错误记录]
-
-**最终状态**: 成功|部分成功|失败
-
-## 注意事项
-
-- 每步执行前必须理解计划意图
-- 不要跳过验证步骤
-- 如果遇到计划外问题，报告而非猜测
-- 保持修改的原子性（小步提交）
-
----
-
-请按照这个框架实施代码，输出结构化的执行报告。