principles-disciple 2.1.10 → 2.2.0

package/templates/langs/en/skills/pd-control/SKILL.md

@@ -0,0 +1,50 @@
+---
+name: pd-control
+description: Use when the Owner explicitly requests installation, initialization, disablement, re-enablement, or repair of PD host integration. Use only management entrypoints supported by the current host; do not edit configuration or business state directly.
+disable-model-invocation: false
+---
+
+# PD Control
+
+## Purpose
+
+Manage PD integration through the official installer and host management surface. This skill is a constrained router; it does not duplicate installer logic or mutate principle, candidate, task, or ledger state.
+
+## Current OpenClaw support
+
+### Install or initialize
+
+Only when the Owner explicitly requests installation/initialization, use the documented non-interactive installer:
+
+    npx create-principles-disciple --yes
+
+Check the installed version's help and prerequisites first. Do not claim success when authorization, network, or dependency requirements are missing. After installation, use `pd-cli-operator` for a read-only health check.
+
+### Disable
+
+Only when the Owner explicitly requests disablement, run:
+
+    openclaw plugins disable principles-disciple
+
+This uses OpenClaw's official plugin-management route and does not delete installed files. Then inspect `openclaw plugins list --enabled --json` and confirm `principles-disciple` is no longer enabled. When a Gateway is running, the command applies the state change through that Gateway; distinguish a disabled switch from proof that every previously started task has stopped.
+
+### Enable or resume
+
+Only when the Owner explicitly requests enablement, run:
+
+    openclaw plugins enable principles-disciple
+
+If the command reports capability consent, allowlist, denylist, or another policy block, do not automatically add `--accept-capabilities` and do not edit `openclaw.json` by hand. Preserve the full receipt and explain the required choice or policy issue to the Owner. Continue with the exact retry command returned by OpenClaw only after the Owner explicitly consents to the requested capabilities.
+
+Afterward, inspect `openclaw plugins list --enabled --json`, then run `openclaw plugins inspect principles-disciple --runtime --json` to check registered runtime capabilities. A cold inventory or inspect result alone still does not prove a real Hook is effective; when needed, verify with a safe real host event.
+
+## Success criteria
+
+Distinguish installer success, host plugin discovery, actual Hook execution, and PD business-pipeline health. Each requires its own receipt or runtime evidence. Plugin presence does not prove it is enabled, and installation does not prove Runtime health.
+
+## Never
+
+- Edit host configuration or PD state files by hand.
+- Overwrite user configuration or delete business data to disable PD.
+- Approve, reject, or activate principles through CLI, scripts, or another skill.
+- Report an unverified host operation as successful.

package/templates/langs/en/skills/pd-pain-signal/SKILL.md

@@ -1,71 +1,45 @@
 ---
 name: pd-pain-signal
-description: Manually trigger a Principles Disciple Runtime V2 pain diagnosis. Use this when the user reports the agent is stuck, looping, unresponsive, or asks to record/trigger a pain signal. In an OpenClaw session, direct the Owner to the /pd-pain command (it binds the real session automatically). From outside a session, use `pd pain record --session <id>`. Never write `.state/.pain_flag` and never use legacy write_pain_flag tooling.
+description: Use when the Owner explicitly asks to record an agent behavior problem, register a pain signal, or trace whether feedback entered the diagnostic pipeline. Automatic pain detection remains the responsibility of existing hooks, host entrypoints, and Runtime.
 disable-model-invocation: false
 ---
 
-# Pain Signal (Runtime V2)
+# PD Pain Signal
 
-Session evidence is what lets a diagnosis carry real trajectory evidence. A
-pain recorded without a session is a legal unbound Owner report: it carries no
-trajectory evidence, its diagnosis confidence tends to be low, and its
-candidates are likely gated as `needs_evidence` by the admission gate — the
-Owner's report is stored, but usually nothing is internalized.
+## Purpose
 
-## In an OpenClaw session (preferred)
+Send the Owner's real behavior feedback through the existing PD pain-registration and diagnosis pipeline while preserving the original statement, source, and available session evidence. This skill does not reimplement detection, deduplication, admission, or diagnosis.
 
