software-dev

name	software-dev
description	遵循敏捷开发流程：需求分析 → 架构设计 → Sprint 规划 → Sprint 执行 → 质量门禁 → 发布 → 监控。每个阶段产出特定交付物。
allowed-tools	bash sub-agent collect-results task-create task-update task-get task-list team-create team-list team-get-tasks find-experts
metadata	{"requires":{"bins":["git","python3"]},"name_zh":"软件开发","name_zh-tw":"軟體開發","description_zh":"遵循敏捷开发流程：需求分析 → 架构设计 → Sprint 规划 → Sprint 执行 → 质量门禁 → 发布 → 监控","description_zh-tw":"遵循敏捷開發流程：需求分析 → 架構設計 → Sprint 規劃 → Sprint 執行 → 質量門禁 → 發佈 → 監控"}

何时使用

遇到以下情况时激活此技能：

• 用户想要构建软件功能、模块或完整产品
• 用户提到：开发、实现、构建、冲刺、发布、重构、架构
• 任务涉及多个文件或跨多个会话

以下情况无需激活：单文件编辑、简单的 Bug 修复——直接处理即可。

---

阶段 1 — 需求分析

必须首先完成此阶段。不要直接跳到编码。

步骤 1.1 — 从用户处获取需求

按顺序向用户提出以下五个问题。等待每个回答后再继续。

1. 核心问题 — "你要解决什么问题？要实现什么场景？"
2. 用户与规模 — "谁会使用？规模多大？"
3. 具体功能 — "具体需要构建什么？列出核心功能。哪些是 MVP，哪些是后续迭代？"
4. 约束条件 — "有技术、平台、时间线或资源方面的限制吗？"
5. 完成标准 — "如何验证已完成？验收标准是什么？"

对话过程中要主动引导：

• 用户描述模糊 → 追问澄清
• 用户列了太多功能 → 帮排优先级（"哪 3 个最关键？"）
• 用户说的是方案而非问题 → 往下挖（"这背后要解决什么问题？"）

步骤 1.2 — 输出需求简报

把回答整合为以下文档，保存到 docs/requirements.md，继续之前先展示给用户确认：

# 需求简报

## 概述
[一句话总结要构建什么]

## 核心问题
[痛点或目标]

## 目标用户
[谁，以及什么规模]

## MVP 功能
1. [功能 A]
2. [功能 B]
3. [功能 C]

## 后续范围（本轮不包含）
- [功能 D]
- [功能 E]

## 约束条件
- 技术栈：[例如 Go + React + PostgreSQL]
- 平台：[例如 Web / iOS / Android]
- 时间线：[例如 2 周]
- 其他：

## 验收标准
- [ ] [可验证的标准 1]
- [ ] [可验证的标准 2]
- [ ] [可验证的标准 3]

## 成功指标
[如何衡量成功]

阶段 1 在 docs/requirements.md 保存到项目目录并经用户确认后完成。

---

阶段 2 — 架构设计

基于已确认的需求简报，产出架构蓝图。保存到 docs/architecture.md。

输出：架构蓝图

# 架构蓝图

## 1. 系统架构图

[使用 Mermaid 绘制：客户端 → API 网关 → 服务层 → 数据层，等等]

## 2. 项目目录结构

project-root/ ├── cmd/ # 入口点 ├── internal/ │ ├── api/ # HTTP/gRPC 处理器 │ ├── service/ # 业务逻辑 │ ├── repository/ # 数据访问 │ └── model/ # 数据模型 ├── pkg/ # 共享库 ├── migrations/ # 数据库迁移 ├── configs/ # 配置文件 └── deploy/ # 部署文件

## 3. 核心数据模型

- [实体 1]：{字段, 关系}
- [实体 2]：{字段, 关系}

## 4. API 接口

- `POST /api/resource` — 创建资源
- `GET /api/resource/:id` — 获取资源
- ...

## 5. 组件依赖关系

- 组件 B 依赖 A（先构建 A）
- 组件 C 是独立的（可以与 A/B 并行）

阶段 2 在 docs/architecture.md 保存到项目目录后完成。

---

阶段 3 — Sprint 规划

每个 Sprint 以需求为驱动。从需求简报中选出本 Sprint 要交付的需求，Sprint 的目标就是交付这些具体需求。不要脱离需求、仅从架构出发创建任务——任务是为需求服务的。

步骤 3.1 — 选择 Sprint 需求

从需求简报中选取一个 Sprint 周期内能交付的子集。Sprint 目标必须明确引用具体的需求名称。

步骤 3.2 — 发现可用智能体

运行 mindx agent list 查看可用的智能体及其能力。据此确定每个任务由谁负责。

步骤 3.3 — 将需求分解为任务

针对每个选定的需求，按依赖关系分波次拆解为可执行的任务。每个任务都必须关联到 Sprint 目标中的某个需求。

步骤 3.4 — 输出 Sprint 计划

将 Sprint 计划保存到 docs/sprint-plan.md。

# Sprint 1：[源自需求——例如 "用户认证与个人资料"]

要解决的需求：
  - [需求简报中的需求 A]
  - [需求简报中的需求 B]

波次 1（无依赖，可并行）：
  任务：[功能 A] — 需求：[需求 A] — 负责人：[智能体] — 预估：M
  任务：[功能 B] — 需求：[需求 A] — 负责人：[智能体] — 预估：M

