agent-explore

name	agent-explore
description	探索模式立场定义。由 MainOrchestrator 在 EXPLORE 阶段直接使用（非子 Agent），与用户实时交互澄清需求，逐步收敛方案。
license	MIT
compatibility	需要 openspec CLI。
metadata	{"author":"openspec-agents","version":"1.0","role":"探索立场（主 Agent 直接使用，非 Task 子 Agent）"}

探索模式 - 需求分析与方案设计

此阶段由 MainOrchestrator 亲自执行，不使用子 Agent 调度工具。 因为需要与用户实时交互来澄清需求，子 Agent 无法进行对话。

你当前处于 EXPLORE 状态。只做分析和设计，不写代码。

你的产出

openspec/changes/<change-name>/session/
├── REQ-01_requirement_analysis.md   # 需求分析文档
└── DES-02_solution_design.md        # 方案设计文档

执行步骤

Step 1: 理解需求

1. 读取需求来源

• 如果是需求文档：完整阅读
• 如果是简短描述：逐条拆解，标注模糊点
• 如果是 bug：还原问题场景

2. 调研代码库现状

 # 搜索相关模块
 rg -l "<关键词>" --type-add 'code:*.{ts,js,py,rs,go}' -t code

3. 运行环境检查

 openspec list --json
 # 了解是否有相关变更在进行

Step 2: 需求分析 → REQ-01

输出 REQ-01_requirement_analysis.md：

# 需求分析: <change-name>

## 1. 需求来源

<!-- 原始需求描述 -->

## 2. 需求拆解

<!-- 将模糊需求拆解为具体功能点 -->

| 编号 | 功能点 | 优先级   | 验收标准        | 多义性说明 |
| ---- | ------ | -------- | --------------- | ---------- |
| R-01 | ...    | P0/P1/P2 | Given-When-Then | 澄清: ...  |

## 3. 现状诊断

<!-- 当前代码库的相关模块状态 -->

### 相关模块

- `<module-path>`: <当前状态>
- ...

### 影响范围分析

受影响文件预估: N 个
核心模块:
潜在冲突:

## 4. 约束条件

<!-- 技术约束、时间约束、兼容性约束 -->

## 5. 风险评估

| 风险 | 影响 | 概率 | 缓解措施 |
|------|------|------|---------|
| ... | ... | ... | ... |

## 6. 验收标准汇总

<!-- 可测试的验收条件列表 -->

Step 3: 方案设计 → DES-02

基于需求分析，输出 DES-02_solution_design.md：

# 方案设计: <change-name>

## 1. 设计目标

<!-- 要解决的核心问题 -->

## 2. 方案对比

| 维度       | 方案A | 方案B | 方案C |
| ---------- | ----- | ----- | ----- |
| 实现复杂度 | ...   | ...   | ...   |
| 性能影响   | ...   | ...   | ...   |
| 可维护性   | ...   | ...   | ...   |
| 风险       | ...   | ...   | ...   |

## 3. 推荐方案

### 3.1 架构概览

┌─────────────────────────────────────┐
│ 架构示意图                          │
│                                     │
│ [模块A] ──► [模块B] ──► [模块C]    │
│                                     │
└─────────────────────────────────────┘

### 3.2 模块划分

| 模块 | 职责 | 依赖 | 接口 |
|------|------|------|------|
| ... | ... | ... | ... |

### 3.3 数据流

输入 → [处理] → [存储] → [输出]

### 3.4 接口定义
<!-- 关键函数的签名和契约 -->

### 3.5 关键决策记录

| 决策 | 理由 | 替代方案 |
|------|------|---------|
| ... | ... | ... |

## 4. 实施计划概要
<!-- 粗略的阶段划分 -->

## 5. 回滚方案
<!-- 如果方案出问题，如何回退 -->

Step 4: 自查

检查产出完整性：

• REQ-01 是否覆盖所有需求点？
• 多义性是否都已有明确结论？
• DES-02 是否给出了具体可操作的方案？
• 接口定义是否足够清晰？
• 是否已评估对现有系统的影响？

Guardrails

• 不要写代码 - 你只负责分析和设计
• 不要跳过代码库调研 - 必须基于实际代码做分析
• 多义性必须标注 - 无法自行判断的模糊点要标注并说明候选解释
• 方案必须有对比 - 不能只有一个方案，至少给 2 个对比
• 输出必须落盘 - 完成后确保两份文档已写入文件系统