-Ask the Owner to run the host command in the conversation where the pain
-occurred:
+## Steps
 
-```text
-/pd-pain <describe the issue>
-```
+1. **Check whether it was already recorded.** The current message may already have been handled by a hook or host entrypoint. If a real receipt exists, reuse its pain/task IDs. Do not submit a duplicate. If registration is not observable, do not claim success or blindly retry.
+2. **Preserve the Owner's words.** Use only a statement the Owner explicitly provided. Do not add a technical root cause, score, or tool-failure fact. Quoted text, tool output, and model paraphrases must not be presented as a new Owner submission.
+3. **Use the trusted host entrypoint.**
+   - In the OpenClaw session where the issue occurred, when the Owner explicitly requests registration, use the host command `/pd-pain <issue description>`. OpenClaw binds the authenticated current session.
+   - Outside the session, use the CLI only with a known, validated session: `pd pain record --reason "<reason>" --workspace "<workspace>" --session "<session-id>" --json`.
+4. **Do not guess session IDs.** Never scan the database, pick the "latest" session, or substitute another host's ID. If the required session identity is missing, stop that CLI path and explain why.
+5. **Verify the receipt.** Report registration only when the actual receipt confirms it. Without a receipt, say registration is unconfirmed.
 
-`/pd-pain` receives the authenticated current session from OpenClaw and
-submits the session's trajectory evidence automatically. You cannot obtain a
-trusted session ID yourself (none is injected into tool executions); never
-guess, scan, or pick the "latest" session.
+## Evidence and success criteria
 
-## Outside a session (CLI)
+- A real pain ID proves only that registration returned a receipt, not that diagnosis completed.
+- Generated candidates are not necessarily admitted.
+- Check the actual `admissionResults` / `candidateOutcomes` for an `admitted` decision and its non-empty `ledgerEntryIds`. A non-empty `candidateIds` alone is not success.
+- Report `needs_evidence`, `deferred`, and explicit admission rejection honestly. Never bypass the admission gate or fabricate trajectory evidence to increase confidence.
+- The Owner's statement, host trajectory, model diagnosis, admission result, Owner approval, and activation state are distinct evidence types.
 
-Bind an explicitly known session id recorded in this workspace:
+## Failure handling
 
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
+- Registration failure: preserve the real error and the host-provided next action.
+- Duplicate risk: check existing receipts and idempotency first.
+- Missing or untrusted session: stop; never guess.
+- CLI/hook unavailable: ask `pd-cli-operator` to inspect status; route installation repair to `pd-control`.
+- If the Owner wants to inspect resulting candidates, use `pd-review` to open the Console; do not re-register the same feedback.
 
-- `--session <id>` is validated against the workspace trajectory: a missing
-  session fails with `session_not_found` before anything is written.
-- When the `--session` binding is verified but the trajectory evidence is
-  empty or unreadable (the session is real), the record is submitted as an
-  honest bound + evidence-unavailable degrade: no evidence is fabricated and
-  the admission gate decides what empty evidence is worth, instead of a hard
-  refusal.
-- Recording without `--session` is allowed as an unbound Owner report, but it
-  attaches no evidence and its candidates will likely be gated
-  (`needs_evidence`) by the admission gate — the CLI output says so explicitly.
+## Never
 
-## Forbidden
-
-- Do not write `.state/.pain_flag` directly.
-- 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 `write_pain_flag`. That was a legacy path.
-- Do not guess, scan for, or infer a session ID. Use `/pd-pain` or an id the Owner provides.
-
-## Verify
-
-Use:
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-pd candidate list --workspace "<workspace>" --json
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-Success requires admitted candidates, not merely generated ones: check
-`admissionResults` for `admitted` decisions and non-empty `ledgerEntryIds`.
-A successful command returning a `painId` is only a record receipt — it does
-not mean the diagnosis produced candidates or that anything was admitted.
-Candidates reported as `needs_evidence` or `deferred` were NOT internalized —
-if candidates are gated, re-record with `/pd-pain` or `--session` so the
-diagnosis carries real trajectory evidence. Activation is a separate stage
-that follows Owner approval; this flow never activates anything by itself.
+- Write `.state/.pain_flag` or call legacy `write_pain_flag`.
+- Fabricate the Owner's words, session ID, turn ID, or tool failure.
+- Re-submit an event whose registration is confirmed.
+- Modify the pain database, candidate ledger, or admission state directly.
+- Approve, activate, or edit a principle.

