pi-workflow

Pi 的任务管理、自我改进和代码质量标准的工作流程编排。在开始新项目、管理多步骤任务（3 个以上步骤或架构决策）、从错误中吸取教训、编写可验证的代码或在完成之前建立质量关卡时使用。包括计划模板、进度跟踪、错误修复自主性以及防止重复错误的经验教训捕获系统。

# Pi Workflow Orchestration

This skill provides Pi's structured approach to task management, quality assurance, and continuous self-improvement.

## Core Workflows

### 1. Plan Node Default
Enter plan mode for ANY non-trivial task (3+ steps or architectural decisions):
- Write detailed specs upfront to reduce ambiguity
- If something goes sideways, STOP and re-plan immediately—don't keep pushing
- Use plan mode for verification steps, not just building

### 2. Subagent Strategy
- Use subagents liberally to keep main context window clean
- Offload research, exploration, and parallel analysis to subagents
- For complex problems, throw more compute at it via subagents
- One tack per subagent for focused execution

### 3. Self-Improvement Loop
- After ANY correction from the user: update `tasks/lessons.md` with metadata (Priority, Status, Area, Pattern-Key)
- Log command failures to `tasks/errors.md` for diagnosis patterns
- Log feature requests to `tasks/feature_requests.md` for future work
- Write rules for yourself that prevent the same mistake
- Ruthlessly iterate on these lessons until mistake rate drops
- Review lessons at session start for relevant projects
- Track recurring patterns with Recurrence-Count (bump priority at ≥3 occurrences)

### 4. Verification Before Done
- Never mark a task complete without proving it works
- Diff behavior between main and your changes when relevant
- Ask yourself: "Would a staff engineer approve this?"
- Run tests, check logs, demonstrate correctness

### 5. Demand Elegance (Balanced)
- For non-trivial changes: pause and ask "is there a more elegant way?"
- If a fix feels hacky: "Knowing everything I know now, implement the elegant solution"
- Skip this for simple, obvious fixes—don't over-engineer
- Challenge your own work before presenting it

### 6. Autonomous Bug Fixing
- When given a bug report: just fix it. Don't ask for hand-holding
- Point at logs, errors, failing tests—then resolve them
- Zero context switching required from the user
- Go fix failing CI tests without being told how

## Task Management

1. **Plan First**: Write plan to `tasks/todo.md` with checkable items
2. **Verify Plan**: Check in before starting implementation
3. **Track Progress**: Mark items complete as you go
4. **Explain Changes**: High-level summary at each step
5. **Document Results**: Add review section to `tasks/todo.md`
6. **Capture Lessons**: Update `tasks/lessons.md` after corrections

## File Organization

- `tasks/todo.md` — active sprint (current project)
- `tasks/lessons.md` — corrections, insights, best practices (structured)
- `tasks/errors.md` — command failures, API errors, exceptions (NEW)
- `tasks/feature_requests.md` — missing capabilities, feature requests (NEW)
- `memory/YYYY-MM-DD.md` — session logs (daily)
- `MEMORY.md` — your curated memories (maintained by user)

See [WORKFLOW_ORCHESTRATION.md](references/workflow_orchestration.md) for detailed reference.

See [LESSONS.md](references/lessons.md) for philosophy and framing.

See [PHASE1-PHASE2-ENHANCED-LESSONS.md](references/phase1-phase2-enhanced-lessons.md) for structured lesson format and file separation.

See [LESSONS_UPDATE_GUIDE.md](references/lessons_update_guide.md) for syncing lessons from workspace to skill.

## Capturing Lessons

### Lessons Format (Phase 1+2 Enhanced)

Each lesson gets structured metadata for filtering and recurring pattern detection:

```markdown
## [LRN-YYYYMMDD-XXX] rule_name (category)

**Logged**: ISO-8601 timestamp
**Priority**: low | medium | high | critical
**Status**: pending | in_progress | resolved | promoted
**Area**: backend | infra | tests | docs | config
**Pattern-Key**: category.pattern_name (optional, for recurring detection)

### Summary
One-line description

### Details
Full context and examples

### Applied to
Projects or files where this was used

### Metadata
- Source: correction | insight | user_feedback
- Related Files: path/to/file
- Tags: tag1, tag2
- See Also: LRN-20250225-001 (if related to existing entry)
- Recurrence-Count: 1 (increment if you see it again)
- First-Seen: 2025-02-23
- Last-Seen: 2025-02-23
```

### Errors & Features (NEW)

Log failures and feature gaps separately for better organization:

**Errors** (`tasks/errors.md`):
- Command failures, API errors, exceptions
- Include reproducibility, environment, suggested fix

**Features** (`tasks/feature_requests.md`):
- Missing capabilities, things you wish existed
- Include complexity estimate and suggested implementation

### Syncing to Skill

Periodically merge workspace lessons into the published skill:

```bash
# From openclaw-workflow repo
python3 scripts/sync_lessons.py --workspace ~/.openclaw/workspace

# Dry run (preview changes)
python3 scripts/sync_lessons.py --workspace ~/.openclaw/workspace --dry-run
```

This merges workspace lessons into `references/lessons.md` for version control and sharing.

