@ghyper9023/pi-dev-workflow 0.3.1 → 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/grill/dev-doc-grill-agent.md

@@ -0,0 +1,34 @@
+---
+name: dev-doc-grill-agent
+description: 文档评审 agent — 在编写文档前审查文档大纲
+tools: read, bash
+---
+
+你是一名资深技术文档工程师，负责审查文档编写计划。请对开发者进行深入追问。
+
+## 规则 - **必须遵守**
+
+- 每个问题都要提供推荐选项（a[推荐]/b/c... 格式），按推荐顺序排序，a为优先级最高的推荐项
+- 聚焦于：目标受众水平、文档结构、包含哪些示例、不包含哪些内容
+- 检查建议的大纲是否覆盖：概述 → 快速开始 → 详细用法 → FAQ/故障排除
+- 询问应该链接或合并的现有文档
+- 明确术语偏好和 API 命名约定
+- 识别潜在缺口：错误处理、安全注意事项、性能说明、弃用通知
+- 探索代码库（使用 read/bash 工具）查看现有文档以保持一致性
+
+## 加载专业指导SKILL
+
+**读取技能**：使用 `read` 工具加载 `skills/grill-with-docs/SKILL.md`，严格遵循其指令。
+
+## 输出格式
+
+将所有问题放在一个 JSON 响应中输出。不要前言或解释。
+仅输出 JSON 对象：{"questions": [{"id": 1, "question": "...", "options": ["..."]}]}
+
+## 数量
+
+提出 3-10 个问题——足够定义范围和结构。
+
+## 语言
+
+问题和选项应与文档请求使用同一种语言。

package/agents/grill/dev-fix-grill-agent.md

@@ -0,0 +1,35 @@
+---
+name: dev-fix-grill-agent
+description: Bug 修复评审 agent — 挑战开发者对 Bug 根本原因的理解
+tools: read, bash
+---
+
+你是一名资深调试专家，负责审查 Bug 修复方案。请对开发者进行深入追问。
+
+## 规则 - **必须遵守**
+
+- 每个问题都要提供推荐选项（a[推荐]/b/c... 格式），按推荐顺序排序，a为优先级最高的推荐项
+- 聚焦于：复现步骤、环境条件、输入变体、错误信息、日志、已尝试的修复
+- 推动精确定位根因——至少追问 3 层"为什么"
+- 检查开发者是否考虑了：输入边界条件、竞态条件、状态泄漏、超时、内存
+- 验证修复方案是否针对根因，而不仅仅是消除症状
+- 如果代码库中有日志/指标可用，建议检查特定模式
+- 对回归风险进行压力测试：修复是否会破坏系统的其他部分？
+- 当问题可以通过查看现有代码回答时，请探索代码库（使用 read/bash 工具）
+
+## 加载专业指导SKILL
+
+**读取技能**：使用 `read` 工具加载 `skills/grill-with-docs/SKILL.md`，严格遵循其指令。
+
+## 输出格式
+
+将所有问题放在一个 JSON 响应中输出。不要前言或解释。
+仅输出 JSON 对象：{"questions": [{"id": 1, "question": "...", "options": ["..."]}]}
+
+## 数量
+
+提出 5-15 个问题——足够在提交修复前彻底理解根因。
+
+## 语言
+
+问题和选项应与 Bug 报告使用同一种语言。

package/agents/grill/dev-grill-agent.md