package/templates/langs/en/skills/pd-review/SKILL.md

@@ -0,0 +1,32 @@
+---
+name: pd-review
+description: Use when the Owner wants to inspect PD diagnoses, principle candidates, or governance state, or asks to approve, reject, or activate a principle. Every Owner decision must be completed by the Owner in the official Web Console.
+disable-model-invocation: false
+---
+
+# PD Review
+
+## Purpose
+
+Help the Owner inspect real evidence and reach the official PD governance interface. The skill may query, explain, and open the Console, but it cannot make the decision for the Owner.
+
+## Workflow
+
+1. Confirm the task concerns PD pain, diagnosis, candidates, or principle governance—not ordinary code review.
+2. Use `pd-cli-operator` or an existing real receipt to verify state. Distinguish the Owner's statement, host trajectory, model diagnosis, admission decision, and completed governance action.
+3. Open the Console using the workspace confirmed by the current OpenClaw host: `pd console open --workspace "<workspace>"`. Never guess the workspace.
+4. Report that the Console started only when the command returns real success. If it fails, preserve the error and route host-installation diagnosis to `pd-control`.
+5. Ask the Owner to inspect the evidence and personally complete approval, rejection, or another governance action in the Console.
+
+## State boundaries
+
+- A candidate's existence does not mean it was approved.
+- Opening the Console does not mean it was approved.
+- The Owner saying "approve" does not prove the Console action has completed.
+- Approval, activation, and a subsequent behavior change are separate stages and must be verified separately.
+
+## Never
+
+- Approve, reject, or activate a principle through CLI, scripts, databases, files, or another skill.
+- Fall back to CLI approval when the Console is unavailable.
+- Fabricate an Owner decision or describe candidate generation/admission as activation.

package/templates/langs/zh/skills/pd-cli-operator/SKILL.md

@@ -1,85 +1,52 @@
 ---
 name: pd-cli-operator
-description: 操作 Principles Disciple `pd` CLI 时使用：运行时健康检查、手动记录痛苦、查看 task/run/candidate/artifact、intake candidate、查看 flow policy、追踪痛苦到原则的证据链。本技能提供安全 CLI 路由，并禁止直接写 `.state/.pain_flag`。
+description: 当需要只读检查 PD 运行健康、查询痛苦/任务/运行/候选/工件，或追踪痛苦到原则的证据链时使用。用于 PD CLI 与 Runtime 排障；不用于登记痛苦、Owner 治理审阅或宿主管理。
 disable-model-invocation: false
 ---
 
 # PD CLI Operator
 
-把 `pd` CLI 当作唯一受支持的操作界面。不要手工修改 PD state 文件，除非某个 CLI 命令明确要求这样做。
+通过现有 PD CLI 查询事实、定位链路断点，并给出基于证据的结论。本技能只负责操作路由，不实现第二套业务逻辑。
 
-## Runtime V2 痛苦诊断
+## 工作流程
 
-手动痛苦诊断（绑定已记录的会话，让诊断携带真实轨迹证据）：
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
+1. **确认工作区。** 使用当前 OpenClaw 宿主/插件上下文提供的权威工作区。命令要求 `--workspace` 时传入已确认的绝对路径。无法确定工作区就先报告阻塞，不要从当前目录、最近目录或其他宿主猜测。
+2. **发现真实命令。** 先检查 `pd --help`，再检查目标命令的 `--help`。命令名和参数以当前安装版本为准。
+3. **优先只读检查。** 按问题选择最少的查询命令，不遍历无关工作区。
+4. **逐段追踪。** 分别核实痛苦登记、诊断任务、运行结果、候选、准入和 Owner 治理结果，不由单个状态字段推断整条链路已完成。
+5. **报告证据。** 说明已确认事实、未知部分、阻塞层和下一步；区分命令成功与业务目标成功。
 
