principles-disciple 1.81.0 → 1.82.0

package/templates/langs/en/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 Digital Architect (Second-Order Observation)
-
-Your identity is now the system's **Digital Architect**. Your responsibility is not to fix business code, but to optimize the system's own "genes" (Prompts, Hooks, Rules) by analyzing system runtime data.
-
-## 1. Metrics Analysis
-- **Read Data**:
-  - `.state/AGENT_SCORECARD.json`: Calculate each Agent's win rate (wins / (wins + losses)).
-  - `memory/ISSUE_LOG.md`: Identify repeated patterns in the last 10 records (Pain Patterns).
-- **Identify Anomalies**:
-  - **Inefficient Agent**: Agents with win rate below 50% and sample size >= 3.
-  - **Systemic Issues**: Same type of systemic errors appearing more than 2 times in Issue Log.
-
-## 2. Systemic Diagnosis
-- For identified anomalies, analyze their definitions in `.claude/agents/` or `.claude/hooks/`.
-- **Think**: 
-  - Is the Prompt description too vague causing hallucinations?
-  - Does the Hook logic have boundary blind spots?
-  - Is a critical Guardrail missing?
-
-## 2.5 Clinical Trial - *Optional*
-**If root cause is unclear**, conduct empirical testing:
-- **Consult**: Use `AskUserQuestion` to ask: "To confirm the issue, I need to run an automatic diagnostic task for [Agent], which may consume some tokens. Continue?"
-- **Silent Execution**:
-  - If user agrees, directly call ``pd_spawn_agent` 工具` to initiate test.
-  - **Instruction**: "You are being diagnosed. Please execute the following task: [Test Scenario]. Keep output extremely concise, only return final result or error message."
-  - **Observe**: Check if its tool call chain meets expectations (e.g., did it use the correct Search tool).
-- **Diagnose**: Based on test performance, pinpoint the issue.
-
-## 3. Optimization Proposal
-**If root cause is confirmed**, generate `SYSTEM_OPTIMIZATION_PLAN.md`, including:
-- **Diagnosis Conclusion**: Clearly state which part of the system is "sick".
-- **Modification Suggestion**: Provide specific code/Prompt modification diffs.
-- **Expected Benefits**: Explain how this modification improves win rate or reduces pain.
-
-## 4. Safety Gate
-- **Mandatory Confirmation**: Before modifying any system files (under `.claude/` directory), must use `AskUserQuestion` to present the proposal and obtain explicit user authorization.
-- **Atomicity**: Only suggest one high-leverage optimization point at a time, don't attempt to refactor the entire system at once.
-
-## Completion
-Output: "✅ System self-diagnosis complete. Proposal submitted, awaiting boss decision."

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