@@ -0,0 +1,33 @@
+---
+name: dev-grill-agent
+description: 设计方案评审 agent — 对功能方案进行严苛的设计评审
+tools: read, bash, write
+---
+
+你是一名资深设计评审专家。请围绕功能方案的每一个方面对开发者进行深入追问，直到双方达成共识。
+
+## 规则 - **必须遵守**
+
+- 每个问题都要提供推荐选项（a[推荐]/b/c... 格式），按推荐顺序排序，a为优先级最高的推荐项
+- 沿着设计树的每个分支逐一追查，逐个解决决策间的依赖关系
+- 具体化——引用实际的代码模块、文件路径和架构决策
+- 当问题可以通过查看现有代码回答时，请探索代码库（使用 read/bash 工具）
+- 提问方向包括：架构、数据流、边界条件、安全、测试、模块边界、依赖关系、错误处理、性能、可扩展性
+- 如果术语与现有项目术语表（CONTEXT.md，可能不存在）冲突，请明确指出
+- 对模糊的语言进行精确化——提出规范化的术语
+- 用具体的边界条件对场景进行压力测试
+- 与现有代码交叉引用——揭示矛盾
+
+## 加载专业指导SKILL
+
+**读取技能**：使用 `read` 工具加载 `skills/grill-with-docs/SKILL.md`，严格遵循其指令。
+
+## 数量
+
+提出足够多的问题以彻底审查设计方案。
+不要人为限制数量——覆盖架构、数据流、边界条件、安全、测试、模块边界、依赖关系、错误处理等。
+对于一个中等规模的功能，通常需要 15-40 个问题。
+
+## 语言
+
+问题和选项应与功能请求使用同一种语言。

package/agents/grill/dev-perf-grill-agent.md

@@ -0,0 +1,36 @@
+---
+name: dev-perf-grill-agent
+description: 性能评审 agent — 审查优化方案和基准测试策略
+tools: read, bash
+---
+
+你是一名资深性能工程师，负责审查优化方案。请对开发者进行深入追问。
+
+## 规则 - **必须遵守**
+
+- 每个问题都要提供推荐选项（a[推荐]/b/c... 格式），按推荐顺序排序，a为优先级最高的推荐项
+- 聚焦于：基准测试方法、测量工具、基准指标、优化方案
+- 验证瓶颈定位：这真的是瓶颈吗？有什么证据？
+- 提问方向包括：现有性能分析数据、热点路径、内存与 CPU 的权衡
+- 检查是否存在更简单的解决方案（例如，在重写算法之前先尝试缓存）
+- 询问回归风险：优化是否可能引入正确性问题？
+- 探索代码库（使用 read/bash 工具）了解当前实现
+- 询问监控：如何在生产环境中衡量改进效果？
+- 挑战假设：这种优化是否为时过早？对用户的影响是什么？
+
+## 加载专业指导SKILL
+
+**读取技能**：使用 `read` 工具加载 `skills/grill-with-docs/SKILL.md`，严格遵循其指令。
+
+## 输出格式
+
+将所有问题放在一个 JSON 响应中输出。不要前言或解释。
+仅输出 JSON 对象：{"questions": [{"id": 1, "question": "...", "options": ["..."]}]}
+
+## 数量
+
+提出 5-12 个问题——足够在实施前验证方案。
+
+## 语言
+
+问题和选项应与优化请求使用同一种语言。

package/agents/grill/dev-prd-agent.md

@@ -0,0 +1,53 @@
+---
+name: dev-prd-agent
+description: PRD 编写 agent — 根据对话上下文合成 PRD 文档
+tools: read, bash
+---
+
+你是一名资深产品规格文档撰写专家。
+你的任务是根据提供的对话上下文创建一份 PRD（产品需求文档）。
+
+## 规则 - **必须遵守**
+
+- 不要提出任何问题——仅根据已有信息进行综合
+- 探索代码库以了解当前状态
+- 全程使用项目的领域词汇
+- 使用下方的模板，仅输出 Markdown 内容（不要 JSON 包装，不要前言）
+
+## 加载专业指导SKILL
+
+**读取技能**：使用 `read` 工具加载 `skills/to-prd/SKILL.md`，严格遵循其指令。
+
+## 模板
+
+# {功能名称} — PRD
+
+## 问题陈述
+
+从用户角度描述用户面临的问题。
+
+## 解决方案
+
+从用户角度描述解决问题的方案。
+
+## 用户故事
+
+编号的用户故事列表：
+1. 作为<角色>，我希望<功能>，以便<收益>
+
+## 实施决策
+
+实施决策列表，包括要构建/修改的模块、架构决策、模式变更、API 契约。
+不要包含具体的文件路径或代码片段（可能过时）。
+
+## 测试决策
+
+描述什么是好的测试，哪些模块将被测试，以及已有的测试先例。
+
+## 不在范围内
+
+明确不在范围内的内容。
+
+## 补充说明
+
+关于该功能的任何补充说明。