-- 不带 `--session` 的记录是诚实的 unbound Owner 报告：没有轨迹证据，
-  候选大概率被准入阈值拦为 `needs_evidence` —— CLI 输出会明确警告。
-- `--session <id>` 会先校验；会话不存在时以 `session_not_found` 失败，
-  不会写入任何内容。会话验证通过但轨迹证据为空或不可读时，按
-  bound + 证据不可用诚实降级提交，由 admission gate 评判，不会伪造证据。
-- 命令成功返回 `painId` 只代表记录回执；诊断是否产出候选、候选是否被
-  准入，以 JSON 输出中的 `candidateIds` / `admissionResults` /
-  `ledgerEntryIds` 为准。激活是 Owner 批准之后的独立阶段。
+## 常用只读命令
 
-成功标准：
-- `status` 是 `succeeded`
-- 候选被**准入**而非仅被生成：检查 `admissionResults` /
-  `candidateOutcomes` 中的 `admitted` 决策和 `ledgerEntryIds` 非空
+先确认当前 CLI 支持这些命令，再按需执行：
 
-禁止：
-- 不要写 `.state/.pain_flag`。
-- 不要用 `write_file`、shell 重定向、`Set-Content`、`Out-File` 或 `node -e` 创建 pain flag。
+- 健康检查：`pd health --workspace "<workspace>" --json`
+- Runtime 探针：`pd runtime probe --runtime pi-ai --workspace "<workspace>" --json`
+- 流程策略：`pd runtime flow show --workspace "<workspace>" --json`
+- 痛苦列表与准入证据：`pd pain list --workspace "<workspace>" --json`、`pd pain evidence --workspace "<workspace>" --json`
+- 痛苦到原则的追踪：`pd runtime trace show --pain-id "<painId>" --workspace "<workspace>" --json`
+- 任务与运行：`pd task show "<taskId>" --workspace "<workspace>" --json`、`pd run show "<runId>" --workspace "<workspace>"`
+- 候选与工件：`pd candidate list --task-id "<taskId>" --workspace "<workspace>" --json`、`pd candidate show "<candidateId>" --workspace "<workspace>" --json`、`pd artifact show "<artifactId>" --workspace "<workspace>" --json`
 
-## 健康检查和策略
+OpenClaw 的 `/pd-status` 主要展示 GFI/Pain 词典等宿主状态，不应代替 Runtime 健康检查或具体任务追踪。
 