@@ -1,96 +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: Objectives and Key Results Management
-
-You are an OKR organization expert. Your task is to coordinate alignment between overall strategy (`STRATEGY.md`) and each sub-agent's goals (`agents/*.md`).
-
-## Execution Principles
-1. **SMART Mandatory**: All KRs must be quantifiable, bounded, and time-bound.
-2. **Options First**: When confirming or reviewing, use `AskUserQuestion` to provide ["Approve", "Modify", "Reject"] or ["On Track", "At Risk"] options to reduce user input.
-3. **Responsibility Alignment**: Automatically identify which dimension a KR should belong to (quality/architecture/execution speed).
-4. **Dynamic Evolution**: KRs have lifecycles. Use this command to update, complete, or retire KRs.
-5. **Governance Protocol Mandatory**:
-   - `Proposal` is a process phase, not a new role.
-   - Proposer can be main agent or OKR owner, but challenger must be a different agent.
-   - Final execution plan must pass `AskUserQuestion` to get Owner approval before locking for execution.
-
-### Lifecycle Governance Files (Must Maintain)
-- `memory/okr/WEEK_STATE.json`: Week state machine (DRAFT/CHALLENGE/PENDING_OWNER_APPROVAL/LOCKED/EXECUTING/REVIEW/CLOSED/INTERRUPTED)
-- `memory/okr/WEEK_EVENTS.jsonl`: Execution event stream (task_started/heartbeat/blocker/task_completed)
-- `memory/okr/WEEK_PLAN_LOCK.json`: Lock file after Owner approval
-
-### Governance Commands (Recommend scripts to reduce manual errors)
-```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 & Status Check
-- Read `memory/STRATEGY.md`.
-- **Build Full Roster**:
-  - **Core Team**: `explorer`, `diagnostician`, `auditor`, `planner`, `implementer`, `reviewer`.
-  - **Extended Team**: Scan project root `.claude/agents/*.md`, extract names.
-- **Resume Check**:
-  - Check if `memory/okr/.negotiation_status.json` exists.
-  - **If exists**: Read `pending` list. Inform user: "Detected unfinished negotiation from last session (remaining: ...). Resuming."
-  - **If not exists**: Initialize this file, write all roster to `pending` list.
-- **Week Governance Status Check**:
-  - Read `memory/okr/WEEK_STATE.json` (if not exists, use `weekly_governance.py new-week` to initialize).
-  - If `stage=INTERRUPTED`, organize recovery plan and confirm with user before continuing plan orchestration.
-
-### 2. User Commitment
-- **Turn to User**: Before interviewing sub-agents, align with user first.
-- **Ask**: Use `AskUserQuestion`.
-  > "To ensure project success, besides the AI team's efforts, your collaboration is needed.
-  > **What are your personal OKRs for this cycle?**
-  > (Suggested directions: behavioral constraints like 'no changing requirements', personal contributions like 'complete design drafts', or learning goals)"
-- **Persist**: Write user commitment to `memory/okr/user.md`.
-
-### 3. Negotiation & Alignment
-- **Scheduling Principle**: ⚠️ **Throttled Concurrency**. Max 2-3 concurrent Tasks at a time, wait for results before adding new tasks. Never send all requests at once to prevent terminal freeze.
-- **Interview Loop**:
-  1. Take a batch of Agents from `pending` (2-3).
-  2. Call ``pd_spawn_agent` 工具` to initiate interview (Prompt below).
-  3. After each response, **immediately update** `memory/okr/.negotiation_status.json`:
-     - Move that Agent to `completed` list.
-     - This ensures recoverability after system crash.
-- **Interview Prompt**:
-  > "Hello, <AgentName>. The company's annual strategy is [Strategy Summary].
-  > **Mandatory Action**: Before answering, you must call tools (Glob/Grep/Read) to **scan current codebase** to understand the status relevant to your responsibilities.
-  > Based on your **field research**, capabilities, and strategy, propose 1-3 **Key Results (KR)** you commit to achieving this cycle.
-  > Requirements: Must be specific, quantifiable, and **aligned with project reality**. Output KR list in Markdown format directly."
-
-### 3.5 Reverse Challenge & Comparison
-- Select one proposer from candidates (main agent or corresponding OKR owner) to output Proposal.
-- Assign a different agent to output Challenge (at least 3 criticisms + 1 alternative solution).
-- Merge Proposal and Challenge into Final Plan draft, persist to governance state machine:
-  - `record-proposal`
-  - `record-challenge`
-
-### 4. Confirmation
-- Aggregate all (including this session's new completions and previous completions) Agent proposals.
-- Use `AskUserQuestion` to present to user for confirmation (must include options: `Approve for Execution` / `Continue Modifying` / `Reject and Redo`).
-- Update governance state based on user option:
-  - `Approve for Execution` -> `owner-decision approve` (generate `WEEK_PLAN_LOCK.json`)
-  - `Continue Modifying` / `Reject and Redo` -> `owner-decision revise|reject`
-
-### 5. Commitment
-- Only enter this step when `WEEK_PLAN_LOCK.json` exists.
-- If approved, write each Agent's KR to dedicated file `memory/okr/<agent_name>.md`.
-- **Summary Focus**: Update `memory/okr/CURRENT_FOCUS.md`.
-- **Agent Auto-Onboarding**: Check and inject `@memory/okr/...` references to external Agent definition files.
-- **Cleanup**: Delete `memory/okr/.negotiation_status.json`.
-
-### 6. Progress Check-in - *Optional*
-- If user's goal is review, read above files, ask user about current progress, and update completion markers.
-- Also read `memory/okr/WEEK_EVENTS.jsonl`, output "This week completed / blocked / in progress" summary by event stream to avoid forgetting.
-
-## Completion
-Output: "✅ OKR negotiation complete. All members' goals aligned."

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

@@ -1,199 +0,0 @@
----
-name: pd-daily
-description: Configure and send daily evolution reports. TRIGGER CONDITIONS: (1) User asks "what did you do today", "send daily report" (2) Need to configure scheduled delivery (Feishu/email/IM) (3) First run guides through configuration (4) Already configured, generate and send report.
-disable-model-invocation: true
----
-
-# Evolution Daily Report
-
-This skill enables the agent to help users configure and automatically send daily evolution reports, allowing users to perceive the system "improving every day."
-
-## Execution Principles
-
-1. First run must confirm requirements with the user
-2. User preferences are stored in `{stateDir}/daily-report.md`; skip collection if exists
-3. Use OpenClaw's cron tool to create scheduled tasks
-4. Autonomously select available delivery channels
-
----
-
-## Flow
-
-### Step 1: Check Configuration File
-
-Read `{stateDir}/daily-report.md`:
-- **Exists** → Check cron task status, execute report generation
-- **Not exists** → Enter requirement collection flow
-
-### Step 2: Requirement Collection (First Run)
-
-Ask through conversation:
-
-1. **Enable evolution daily report?**
-2. **Send time?** (Default: 9:00 daily)
-3. **Timezone?** (Default: Asia/Shanghai)
-4. **Delivery channel?**
-   - Email → Need email address
-   - WhatsApp/Telegram → Need phone number/User ID
-   - Discord/Slack → Need channel ID
-   - Voice notification → Need phone number
-5. **Report style?** (See "Style Options" below)
-6. **Content preferences?** Select which modules to include
-
-### Step 3: Create Configuration File
-
-Write user preferences to `{stateDir}/daily-report.md`:
-
-```markdown
-# Daily Report Configuration
-
-## Basic Info
-- Status: enabled
-- Created: {date}
-
-## Send Settings
-- Send time: 09:00
-- Timezone: Asia/Shanghai
-- Cron expression: 0 9 * * *
-
-## Delivery Channel
-- Channel: whatsapp
-- Target: +8613800138000
-
-## Report Style
-- Style: standard
-- Language: en
-
-## Content Preferences
-- Growth highlights: yes
-- Pain signals: yes
-- Trend comparison: yes
-- Insights: yes
-
-## Cron Task
-- jobId: {filled after creation}
-```
-
-### Step 4: Create Cron Task
-
-Use cron tool:
-
-```json
-{
-  "action": "add",
-  "job": {
-    "name": "evolution-daily-report",
-    "schedule": { "kind": "cron", "expr": "0 9 * * *", "tz": "Asia/Shanghai" },
-    "sessionTarget": "isolated",
-    "payload": {
-      "kind": "agentTurn",
-      "message": "Execute daily report skill: read log data, generate report and send"
-    },
-    "delivery": { "mode": "announce", "channel": "whatsapp", "to": "+8613800138000" }
-  }
-}
-```
-
-### Step 5: Report Generation (Triggered via cron or manually)
-
-1. **Read Quantitative Data**: Fetch metrics from `daily-stats.json` and `pain_dictionary.json`.
-2. **Extract Qualitative Memory (Critical Anti-Forgetting Step)**: Because your context window may have rolled over, you **MUST use file reading tools** to scan the following core evolution files for today's entries:
-   - `memory/ISSUE_LOG.md`: Find specific errors and reflections recorded today.
-   - `memory/DECISIONS.md`: Find new architectural rules established today.
-   - `memory/logs/SYSTEM.log`: Find gatekeeper blocks or subagent spawn events from today.
-3. **Synthesize & Generate**: Combine hard metrics with qualitative memories to generate deep insights. Never hallucinate insights.
-4. **Send Report**: Dispatch via OpenClaw channel or print to screen.
-
----
-
-## Data Sources
-
-| Data | Path | Description |
-|------|------|-------------|
-| Daily Stats | `{stateDir}/logs/daily-stats.json` | Aggregated data (Success rate/GFI) |
-| System Events | `memory/logs/SYSTEM.log` | Audit trail for gatekeeper and subagents |
-| Core Reflections | `memory/ISSUE_LOG.md` | **(Critical)** Specific pitfalls and lessons learned today |
-| Decisions | `memory/DECISIONS.md` | **(Critical)** Systemic principles solidified today |
-| Pain Rules | `{stateDir}/pain_dictionary.json` | Total active rules |
-| User Config | `{stateDir}/daily-report.md` | Formatting preferences |
-
----
-
-## Style Options
-
-Ask user preference during requirement collection:
-
-| Style | Features | Suitable For |
-|-------|----------|--------------|
-| **Concise** | 3-5 core metrics, 1 min read | Busy users |
-| **Standard** | Full metrics + trend comparison, 5 min read | Default recommendation |
-| **Detailed** | Full data + analysis suggestions, 15 min read | Data enthusiasts |
-| **Humorous** | Casual tone + emoji style | Casual users |
-| **Visual** | ASCII charts + progress bars | Visual learners |
-
----
-
-## Evolution Metrics Elements
-
-### Growth Highlights (Positive)
-
-| Metric | Data Source | Progress Signal |
-|--------|-------------|-----------------|
-| Rules learned | `pain_dictionary.json` rule count | System learned to identify new error patterns |
-| Rules promoted | `DailyStats.pain.candidatesPromoted` | L3 semantic detection → formal rule |
-| Evolution tasks completed | `DailyStats.evolution.tasksCompleted` | Self-improvement completed |
-| GFI peak decrease | `DailyStats.gfi.peak` MoM | Less friction, more stable |
-| Success rate increase | `DailyStats.toolCalls.success/total` | Smoother execution |
-
-### Health Monitoring (Warnings)
-
-| Metric | Data Source | Warning Signal |
-|--------|-------------|----------------|
-| Pain signal count | `DailyStats.pain.signalsDetected` | How many error patterns detected |
-| GFI peak hour | `DailyStats.gfi.hourlyDistribution` | When is most painful |
-| Death spiral detection | fix/fail/error word frequency in git log | Stuck in fix loop |
-| Queue health | Evolution queue status | Congested or not |
-
-### Trend Comparison (Progress Perception)
-
-| Metric | Calculation | Meaning |
-|--------|-------------|---------|
-| 7-day success rate trend | 7-day success/total change | Long-term stability |
-| Pain signal weekly change | This week vs last week | Problems decreasing? |
-| Rule growth rate | New rules this week | Learning speed |
-| GFI average change | 7-day GFI average trend | Overall friction trend |
-
----
-
-## Default Report Template
-
-```markdown
-# 🌱 Evolution Daily Report - {date}
-
-## 📈 Today's Growth
-- 🧠 Rules learned: {rules_promoted}
-- ✅ Evolutions completed: {tasks_completed}
-- 🎯 Success rate: {success_rate}% ({trend_emoji})
-- 📉 GFI peak: {gfi_peak} ({gfi_trend})
-
-## ⚡ Pain Signals
-- Detections: {pain_count}
-- Avg intensity: {avg_score}
-- Top sources: {top_sources}
-
-## 📊 Trend Comparison
-- 7-day success rate trend: {success_trend}
-- Pain signal weekly change: {pain_trend}
-
-## 💡 Today's Insights
-{insights}
-
----
-📊 Source: Principles Disciple
-```
-
----
-
-## Manual Trigger
-
-Users can run `/evolution-daily` anytime to manually generate and send today's report.

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

@@ -1,46 +0,0 @@
----
-name: pd-grooming
-description: Perform a "Workspace Grooming" to archive or clean up scattered temporary files. TRIGGER CONDITIONS: (1) User says "project is messy", "too many files", "need to organize", "clean up" (2) HEARTBEAT patrol finds temp files in root (3) Need to maintain digital cleanliness.
----
-
-# 🧹 Skill: Workspace Grooming
-
-> **Trigger**: When the user types `/workspace-grooming`, or proactively invoked during a `HEARTBEAT` check if stray files are detected in the root directory.
-
-## 🎯 Core Objective
-Implement the "Entropy Reduction" rule by cleaning up "digital garbage" in the workspace root, while **absolutely ensuring the safety of core business code and configuration files**.
-
-## 🛡️ The Red Lines (Safety Rules)
-
-When performing cleanup operations, you MUST strictly adhere to the following whitelists and blacklists:
-
-### 🚫 DO NOT TOUCH (Absolute Exclusion Zone)
-**Even if these files/directories look messy, you are absolutely forbidden to delete or move them:**
-- **Business Source Code**: `src/`, `lib/`, `tests/`, `app/`, `pages/`, `components/` and any file ending with `.ts`, `.js`, `.py`, `.go`, `.rs`, `.java`.
-- **Project Configs**: `package.json`, `Cargo.toml`, `requirements.txt`, `tsconfig.json`, `vite.config.ts`, `.env*`, etc.
-- **Version Control**: `.git/`, `.gitignore`.
-- **Build Outputs**: `dist/`, `build/`, `node_modules/`, `target/`.
-
-### 🌟 Core Assets
-**These files must remain in the root directory. Do not touch:**
-- `AGENTS.md`, `SOUL.md`, `HEARTBEAT.md`, `TOOLS.md`, `IDENTITY.md`, `USER.md`, `MEMORY.md`
-- `README.md`
-- `.principles/`, `.state/`
-
-### 🎯 Targets for Grooming
-**You may take action on the following:**
-1. **Test Debris**: Stray files in the root like `test.txt`, `temp.md`, `debug.log`, `foo.js` that are clearly throwaway test scripts.
-2. **Draft Notes**: Uncategorized `.md` notes or `_scratchpad.md`.
-3. **Naming Violations**: Documents using spaces or arbitrary capitalization (e.g., `My New Feature.md`).
-
-## 🪜 Execution Steps
-
-1. **Scan Environment**: Execute `ls -la` to inspect the root directory.
-2. **Identify Targets**: Based on the "Red Lines" above, list all suspicious files that belong to the "Targets for Grooming" category.
-3. **Draft a Plan**:
-   - For temporary garbage (empty files, test scripts): Propose to **Delete (`rm`)**.
-   - For valuable notes or logs: Propose to **Archive (`mv`)** to `memory/archive/`.
-   - For incorrectly named files: Propose to **Rename (`mv`)** using `kebab-case`.
-4. **Human Confirmation (MUST)**: **Unless the file is an obvious test script you just created, you MUST use `AskUserQuestion` to get user approval before executing `rm` or sweeping `mv` commands.**
-   - Example prompt: "I found `test1.txt` and `old_notes.md` in the root. I plan to delete the first one and archive the second to `memory/archive/`. Do you approve?"
-5. **Execute & Report**: Execute the file operations after approval and reply with a brief confirmation that the grooming is complete.

package/templates/langs/zh/skills/ai-sprint-orchestration/EXAMPLES.md

@@ -1,63 +0,0 @@
-# AI 冲刺编排示例
-
-## 示例 1：baseline + validation
-
-```powershell
-node scripts/run.mjs --self-check
-node scripts/run.mjs --help
-node scripts/run.mjs --task workflow-validation-minimal
-node scripts/run.mjs --task workflow-validation-minimal-verify
-```
-
-## 示例 2：自定义 runtime 根目录
-
-```powershell
-node scripts/run.mjs --task workflow-validation-minimal --runtime-root D:/Temp/ai-sprint-runtime
-```
-
-## 示例 3：失败分类
-
-- `workflow bug`：package-local script 仍然写回 repo-root `ops/ai-sprints`
-- `agent behavior issue`：reviewer 漏掉 `VERDICT`，或 `DIMENSIONS` 格式错误
-- `environment issue`：`acpx` 缺失，或 workspace 不可写
-- `sample-spec issue`：validation spec 要求的字段，当前 sample / product 还没有实现
-
-## 示例 4：何时停止
-
-如果问题属于以下情况，完成分类后立刻停止本轮：
-
-- the issue belongs to `packages/openclaw-plugin`
-- the issue depends on `D:/Code/openclaw`
-- the fix would require dashboard/stageGraph/self-optimization sprint expansion
-- the problem is a sample-side or product-side gap rather than workflow plumbing
-
-## 示例 5：从复杂 bugfix 模板开始
-
-1. Copy `references/specs/bugfix-complex-template.json`
-2. Replace every placeholder in `taskContract`
-3. Narrow `executionScope` to the smallest useful round
-4. Run the packaged entrypoint with the edited spec:
-
-```powershell
-node scripts/run.mjs --task custom-bugfix --task-spec D:/path/to/your-bugfix-spec.json
-```
-
-## 示例 6：从复杂 feature 模板开始
-
-1. Copy `references/specs/feature-complex-template.json`
-2. Fill `Goal`, `In scope`, `Out of scope`, `Validation commands`, and `Expected artifacts`
-3. Confirm the spec does not require product-side closure outside this milestone
-4. Run:
-
-```powershell
-node scripts/run.mjs --task custom-feature --task-spec D:/path/to/your-feature-spec.json
-```
-
-## 示例 7：continuation 前先看 checkpoint summary
-
-当一轮以 `revise` 结束时，优先检查：
-
-- `stages/<stage>/checkpoint-summary.md`
-- `stages/<stage>/handoff.json`
-
-下一轮应该把 checkpoint summary 当作主 carry-forward，上下文不够时才回退到完整 decision 文本。

package/templates/langs/zh/skills/ai-sprint-orchestration/REFERENCE.md

@@ -1,136 +0,0 @@
-# AI 冲刺编排参考
-
-## 包结构
-
-- `scripts/run.mjs`：package-local orchestrator 入口
-- `scripts/lib/`：decision、contract validation、state store、spec loading、archive helper
-- `references/specs/`：内置 validation spec
-- `references/agent-registry.json`：package-local 的 agent/model 注册表
-- `references/workflow-v1-acceptance-checklist.md`：handoff 检查清单
-- `runtime/`：运行产物默认目录
-
-## Runtime 结构
-
-默认 runtime 根目录：
-
-- `packages/openclaw-plugin/templates/langs/<lang>/skills/ai-sprint-orchestration/runtime`
-
-子目录：
-
-- `runs/<run-id>/`
-- `archive/<run-id>/`
-- `tmp/sprint-agent/<run-id>/...`
-
-也可以通过以下方式覆盖：
-
-- `--runtime-root <path>`
-- `AI_SPRINT_RUNTIME_ROOT=<path>`
-
-## 自检
-
-在新安装环境中先跑：
-
-- `node scripts/run.mjs --self-check`
-
-它会检查：
-
-- package-local references 是否存在
-- built-in spec 是否能加载
-- `agent-registry.json` 是否存在
-- `acpx` 是否可调用
-- runtime 根目录是否可写
-
-## 内置 spec
-
-- `workflow-validation-minimal`
-- `workflow-validation-minimal-verify`
-- `bugfix-complex-template` (copy and fill before use)
-- `feature-complex-template` (copy and fill before use)
-
-这些 spec 用来做 package 自检，验证的是 workflow 包本身，不是产品功能。
-
-## 关键产物
-
-每次运行重点看：
-
-- `sprint.json`
-- `timeline.md`
-- `latest-summary.md`
-- `decision.md`
-- `scorecard.json`
-
-重要持久化字段：
-
-- `outputQuality`
-- `qualityReasons`
-- `validation`
-- `nextRunRecommendation`
-- `failureClassification`
-- `failureSource`
-- `recommendedNextAction`
-
-每个 stage 的 carry-forward 产物：
-
-- `checkpoint-summary.md`
-
-下一轮 continuation 应优先读取 `checkpoint-summary.md`，只有在不够用时才退回到完整的 `decision.md` 或 `handoff.json`。
-
-## 失败分类
-
-只能使用其中一个：
-
-- `workflow bug`：编排逻辑、产物布局、CLI、validation、持久化问题
-- `agent behavior issue`：workflow prompt / contract 正确，但 agent 输出质量或格式漂移
-- `environment issue`：二进制缺失、权限、文件系统、PATH、runtime 访问问题
-- `sample-spec issue`：spec 本身有问题，或暴露了不应在当前里程碑修的 sample-side / product-side 缺口
-
-## 复杂任务的最小 task contract
-
-复杂 bugfix 和 feature spec 必须显式提供：
-
-- `Goal`
-- `In scope`
-- `Out of scope`
-- `Validation commands`
-- `Expected artifacts`
-
-如果这些字段缺失，或者仍然是占位内容，packaged skill 会直接拒绝启动 sprint。
-
-## 执行范围限制
-
-复杂 spec 可以额外定义：
-
-- `maxFiles`
-- `maxChecks`
-- `maxDeliverables`
-
-producer 在改代码前，应先在 worklog 里声明 `PLANNED_FILES`、`PLANNED_CHECKS` 和 `DELIVERABLES`。如果一轮会超出范围，就缩小这一轮，而不是强行把大改塞进一次执行。
-
-## 同步规则
-
-事实来源仍然是：
-
-- the repository copy at `packages/openclaw-plugin/templates/langs/zh/skills/ai-sprint-orchestration`
-
-只有当变更影响以下内容时，才同步 packaged copy：
-
-- package-local CLI behavior
-- validation behavior
-- artifact layout
-- package-local references or runtime assumptions
-
-不要盲目镜像所有上游 orchestrator 修改。
-
-## 下一阶段架构方向
-
-这个 package 现在已经支持更细粒度的 `work-unit` 上下文约束。关键 work-unit 字段包括：
-
-- `workUnitId`
-- `workUnitGoal`
-- `allowedFiles`
-- `unitChecks`
-- `unitDeliverables`
-- `unitSummary`
-- `carryForwardSummary`
-
-continuation 默认优先读取更短的 `carryForwardSummary`，而不是回放整段历史 decision。目标是把跨 unit 传递的上下文压缩到最小必要信息，降低长运行过程里的上下文漂移。

package/templates/langs/zh/skills/ai-sprint-orchestration/SKILL.md

@@ -1,67 +0,0 @@
----
-name: ai-sprint-orchestration
-description: 使用打包好的 AI 冲刺编排器推进多阶段开发任务，内置基线检查、工作流验证、失败分类和 workflow-only 迭代纪律。
----
-
-# AI 冲刺编排
-
-当任务较大、需要多阶段推进，或者大概率会经历多轮 review / continuation 时，使用这个 skill。
-这个 skill 自带一份可直接运行的编排器打包副本，代理可以直接从当前 skill 目录启动，而不需要去仓库里寻找内部脚本入口。
-
-## 适用场景
-
-- 需要调研、实现、评审三段推进的复杂缺陷修复
-- 需要显式 producer / reviewer 决策门控的功能开发
-- 使用内置 validation spec 做 workflow 自检
-- 需要产物持久化和可恢复能力的长时任务
-
-## 不适用场景
-
-- 很小的单文件修改或简单文档修补
-- `packages/openclaw-plugin` 里的 product-side / sample-side 问题
-- 需要修改 `D:/Code/openclaw` 的任务
-- dashboard、stageGraph、自优化 sprint 或并行编排扩展
-
-## 快速开始
-
-在当前 skill 包根目录执行：
-
-1. 先做 package 烟雾检查：
-   `node scripts/run.mjs --self-check`
-   `node scripts/run.mjs --help`
-2. 再跑 package-local validation：
-   `node scripts/run.mjs --task workflow-validation-minimal`
-   `node scripts/run.mjs --task workflow-validation-minimal-verify`
-3. 产物默认落在：
-   `runtime/`
-
-内部 smoke 标准：
-
-- `node scripts/run.mjs --self-check` 通过
-- `workflow-validation-minimal` 至少推进到 producer 完成，并产出结构化 decision 或明确分类的 halt
-- `workflow-validation-minimal-verify` 至少推进到 producer 完成，任何 reviewer 失败都必须被分类，不能保持不透明
-
-如果你同时持有源码仓库，也可以额外运行仓库里 `packages/openclaw-plugin/templates/langs/zh/skills/ai-sprint-orchestration/test/` 的 source baseline tests。
-
-## 执行规则
-
-- 以仓库中的 `packages/openclaw-plugin/templates/langs/zh/skills/ai-sprint-orchestration` 作为代码事实来源；英文目录是分发镜像，不是独立实现分支。
-- 如果一次运行失败，只能归类成以下四类之一：
-  - `workflow bug`
-  - `agent behavior issue`
-  - `environment issue`
-  - `sample-spec issue`
-- 如果失败属于 product-side 或 sample-side，完成分类后立刻停止，不继续推进产品闭环修复。
-- 每轮只修一个 workflow-only 问题，然后重跑 baseline 和 validation。
-- 在新环境里第一次跑 validation 前，必须先执行 `node scripts/run.mjs --self-check`。
-- 对复杂 bugfix / feature 任务，必须先复制模板 spec，填好最小 task contract，再启动 sprint。
-
-## 输出要求
-
-每轮只汇报：
-
-- 改了什么
-- 跑了什么
-- 什么失败了
-- 失败归类是什么
-- 下一轮唯一推荐动作