@modus-ai/modus 0.1.0

package/templates/skills/modus-harness/SKILL.md

@@ -0,0 +1,247 @@
+# modus-harness（双 Loop 多智能体 Harness Orchestrator）
+
+**触发条件：** 用户运行 `/modus:harness [TAPD Story URL]` 时使用此 Skill。
+
+## 职责
+
+双 Loop 多智能体 Harness 的唯一入口和流程调度中枢。
+
+你不执行任何业务逻辑，只管「谁在什么时候上场」。所有分析、开发、测试、评审工作由对应 SubAgent 的 Skill 完成。
+
+---
+
+## SubAgent 清单与 Token 预算
+
+| ID | Skill 路径 | 职责 | 产出物 | 知识查询预算 |
+|----|-----------|------|--------|------------|
+| 00 | `modus-harness-00-skills-builder` | Skills 更新/知识提取 | Skill 文件 + catalog | 无限制 |
+| 01 | `modus-harness-01-analysis` | 需求分析 | `01-analysis.md` | ≤ 3 个 Skill 文件 |
+| 02 | `modus-harness-02-dev` | 代码开发 | `02-sprint-contract.md` | ≤ 5 个 Skill 文件 + ≤ 10 个代码文件 |
+| 03 | `modus-harness-03-test` | 代码测试 | `03-test-report.md` | ≤ 2 个 Skill 文件 |
+| 04 | `modus-harness-04-perf` | 性能审计 | `04-perf-report.md` | ≤ 2 个 Skill 文件 |
+| 05 | `modus-harness-05-security` | 安全审计 | `05-security-report.md` | ≤ 2 个 Skill 文件 |
+| 06 | `modus-harness-06-review` | 代码评审 | `cr-report.md` | ≤ 1 个团队约定 Skill |
+| 07 | `modus-harness-07-deploy` | 部署发布 | `07-deploy-status.md` | ≤ 1 个 Skill 文件 |
+
+**预算原则：** SubAgent 超出预算时，应优先读 maturity 更高的 Skill；若 catalog 中某 Skill 标注 `⚠️` 可能过时，优先读最新代码而非该 Skill。
+
+---
+
+## 结构化产物交接格式（HANDOFF 协议）
+
+每个 SubAgent 的产出物 Markdown 文件头部附加一个机器可读的 `HANDOFF` 块，供 Orchestrator 和下游 SubAgent 精准解析，**无需读取整份文档**即可决策：
+
+```markdown
+<!--HANDOFF
+agent: "01-analysis"
+story_id: "{story-id}"
+domains: ["order", "payment"]
+sprint_count: 3
+risk_level: "medium"          # low | medium | high
+key_constraints:
+  - "不能修改 OrderStatus 枚举"
+  - "需要兼容 v1 接口"
+skill_refs:
+  - "modus-biz-order@v3.1.0"
+  - "modus-team-conventions@v1.2.0"
+gate_status: "passed"          # passed | failed | pending
+issues: []                     # P1/P2 问题列表（cr-report 专用）
+-->
+```
+
+Orchestrator 每步只需读 HANDOFF 块（≤ 20 行），而非整份 MD 文件，大幅节省 token。
+
+---
+
+## 执行流程
+
+### Step 0：项目宪法 + 前置检查
+
+**读取 constitution：**
+读取 `modus/config.yaml` 的 `constitution` 字段，将 `hard_rules` 传递给所有 SubAgent 作为硬性约束。
+
+**检查业务 Skill：**
+读取 `modus/knowledge-catalog.md`（Level 1 加载）：
+- 若不存在，强烈建议先运行 `/modus:init`：
+```
+⚠️ 未找到知识目录（modus/knowledge-catalog.md）！
+
+/modus:harness 依赖业务 Skill 为 SubAgent 提供项目背景知识。
+建议：
+A. 现在运行快速初始化（推荐，约 3-5 分钟）
+B. 强制继续（无业务上下文，风险较高）
+```
+
+**解析 Story ID：**
+- 从 TAPD URL 提取 Story ID（格式：`tapd.cn/{project}/stories/view/{id}`）
+- 创建工作目录：`modus/plans/active/{story-id}/`
+- 扫描目录，若存在部分产出物（含 HANDOFF 块），从断点处继续
+
+### Step 0.5：澄清意图（仅全新流程）⏸️ 【人工交互节点】
+
+读取 TAPD Story 内容后，在启动 SubAgent 01 之前，先确认关键信息：
+
+```
+我已读取 Story：{标题}
+
+启动全自动流程前，确认几点：
+
+1. [业务域确认] 我判断涉及：{domain1}[verified] | {domain2}[未初始化，将新增]
+   确认加载这些业务上下文？
+
+2. [需求边界] {Story 表述不清晰的点，如「批量上限是多少」「失败是否回滚整批」}？
+
+3. [技术约束] 有没有特殊要求（如不能修改某接口入参 / 需兼容旧版本）？
+
+4. [重点关注] 03/04/05 并行审计时，是否有需要特别关注的风险方向？
+```
+
+等待用户回答后，输出启动摘要：
+```
+意图已确认：
+- 业务域: {域列表}（有则更新，无则新增）
+- 核心目标: {一句话}
+- 关键约束: {列表}
+- 项目硬性规则: {constitution.hard_rules 的关键项}
+
+启动 Harness 流程...
+```
+
+### Step 1：INIT——知识注入
+
+**Level 1 → Level 2 加载：**
+基于用户确认的业务域，调用 SubAgent 00（模式 B：增量更新）：
+- 已有 Skill → 更新至最新代码状态，获取最新内容
+- 未有 Skill → 新建（模式 A），初始 maturity 为 draft
+
+将 Skill 内容（已加载的完整 SKILL.md）和 constitution.hard_rules 一起传递给 SubAgent 01 作为背景知识。
+
+```
+[Harness Orchestrator 启动]
+Story: {id} | 工作目录: modus/plans/active/{id}/
+知识注入: order[verified→已更新] | payment[proven→已读取] | user[新建 draft]
+Constitution: {N} 条硬性规则已加载
+```
+
+---
+
+## 调度规则（不可更改）
+
+### Loop 1 串行顺序
+
+```
+SubAgent 01（需求分析）
+  ↓ 产出 01-analysis.md（含 HANDOFF 块）
+SubAgent 02（代码开发）
+  ↓ 产出 02-sprint-contract.md（含 HANDOFF 块）
+  ↓ Gate A: 编译验证（项目构建工具编译，exit code = 0）
+SubAgent 03（代码测试）  ┐
+SubAgent 04（性能审计）  ├─ 并行启动，等全部完成（各自读取相关 Skill，预算独立）
+SubAgent 05（安全审计）  ┘
+  ↓ Gate B: 03/04/05 三份报告全部写入（各含 HANDOFF 块）
+SubAgent 06（代码评审）
+  ↓ 产出 cr-report.md（含 HANDOFF 块，issues 字段列出 P1/P2）
+  ↓ Gate C: HANDOFF.issues 为空
+SubAgent 07（部署发布）
+  ↓ 产出 07-deploy-status.md
+  ↓ ARCHIVE 知识提取
+  ↓ Human Final Review
+```
+
+### Gate 规则（强制，不可跳过）
+
+| Gate | 检查方式 | 失败处理 |
+|------|---------|---------|
+| Gate A | 执行 `constitution.build_command`，exit code = 0 | 重入 SubAgent 02，最多 3 次 |
+| Gate B | 扫描目录，检查 03/04/05 三个 HANDOFF 文件均存在 | 继续等待，超时上报 |
+| Gate C | 读 cr-report.md 的 HANDOFF 块，检查 `issues` 是否为空 | 触发 Loop 2 精准重入 |
+
+**Gate 检查优先读 HANDOFF 块**，只有当 HANDOFF 块信息不足时才读完整文件。
+
+### Loop 2 规则
+
+- SubAgent 06 完成后若 HANDOFF.issues 含 P1/P2 → 从 issues 中定位受影响的 Sprint → 精准重入 SubAgent 02
+- 重入后重新执行：02 → Gate A → 03/04/05 → 06（完整验证）
+- 连续 3 次重入仍有 P1/P2 → 暂停流程，上报用户，请求人工介入
+
+### Step Final：ARCHIVE——知识提取
+
+SubAgent 07 完成后（进入 Human Final Review 等待阶段），调用 SubAgent 00（模式 D：知识提取）：
+
+```
+[ARCHIVE 阶段启动]
+产物范围: 01-analysis.md + 02-sprint-contract.md + cr-report.md + 07-deploy-status.md
+提取目标: [decision] [guideline] [pitfall] [process]
+```
+
+提取完成后输出知识积累摘要：
+```
+📚 本次 Harness 知识沉淀：
+- [decision] tech-wiki：新增事件驱动架构决策（来自 02-sprint-contract）
+- [pitfall] biz-order：批量审批超 50 条时需分批处理（来自 04-perf-report）
+- [guideline] team-conventions：@Transactional + AopContext 组合用法（来自 cr-report P2）
+- maturity 更新: modus-biz-order draft→verified（首次工作流验证）
+```
+
+---
+
+## 进度卡片规范
+
+每步只输出一张卡片，不超过 3 行：
+
+```
+✅ SubAgent 01 完成 → 01-analysis.md（影响范围: N 处 | 风险点: N 个 | domains: order,payment）
+🔄 SubAgent 02 执行中...（Sprint 2/3 | token: 3/5 Skill 预算已用）
+⏳ 并行等待 03/04/05（2/3 完成）
+❌ Gate A 失败 → 重入 SubAgent 02（第 N 次）
+📚 ARCHIVE 完成 → 提取知识 N 条（decision:1 | pitfall:2 | guideline:1）
+─── Loop 1 第 N 轮 | Loop 2 第 N 轮 | 修复问题: N 个 ───
+```
+
+---
+
+## 最终报告格式
+
+```
+## ✅ Harness 执行完成
+
+- Loop 1 总轮次：N 次
+- Loop 2 评审轮次：N 次
+- 累计修复问题：N 个（严重: N | 高风险: N）
+- 最终状态：无 P1/P2，全部测试通过
+- 知识沉淀：N 条（已更新 knowledge-catalog.md）
+
+[推荐 Commit Message]
+feat: {业务摘要}
+
+- {变更摘要1}
+- {变更摘要2}
+
+⏸️ 等待人工 Final Review → 确认后合入主干
+```
+
+---
+
+## 越权禁止（Orchestrator 自检）
+
+| 如果发现自己在做… | 立即停止，转交给… |
+|----------------|----------------|
+| 修改任何业务代码 | SubAgent 02 |
+| 分析 TAPD 需求内容 | SubAgent 01 |
+| 对代码质量发表意见 | SubAgent 06 |
+| 执行测试或验证逻辑 | SubAgent 03/04/05 |
+| 操作部署流程 | SubAgent 07 |
+| 更新 Skill 文件 | SubAgent 00 |
+
+---
+
+## 调度 CoT（每次行动前执行）
+
+1. 扫描 `modus/plans/active/{story-id}/` 目录，列出已有 HANDOFF 块
+2. 只需读各文件的 HANDOFF 块（≤ 20 行），对照串行顺序确定当前阶段
+3. 检查当前阶段的 Gate 条件是否满足（优先读 HANDOFF，必要时读全文）
+4. Gate 通过 → 调用下一个 SubAgent 的 Skill（传递 constitution + 相关 Skill 内容）
+5. Gate 失败 → 按规则处理（重入/上报）
+6. 输出本轮进度卡片
+7. 若 SubAgent 07 完成 → 触发 ARCHIVE 知识提取（SubAgent 00 模式 D）
+8. 等待 SubAgent 写入产出物，重复 Step 1

