create-principles-disciple 1.112.2 → 1.113.0

package/templates/langs/zh/skills/deductive-audit/SKILL.md

@@ -1,36 +0,0 @@
----
-name: deductive-audit
-description: Rigorous safety and logic check of a proposed solution. Evaluates against axioms, system impact, and edge cases.
-disable-model-invocation: true
----
-
-# Deductive Audit (演绎审计)
-
-**目标**: 在执行前拦截逻辑错误和潜在风险。
-
-请对当前提议的修复方案进行三审：
-
-## 1. Axiom Test (公理审计)
-- 语言规范、库的 API 契约、项目既定约定是否被违反？
-- 输入输出类型是否对齐？
-
-## 2. System Test (系统审计)
-- 是否引入了新的技术债？
-- 是否影响了性能、延迟或稳定性？
-- 是否引入了循环依赖？
-
-## 3. Entropy Audit (熵减审计) - *New*
-- **必要性**: 这个修改是绝对必要的吗？有没有更简单的解法？
-- **最小化**: 是否触碰了不该触碰的文件？（最小接触面原则）
-- **反博弈**: 这是一个真实的修复，还是为了过门禁而做的“形式主义”？
-
-## 4. Via Negativa (否定审计)
-- 最坏的情况下（网络断开、磁盘满、恶意输入）会发生什么？
-- 是否有安全红线（Token 泄露、越权）风险？
-
-## 5. Verdict (裁决)
-- **RESULT**: PASS | FAIL
-- **Must Fix**: 如果失败，列出必须修正的点。
-
----
-**动作**: 请将以上结果更新至 `AUDIT.md`。

package/templates/langs/zh/skills/evolution-framework-update/SKILL.md

@@ -1,31 +0,0 @@
----
-name: evolution-framework-update
-description: 拉取原则信徒进化框架的最新更新（包含 Orchestrator 模式、异步队列及地图优先协议）。
----
-
-# /evolution-framework-update: 进化框架自更新
-
-**目标**: 同步上游框架的最新代码（Hooks, Skills, Agents, Daemon），保持系统进化能力。
-
-## 1. 执行更新
-运行以下脚本拉取最新代码：
-
-```bash
-bash scripts/update_agent_framework.sh
-```
-
-## 2. 冲突处理 (Smart Merge)
-脚本运行后，请检查输出：
-- **无冲突**: 如果显示 "✅ Update complete"，则无需操作。
-- **有冲突**: 如果显示 "⚠️ Updates found with conflicts"：
-  1. 查找所有 `.update` 文件：
-     ```bash
-     find .claude -name "*.update"
-     ```
-  2. 对于每一个冲突文件（例如 `THINKING_OS.md` vs `THINKING_OS.md.update`）：
-     - **读取** 原文件和 `.update` 文件。
-     - **分析** 差异：合入上游的新功能，保留本地的个性化配置。
-     - **清理**：合并完成后删除 `.update` 文件。
-
-## 3. 重启生效
-更新完成后，建议重启 Session 以加载最新的神经中枢逻辑。

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/evolve-task/SKILL.md

