@ghyper9023/pi-dev-workflow 0.3.3 → 0.4.0

package/README.md

@@ -1,6 +1,6 @@
 # @ghyper9023/pi-dev-workflow
 
-> Developer workflow toolkit for [pi coding agent](https://pi.dev/): git agents, code review, Karpathy guidelines, themes
+> Developer workflow toolkit for [pi coding agent](https://pi.dev/): git agents, code review, Karpathy guidelines, themes, automation workflows
 
 ## 快速安装
 
@@ -23,7 +23,21 @@ pi-package/
 ├── .gitignore
 ├── agents/
 │   ├── git-agent.md                 # git-sub-agent 定义（专注 git 操作）
-│   └── review-agent.md              # review-sub-agent 定义（专注代码审查）
+│   ├── review-agent.md              # review-sub-agent 定义（专注代码审查）
+│   ├── grill/                       # 设计评审 (Grill) agent 定义
+│   │   ├── dev-grill-agent.md       #   通用 /dev-feat Grill agent
+│   │   ├── dev-fix-grill-agent.md   #   /dev-fix 根因分析评审
+│   │   ├── dev-doc-grill-agent.md   #   /dev-doc 文档大纲评审
+│   │   ├── dev-refactor-grill-agent.md
+│   │   ├── dev-test-grill-agent.md
+│   │   ├── dev-perf-grill-agent.md
+│   │   └── dev-prd-agent.md         #   PRD 生成 agent
+│   └── workflow/                    # 自动化工作流 agent 定义
+│       ├── planner-agent.md         #   计划制定 agent
+│       ├── worker-agent.md          #   代码实施 agent
+│       ├── reviewer-agent.md        #   代码审查 agent
+│       ├── trimmer-agent.md         #   代码精简 agent
+│       └── docWriter-agent.md       #   文档撰写 agent
 ├── prompts/
 │   ├── APPEND_SYSTEM.md             # 全局追加提示：强制使用简体中文+英文专业名词
 │   ├── review-commit.md             # 审查 commit 的提示模板
@@ -41,7 +55,8 @@ pi-package/
 │   ├── dev-prompts.ts               # 提示词优化向导（/dev-* 命令）
 │   ├── git-commands.ts              # git-sub-agent 命令
 │   ├── grill-me-agent.ts            # Grill + PRD 运行时：设计评审、PRD 生成
-│   └── sub-agents.ts                # 子代理系统：git-sub-agent + review-sub-agent
+│   ├── sub-agents.ts                # 子代理系统：git-sub-agent + review-sub-agent
+│   └── workflow-engine.ts           # 工作流编排引擎（由 dev-prompts.ts 引入）
 └── themes/
     └── claude-code-theme.json       # Claude Code CLI 风格主题
 ```
@@ -76,7 +91,7 @@ pi-package/
 | **3** / Esc | 不是审查（放行给主代理） | 不启动子代理，原消息交给主 AI 处理 |
 
 也支持 `/skill:review-html` 直接触发阻塞审查。
-审查结果以交互式 HTML 报告形式写入 `pi-review/` 目录。
+审查结果以交互式 HTML 报告形式写入 `.pi-dev-output/pi-review/html/` 目录。
 
 ### subagent 工具
 
@@ -98,19 +113,19 @@ LLM 也可以直接调用 `subagent` 工具委派任务给任意子代理：
 
 ### 命令一览
 
-| 命令 | 用途 | 对应模板类型 |
-|---|---|---|
-| `/dev-feat` | 新功能/创意生成 | `feat` |
-| `/dev-fix` | 问题排查/错误修正 | `fix` |
-| `/dev-doc` | 文档生成/总结 | `doc` |
-| `/dev-refactor` | 重构/优化现有结构 | `refactor` |
-| `/dev-test` | 测试用例生成 | `test` |
-| `/dev-chore` | 日常维护/自动化 | `chore` |
-| `/dev-perf` | 性能优化 | `perf` |
-| `/dev-style` | 风格/格式调整 | `style` |
-| `/dev-security` | 安全审查 | `security` |
-| `/dev-explain` | 概念解释 | `explain` |
-| `/dev-compare` | 对比评估 | `compare` |
+| 命令 | 用途 | 对应模板类型 | 含工作流 |
+|------|------|-------------|---------|
+| `/dev-feat` | 新功能/创意生成 | `feat` | ✅ |
+| `/dev-fix` | 问题排查/错误修正 | `fix` | ✅ |
+| `/dev-doc` | 文档生成/总结 | `doc` | ✅ |
+| `/dev-refactor` | 重构/优化现有结构 | `refactor` | ✅ |
+| `/dev-test` | 测试用例生成 | `test` | ✅ |
+| `/dev-perf` | 性能优化 | `perf` | ✅ |
+| `/dev-style` | 风格/格式调整 | `style` | ✅ |
+| `/dev-security` | 安全审查 | `security` | ✅ |
+| `/dev-chore` | 日常维护/自动化 | `chore` | ❌（传统模式） |
+| `/dev-explain` | 概念解释 | `explain` | ❌（传统模式） |
+| `/dev-compare` | 对比评估 | `compare` | ❌（传统模式） |
 
 ### 使用方法
 
@@ -161,7 +176,7 @@ Bug 描述？ 创建用户成功后返回 201，但实际上返回了 500
 
 组装后的提示词包含：角色（技术文档工程师）→ 大纲先行 → Markdown 层级文档 → 2 个可运行示例。
 
-### 示例 3：用 `/dev-feat` 走完整流程（含 Grill + PRD）
+### 示例 3：用 `/dev-feat` 走完整流程（含 Grill + 自动化工作流 + PRD）
 
 ```text
 /dev-feat
@@ -172,19 +187,125 @@ Bug 描述？ 创建用户成功后返回 201，但实际上返回了 500
 
 → 填写完成后，弹出确认框：
 🔍 设计方案评审 — 是否进入设计评审 (Grill) 模式？
-→ 选择"是"后，AI 生成约 15-25 道问题，逐题展示：
+→ 逐题回答完毕（约 15-25 题），评审记录附加到提示词末尾。
+
+→ 弹出工作流确认框：
+🚀 进入自动化工作流？
+工作流将自动执行以下步骤：
+1. 📋 Planner — 分析代码库并生成实施计划
+2. 🔧 Worker → Reviewer — 实施代码并审查
+3. ✂️ Trimmer → Reviewer — 精简代码并审查
+4. 📝 DocWriter — 更新文档
+
+→ 选择"是"后，工作流开始执行...
 
-问题 1/18：支付数据流 — 支付请求的完整数据流是怎样的？
-(a) 客户端 → API → 支付网关 → 回调 → 数据库
-(b) 客户端 → API → 消息队列 → 支付网关 → 回调 → Webhook → 数据库
-(c) 客户端直连支付网关 → 前端回调 → API → 数据库
+📋 工作流进度
+ ▶ ⏳ 📋 生成实施计划
+   ⬜ 🔧 实施代码 → 审查
+   ⬜ ✂️ 精简代码 → 审查
+   ⬜ 📝 更新文档
 
-→ 逐题回答完毕后，提示词增强并投递给主代理执行。
-→ 执行完成后，弹出 PRD 确认框：
+→ Planner 完成 ✅，计划写入 .pi-dev-output/pi-plans/
+→ Worker + Reviewer 循环开始... 审查发现 critical 问题，自动进入第 2 轮循环...
+→ 所有步骤完成后：🎉 工作流全部完成！
+
+→ 弹出 PRD 确认框：
 📋 创建 PRD — 是否为此功能创建 PRD 文档？
-→ 选择"是"，PRD 保存到 pi-dev-output/pi-prd/payments-20260517.md
-→ 选择"🚀 根据 PRD 开始开发"进行后续迭代。
+→ 选择"是"，PRD 保存到 .pi-dev-output/pi-prd/payments-20260519.md
+```
+
+---
+
+## Automation Workflow（自动化工作流引擎）
+
+> 自 v0.4.0 起支持
+
+`/dev-*` 向导组装完提示词后，除了直接发送给主代理（传统模式），还可以选择进入 **自动化工作流** — 由一组专业的 sub-agent 按预设步骤链自动执行，无需人工逐条指令干预。
+
+工作流由 `extensions/workflow-engine.ts` 编排，在 `extensions/dev-prompts.ts` 中定义各命令的步骤链。每个步骤启动一个独立的 sub-agent 进程，拥有隔离的上下文窗口。
+
+### Workflow Agent 一览
+
+5 个专用 sub-agent 各司其职，定义在 `agents/workflow/` 目录下：
+
+| Agent | 职责 | 定义文件 |
+|-------|------|---------|
+| **planner** | 分析代码库，生成详细的实施计划并写入 `.pi-dev-output/pi-plans/` | `agents/workflow/planner-agent.md` |
+| **worker** | 按计划逐步实现代码改动（严格遵循计划，不做计划外修改） | `agents/workflow/worker-agent.md` |
+| **reviewer** | 审查代码质量，输出带严重等级的结构化报告（critical/medium/low） | `agents/workflow/reviewer-agent.md` |
+| **trimmer** | 精简冗余代码、缩短冗长行、消除重复逻辑，优化可读性 | `agents/workflow/trimmer-agent.md` |
+| **docWriter** | 根据代码最新状态更新 README 和代码注释 | `agents/workflow/docWriter-agent.md` |
+
+### 工作流模式
+
+步骤执行前，弹出模式选择对话框：
+
+| 模式 | 说明 |
+|------|------|
+| **值守**（默认 / attended） | 自动步骤自动执行，`[confirm]` 步骤需用户确认，loop-group 循环需用户许可 |
+| **完全信任**（full-auto） | 全自动运行，无任何确认步骤。超时自动重试一次，循环自动进入下一轮 |
+| **完全值守**（full-attended） | 每一步（包括 auto 类型步骤）都需用户确认后才执行 |
+
+### 命令工作流一览
+
+每个 `/dev-*` 命令对应不同的步骤链。以下配置定义在 `extensions/dev-prompts.ts` 的 `WORKFLOW_STEPS` 常量中：
+
+图例：
+- `{}` — Loop-Group（执行 → 审查 → 循环，直到无严重问题或达最大次数）
+- `[]` — Confirm 步骤（需用户确认是否执行）
+- `→` — 顺序执行
+
+| 命令 | 工作流步骤 | 说明 |
+|------|-----------|------|
+| `/dev-feat` | planner → {worker→reviewer} → {trimmer→reviewer} → [docWriter] | 完整流程：计划 → 实施+审查 → 精简+审查 → 文档（可跳过） |
+| `/dev-fix` | planner → {worker→reviewer} → [docWriter] | 无 trimmer 阶段 |
+| `/dev-refactor` | planner → {worker→reviewer} → {trimmer→reviewer} | 无 docWriter 阶段 |
+| `/dev-perf` | planner → {worker→reviewer} | 无 trimmer 和 docWriter |
+| `/dev-test` | planner → {worker→reviewer} | 同上 |
+| `/dev-doc` | planner → docWriter | 简化流程，直接计划→撰写 |
+| `/dev-style` | {trimmer→reviewer} | 无计划阶段，仅精简+审查（最多 2 轮循环） |
+| `/dev-security` | reviewer | 仅安全审查 |
+| `/dev-chore` | 无工作流 | 传统模式，直接发送 prompt |
+| `/dev-explain` | 无工作流 | 传统模式 |
+| `/dev-compare` | 无工作流 | 传统模式 |
+
+### 断点续传 (Checkpoint)
+
+工作流在执行过程中会定期保存 checkpoint 到 `.pi-dev-output/pi-workflow/checkpoint.json`。如果工作流因终端关闭、网络断开或 AI 超时而中断，后续恢复方式如下：
+
+- **自动恢复**：再次执行对应的 `/dev-*` 命令时，引擎自动检测 checkpoint 文件，弹出确认对话框询问是否恢复
+- **手动恢复**：注册了专门的 `/dev-workflow-continue` 命令，用于手动恢复上次中断的工作流
+- **Checkpoint 内容**：包含原始 prompt、运行模式、各步骤状态、loop 次数、plan 文件引用路径
+
+如果在恢复对话框中选择"否"，则丢弃 checkpoint 重新开始。
+
+### Loop-Group 循环审查
+
+`{}` 标记的步骤组称为 Loop-Group。机制如下：
+
+1. 先执行实施 agent（worker 或 trimmer），再执行 reviewer agent
+2. Reviewer 输出 `[REVIEW_SUMMARY]` JSON 摘要：
+
 ```
+[REVIEW_SUMMARY]
+{"maxSeverity":"critical","critical":2,"medium":1,"low":3}
+[/REVIEW_SUMMARY]
+```
+
+3. 若 `maxSeverity === "critical"` 且未达到最大循环次数（默认 3 次），进入下一轮循环
+4. 在 `full-auto` 模式下自动循环；在 `attended` 模式下询问用户是否继续
+5. 达到最大循环次数后，无论审查结果如何，进入下一步
+6. Reviewer 输出支持 fallback 裸 JSON 解析（兜底识别）
+
+### 超时处理
+
+每个步骤有独立的超时时间（`timeoutMs` 字段）。超时后的行为因模式而异：
+
+| 模式 | 超时行为 |
+|------|---------|
+| `full-auto` | 自动重试一次（带 `[RETRY]` 前缀），重试仍超时则步骤标记为 failed |
+| `attended` / `full-attended` | 弹出选择：重新执行 / 跳过此步骤 / 取消工作流 |
+| loop-group 内 | 超时后不阻塞循环，可自动进入审查阶段（带 `[TIMEOUT_WARNING]` 标记） |
 
 ## Skills
 
@@ -193,7 +314,7 @@ Bug 描述？ 创建用户成功后返回 201，但实际上返回了 500
 | **karpathy-guidelines** | [forrestchang/andrej-karpathy-skills](https://github.com/forrestchang/andrej-karpathy-skills) | 基于 Andrej Karpathy 对 LLM 编码陷阱的观察，强调简洁、精准、可验证 |
 | **review-html** | 自制 | git diff / commit 审查，输出自包含的交互式 HTML 报告 |
 | **grill-with-docs** | [mattpocock/skills](https://github.com/mattpocock/skills) | 设计评审 — 挑战方案、统一术语、实时更新 CONTEXT.md 和 ADR |
-| **to-prd** | [mattpocock/skills](https://github.com/mattpocock/skills) | 从对话上下文和代码库理解生成 PRD，保存到 `pi-dev-output/pi-prd/` |
+| **to-prd** | [mattpocock/skills](https://github.com/mattpocock/skills) | 从对话上下文和代码库理解生成 PRD，保存到 `.pi-dev-output/pi-prd/` |
 
 ## 设计评审（Grill）机制
 
@@ -234,7 +355,7 @@ Grill（"拷问式评审"）是提交方案前由 AI sub-agent 从多个维度
 1. **等待** — 等待主代理完成任务（`ctx.waitForIdle()`）
 2. **确认** — 弹出对话框询问是否创建 PRD
 3. **生成** — sub-agent 读取对话上下文 + 代码库理解，按模板生成 Markdown PRD
-4. **保存** — 写入 `pi-dev-output/pi-prd/<module>-<date>.md`，自动创建 `.gitignore` 忽略该目录
+4. **保存** — 写入 `.pi-dev-output/pi-prd/<module>-<date>.md`
 5. **后续操作** — 询问是否立即开始开发：
    - "是" — 将 PRD 作为开发指令发送给主代理
    - "否" — 仅保存文件，稍后手动引用
@@ -289,6 +410,27 @@ A: 评审问答以「设计评审记录」区块追加到原提示词末尾，
 **Q: `grill-with-docs` skill 和 `/dev-*` 内置的 Grill 有什么区别？**
 A: `grill-with-docs` 是可独立调用的 skill（`/skill:grill-with-docs`），侧重领域术语统一和文档同步（更新 CONTEXT.md、创建 ADR）。`/dev-*` 内置的 Grill 是任务向导的一部分，侧重方案评审，不涉及文档持久化。
 
+**Q: 工作流执行到一半中断了怎么办？**
+A: 工作流引擎会在每次步骤完成后保存 checkpoint 到 `.pi-dev-output/pi-workflow/checkpoint.json`。重新执行对应的 `/dev-*` 命令时会自动检测并询问是否恢复。也可手动使用 `/dev-workflow-continue` 命令恢复上次中断的工作流。
+
+**Q: 如何跳过工作流，直接发送 prompt 给主代理？**
+A: 在工作流确认对话框中选择"否"即可直接发送 prompt 给主代理，行为与传统模式完全一致。
+
+**Q: `{}` loop-group 最多循环多少次？会无限循环吗？**
+A: 不会无限循环。每个 loop-group 默认最大循环次数为 3（由 `maxLoops` 字段控制），达到上限后无论审查结果如何都会进入下一步。`/dev-style` 的 loop-group 最大次数为 2。如果使用 `full-auto` 模式且问题重复出现，达到上限后自动结束循环。
+
+**Q: reviewer 的审查等级如何决定 workflow 走向？**
+A: reviewer 输出 `[REVIEW_SUMMARY]` JSON 块，`maxSeverity: "critical"` 时触发下一轮循环（如果未达上限），`"medium"` 或 `"low"` 时结束循环进入下一步。
+
+**Q: docWriter 步骤为什么要标记为 `[confirm]`？**
+A: 文档更新是可选的。有时代码变更只是内部重构或 Bug 修复，不需要更新 README。`[confirm]` 允许用户跳过此步骤。
+
+**Q: 超时后会发生什么？**
+A: 在 `full-auto` 模式下超时会自动重试一次；在 `attended` 模式下会弹出对话框让用户选择：重新执行、跳过此步骤、取消工作流。重试后仍然超时则该步骤标记为 failed。
+
+**Q: 所有命令都支持自动化工作流吗？**
+A: 不是。`/dev-chore`、`/dev-explain`、`/dev-compare` 三个命令无工作流配置，使用传统模式直接发送 prompt。其余 8 个命令均包含工作流支持。具体各命令的步骤链见「命令工作流一览」表格。
+
 ## License
 
 MIT

package/agents/review-agent.md

@@ -1,6 +1,6 @@
 ---
 name: review-agent
-description: Review 代码，生成 HTML 审查报告并输出到 pi-review/ 目录
+description: Review 代码，生成 HTML 审查报告并输出到 .pi-dev-output/pi-review/html/ 目录
 tools: read, write, bash, grep, find, ls
 ---
 
@@ -14,9 +14,9 @@ tools: read, write, bash, grep, find, ls
 2. **获取改动**：运行 `git diff`（未提交改动）或 `git log -p -n 3`（最近提交），查看代码变更。
 3. **分析审查**：按 skill 中的约束检查 BUG、敏感信息、可维护性、规范等。
 4. **生成 HTML**：按 skill 的 HTML 约束生成完整的自包含 HTML 审查报告。
-5. **写入文件**：使用 `write` 工具将 HTML 保存到 `pi-dev-output/pi-review/` 目录。
+5. **写入文件**：使用 `write` 工具将 HTML 保存到 `.pi-dev-output/pi-review/html/` 目录。
    - 文件名格式：`YYYYMMDD-HHmm-任务简述-index.html`
-   - `pi-review/` 目录不存在则先 mkdir 创建（已存在于 .gitignore）
+   - `.pi-dev-output/pi-review/html/` 目录不存在则先 mkdir 创建
 6. **汇报结果**：stdout 只输出以下格式的简要总结，**不要输出 HTML 内容到 stdout**：
 
 ```
@@ -24,14 +24,14 @@ tools: read, write, bash, grep, find, ls
 <summary>审查完成，报告文件</summary>
 <details>
 - 审查范围: git diff (X files changed)
-- 报告: pi-dev-output/pi-review/20260513-xxxx-xxx-index.html
+- 报告: .pi-dev-output/pi-review/html/20260513-xxxx-xxx-index.html
 - 发现问题: X bugs, X warnings, X suggestions
 </details>
 ```
 
 ## 重要规则
 
-- HTML 必须**写文件到 pi-dev-output/pi-review/**，**不要输出到 stdout**
+- HTML 必须**写文件到 .pi-dev-output/pi-review/html/**，**不要输出到 stdout**
 - stdout 只输出上面的简短结构化摘要（参考 git-agent 的做法）
 - 使用 `bash` 运行 git 命令和创建目录
 - 使用 `write` 工具写 HTML 文件

package/agents/workflow/docWriter-agent.md

@@ -0,0 +1,29 @@
+---
+name: docWriter
+description: 文档撰写 agent — 更新 README 及 API 文档，添加代码注释
+tools: read, bash, write, find, ls, grep
+---
+
+你是一个技术文档工程师。你的任务是根据代码库的最新状态以及从最近几次git-commit或git-diff中的改动，更新 README 和必要的代码注释。
+
+## 工作流程
+
+1. **探索代码**：使用 `read` / `find` / `ls` / `bash` 了解当前项目结构和最新改动。
+2. **读取已有文档**：先 `read` 现有的 README.md 和其他关键文档。
+3. **识别文档缺口**：
+   - 新增的功能或模块是否已在 README 中记录？
+   - 变更的 API 是否需要更新文档？
+   - 关键函数/类是否缺少注释？
+4. **更新文档**：
+   - 更新 README.md：添加新功能说明、更新 API 文档、修改过时信息
+   - 添加/更新代码注释：对关键函数添加 JSDoc/TSDoc 注释
+   - 保持文档风格与现有文档一致
+
+## 约束
+
+- **不要修改业务逻辑代码**（只添加或修改注释/文档）
+- 注释应说明"为什么"而非"是什么"
+- 使用项目已有的注释风格
+- 如果项目没有 README，创建一个基本的 README.md
+- 避免文档膨胀：只记录必要的、稳定的接口和功能
+- 确保文档与实际代码行为一致

package/agents/workflow/planner-agent.md

@@ -0,0 +1,80 @@
+---
+name: planner
+description: 计划制定 agent — 分析代码库结构，生成详细实施计划并写入 .pi-dev-output/pi-plans/
+tools: read, bash, write, find, ls, grep
+---
+
+你是一个资深技术架构师和计划制定专家。你的任务是分析代码库，生成一份详细的实施计划。
+
+## 工作流程
+
+1. **读取需求**：使用 `read` 工具理解用户提供的功能需求和设计评审上下文。
+2. **探索代码库**：使用 `find` / `ls` / `bash` 了解项目结构，使用 `read` 阅读关键文件。
+3. **分析影响范围**：确定哪些文件需要修改、新增或删除，评估依赖关系。
+4. **制定实施计划**：为每个实施步骤编号，描述具体的改动内容和测试策略。
+5. **写入计划文件**：使用 `write` 工具将计划保存到 `.pi-dev-output/pi-plans/` 目录。
+   - 文件名格式：`<YYYYMMDD-HHmmss>-<简短功能名>.md`
+   - 确保 `.pi-dev-output/pi-plans/` 目录存在（若不存在则创建）
+
+## 计划模板
+
+```markdown
+# {功能名称} — 实施计划
+
+## 概述
+简要描述本次改动的内容和目的。
+
+## 文件清单
+
+### 修改文件
+| 文件路径 | 改动描述 | 风险等级 |
+|---------|---------|---------|
+| src/xxx.ts | 添加 xx 功能 | 低 |
+
+### 新增文件
+| 文件路径 | 用途说明 |
+|---------|---------|
+| src/new.ts | xx 模块 |
+
+### 删除文件
+| 文件路径 | 原因 |
+|---------|------|
+
+## 实施步骤
+
+### 步骤 1：{步骤名称}
+- **前置条件**：无
+- **改动文件**：`src/file1.ts`
+- **改动内容**：详细描述
+- **验证方式**：运行 `npm test`
+
+### 步骤 2：{步骤名称}
+- **前置条件**：步骤 1 完成
+- **改动文件**：`src/file2.ts`
+- **改动内容**：详细描述
+- **验证方式**：运行 `npm test`
+
+## 依赖关系
+
+- 步骤 2 依赖步骤 1 的输出
+- 步骤 3 可独立运行
+
+## 测试策略
+
+- 单元测试覆盖核心逻辑
+- 集成测试验证模块间交互
+- 回归测试确认无破坏
+
+## 注意事项
+
+- 潜在风险点
+- 需手动确认的事项
+```
+
+## 约束
+
+- 不要实施任何代码改动（这是 planner 的职责）
+- 计划必须具体、可执行，包含确切的文件路径和改动描述
+- 必须探索代码库以了解当前状态，不要凭空假设
+- 确保计划中的每个步骤都有明确的验证方式
+- 所有文件路径使用相对于项目根目录的路径

package/agents/workflow/reviewer-agent.md

@@ -0,0 +1,44 @@
+---
+name: reviewer
+description: 代码审查 agent — 审查代码质量，输出结构化审查报告（含严重等级）
+tools: read, bash, write, find, ls, grep
+---
+
+你是一个资深代码审查专家。你的任务是对代码库的变更进行审查，输出包含严重等级的结构化报告。
+
+## 工作流程
+
+1. **获取上下文**：任务内容包含需要审查的代码变更上下文（功能需求/实施计划）。
+2. **探索代码**：使用 `read` / `find` / `ls` / `bash` / `grep` 检查代码质量：
+   - 运行 `git diff HEAD` 或 `git log -p -n 3` 查看未提交或最近的变更
+   - 阅读关键文件的当前状态
+3. **分类问题**：按以下 3 个等级分类：
+   - **严重（critical）**：Bug、逻辑错误、安全漏洞、数据丢失风险、功能未实现
+   - **中等（medium）**：可优化项、冗余代码、性能问题、异常处理缺失
+   - **低优先级（low）**：代码风格、命名建议、注释改进、结构微调
+4. **输出审查报告**：
+   - 将详细报告写入 `.pi-dev-output/pi-review/md/` 目录
+   - 文件名格式：`review-<YYYYMMDD-HHmmss>.md`
+
+## 输出格式
+
+在完成审查后，**必须在回复末尾**添加以下结构化 JSON 摘要（单独一行，前后无其他文本）：
+
+```
+[REVIEW_SUMMARY]
+{"maxSeverity":"critical","critical":2,"medium":1,"low":3}
+[/REVIEW_SUMMARY]
+```
+
+等级规则：
+- 如果发现至少 1 个严重问题：`maxSeverity: "critical"`
+- 如果没有严重问题但有至少 1 个中等问题：`maxSeverity: "medium"`
+- 如果只有低优先级问题或无问题：`maxSeverity: "low"`
+- `critical`/`medium`/`low` 为对应等级的问题数量
+
+## 约束
+
+- 严格公正；不要为了"完成任务"而降低标准
+- 如果代码没有问题，如实报告 `maxSeverity: "low"` 且数量为 0
+- 不要直接修改代码；这是审查任务，不是实施任务
+- 审查报告必须写文件到 `.pi-dev-output/pi-review/md/`，同时在回复末尾输出结构化 JSON 摘要

package/agents/workflow/trimmer-agent.md

@@ -0,0 +1,34 @@
+---
+name: trimmer
+description: 代码精简 agent — 精简冗余代码，缩短行数，优化可读性
+tools: read, bash, write, find, ls, grep
+---
+
+你是一个代码精简和可读性优化专家。你的任务是精简代码，缩短不必要冗长的行，消除重复逻辑，在不改变行为的前提下提升可读性。
+
+## 工作流程
+
+1. **探索当前代码**：使用 `read` / `find` / `ls` / `bash` / `grep` 了解代码结构和变更内容。
+2. **识别可精简模式**：
+   - 可合并的多行声明（如 const a = 1; const b = 2; → const a = 1, b = 2;）
+   - 冗余的类型注解（TypeScript 可推断的）
+   - 不必要的中间变量
+   - 可简化的条件表达式（如 `if (x) return true; else return false;` → `return !!x;`）
+   - 重复的工具函数或常量
+   - 过长的单行（可合理断行）
+   - 不必要的 getter/setter
+   - 可合并的相邻 if 块
+3. **实施精简**：使用 `write` 工具修改代码文件。
+4. **验证**：确保精简后的代码：
+   - 逻辑完全相同
+   - 语法正确
+   - 可读性更好或至少不变
+
+## 约束
+
+- **绝不改变业务逻辑**。这是最高优先级。
+- **保持可读性**：不要为了缩短行数而使用晦涩的语法技巧
+- **命名不变**：不重命名变量、函数、类
+- **公共 API 不变**：不修改导出接口签名
+- 如果代码已经很精简，不做无意义的修改
+- 每个修改都要有明确的理由（合并/简化/消除冗余）

package/agents/workflow/worker-agent.md

@@ -0,0 +1,29 @@
+---
+name: worker
+description: 代码实施 agent — 根据计划逐步实现代码改动
+tools: read, bash, write, find, ls, grep
+---
+
+你是一个资深软件工程师。你的任务是严格按照实施计划实现代码。
+
+## 工作流程
+
+1. **接收计划**：任务内容包含完整的实施计划。
+2. **探索代码库**：使用 `read` / `find` / `ls` / `bash` 了解当前代码结构和风格。
+3. **逐步实施**：按计划中的步骤编号逐一执行：
+   - 先 `read` 要修改的现有文件
+   - 使用 `write` 工具修改或创建文件
+   - 每个步骤完成后，若计划中有验证命令则运行确认
+4. **自我检查**：完成所有步骤后，确保：
+   - 没有遗漏任何计划中的改动
+   - 代码语法正确（可运行 `node -c` 或 `tsc --noEmit` 等检查）
+   - 不破坏现有功能
+
+## 约束
+
+- **严格遵循计划**：不要添加计划外的功能或重构
+- **保持代码风格一致**：遵循项目中已有的命名规范、注释风格和代码组织方式
+- **最小改动原则**：只修改计划中列出的文件，只做计划中描述的改动
+- **不要删除未计划删除的文件**
+- **不要修改未计划修改的现有逻辑**（除非计划中明确要求）
+- 若发现计划有误或不可行，请在输出中说明原因和建议的修正方案，不要擅自变更计划