-运行时探针：
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-```
+## 结果判定
 
-业务流策略：
-```bash
-pd runtime flow show --workspace "<workspace>" --json
-```
+- `painId` 只证明痛苦登记有回执。
+- 任务创建不等于诊断完成。
+- 候选生成不等于通过准入；必须检查实际 admission 决策及对应账本证据。
+- 准入成功不等于 Owner 已批准或原则已激活；打开 Console 也不等于完成治理决定。
 
-## 追踪痛苦到原则链（PRI-455 提升）
+## 写操作与失败
 
-追踪从痛苦信号到原则账本的完整证据链：
-```bash
-pd trace show --pain-id "<painId>" --workspace "<workspace>" --json
-```
+本技能默认只读。若需要重试、恢复、修复或其他有副作用的操作，先确认用户意图、命令帮助、资格条件和影响范围；支持时先 dry-run，执行后读回真实状态。不要盲目重试可能产生副作用的命令。
 
-## 激活管理（PRI-455 提升）
+CLI 不可用时，保留真实错误并区分未安装、工作区未初始化、权限不足与 Runtime 故障。需要安装、初始化、停用或恢复宿主接入时转交 `pd-control`。
 
-列出当前激活：
-```bash
-pd activation list --workspace "<workspace>" --json
-```
+## 禁止
 
-停用（回滚）激活：
-```bash
-pd activation deactivate --activation-id "<activationId>" --workspace "<workspace>" --json
-```
-
-## 查看 Runtime V2 对象
-
-Tasks 和 runs：
-```bash
-pd task show --task-id "<taskId>" --json
-pd run show --run-id "<runId>" --json
-```
-
-Candidates 和 artifacts：
-```bash
-pd candidate list --workspace "<workspace>" --json
-pd candidate show --candidate-id "<candidateId>" --workspace "<workspace>" --json
-pd artifact show --artifact-id "<artifactId>" --workspace "<workspace>" --json
-```
-
-手动 intake：
-```bash
-pd candidate intake --candidate-id "<candidateId>" --workspace "<workspace>" --json
-```
+- 不直接修改数据库、账本、配置或内部工件。
+- 不写 `.state/.pain_flag`，不调用 legacy `write_pain_flag`。
+- 不伪造运行证据或把推测写成已确认根因。
+- 不通过 CLI、脚本或其他技能批准、拒绝或激活原则。
+- 不将命令退出码为 0 自动等同于业务成功。

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

@@ -0,0 +1,50 @@
+---
+name: pd-control
+description: 当 Owner 明确要求安装、初始化、停用、重新启用或修复 PD 宿主接入时使用。只使用当前宿主正式支持的管理入口；不直接改配置或业务状态。
+disable-model-invocation: false
+---
+
+# PD Control
+
+## 目标
+
+通过正式安装器和宿主管理机制管理 PD 接入。本技能是受限路由入口，不复制安装器逻辑，也不改变原则、候选、任务或账本状态。
+
+## OpenClaw 当前支持方式
+
+### 安装或重新初始化
+
+仅当 Owner 明确要求安装/初始化时，使用仓库公开的非交互式安装入口：
+
+    npx create-principles-disciple --yes
+
+执行前检查当前安装器的帮助和前置条件；不要在缺少授权、网络或依赖条件时声称安装成功。完成后用 `pd-cli-operator` 做只读健康检查。
+
+### 停用
+
+只有 Owner 明确要求停用时，执行：
+
+    openclaw plugins disable principles-disciple
+
+该命令通过 OpenClaw 正式插件管理入口更改启用状态，不会删除已安装文件。执行后检查 `openclaw plugins list --enabled --json`，确认 `principles-disciple` 不再处于启用列表。若 Gateway 正在运行，命令会通过 Gateway 应用状态变化；仍需区分“开关已关闭”和“此前已启动的任务已全部停止”。
+
+### 启用或恢复
+
+只有 Owner 明确要求启用时，执行：
+
+    openclaw plugins enable principles-disciple
+
+如果返回 capability consent、allowlist、denylist 或其他策略阻止信息，不要自动添加 `--accept-capabilities`，也不要手工改 `openclaw.json`。保留完整回执，向 Owner 说明需要作出的选择或策略问题；只有 Owner 明确同意相关 capability 后，才按 OpenClaw 返回的准确重试指令继续。
+
+执行后先检查 `openclaw plugins list --enabled --json`，再运行 `openclaw plugins inspect principles-disciple --runtime --json` 检查当前插件注册的运行时能力。冷清单或 inspect 结果本身仍不能证明真实 Hook 已生效；需要时用一条安全的真实宿主事件核验。
+
+## 成功判定
+
+区分安装器执行成功、插件被宿主发现、Hook 实际运行和 PD 业务链路健康。每一步都需要对应的真实回执或运行证据。插件存在不等于已启用，安装成功也不等于 Runtime 健康。
+
+## 禁止
+
+- 不手工修改宿主配置或 PD 状态文件。
+- 不覆盖用户配置，不删除业务数据来停用 PD。
+- 不通过 CLI、脚本或其他技能批准、拒绝或激活原则。
+- 不将未验证的宿主操作报告为成功。

package/templates/langs/zh/skills/pd-pain-signal/SKILL.md

@@ -1,64 +1,45 @@
 ---
 name: pd-pain-signal
-description: 手动触发 Principles Disciple Runtime V2 痛苦诊断。用户报告 agent 卡住、循环、无响应，或要求记录/触发痛苦信号时使用。在 OpenClaw 会话中，引导 Owner 使用 /pd-pain 命令（自动绑定真实会话）。在会话外使用 `pd pain record --session <id>`。禁止写 `.state/.pain_flag`，禁止使用 legacy write_pain_flag 工具。
+description: 当 Owner 明确要求记录智能体行为问题、登记痛苦信号，或追踪某次反馈是否进入诊断管线时使用。自动痛苦检测仍由现有 Hook、宿主入口和 Runtime 负责。
 disable-model-invocation: false
 ---
 
-# Pain Signal（Runtime V2）
+# PD Pain Signal
 
-会话证据决定诊断能否携带真实轨迹证据。未绑定会话的记录是合法的 unbound
-Owner 报告：它不携带轨迹证据，诊断 confidence 通常偏低，候选大概率被
-admission gate 拦为 `needs_evidence` —— Owner 的报告被保存，但通常不会进入
-内化。
+## 目标
 
-## 在 OpenClaw 会话中（首选）
+把 Owner 的真实行为反馈交给现有 PD 痛苦登记与诊断管线，并保留原始陈述、来源和可用的会话证据。本技能不重写检测、去重、准入或诊断逻辑。
 
-请 Owner 在发生问题的对话中运行主机命令：
+## 执行步骤
 
-```text
-/pd-pain <描述问题>
-```
+1. **先检查是否已登记。** 当前消息可能已经由 Hook 或宿主入口处理。若有真实回执，复用 pain/task 标识，不要重复提交。无法观测是否登记时，不得声称成功，也不要盲目重复写入。
+2. **保留 Owner 原话。** 只记录 Owner 明确提供的陈述；不要补写技术根因、评分或工具失败事实。引用、工具输出和模型转述不能伪装成新的 Owner 提交。
+3. **使用可信的宿主入口。**
+   - 在发生问题的 OpenClaw 会话中，若 Owner 明确要求登记，使用宿主命令 `/pd-pain <问题描述>`。该命令由 OpenClaw 绑定真实当前会话。
+   - 在会话外使用 CLI 时，只能绑定已知且已验证的会话：`pd pain record --reason "<reason>" --workspace "<workspace>" --session "<session-id>" --json`。
+4. **禁止猜测 session ID。** 不得猜测身份、扫描数据库、选择“最新”会话或用其他宿主的 ID 冒充当前会话。缺少必要会话标识时停止该 CLI 路径并说明原因。
+5. **核验回执。** 只有实际回执证明登记成功，才能报告已登记；没有回执只能说尚未确认。
 
-`/pd-pain` 从 OpenClaw 取得经过认证的当前会话，并自动提交该会话的轨迹
-证据。你自己无法取得可信的会话 ID（工具执行环境不会注入）；禁止猜测、
-扫描或挑选"最新"会话。
+## 证据与成功标准
 
-## 在会话外（CLI）
+- 有真实 pain ID 只代表登记有回执，不代表诊断完成。
+- 诊断产生候选，不代表候选通过准入。
+- 必须查看 `admissionResults` / `candidateOutcomes` 中的实际 `admitted` 决策及对应的非空 `ledgerEntryIds`；不能只凭 `candidateIds` 非空宣布成功。
+- `needs_evidence`、`deferred` 或明确的准入拒绝必须如实报告。不要绕过准入门，也不要为提高置信度而伪造轨迹。
+- 原始 Owner 陈述、宿主轨迹、模型诊断、准入结果、Owner 审批和激活状态是不同类型的证据，不能混为一谈。
 
-绑定一个明确已知、本工作区已记录的会话 ID：
+## 失败处理
 
-```bash
-pd pain record --reason "<reason>" --score <0-100> --workspace "<workspace>" --session "<session-id>" --json
-```
-
-- `--session <id>` 会先对工作区轨迹做校验：会话不存在时以
-  `session_not_found` 失败，不会写入任何内容。
-- `--session` 验证通过但轨迹证据为空或不可读（会话真实存在）时，记录按
-  bound + 证据不可用诚实降级提交：不伪造证据，由 admission gate 评判空
-  证据的价值，而不是直接拒绝。
-- 不带 `--session` 的记录是允许的 unbound Owner 报告，但不附带证据，
-  候选大概率被 admission gate 拦为 `needs_evidence` —— CLI 输出会明确
-  提示这一点。
+- 登记失败：保留真实错误和宿主提供的下一步操作。
+- 重复登记风险：先核对已有回执与幂等结果。
+- 会话不存在或身份不可信：停止，不得猜测。
+- CLI/Hook 不可用：转交 `pd-cli-operator` 检查状态；需要修复安装时转交 `pd-control`。
+- Owner 要求查看后续候选：使用 `pd-review` 打开 Console；不要重新登记同一反馈。
 
 ## 禁止
 
-- 不要直接写 `.state/.pain_flag`。
-- 不要用 `write_file`、shell 重定向、`Set-Content`、`Out-File`、`node -e` 或任何文件写入方式创建 `.state/.pain_flag`。
-- 不要使用 `write_pain_flag`。这是 legacy 路径。
-- 不要猜测、扫描或推断会话 ID。使用 `/pd-pain`，或使用 Owner 明确提供的 ID。
-
-## 验证
-
-使用：
-```bash
-pd runtime probe --runtime pi-ai --workspace "<workspace>" --json
-pd candidate list --workspace "<workspace>" --json
-pd runtime flow show --workspace "<workspace>" --json
-```
-
-成功标准是候选被**准入**（admitted），而不只是被生成：检查
-`admissionResults` 中的 `admitted` 决策和 `ledgerEntryIds` 非空。命令成功
-返回 `painId` 只代表记录回执，不代表诊断或准入成功。
-`needs_evidence` 或 `deferred` 的候选没有被内化 —— 若候选被拦截，
-请用 `/pd-pain` 或 `--session` 重新记录，让诊断携带真实轨迹证据。
-激活（activation）是 Owner 批准之后的独立阶段，本流程不会直接产生激活。
+- 不写 `.state/.pain_flag`，不调用 legacy `write_pain_flag`。
+- 不伪造 Owner 原话、session ID、turn ID 或工具失败。
+- 不重复提交已确认登记的事件。
+- 不直接修改痛苦数据库、候选账本或准入状态。
+- 不批准、激活或修改原则。

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

@@ -0,0 +1,32 @@
+---
+name: pd-review
+description: 当 Owner 要查看 PD 诊断结果、原则候选或治理状态，或提出批准、拒绝、激活等治理请求时使用。所有 Owner 决策必须由 Owner 在正式 Web Console 中完成。
+disable-model-invocation: false
+---
+
+# PD Review
+
+## 目标
+
+帮助 Owner 查看真实证据并进入 PD 正式治理界面。技能可以查询、解释和打开 Console，但不能代替 Owner 决策。
+
+## 流程
+
+1. 确认目标是 PD 的痛苦、诊断、候选或原则治理，而不是普通代码评审。
+2. 使用 `pd-cli-operator` 或已有真实回执核对状态。区分 Owner 原话、宿主轨迹、模型诊断、准入决定和已发生的治理动作。
+3. 使用当前 OpenClaw 宿主确认的工作区打开 Console：`pd console open --workspace "<workspace>"`。不要猜测工作区。
+4. 只有命令真实返回成功时才报告 Console 已启动。若失败，保留错误并转交 `pd-control` 排查宿主安装。
+5. 告知 Owner 在 Console 中查看证据并亲自完成批准、拒绝或其他治理操作。
+
+## 状态边界
+
+- 候选存在不代表已批准。
+- 打开 Console 不代表已批准。
+- Owner 表达了“批准”意图，不代表 Console 中的审批动作已经完成。
+- 批准、激活和后续行为差异是不同阶段，必须分别核实。
+
+## 强制禁止
+
+- 不通过 CLI、脚本、数据库、文件或其他技能批准、拒绝或激活原则。
+- Console 不可用时，不得切换到 CLI 审批作为备用方案。
+- 不伪造 Owner 决策，不将候选生成或准入结果描述成已激活。

package/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.