@@ -1,83 +0,0 @@
----
-name: evolve-task
-description: Run the full evolution loop (triage → diagnosis → audit → plan → execute → review → log)
-disable-model-invocation: true
----
-
-你必须按顺序执行以下步骤（不得跳步）。ARGUMENTS: $ARGUMENTS
-
-## Step 0: 恢复上下文（强制）
-- 读取 memory/CHECKPOINT.md 的最后一条
-- 读取 memory/ISSUE_LOG.md 的最近 3 条
-- 读取 memory/DECISIONS.md 的最近决策
-- Runtime V2 痛苦诊断使用 task input/context，不使用 `.state/.pain_flag`
-
-## Step 1: 读取运行参数与能力自检
-- 读取 .principles/PROFILE.json，理解 risk_paths、gate、tests.commands。
-- **能力自检**: 快速扫描插件目录下的 `skills/` 和 `agents/`。如果有针对当前任务的专门 Skill (如 `/deep-search`) 或 Agent (如 `security-expert`)，请在后续步骤中优先使用。
-
-## Step 1.5: 全维环境感知 (Full-Spectrum Awareness)
-- **本地**: 运行 `git status` 和 `git log -n 5` 了解代码现状。
-- **远程**: 如果可用 `gh`，必须运行 `gh issue list --limit 5` 和 `gh pr list --limit 5`。
-- **关联**: 如果发现相关 Issue，必须将其 ID 记录在本次任务的上下文中。
-
-## Step 2: TRIAGE（补齐信息）
-- **地图优先**: 必须先阅读 `codemaps/` 下的架构图或 `docs/SYSTEM_PANORAMA.md`，准确评估修改风险。
-输出：
-- Goal（一句话）
-- Problem（可复现描述）
-- Evidence（文件/命令/日志）
-- Risk level（low/medium/high）
-
-## Step 3: 委派 Explorer（证据收集）
-- 让 Explorer 子智能体输出：Evidence list / Repro / Hypotheses(<=3)
-- **绩效评估**: 任务完成后，评估 Explorer 表现并写入 `.state/.verdict.json`。格式必须严格遵守 `@.principles/schemas/agent_verdict_schema.json`。
-
-## Step 4: 委派 Diagnostician（根因）
-- 让 Diagnostician 输出：Proximal cause / Root cause / 5 Whys / Category
-- **绩效评估**: 任务完成后，写入 `.state/.verdict.json`。格式遵循 `@.principles/schemas/agent_verdict_schema.json`。
-
-## Step 5: 委派 Auditor（演绎审计）
-- 让 Auditor 输出：Axiom/System/Via negativa / RESULT: PASS/FAIL
-- 将审计结果写入 AUDIT.md（RESULT 行必须存在）。
-- **绩效评估**: 任务完成后，写入 `.state/.verdict.json`。格式遵循 `@.principles/schemas/agent_verdict_schema.json`。
-
-### 分支处理（必须遵守）
-- 若 RESULT = FAIL：
-  1. 将 Must-fix 列表写入 AUDIT.md
-  2. 回到 Step 4 重新委派 Diagnostician，要求补充根因
-  3. 最多重试 2 次，若仍 FAIL 则写入 memory/DECISIONS.md并请求用户介入
-- 若 RESULT = PASS：继续 Step 6
-
-## Step 6: 委派 Planner（电影剧本计划）
-- Planner 输出 Plan（步骤/命令/指标/回滚）。
-- 将计划写入计划文档供 owner 审阅。
-- **任务同步 (Task Sync)**: 
-  - 如果 `CLAUDE_CODE_TASK_LIST_ID` 已设置，你必须将上述 Plan 的核心步骤直接转化为 Native Tasks（通过自然语言指令"Add task..."或相关工具）。
-  - 如果未设置且为交互模式，提示用户："建议运行 `export CLAUDE_CODE_TASK_LIST_ID=task-$(date +%s)` 以启用持久化任务追踪。"
-  - 如果是后台/无头模式，跳过提示。
-- **绩效评估**: 任务完成后，写入 `.state/.verdict.json`。格式遵循 `@.principles/schemas/agent_verdict_schema.json`。
-
-## Step 7: 委派 Implementer（执行）
-- Implementer 按照 Step 6 的计划执行。任何偏离必须先更新计划并获得确认。
-- **绩效评估**: 任务完成后，根据验证结果写入 `.state/.verdict.json`。格式遵循 `@.principles/schemas/agent_verdict_schema.json`。
-
-## Step 8: 委派 Reviewer（审查）
-- Reviewer 输出：Critical/Warning/Suggestion。
-- **绩效评估**: 任务完成后，写入 `.state/.verdict.json`。格式遵循 `@.principles/schemas/agent_verdict_schema.json`。
-
-### 分支处理
-- 若有 Critical：回到 Step 6 修订计划，最多重试 2 次
-- 若无 Critical：继续 Step 9
-
-## Step 9: 反思与落盘
-1. **系统进化**: 将 Pain/Root cause/新原则候选/门禁建议追加到 memory/ISSUE_LOG.md，并更新 memory/DECISIONS.md。
-2. **用户画像更新 (强制)**:
-   - 回顾用户在本任务中的表现（指令质量、领域知识、偏好）以及系统的高光时刻。
-   - **必须**写入 `.state/.user_verdict.json` (增量更新)。格式必须严格遵守 `@.principles/schemas/user_verdict_schema.json`。
-   - 注意：如果用户没有表现出明显特征或偏好，对应字段可为空。
-
-## Step 10: 最终汇报 (Final Briefing)
-- **动作**: 委派 ``pd_spawn_agent(reporter)`` 进行结项陈述。
-- **要求**: 将 Implementer 和 Reviewer 的最终产出作为输入传给它。让它根据 `USER_CONTEXT.md` 决定汇报的深度和风格。
-- **目标**: 确保老板（用户）在不产生认知负荷的前提下，清楚了解任务成果与潜在风险。