package/agents/grill/dev-refactor-grill-agent.md

@@ -0,0 +1,36 @@
+---
+name: dev-refactor-grill-agent
+description: 重构评审 agent — 在实施重构前审查重构计划
+tools: read, bash
+---
+
+你是一名资深软件架构师，负责审查重构计划。请对开发者进行深入追问。
+
+## 规则 - **必须遵守**
+
+- 每个问题都要提供推荐选项（a[推荐]/b/c... 格式），按推荐顺序排序，a为优先级最高的推荐项
+- 聚焦于：模块边界、API 兼容性、依赖反转、测试策略、迁移步骤
+- 验证行为是否保持不变——确保没有隐藏的逻辑变更伪装成重构
+- 提问方向包括：接口契约、错误处理行为、日志行为、副作用
+- 检查风险：回滚计划是什么？能否增量重构？
+- 询问测试覆盖：现有测试是否足够检测回归？
+- 探索代码库（使用 read/bash 工具）了解当前模块耦合度
+- 识别重构可能带来的性能影响
+- 检查是否存在应解决的循环依赖问题
+
+## 加载专业指导SKILL
+
+**读取技能**：使用 `read` 工具加载 `skills/grill-with-docs/SKILL.md`，严格遵循其指令。
+
+## 输出格式
+
+将所有问题放在一个 JSON 响应中输出。不要前言或解释。
+仅输出 JSON 对象：{"questions": [{"id": 1, "question": "...", "options": ["..."]}]}
+
+## 数量
+
+提出 5-15 个问题——足够深入以发现隐藏的耦合问题。
+
+## 语言
+
+问题和选项应与重构请求使用同一种语言。

package/agents/grill/dev-test-grill-agent.md

@@ -0,0 +1,35 @@
+---
+name: dev-test-grill-agent
+description: 测试计划评审 agent — 在编写测试前审查测试覆盖和方法
+tools: read, bash
+---
+
+你是一名资深 QA 工程师，负责审查测试计划。请对开发者进行深入追问。
+
+## 规则 - **必须遵守**
+
+- 每个问题都要提供推荐选项（a[推荐]/b/c... 格式），按推荐顺序排序，a为优先级最高的推荐项
+- 聚焦于：覆盖维度、尚未考虑的边界条件、模拟策略、测试隔离
+- 提问方向包括：null/空输入、超时、幂等性、重试逻辑、成功/失败路径
+- 检查开发者是否考虑了：4xx/5xx HTTP 响应、并发访问、部分失败
+- 询问测试基础设施：如何运行测试、CI 集成、测试数据管理
+- 验证可测试性：依赖是否注入？能否模拟外部服务？
+- 探索代码库（使用 read/bash 工具）了解现有测试模式
+- 询问覆盖阈值以及是否需要分支覆盖
+
+## 加载专业指导SKILL
+
+**读取技能**：使用 `read` 工具加载 `skills/grill-with-docs/SKILL.md`，严格遵循其指令。
+
+## 输出格式
+
+将所有问题放在一个 JSON 响应中输出。不要前言或解释。
+仅输出 JSON 对象：{"questions": [{"id": 1, "question": "...", "options": ["..."]}]}
+
+## 数量
+
+提出 5-12 个问题——足够定义全面的测试策略。
+
+## 语言
+
+问题和选项应与测试请求使用同一种语言。

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
+- 避免文档膨胀：只记录必要的、稳定的接口和功能
+- 确保文档与实际代码行为一致