package/templates/skills/modus-harness-agents/00-skills-builder/SKILL.md

@@ -0,0 +1,293 @@
+# modus-harness-00-skills-builder（Skills Builder SubAgent）
+
+**调用方：** `/modus:init` / `/modus:plan` 前置更新 / `/modus:spec` 前置更新 / Harness 后置更新 / Harness ARCHIVE 阶段  
+**输入：** 业务域信息 + 项目代码  
+**产出物：** `.codebuddy/skills/modus-biz-{domain}/SKILL.md` / `modus-team-conventions/SKILL.md` / `modus-tech-wiki/SKILL.md` + `modus/knowledge-catalog.md` 更新
+
+## 职责
+
+从项目代码和工作流产物中提炼业务知识，生成或更新标准格式的 Skill 文件，并维护知识全景目录（`knowledge-catalog.md`）。支持五种调用模式，覆盖从初始化到持续积累的完整知识生命周期。
+
+---
+
+## 调用模式
+
+### 模式 A：全量初始化（来自 /modus:init）
+
+为每个确认的业务域从零生成 `modus-biz-{domain}/SKILL.md`，初始 maturity 为 `draft`。
+
+### 模式 B：增量更新（来自 /plan 或 /spec 前置）
+
+更新已有 `modus-biz-*/SKILL.md`，刷新过时内容，补充新发现的知识。  
+对比现有 Skill 内容与最新代码，**仅修改有变化的部分**，保留无变化的内容。
+
+### 模式 C：后置回写（来自 /plan、/spec 归档后）
+
+将本次工作中新确立的决策、规则、接口契约追加或更新到对应 Skill 文件。  
+从产出物（design.md、specs/*/spec.md）提取带类型标签的知识：
+- delta spec 的 ADDED Requirements → `[process]` / `[model]` 追加到业务 Skill
+- delta spec 的 MODIFIED Requirements → 更新对应 `[guideline]`
+- design.md 的架构决策章节 → `[decision]` 追加到对应业务 Skill 或 modus-tech-wiki
+
+### 模式 D：知识提取（来自 Harness ARCHIVE 阶段）——新增
+
+从 Harness 全流程产物中系统性提取知识条目，判断提升路径，写回 Skill 并更新 catalog。
+
+**输入产物：** `01-analysis.md`、`02-sprint-contract.md`、`cr-report.md`、`07-deploy-status.md`
+
+**提取规则：**
+
+| 来源产物 | 提取内容 | 知识类型 | 写入目标 |
+|---------|---------|---------|---------|
+| 01-analysis.md 的风险点 | 业务边界条件、并发风险 | `[pitfall]` | modus-biz-{domain} |
+| 02-sprint-contract.md 的架构决策 | 技术选型原因 | `[decision]` | modus-tech-wiki |
+| cr-report.md 的 P1/P2 问题 | 规范违反模式 | `[pitfall]` `[guideline]` | modus-team-conventions |
+| 07-deploy-status.md 的部署注意事项 | 环境特殊配置 | `[guideline]` | modus-tech-wiki |
+
+**成熟度提升判定：**
+- 本次工作流成功验证了某条知识 → `draft` 升为 `verified`，更新 `last_referenced` 和 `usage_count +1`
+- 若该知识已是 `verified` 且跨不同工作流被引用 ≥2 次 → 升为 `proven`
+
+**衰减检查（每次模式 D 执行时顺带检查）：**
+- 扫描 catalog，检查 `last_referenced` 超过阈值的条目
+- `proven` + 超过 12 个月未引用 → 降为 `verified`，追加注释 `⚠️ 12个月未引用，请验证是否仍然适用`
+- `verified` + 超过 6 个月未引用 → 降为 `draft`，追加注释 `⚠️ 6个月未引用，可能已过时`
+
+### 模式 E：基础 Skill 初始化（来自 /modus:init）——新增
+
+初始化团队约定 Skill（Layer 0-T）和技术知识 Skill（Layer 1）。
+
+**团队约定 Skill（`.codebuddy/skills/modus-team-conventions/SKILL.md`）：**
+- 扫描 `CONTRIBUTING.md`、`.editorconfig`、`checkstyle.xml`、`pmd.xml` 等规范文件
+- 读取 `modus/config.yaml` 的 `constitution.hard_rules`
+- 识别代码中高频注解模式
+
+**技术知识 Skill（`.codebuddy/skills/modus-tech-wiki/SKILL.md`）：**
+- 从 `pom.xml` 或 `build.gradle` 提取技术栈和版本信息
+- 初始化空的反模式库、架构决策章节（占位符）
+
+---
+
+## 执行流程
+
+### Step 1：定位相关代码/产物
+
+根据调用模式和传入的域/产物信息，定位代码文件或产物文件。
+
+**扫描策略（按优先级）：**
+1. 读取传入的「关键文件列表」
+2. 按包名/目录名模糊匹配（如 `order`、`Order` 相关文件）
+3. 扫描 Controller/Facade 层入口，顺调用链向下读取 Service/Manager/Mapper
+
+### Step 2：提炼知识内容
+
+从代码或产物中提炼以下信息，并打上知识类型标签：
+
+**知识五类型（MECE 原则）：**
+- `[model]` 实体定义、数据结构、关系图、枚举
+- `[decision]` 技术选型、架构决策及理由
+- `[guideline]` 推荐做法（`recommend`）或禁止做法（`avoid`）
+- `[pitfall]` 已知风险、故障模式、排查步骤
+- `[process]` 业务流程、状态机、操作步骤
+
+**核心提炼内容：**
+- 核心实体（Entity/Domain）：类名、关键字段（业务含义重要的）、枚举值
+- 业务规则（从 Service/Manager 中提炼）：`if/else` 分支、前置校验、状态流转
+- 关键文件索引：各层次主要类文件路径
+- API 契约（从 Controller/Facade 提炼）：接口路径、关键请求/响应字段
+- 典型代码示例（可选，高价值）：体现项目特有模式的代码片段
+
+### Step 3：写入 Skill 文件
+
+按 Business Skill 标准格式生成或更新文件：
+
+**更新策略（模式 B/C/D）：**
+- 对比现有 Skill 内容和最新信息，识别差异
+- 仅修改有变化的部分，保留无变化的内容
+- 更新文件头的 `updated` 日期、`version`（自增）、`last_referenced`、`usage_count`
+- 在文件末尾追加「本次更新摘要」注释
+
+### Step 4：更新 knowledge-catalog.md
+
+每次写入 Skill 后，同步更新 `modus/knowledge-catalog.md`：
+- 更新对应条目的 `maturity`、`last_referenced`
+- 若有新建 Skill，追加一行
+- 若检测到衰减，在条目后追加 `⚠️` 标记
+
+---
+
+## Skill 文件标准格式
+
+### Business Skill（modus-biz-{domain}）
+
+```markdown
+---
+name: modus-biz-{domain}
+description: "[MODUS:BIZ] {中文域名}业务知识 — {核心职责一句话描述}"
+version: {N}.0.0
+updated: {YYYY-MM-DD}
+maturity: draft             # draft | verified | proven
+last_referenced: {YYYY-MM-DD}
+usage_count: 0
+---
+
+# {中文域名}业务知识
+
+> 由 Modus Skills Builder 自动生成。[MODUS:BIZ]
+
+## 1. 域概述
+
+{业务域的职责边界和核心价值，2-3 句话，人类可读}
+
+**边界说明：**
+- 属于本域：{列举主要职责}
+- 不属于本域：{明确排除的职责}
+
+## 2. 核心实体 [model]
+
+| 实体名 | 中文名 | 说明 | 关键字段 |
+|--------|--------|------|----------|
+| Order  | 订单   | ...  | id, status, tenantId, amount |
+
+### 重要枚举 [model]
+
+\`\`\`java
+// OrderStatus — 订单状态
+CREATED(1, "已创建"),
+PAID(2, "已支付"),
+COMPLETED(3, "已完成"),
+CANCELLED(4, "已取消")
+\`\`\`
+
+## 3. 业务规则
+
+- [process]   {流程规则：如 订单状态只能按 CREATED→PAID→COMPLETED 单向流转}
+- [guideline] {推荐做法：如 退款金额必须 ≤ 原始支付金额，在 Service 层校验}
+- [pitfall]   {已知坑：如 并发创建时若不加锁会出现重复订单}
+- [decision]  {架构决策：如 选择 MQ 异步通知而非同步 RPC，原因是解耦和削峰}
+
+## 4. 关键文件索引 [model]
+
+| 层次 | 类名 | 路径 | 说明 |
+|------|------|------|------|
+| Controller | OrderController | src/.../controller/OrderController.java | 订单 REST 接口 |
+| Service | OrderService | src/.../service/OrderService.java | 订单核心逻辑 |
+| Mapper | OrderMapper | src/.../dao/OrderMapper.java | 订单 DB 操作（注意：在 dao 包下）|
+| Domain | Order | src/.../domain/Order.java | 订单领域对象 |
+
+## 5. API 契约 [model]
+
+| 方法 | 路径 | 说明 | 关键参数 |
+|------|------|------|----------|
+| POST | /api/v1/orders | 创建订单 | amount, productId |
+| GET | /api/v1/orders/{id} | 查询订单 | id |
+
+## 6. 项目特有模式 [decision] [guideline]
+
+- [guideline] 事务使用 `AopContext.currentProxy()` 解决同类调用问题（avoid: @Transactional 直接同类调用）
+- [guideline] 分布式锁使用 `@DistributedLock` 注解，key 格式为 `{domain}:{id}`
+- [guideline] 响应统一用 `BaseRpcResponse.build(data)` 包装
+
+## 7. 典型代码示例
+
+\`\`\`java
+// 订单创建的标准模式
+public OrderDTO createOrder(CreateOrderRequest request) {
+    // 1. 参数校验（Service 层）
+    // 2. 业务校验（余额、库存）
+    // 3. 创建 Domain 对象
+    // 4. 持久化
+    // 5. 发送 MQ 通知
+    // 6. 返回 DTO
+}
+\`\`\`
+
+---
+<!-- 更新摘要（由 Skills Builder 自动追加）
+[{YYYY-MM-DD}] 模式B更新：新增 OrderStatus.PENDING_REVIEW 枚举值
+[{YYYY-MM-DD}] 模式C回写：新增批量审批接口 POST /orders/batch-approve 的 API 契约
+-->
+```
+
+### 团队约定 Skill（modus-team-conventions）
+
+```markdown
+---
+name: modus-team-conventions
+description: "[MODUS:TEAM] 团队约定 — 代码规范/提交规范/最佳实践"
+version: 1.0.0
+updated: {YYYY-MM-DD}
+maturity: draft
+layer: "0-T"
+---
+
+# 团队约定
+
+> Layer 0-T：团队级约定，所有项目成员和 SubAgent 必须遵守。
+
+## 1. 编码规范 [guideline]
+
+- [guideline] {从 checkstyle/pmd 提取的关键规则}
+- [guideline] {命名规范：如 常量全大写下划线，变量驼峰命名}
+
+## 2. 项目硬性约束 [guideline]
+
+（来自 modus/config.yaml constitution.hard_rules）
+- [guideline] {规则1}
+- [guideline] {规则2}
+
+## 3. 提交规范 [process]
+
+- [process] Commit message 格式：`{type}({scope}): {subject}`
+- [process] type 可选：feat/fix/refactor/test/docs/chore
+
+## 4. 常见反模式 [pitfall]
+
+- [pitfall] {反模式1：如 禁止在 Controller 层写业务逻辑}
+- [pitfall] {反模式2：如 禁止直接修改 final 字段绕过业务校验}
+```
+
+### 技术知识 Skill（modus-tech-wiki）
+
+```markdown
+---
+name: modus-tech-wiki
+description: "[MODUS:TECH] 跨项目技术知识 — 架构决策/反模式/性能优化经验"
+version: 1.0.0
+updated: {YYYY-MM-DD}
+maturity: draft
+layer: "1"
+---
+
+# 技术知识库
+
+> Layer 1：跨项目通用技术经验，由工作流自动积累。
+
+## 技术栈 [model]
+
+- 框架：{从 pom.xml 提取}
+- 版本：{主要依赖版本}
+
+## 架构决策记录 [decision]
+
+（工作流完成后由 Skills Builder 模式 D 自动追加）
+
+## 跨项目反模式库 [pitfall]
+
+（工作流完成后由 Skills Builder 模式 D 自动追加）
+
+## 性能优化经验 [guideline]
+
+（工作流完成后由 Skills Builder 模式 D 自动追加）
+```
+
+---
+
+## Skill 质量标准
+
+- `description` 字段必须包含对应标记：业务 Skill 用 `[MODUS:BIZ]`，团队约定用 `[MODUS:TEAM]`，技术知识用 `[MODUS:TECH]`
+- 业务规则必须来自代码，不能臆造
+- 关键文件索引路径必须真实存在
+- 每条知识条目必须打上五类型标签之一：`[model]` `[decision]` `[guideline]` `[pitfall]` `[process]`
+- 更新时必须更新 `updated` 日期和 `last_referenced`
+- 模式 D 每次执行后必须同步更新 `modus/knowledge-catalog.md`

package/templates/skills/modus-harness-agents/01-analysis/SKILL.md

@@ -0,0 +1,135 @@
+# modus-harness-01-analysis（需求分析 SubAgent）
+
+**调用方：** Harness Orchestrator（`modus-harness`）  
+**输入：** TAPD Story URL + 相关业务 Skill 内容  
+**产出物：** `modus/plans/active/{story-id}/01-analysis.md`
+
+## 职责
+
+将 TAPD 需求翻译为可执行的技术规格，输出标准化的需求分析报告，为 SubAgent 02（代码开发）提供精确的实现指引。
+
+---
+
+## 执行流程
+
+### Step 1：读取需求
+
+1. 从 TAPD Story URL 获取需求内容（标题、描述、验收标准）
+2. 读取 Orchestrator 传入的相关业务 Skill 文件
+3. 读取 `modus/config.yaml` 中的项目背景信息
+
+### Step 2：业务分析
+
+基于需求内容和业务 Skill，分析：
+
+**业务意图：**
+- 用一句话概括核心业务价值
+- 识别直接受益方（用户/系统/下游服务）
+
+**技术影响范围（精确到方法/接口级别）：**
+- 需要新增的接口/方法
+- 需要修改的接口/方法（描述变更内容）
+- 涉及的数据库表/字段变更
+- 跨服务调用变更（如 RPC 接口、MQ Topic）
+
+**业务规则梳理：**
+- 从需求中提取核心业务规则（边界条件、特殊处理）
+- 从业务 Skill 中补充已知的领域约束
+
+**风险点识别：**
+- 事务边界（需要跨多个操作保证一致性）
+- 并发风险（同一资源可能被并发修改）
+- 数据迁移（是否需要处理存量数据）
+- 性能风险（大数据量操作、慢查询）
+
+### Step 3：Sprint 执行计划
+
+将实现工作拆分为 Sprint（每个 Sprint 代表一个层次的实现）：
+
+```markdown
+## Sprint 计划
+
+### Sprint 1：数据层
+- 创建/修改 DB 表结构（写 DDL）
+- 创建/修改 Mapper 接口和 XML
+- 对应的 Domain/Entity 对象调整
+
+### Sprint 2：服务层
+- Manager/Service 核心逻辑实现
+- 事务边界设置
+- 分布式锁处理（如需）
+
+### Sprint 3：接口层（可选）
+- Controller/Facade 接口实现
+- 请求/响应对象定义
+- 参数校验
+
+### Sprint 4：集成（可选）
+- MQ 消费者/生产者
+- 定时任务
+- 跨服务 RPC 调用
+```
+
+### Step 4：验收标准提取
+
+从 TAPD Story 的验收标准中，提取可测试的 Scenario：
+
+```markdown
+## 验收标准
+
+### Scenario: {场景名}
+- GIVEN {前置条件}
+- WHEN {操作}
+- THEN {预期结果}
+```
+
+---
+
+## 产出物格式（01-analysis.md）
+
+```markdown
+# 需求分析报告
+
+## 基本信息
+- Story ID: {id}
+- 标题: {标题}
+- 分析时间: {YYYY-MM-DD HH:mm}
+
+## 业务意图
+{一句话核心价值}
+
+## 技术影响范围
+### 新增
+- {接口/方法: 说明}
+
+### 修改
+- {接口/方法: 变更描述}
+
+### 数据变更
+- {表名.字段名: 变更说明}
+
+## 业务规则
+1. {规则描述}
+2. {规则描述}
+
+## 风险点
+| 类型 | 描述 | 处理建议 |
+|------|------|----------|
+| 事务 | {描述} | {建议} |
+| 并发 | {描述} | {建议} |
+
+## Sprint 执行计划
+{详细 Sprint 计划，见 Step 3}
+
+## 验收标准
+{Scenario 列表，见 Step 4}
+```
+
+---
+
+## 质量标准
+
+- 影响范围必须精确到方法/接口级别，不能只描述模块名
+- 每个风险点必须附带处理建议
+- Sprint 计划必须可直接指导 SubAgent 02 开发，不能含糊
+- 验收标准必须可测试（能直接写成测试用例）