## Hooks (Optional)

Enable automatic bootstrap reminders for self-improvement:

```bash
openclaw hooks enable pi-workflow
```

This injects a reminder at session start showing:
- When to log lessons/errors/features
- Format and metadata fields
- Recurring pattern detection
- Promotion paths

See `hooks/openclaw/HOOK.md` for details.

---

## Core Principles

- **Simplicity First**: Make every change as simple as possible. Minimal code impact.
- **No Laziness**: Find root causes. No temporary fixes. Senior developer standards.
- **Minimal Impact**: Changes should only touch what's necessary. Avoid introducing bugs.

---

## 中文说明

# Pi 工作流编排

本技能提供 Pi 在任务管理、质量保证和持续自我改进方面的结构化方法。

## 核心工作流

### 1. 默认进入计划节点
对于任何非琐碎任务（3 个以上步骤或架构决策）进入计划模式：
- 预先编写详细规格说明以减少歧义
- 如果出现偏差，立即停止并重新计划——不要硬推
- 将计划模式用于验证步骤，而不仅仅是构建

### 2. 子代理策略
- 大量使用子代理以保持主上下文窗口干净
- 将研究、探索和并行分析卸载给子代理
- 对于复杂问题，通过子代理投入更多算力
- 每个子代理专注于一条思路以实现聚焦执行

### 3. 自我改进循环
- 在用户提出任何纠正后：用元数据（Priority、Status、Area、Pattern-Key）更新 `tasks/lessons.md`
- 将命令失败记录到 `tasks/errors.md` 以形成诊断模式
- 将功能请求记录到 `tasks/feature_requests.md` 以供未来工作
- 为自己编写规则以防止重复同一错误
- 无情地迭代这些经验教训，直到错误率下降
- 在会话开始时为相关项目回顾经验教训
- 使用 Recurrence-Count 跟踪重复模式（出现 ≥3 次时提升优先级）

### 4. 完成前验证
- 在证明任务可行之前绝不标记为完成
- 在相关时对比 main 与你的更改之间的行为差异
- 问自己："资深工程师会批准这个吗？"
- 运行测试、检查日志、证明正确性

### 5. 追求优雅（适度）
- 对于非琐碎更改：暂停并问"有没有更优雅的方式？"
- 如果某个修复感觉很 hacky："以我现在知道的一切，实现优雅的解决方案"
- 对于简单、明显的修复跳过此步骤——不要过度工程
- 在呈现之前先挑战自己的工作

### 6. 自主修复 Bug
- 收到 bug 报告时：直接修复它。不要要求别人手把手指导
- 指向日志、错误、失败的测试——然后解决它们
- 无需用户进行任何上下文切换
- 无需别人告知如何做，主动去修复失败的 CI 测试

## 任务管理

1. **先计划**：将带可勾选项的计划写入 `tasks/todo.md`
2. **验证计划**：在开始实现前先确认
3. **跟踪进度**：随进展标记完成项
4. **解释变更**：在每一步给出高层次摘要
5. **记录结果**：在 `tasks/todo.md` 中添加回顾部分
6. **捕获经验**：在纠正后更新 `tasks/lessons.md`

## 文件组织

- `tasks/todo.md` — 当前冲刺（当前项目）
- `tasks/lessons.md` — 纠正、洞见、最佳实践（结构化）
- `tasks/errors.md` — 命令失败、API 错误、异常（新增）
- `tasks/feature_requests.md` — 缺失的能力、功能请求（新增）
- `memory/YYYY-MM-DD.md` — 会话日志（每日）
- `MEMORY.md` — 你精心整理的记忆（由用户维护）

参见 [WORKFLOW_ORCHESTRATION.md](references/workflow_orchestration.md) 获取详细参考。

参见 [LESSONS.md](references/lessons.md) 了解理念与框架。

参见 [PHASE1-PHASE2-ENHANCED-LESSONS.md](references/phase1-phase2-enhanced-lessons.md) 了解结构化经验格式和文件分离。

参见 [LESSONS_UPDATE_GUIDE.md](references/lessons_update_guide.md) 了解如何将经验从工作区同步到技能。

## 捕获经验教训

### 经验格式（Phase 1+2 增强版）

每条经验都有结构化元数据，用于过滤和重复模式检测：

```markdown
## [LRN-YYYYMMDD-XXX] rule_name (category)

**Logged**: ISO-8601 timestamp
**Priority**: low | medium | high | critical
**Status**: pending | in_progress | resolved | promoted
**Area**: backend | infra | tests | docs | config
**Pattern-Key**: category.pattern_name (optional, for recurring detection)

### Summary
One-line description

### Details
Full context and examples

### Applied to
Projects or files where this was used

### Metadata
- Source: correction | insight | user_feedback
- Related Files: path/to/file
- Tags: tag1, tag2
- See Also: LRN-20250225-001 (if related to existing entry)
- Recurrence-Count: 1 (increment if you see it again)
- First-Seen: 2025-02-23
- Last-Seen: 2025-02-23
```

### 错误与功能（新增）

将失败和功能缺口分开记录以便更好地组织：

**错误**（`