波次 2（依赖波次 1）：
  任务：[集成 A+B] — 需求：[需求 A] — 负责人：[智能体] — 预估：S
  任务：[测试 A+B] — 需求：[需求 B] — 负责人：[智能体] — 预估：S

波次 3（依赖波次 2）：
  任务：[端到端测试] — 需求：[需求 A, 需求 B] — 负责人：[智能体] — 预估：M

创建任务并设置依赖关系：

task-create(subject="[需求 X] 任务名称", description="来自需求的验收标准：{criteria}。需修改的文件：{paths}。")
task-update(task_id=B, addBlockedBy=[A])

阶段 3 在 docs/sprint-plan.md 保存且所有任务在系统中创建并设置好依赖关系后完成。

---

阶段 4 — Sprint 执行

按波次执行任务。使用子智能体并行运行任务。

步骤 4.1 — 智能体发现

用 mindx agent list 为每个任务匹配合适的智能体，把任务需求与各智能体的能力对应起来。

步骤 4.2 — 子智能体任务模板

每个委派的任务必须包含以下五个要素，其中 ACCEPTANCE 直接来自需求简报：

subject: 清晰的任务名称
description: |
  GOAL: 要达成什么
  ACCEPTANCE: [从需求简报复制——这些就是标记任务完成所用的相同标准]
  SCOPE: 需要修改的确切文件/路径
  CONSTRAINTS: 技术栈、约定、需遵循的模式
  DELIVERABLE: 期望的输出格式

步骤 4.3 — 执行模式

# 波次 1：并行
task-update(wave1_tasks, status="in_progress")
sub-agent([agent_name], task="{goal}。验收标准：{acceptance}。范围：{paths}。规范：{tech}。")
sub-agent([agent_name], task="{goal}。验收标准：{acceptance}。范围：{paths}。规范：{tech}。")
collect-results(...)
→ 根据各自的验收标准验证每个结果。运行测试。仅在全部通过后标记完成。
task-update(wave1_tasks, status="completed")

# 波次 2：顺序
task-update(wave2_tasks, status="in_progress")
sub-agent([agent_name], task="{goal}。验收标准：{acceptance}。范围：{paths}。")
collect-results(...)
→ 根据验收标准验证。运行集成测试。
task-update(wave2_tasks, status="completed")

---

阶段 5 — 质量门禁

标记任何任务或 Sprint 完成之前，依次运行以下检查：

门禁	操作	失败处理
1. 代码完成	验证所有计划代码已编写	修复或推迟
2. 单元测试	运行测试套件，新代码覆盖率 ≥70%	修复失败的测试
3. 集成冒烟测试	端到端运行主要用户流程	调试并修复
4. 代码审查	阅读关键文件检查结构性问题	必要时重构
5. 无回归	运行所有已有测试	修复回归

通过所有门禁后，将质量报告保存到 docs/quality-report.md，记录每个门禁的结果。

阶段 5 在所有门禁通过且 docs/quality-report.md 保存后完成。

---

阶段 6 — 发布

所有质量门禁通过后，把发布说明保存到 docs/release-notes.md 并通报：

Sprint 1 完成 — [项目名]

已交付：
  ✅ [功能]：[摘要]
  ✅ [功能]：[摘要]

质量：
  测试：X/Y 通过 | 覆盖率：X%
  已知问题：N（已跟踪）

下个 Sprint：
  · [事项 1]
  · [事项 2]

阶段 6 在 docs/release-notes.md 保存后完成。

---

阶段 7 — 监控

发布后检查：

检查项	频率	方式
错误激增	每日	检查日志
性能	24 小时内	与基准对比
用户反馈的 Bug	持续	分类报告
技术债务	每个 Sprint	统计新代码中的 TODO/FIXME

---

硬性规则

• 每个阶段的交付文档保存后才算完成。 没有文档 = 没做完。
• 阶段 1 完成 → docs/requirements.md 已保存且用户已确认。
• 阶段 2 完成 → docs/architecture.md 已保存。
• 阶段 3 完成 → docs/sprint-plan.md 已保存且任务已关联。
• 阶段 5 完成 → 所有质量门禁已通过且 docs/quality-report.md 已保存。
• 阶段 6 完成 → docs/release-notes.md 已保存。
• 阶段 1 必须在阶段 2 之前完成，阶段 2 在阶段 3 之前，阶段 5 在阶段 6 之前。没有例外。
• 每个任务执行前必须有明确的验收标准。
• 未经与用户重新确认，不要修改约定范围之外的文件。
• 所有输出文档必须使用与用户输入相同的语言。
• 阶段 1 定义的验收标准是验证所有输出的唯一标准。如果标准不足以验证结果，问题出在阶段 1——回去完善需求再继续。

---

注意事项

• 验收标准在实现过程中可能会变。 用户看到产出后想法可能会变，此时不要默默调整——更新需求文档并重新确认后再继续。
• Sprint 速度不是交付保证。 一个 2 周 10 个故事点的 Sprint，如果团队中途遇到未知问题，也可能延期。永远不要仅凭速度承诺硬性交付日期。
• 阶段依赖是严格的。 开发没完成就测试，或质量门禁没通过就部署，产出不可靠。不要为了省时间跳过阶段——硬性规则存在是有原因的。
• 第三方依赖变更会破坏构建。 库更新、API 弃用或包移除随时可能让构建挂掉。遇到构建失败时，先检查是否有依赖变更，再去调试代码。