14 KiB
14 KiB
name, description
| name | description |
|---|---|
| monisuo-dev | Monisuo 项目结构化开发流程。融合超级技能体系：需求探索 → 计划分解 → 子代理开发 → 双重审查 → 验证门控 → 构建。 |
Monisuo 开发工作流
融合超级技能（Superpowers）的完整开发流程。每个阶段引用对应的超级技能，确保高质量交付。
流程概览
Phase 0: 分支隔离 → using-git-worktrees
↓
Phase 1: 需求探索 → 融合 brainstorming（提问→方案→评审）
↓
Phase 1.5: 计划分解 → 融合 writing-plans（咬合级任务+TDD）
↓
Phase 2: 开发执行 → 融合 subagent-driven-development（子代理+双重审查）
↓
Phase 3: 质量验证 → verification-before-completion 铁律门控
│ ↓ (通过)
│ [Agent A] 精简 + 测试 → 输出审查报告
│ ↓ (通过)
│ [Agent B] Phase 4: 功能验证
│ ↓ (通过)
│ [Agent C] Phase 5: 构建
↓
Phase 6: 分支完成 → finishing-a-development-branch
↑
Bug 修复循环 → systematic-debugging（根因分析优先）
Phase 0/1/1.5 在主对话完成（需与用户交互，子代理无法代替）。但其中的代码库探索环节可并行派发 Explore 子代理加速。 Phase 2 用子代理驱动，Phase 3/4/5 分别启动独立 Agent。
Phase 0: 分支隔离
引用技能: superpowers:using-git-worktrees
开发前创建隔离工作区，避免在 main 分支直接修改。
执行步骤
- 确认当前在 main 分支且工作区干净
- 使用
EnterWorktree创建隔离工作树，分支名feat/[feature-name] - 后续所有开发在 worktree 中进行
例外
- 紧急热修复可跳过 worktree，直接在 main 分支操作
- 用户明确要求跳过时可以跳过
Phase 1: 需求探索
引用技能: superpowers:brainstorming
将用户需求通过协作对话转化为结构化设计。不再直接写 Spec，而是先充分探索。
执行步骤
-
探索项目上下文 — 检查相关文件、文档、最近提交，理解现有架构
- 可用 Explore 子代理并行加速：涉及多个独立模块时（如后端+Flutter+Admin），派发多个 Explore 子代理并行扫描，结果汇总到主对话
- 单模块时直接在主对话 Glob/Grep/Read 即可，无需子代理
-
逐步提问 — 一次一个问题，理解目的、约束、成功标准（必须主对话）
- 优先使用选择题，也可开放式
- 评估范围：如果涉及多个独立子系统，先分解再逐个设计
-
提出 2-3 个方案 — 含权衡分析和推荐理由
- 领先展示推荐方案及原因
- 每个方案列出优劣
-
逐节呈现设计 — 按复杂度控制篇幅
- 每节确认是否正确
- 覆盖：架构、组件、数据流、错误处理、测试
-
写入 Feature Spec — 保存到
docs/features/[feature-name].md# [功能名称] ## 概述 功能名称 / 优先级(P0-P2) / 业务背景(痛点→方案→收益) ## 用户故事 作为 [角色]，我希望 [行为]，以便 [目的] ## 功能列表 - [ ] 功能点1 - [ ] 功能点2 ## 技术方案（Phase 1.5 填充） ### API 设计 ### 数据模型 ### 技术决策 ## 测试用例 - [ ] 正常 / 异常 / 边界 ## 验收标准 -
Spec 自审 — 快速内联检查
- 占位符扫描：有无 TBD、TODO、未完成章节？修复。
- 内部一致性：各章节是否矛盾？
- 范围检查：是否聚焦到单个实施计划？
- 歧义检查：需求是否有两种解读？选定一种明确写出。
-
用户确认 — 让用户审阅 Spec 文件，确认后才进入下一阶段
硬门控
用户未确认 Spec 之前，不得进入 Phase 1.5。
Phase 1.5: 计划分解
引用技能: superpowers:writing-plans
将 Spec 转化为咬合级实施计划，每步 2-5 分钟。必须先探索代码库再设计。
执行步骤
-
探索现有代码库
- 可用 Explore 子代理并行加速：涉及多个独立模块时（如后端现有 API、Flutter 现有页面、Admin 现有路由），派发多个 Explore 子代理并行扫描
- 单模块时直接在主对话 Glob/Grep/Read 即可
- 识别可复用的组件、Service、工具类
- 确认集成点
-
更新 Spec 技术方案
- 定义 API 契约 — 方法、路径、请求/响应体
- 设计数据模型 — 表结构、Entity/DTO/VO 映射
- 记录技术决策 — 选型理由、模块职责、关键约束
-
映射文件结构 — 列出所有需要创建/修改的文件及职责
-
编写实施计划 — 保存到
docs/superpowers/plans/YYYY-MM-DD-[feature-name].md计划头部：
# [功能名称] Implementation Plan > **For agentic workers:** REQUIRED SUB-SKILL: Use superpowers:subagent-driven-development to implement this plan task-by-task. **Goal:** [一句话描述] **Architecture:** [2-3 句方案描述] **Tech Stack:** [关键技术] --- -
任务分解原则
- 每步一个动作（2-5 分钟）
- TDD 红绿循环：写失败测试 → 验证失败 → 最小实现 → 验证通过 → 提交
- 按模块自底向上：数据层 → 后端 API → Flutter 前端 → Admin 前端
- 不允许占位符：每步必须包含实际代码和命令
### Task N: [组件名称] **Files:** - Create: `exact/path/to/file` - Modify: `exact/path/to/existing.java:123-145` - Test: `tests/exact/path/test` - [ ] **Step 1: 写失败测试** - [ ] **Step 2: 运行验证失败** - [ ] **Step 3: 最小实现** - [ ] **Step 4: 运行验证通过** - [ ] **Step 5: 提交** -
计划自审 — 对照 Spec 逐条检查
- 覆盖性：Spec 每条需求都有对应任务？
- 占位符扫描：无 TBD/TODO
- 类型一致性：前后任务的类型、方法签名一致
-
用户提供执行选择
- 推荐子代理驱动开发（Phase 2 默认方式）
- 用户选择内联执行时，按
superpowers:executing-plans执行
完成标准
- 已扫描现有代码，无重复造轮子
- API 契约完整，前后端可并行开发
- 数据模型与现有表结构兼容
- 每个任务有完整代码和验证命令
Phase 2: 开发执行
引用技能: superpowers:subagent-driven-development
每个子任务独立子代理执行，完成后双重审查（规格合规 + 代码质量）。
核心原则
- 每个任务启动新的子代理，不继承主对话上下文
- 主对话负责提取任务文本、构造上下文、传递给子代理
- 子代理完成后，先做规格合规审查，再做代码质量审查
执行流程
对计划中的每个任务：
1. 提取任务全文和上下文
2. 启动实现子代理（implementer）
3. 子代理提问？→ 回答后重新派发
4. 子代理实现、测试、提交、自审
5. 启动规格审查子代理 → 不通过？→ 实现子代理修复 → 重新审查
6. 启动质量审查子代理 → 不通过？→ 实现子代理修复 → 重新审查
7. 标记任务完成
模型选择策略
- 机械任务（1-2 文件，Spec 完整）→ 快速模型
- 集成任务（多文件，模式匹配）→ 标准模型
- 架构/审查任务 → 最强模型
子代理行为准则
- Flutter:
flutter analyze无错，用 AppSpacing/AppRadius/AppColorScheme，禁止硬编码颜色 - Java: Lombok 简化，资金变动方法加
@Transactional(rollbackFor = Exception.class)，RESTful 设计 - Admin: TypeScript strict，TanStack Vue Query 做数据请求，shadcn-vue 组件不手动编辑
禁止事项
- 不要在 main/master 分支直接实现
- 不要跳过任何审查（规格或质量）
- 不要在审查有未修复问题时进入下一任务
- 不要并行派发多个实现子代理（会冲突）
- 不要让子代理自行读取计划文件（主对话提供全文）
Spec 同步
Phase 2 全部完成后、启动 Agent A 之前，主对话必须更新 Spec：
- 实际实现与设计有差异时，以实现为准更新 Spec
- 确保 Phase 3/4 的 Agent 读到的是最新状态
Phase 3: 质量验证（铁律门控）
引用技能: superpowers:verification-before-completion
验证铁律
没有新鲜验证证据，不得声明任何状态。
Phase 2 完成后，启动独立 Agent 执行代码精简和自动化测试。
启动 Agent A
Agent(
description: "精简+测试验证",
prompt: |
你是 Monisuo 项目质量 Agent，独立完成以下任务，不要询问用户。
## 铁律
没有运行验证命令，不得声称"通过"或"完成"。
使用"应该通过" = 没有验证。
## 1. 读取 Spec
- 路径: docs/features/[feature-name].md
- 理解验收标准
## 2. 代码审查
- git diff 查看变更
- Flutter: flutter analyze, AppSpacing/AppRadius/AppColorScheme 规范
- Java: @Transactional 资金方法, 统一异常处理, RESTful 设计
## 3. 代码精简（simplify）
- 对变更代码执行 /simplify：审查复用性、质量和效率，修复发现的问题
- 精简完成后重新运行 git diff 确认变更合理
## 4. 测试（必须运行并读取完整输出）
- 后端: mvn test（读取输出，确认 0 failures）
- Flutter: cd flutter_monisuo && flutter test（读取输出，确认 0 failures）
- API: ./tests/api/test-[feature].sh（如存在）
## 5. 输出审查报告（供 Agent B 使用）
### 代码审查摘要
- 变更文件列表及每个文件的核心改动
- 代码规范检查结果
- 精简改动摘要（改了什么、为什么改）
### 测试结果
| 项目 | 状态 | 证据（命令输出摘要） |
|------|------|----------------------|
| 代码审查 | ✅/❌ | |
| 代码精简 | ✅/❌ | 改动摘要 |
| 后端测试 | ✅/❌ | X/Y 通过 |
| Flutter 测试 | ✅/❌ | X/Y 通过 |
如有 Bug，列出：文件、原因、修复建议。返回主对话修复后重新验证。
)
门控
Agent A 报告中任何一项 ❌ → 主对话修复 → 重新启动 Agent A。
Phase 4: 功能验证（Agent B）
Agent A 全部通过后，启动独立 Agent。
启动 Agent B
Agent(
description: "功能验证（用例驱动）",
prompt: |
你是 Monisuo 项目功能验证 Agent。基于 Feature Spec 中的测试用例，验证功能实现是否正确。不要询问用户。
## 铁律
没有运行验证命令，不得声称"通过"。逐条代码追踪，不是靠印象。
## 1. 读取 Spec
- 路径: docs/features/[feature-name].md
- 提取「测试用例」和「验收标准」
## 2. 利用审查报告
- Agent A 已完成代码审查，变更文件列表和核心改动见报告
- 仅对报告未覆盖的逻辑路径做补充阅读
- 对照 Spec 中的 API 设计，确认实现与契约一致
## 3. 逐条验证测试用例
对 Spec 中的每条测试用例：
- **正常流程**：追踪代码路径 Controller → Service → Mapper，确认参数传递、返回值、状态变更
- **异常流程**：确认错误处理覆盖（参数校验、权限检查、边界条件）
- **边界条件**：空值、零值、溢出、并发等极端场景是否有防护
## 4. 输出验证报告
| 用例编号 | 用例描述 | 验证结果 | 证据 |
|----------|----------|----------|------|
| TC-01 | 正常：xxx | ✅/❌ | 追踪的具体代码路径 |
| TC-02 | 异常：xxx | ✅/❌ | 具体原因 |
### 总结
- 通过率：X/Y
- 未通过用例：列出失败原因和修复建议
- 风险点：潜在问题或遗漏
如有未通过用例，返回主对话修复后重新启动验证。
)
门控
Agent B 报告中有 ❌ → 主对话修复 → 重新启动 Agent B。
Phase 5: 构建（Agent C）
Agent A 和 Agent B 全部通过后，启动独立 Agent。
启动 Agent C
Agent(
description: "项目构建",
prompt: |
你是 Monisuo 项目构建 Agent，独立完成构建任务，不要询问用户。
## 铁律
没有运行构建命令并看到 exit 0，不得声称"构建成功"。
## 1. 构建（必须运行并读取完整输出）
- 后端: mvn clean package -DskipTests → target/monisuo-*.jar
- Flutter: cd flutter_monisuo && flutter build web --release --dart-define=ENV=prod → build/web/
## 2. 输出报告
| 项目 | 状态 | 证据（命令输出摘要） |
|------|------|----------------------|
| 后端构建 | ✅/❌ | 产物路径 |
| Flutter 构建 | ✅/❌ | 产物路径 |
如有构建失败，列出：模块、错误信息、修复建议。返回主对话修复后重新构建。
)
门控
Agent C 报告中有 ❌ → 主对话修复 → 重新启动 Agent C。
Phase 6: 分支完成
引用技能: superpowers:finishing-a-development-branch
所有 Phase 通过后，完成开发分支。
执行步骤
- 确认所有测试通过（Phase 3 证据）
- 确认功能验证通过（Phase 4 证据）
- 确认构建成功（Phase 5 证据）
- 向用户展示选项：
- 合并到 main
- 创建 PR
- 保留分支待后续处理
- 执行用户选择
- 退出 worktree
Bug 修复循环
引用技能: superpowers:systematic-debugging
遇到 Bug 时，严禁猜测式修复。
四阶段流程
- 根因调查 — 重现问题 → 缩小范围 → 找到根因（未完成此阶段不得提出修复）
- 修复方案 — 针对根因设计最小修复
- 实施修复 → 回到 Phase 3 重新验证
- 回归验证 — 确认修复未引入新问题
错误修复路由
- Agent A 失败（测试不通过）→ 主对话用 systematic-debugging 修复 → 重新启动 Agent A
- Agent B 失败（功能验证不通过）→ 主对话用 systematic-debugging 修复 → 重新启动 Agent B
- Agent C 失败（构建不通过）→ 主对话修复构建问题 → 重新启动 Agent C
- 全部通过 → Phase 6 分支完成
严禁
- 不准跳过根因分析直接修复
- 不准用"应该修好了"代替验证
- 不准在疲劳时降低验证标准