create-dwy 0.3.2 → 0.3.3

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "create-dwy",
-  "version": "0.3.2",
+  "version": "0.3.3",
   "description": "Project scaffolding and Claude Code config sync CLI",
   "type": "module",
   "bin": {

package/templates/claude-global/rules/agent-team-execution.md

@@ -0,0 +1,138 @@
+# Agent 团队并行执行规则
+
+收到任务后，必须先评估是否可以通过 Agent 并行加速执行。这是强制检查，不可跳过。
+
+## 一、可并行性评估
+
+收到任务后立即判断：
+
+| 条件 | 判定 |
+|------|------|
+| 任务可拆为 2+ 个**无依赖**子任务 | → 任务级并行 |
+| 单个任务内有 2+ 个**独立步骤** | → 步骤级并行 |
+| 任务只有单一线性流程 | → 正常执行，不并行 |
+
+**核心原则：只有真正无依赖的工作才并行。** 如果子任务 B 需要子任务 A 的输出，它们必须串行。
+
+## 二、风险分级与自主度
+
+根据任务风险决定执行方式：
+
+### 低风险 — 直接并行执行
+
+- 只读操作（代码研究、搜索、文档查阅）
+- 新建独立文件（写 demo、写测试、写新组件）
+- 独立的 lint / format / 类型检查
+- 查询外部文档或 API
+
+**执行方式：** 直接派 Agent 并行，完成后汇报结果。
+
+### 中风险 — 确认后并行执行
+
+- 修改已有文件
+- 添加/升级依赖
+- 修改构建配置或路由配置
+
+**执行方式：** 先展示拆分计划（哪些 Agent、各做什么、修改哪些文件），用户确认后并行执行。
+
+### 高风险 — 确认 + 强制 Review
+
+- 删除文件或代码
+- 修改核心模块（数据库/认证/路由守卫/支付）
+- 架构重构
+- 涉及 git 操作（rebase / merge / force push）
+
+**执行方式：** 展示详细计划 + 影响分析，用户确认后执行，完成后**必须**触发 review + auto-fix 闭环。
+
+## 三、Agent 派遣协议
+
+### 任务级并行
+
+将大任务拆分为独立子任务，每个子任务派一个 Agent：
+
+1. 识别独立子任务，创建 TaskCreate 追踪
+2. 在**同一条消息**中派出所有 Agent（确保真正并行）
+3. 每个 Agent 的 prompt 必须包含：完整的任务上下文、要操作的文件范围、相关的代码规范要求
+4. 涉及文件修改的 Agent 使用 `isolation: "worktree"` 避免冲突
+5. 所有 Agent 完成后汇总结果
+
+### 步骤级并行
+
+在单个任务执行中，将独立步骤并行化：
+
+1. 识别当前步骤中哪些操作互不依赖
+2. 在同一条消息中发起多个工具调用（Agent、Bash、Grep、Glob 等均可并行）
+3. 等结果返回后再进入依赖这些结果的下一步
+
+### Agent Prompt 要求
+
+派遣 Agent 时，prompt 必须包含以下要素（不可省略）：
+
+- **目标：** 这个 Agent 具体要完成什么
+- **上下文：** 为什么要做这件事，整体任务的背景
+- **范围：** 要操作的文件/目录，明确边界
+- **规范：** 需遵循的代码规范（引用具体规则文件或关键约束）
+- **产出：** 期望的输出形式（代码、报告、修复等）
+
+**禁止：** 写模糊的 prompt 如"基于你的研究结果实现它"。每个 Agent 的 prompt 必须自包含。
+
+## 四、Review + Auto-Fix 闭环
+
+所有并行 Agent 完成后，执行质量保障流程：
+
+### 触发条件
+
+以下情况**必须**触发 review 闭环：
+
+- 任何高风险任务完成后
+- 3 个或以上 Agent 并行修改代码后
+- 用户明确要求 review 时
+
+以下情况**可跳过** review：
+
+- 纯只读研究任务
+- 单个低风险文件创建
+
+### Review 流程
+
+```
+Agent 完成 → code-reviewer Agent 审查 → 发现问题？
+  ├─ 否 → 汇报结果，完成
+  └─ 是 → 自动修复 → 再次 review → 通过？
+       ├─ 否 → 报告给用户，人工介入
+       └─ 是 → 汇报结果，完成
+```
+
+1. 启动 `superpowers:code-reviewer` Agent，审查所有变更
+2. 如发现问题，直接修复（不需再次确认）
+3. 修复后再次 review，最多循环 **2 轮**
+4. 2 轮后仍有问题，向用户报告剩余问题，交由人工判断
+
+### Review Agent 的 Prompt 要求
+
+- 说明本次变更的整体目标
+- 列出所有被修改/新建的文件
+- 引用相关的代码规范规则
+- 要求 review 聚焦：正确性、规范符合度、是否引入 bug
+
+## 五、执行报告
+
+并行任务全部完成后，向用户输出简洁的执行报告：
+
+```
+## 执行报告
+- **并行 Agent 数量：** N 个
+- **完成情况：** 全部完成 / X 个成功、Y 个失败
+- **Review 结果：** 通过 / 修复了 N 个问题
+- **变更文件：** 列出所有新建/修改的文件
+```
+
+仅在多 Agent 并行任务时输出报告，单 Agent 执行不需要。
+
+## 六、禁止事项
+
+- **禁止**派 Agent 做需要用户交互的操作（如需要用户输入、选择）
+- **禁止**多个 Agent 修改同一个文件（必须用 worktree 隔离或拆分为串行）
+- **禁止**在 Agent prompt 中省略上下文让 Agent "自己去查"
+- **禁止**跳过风险评估直接并行执行
+- **禁止**忽略 Agent 的失败结果，必须处理或报告

package/templates/claude-global/rules/agent-team-patterns.md

@@ -0,0 +1,157 @@
+# Agent 并行模式速查表
+
+常见任务的 Agent 并行分工模板。执行前对照此表选择合适的模式。
+
+## 一、任务级并行模式
+
+### 模式 1：批量创建（N 路并行）
+
+**场景：** 创建多个独立的组件/页面/测试/demo
+
+```
+示例："给 5 个组件写 demo 页面"
+
+Agent-1 (worktree) → ComponentA demo
+Agent-2 (worktree) → ComponentB demo
+Agent-3 (worktree) → ComponentC demo
+Agent-4 (worktree) → ComponentD demo
+Agent-5 (worktree) → ComponentE demo
+→ 全部完成后 code-reviewer 审查
+```
+
+**要点：**
+- 每个 Agent 使用 `isolation: "worktree"`
+- 每个 Agent 的 prompt 包含组件的 API 说明和 demo 规范
+- 风险等级：低，直接执行
+
+### 模式 2：研究 + 实现（2 阶段流水线）
+
+**场景：** 需要先了解代码再动手修改
+
+```
+示例："修复 EForm 组件的验证 bug"
+
+阶段 1（并行研究）：
+  Agent-Explore → 分析 EForm 组件代码结构和数据流
+  Agent-Explore → 搜索相关测试和使用示例
+  Agent-Explore → 查看 git 历史和相关 issue
+
+阶段 2（串行实现）：
+  基于研究结果，主线程或单 Agent 实现修复
+
+阶段 3（并行验证）：
+  Agent → 运行测试
+  Agent → code-review 变更
+```
+
+**要点：**
+- 阶段 1 的 Agent 全部用 `subagent_type: "Explore"`
+- 阶段 2 必须等阶段 1 全部完成
+- 风险等级：中，阶段 2 前需确认方案
+
+### 模式 3：多模块同步修改
+
+**场景：** 一个功能涉及多个独立模块的修改
+
+```
+示例："给所有 API 模块添加分页参数"
+
+Agent-1 (worktree) → 修改 user API 模块
+Agent-2 (worktree) → 修改 order API 模块
+Agent-3 (worktree) → 修改 product API 模块
+→ code-reviewer 审查一致性
+```
+
+**要点：**
+- 每个 Agent 必须收到统一的修改规范（参数命名、类型定义）
+- 使用 worktree 隔离
+- 风险等级：中，执行前确认修改规范
+
+### 模式 4：前后端同步开发
+
+**场景：** 接口契约已定，前后端可以同时写
+
+```
+示例："新增用户导出功能"
+
+Agent-1 (worktree) → 后端 API + service 实现
+Agent-2 (worktree) → 前端页面 + API 调用
+→ code-reviewer 审查接口契约一致性
+```
+
+**要点：**
+- 两个 Agent 必须收到相同的接口契约定义（URL、参数、响应格式）
+- 风险等级：中，确认接口契约后执行
+
+## 二、步骤级并行模式
+
+### 模式 A：并行信息收集
+
+在执行任何任务前，将独立的信息收集步骤并行化：
+
+```
+同一消息中发起：
+  Grep → 搜索相关代码引用
+  Glob → 查找相关文件
+  Read → 读取配置文件
+  Agent(Explore) → 分析依赖关系
+```
+
+### 模式 B：并行验证
+
+修改完成后，将独立的验证步骤并行化：
+
+```
+同一消息中发起：
+  Bash → 运行单元测试
+  Bash → 运行 lint 检查
+  Bash → 运行类型检查
+  Bash → 运行构建
+```
+
+### 模式 C：并行文档/测试补充
+
+主要代码完成后，并行补充配套文件：
+
+```
+同一消息中发起：
+  Agent → 写单元测试
+  Agent → 更新相关文档
+  Agent → 更新 changelog
+```
+
+## 三、反模式（禁止使用）
+
+| 反模式 | 问题 | 正确做法 |
+|--------|------|---------|
+| 多 Agent 改同一文件 | 冲突、覆盖 | 串行修改或拆分文件职责 |
+| 无上下文的 Agent | 产出质量差 | prompt 必须自包含 |
+| 链式依赖硬并行 | B 依赖 A 的输出却并行 | 识别依赖，串行执行 |
+| 10+ Agent 同时派出 | 难以管理、context 爆炸 | 单批最多 5 个 Agent |
+| 跳过 review 直接提交 | 质量无保障 | 遵循 review 闭环 |
+
+## 四、Agent 数量指南
+
+| 场景 | 建议 Agent 数 |
+|------|-------------|
+| 批量创建同质文件 | 每个文件 1 个，上限 5 个/批 |
+| 并行研究 | 2-3 个 Explore Agent |
+| 多模块修改 | 每个模块 1 个，上限 4 个/批 |
+| 前后端同步 | 2 个 |
+| 步骤级并行工具调用 | 不限（Grep/Glob/Read 等轻量调用尽量并行） |
+
+超过 5 个 Agent 的任务，分批执行：先派第一批，完成后再派第二批。
+
+## 五、Worktree 使用指南
+
+以下场景**必须**使用 `isolation: "worktree"`：
+
+- 多个 Agent 各自创建/修改不同文件
+- Agent 的修改可能与当前工作区冲突
+- 需要保持主工作区干净（如正在进行其他工作）
+
+以下场景**不需要** worktree：
+
+- 纯只读的 Explore Agent
+- 步骤级并行的工具调用（Grep/Glob/Read/Bash）
+- 单个 Agent 执行（无冲突风险）