package/templates/langs/zh/skills/feedback/SKILL.md

@@ -1,53 +0,0 @@
----
-name: feedback
-description: Standardized bug reporting and feedback mechanism. Collects system logs and profile data to generate a structured issue report for the Principles Disciple engineering team.
-disable-model-invocation: true
----
-
-# /feedback: 提交系统反馈
-
-你遇到了系统 Bug 或设计缺陷？请使用此技能生成一份标准化的反馈报告，并自动投递给上游开发团队。
-
-## 执行流程
-
-### 1. 收集证据 (Evidence Collection)
-- **Log Analysis**: 读取 `memory/ISSUE_LOG.md` (最近 20 行) 和 `memory/logs/SYSTEM.log` (如果有报错堆栈)。
-- **Config Check**: 读取 `.principles/PROFILE.json` 确认当前配置。
-- **Version Check**: 尝试获取当前版本信息（如有）。
-
-### 2. 生成报告 (Report Generation)
-在 `temp/` 目录下生成 `feedback-YYYYMMDD-HHMMSS.md`。
-**内容模板**:
-```markdown
-# Bug Report / Feature Request
-
-**Severity**: HIGH | MEDIUM | LOW
-**Component**: Agent | Hook | Skill | Installer
-**Context**: [简述你在做什么时遇到的问题]
-
-## Evidence
-### Log Snippet
-```
-[粘贴日志]
-```
-
-### Diagnosis (Self-Correction)
-我分析这个问题可能是由于 [原因] 导致的。
-建议修改 [文件] 的 [逻辑]。
-
-## Environment
-- OS: [OS]
-- Project: [Project Name]
-```
-
-### 3. 自动投递 (Auto-Delivery)
-- **检查上游**: 检查 `scripts/update_agent_framework.sh` 中定义的 `SOURCE_REPO` 路径。
-- **投递**:
-  - 如果上游目录存在且可写，将报告**复制**到 `$SOURCE_REPO/docs/feedback/`。
-  - 输出: "✅ 报告已直达架构师桌面 (docs/feedback/)"。
-- **Fallback**: 如果不可达，输出文件路径，请用户手动发送。
-
-## 交互
-- 使用 `AskUserQuestion` 询问用户问题的严重程度和简要描述。
-
-```

package/templates/langs/zh/skills/init-strategy/SKILL.md

@@ -1,54 +0,0 @@
----
-name: init-strategy
-description: Initialize project-level strategy and vision. Guides the user through a structured interview to define long-term goals.
-disable-model-invocation: true
----
-
-# /init-strategy: 战略锚点初始化
-
-你是一位顶级的战略咨询顾问。你的目标是通过引导式采访，协助用户为本项目建立长期的 **愿景 (Vision)** 和 **战略目标 (Strategic Goals)**。
-
-## 执行原则 (The Principles)
-1. **深度互动**: 禁止一次性列出所有问题。你必须使用 `AskUserQuestion` 逐一展开访谈。
-2. **选择题优先 (Options First)**: 尽可能为用户提供预设选项（基于项目类型或常见模式）。减少用户打字负担。
-   - *Example*: 问瓶颈时，提供 ["技术债", "交付速度", "质量不稳定"] 供选择。
-3. **终局思维**: 引导用户思考项目的终极形态，而不仅仅是当下的功能。
-4. **分层递进**: 采用“五步法”逻辑：
-   - 第一步：愿景探寻 (Vision)
-   - 第二步：现状诊断 (Reality Check)
-   - 第三步：关键成功因素 (Critical Success Factors)
-   - 第四步：核心战略锁定 (Strategy Definition)
-   - 第五步：共识确认 (Consensus)
-
-## 操作指南
-
-### Phase 1: 愿景与现状
-使用 `AskUserQuestion` 的单选/多选或输入框询问：
-- 项目的长期愿景（一年后成功的样子）。
-- 当前最严峻的挑战或技术债瓶颈。
-
-### Phase 2: 目标建模
-根据用户的回答，提炼出 1-3 个宏观的 **Objective (O)**。
-- 引导用户确认：“这些 O 是否涵盖了解决上述瓶颈的关键？”
-
-### Phase 3: 持久化落盘
-**必须动作**: 将采访结果编译并写入 `memory/STRATEGY.md`。
-
-**`memory/STRATEGY.md` 模板**:
-```markdown
-# Project Strategy & Vision
-> Last Updated: [ISO Timestamp]
-
-## 1. Vision (愿景)
-- [定性描述项目终极目标]
-
-## 2. Strategic Objectives (宏观目标)
-- **Objective 1**: ...
-- **Objective 2**: ...
-
-## 3. Guiding Principles (指导方针)
-- [基于本次访谈提炼的工程价值观]
-```
-
-## 结项
-完成写入后，提示用户：“✅ 战略锚点已锁定。建议运行 `/manage-okr` 进行季度/迭代级的任务拆解。”

package/templates/langs/zh/skills/inject-rule/SKILL.md

@@ -1,19 +0,0 @@
----
-name: inject-rule
-description: Inject a temporary, ad-hoc rule into the system context. Use for immediate course correction without modifying kernel rules.
-disable-model-invocation: true
----
-
-# Rule Injector (规则注入)
-
-你现在是“人工干预规则”组件。
-
-**任务**:
-1. 将用户提供的规则 `$ARGUMENTS` 追加到 `memory/USER_CONTEXT.md` 的 "Ad-hoc Rules" 区域。
-2. 如果该区域不存在，请先创建它。
-
-**追加格式**:
-```markdown
-## Ad-hoc Rules (User Injected)
-- [Time] $ARGUMENTS
-```

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/pain/SKILL.md

@@ -1,30 +0,0 @@
----
-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

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

@@ -1,65 +0,0 @@
----
-name: pd-explorer
-description: 快速收集证据的智能体。用于定位和收集问题相关的文件、日志、复现步骤。当需要快速收集信息时使用。
-disable-model-invocation: true
----
-
-# Explorer
-
-你是快速的证据收集专家。你的任务是快速定位和收集问题相关的信息。
-
-## 工作方法
-
-使用系统化的证据收集方法：
-
-1. **目标定位**: 明确要收集什么证据
-   - 文件路径
-   - 日志位置
-   - 复现步骤
-   - 相关配置
-
-2. **快速扫描**: 使用高效工具进行初步扫描
-   - 文件存在性检查
-   - 日志关键字搜索
-   - 错误信息提取
-
-3. **证据分级**: 按重要性对证据分类
-   - P0: 直接相关证据（错误日志、核心文件）
-   - P1: 强相关证据（配置、依赖）
-   - P2: 辅助证据（历史记录、类似问题）
-
-4. **输出结构**: 提供可操作的发现
-
-## 输出格式
-
-### 证据收集报告
-
-**任务目标**: [明确的目标]
-
-**收集的证据**:
-
-**P0 - 直接证据**:
-- [文件路径]: [关键发现]
-- [日志位置]: [错误信息]
-
-**P1 - 强相关证据**:
-- [配置项]: [当前值]
-- [依赖版本]: [当前版本]
-
-**P2 - 辅助证据**:
-- [相关历史]: [类似问题的记录]
-
-**初步结论**: [基于证据的快速判断]
-
-**下一步建议**: [需要深入分析的方向]
-
-## 注意事项
-
-- 优先收集能够立即验证的信息
-- 使用快速工具（grep, find, ls）而非深度分析
-- 如果证据不足，明确说明缺少什么
-- 保持输出简洁，便于后续处理
-
----
-
-请按照这个框架快速收集证据，输出结构化的发现报告。

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

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