@chongyan/autospec 1.0.1

package/plugins/skills/design-stage/SKILL.md

@@ -0,0 +1,216 @@
+---
+name: design-stage
+description: "When technical design, architecture planning, API design, or database schema design is needed — loads AutoSpec design process and skill."
+---
+
+# AutoSpec 方案设计（Stage 02）
+
+你正在执行方案设计阶段。此阶段将需求文档转化为可指导编码的技术方案。
+
+## 前置检查
+
+1. 确认需求分析阶段已完成（检查 `.autospec/runtime/state.json`）
+2. 读取 `${KNOWLEDGE}/principles/constitution.md` → 确认红线
+3. 读取上游精炼契约（需求文档）
+4. **检查是否为多系统项目**：读取 `.autospec/runtime/config.json` 的 `subsystems` 字段
+5. **检查是否需要效果指标设计**：检查是否有 ai 类型子系统或需求文档包含效果指标
+6. 加载创业团队角色画像：读取 `${KNOWLEDGE}/guides/stages/` 目录下的角色文件
+7. 加载方法论原则：读取 `${KNOWLEDGE}/principles/core-principles.md` → 注入 P7(class先于instance)、P8(抽象力度控制)、P3(系统六要素) 等设计原则
+8. 加载设计哲学：读取 `${KNOWLEDGE}/principles/design-philosophy.md` → 注入 DP15(Brownfield适配)、DP16(模板即约束) 原则
+9. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/core-principles.md` → 本阶段重点应用 CP4(逻辑链完整)、CP9(刚好够用)、CP5(置信度标注)
+
+## 认知姿态（本阶段：发散→收敛 + 防过度设计）
+
+- **CP4 逻辑链完整**：每个技术选型必须说明"选了什么 + 为什么 + 放弃了什么"。关键决策记录不可跳步
+- **CP9 刚好够用**：抵制过度设计。添加架构层次前自问：这是必须的吗？更简单的方案能不能满足需求？
+- **CP5 置信度**：对不确定的设计决策，标注置信度。技术选型的风险评估要诚实标注不确定性
+
+## 执行
+
+### Step 1: 确定模式与复杂度
+
+读取 `.autospec/runtime/config.json`，检查 `subsystems` 字段：
+- **无 subsystems 或长度为1** → 单系统模式
+- **有 subsystems 且长度>1** → 多系统模式
+
+**继承或重新评估复杂度**：
+- 如果需求阶段已有复杂度评估，继承结果
+- 如有新的技术复杂度因素，重新评估
+
+**【强制】** 读取 `${KNOWLEDGE}/config/team-triggers.yaml`，检查强制触发规则：
+- 涉及新架构/框架 → 强制引入 tech-lead
+- 跨系统变更 → 强制引入 tech-lead + devops-engineer
+- 新服务部署 → 强制引入 devops-engineer
+
+### Step 2: 创业团队对抗设计审查
+
+根据复杂度评估结果，启动团队对抗审查：
+
+#### 简单任务（score <= 5）
+快速通道，仅技术负责人审查：
+- 技术负责人：架构合理性、过度设计检查
+
+#### 中等任务（score 6-8）
+引入工程师视角：
+- 技术负责人 + 相关工程师（根据涉及的子系统类型）
+
+#### 复杂任务（score >= 9）
+引入完整团队：
+- 技术负责人 + 全部相关工程师
+- 如触发强制规则，额外引入安全工程师/运维工程师
+
+**对抗审查执行方式**：
+
+**自主模式 — 多Agent并行对抗**：
+```
+**【强制】** 读取 `${KNOWLEDGE}/guides/support/team-orchestrator.md`
+并行启动角色Agent（信息隔离，做审分离）：
+  - 技术负责人 Agent：架构合理性、技术选型、过度设计检查
+  - 后端工程师 Agent：API设计、数据库设计、性能（如涉及）
+  - 前端工程师 Agent：组件设计、状态管理、用户体验（如涉及）
+  - 数据工程师 Agent：数据模型、ETL设计（如涉及）
+  - AI工程师 Agent：模型选型、评估方案（如涉及）
+  - 安全工程师 Agent：安全设计（如触发）
+  - 运维工程师 Agent：部署方案、监控设计（如触发）
+汇总意见，生成团队对抗审查报告
+```
+
+**交互模式 — 与用户互动完成**：
+将团队各角色的关注点作为确认框架，与用户交互：
+1. **技术负责人视角**：架构方案、技术选型理由、关键决策
+2. **工程师视角**：实现可行性、技术风险
+3. **安全视角**（如触发）：安全方案、数据保护
+4. **运维视角**（如触发）：部署方案、监控告警
+
+### Step 3: 单系统模式设计
+
+1. **【强制】** 加载做类skill：读取 `${KNOWLEDGE}/guides/stages/design-planner.md` → **按步骤执行**
+2. 加载检查清单：读取 `${KNOWLEDGE}/checklists/design.md` → 逐项核对
+3. 加载元学习方法：读取 `${KNOWLEDGE}/principles/core-principles.md` → 应用"自顶向下+自底向上"双向设计法
+4. **设计决策的双模式处理**：
+   - 技术选型涉及多个可行方案时：
+     - 交互模式：展示选项 + 推荐 + 理由，等待用户选择
+     - 自动模式：选择推荐方案，记录到 `autoDecisions`（含备选方案和放弃理由）
+   - 安全/合规相关设计决策：
+     - 两种模式都使用最安全选项
+     - 自动模式额外标记 `HIGH_PRIORITY_REVIEW`
+5. **【效率优化】并行化设计分析**：
+   - 架构设计与数据模型设计可并行进行
+   - API设计与技术选型可并行进行
+   - 使用 Agent 工具并行启动独立分析任务
+6. **【效率优化】复用已有分析结果**：
+   - 检查需求阶段的技术可行性分析结果
+   - 复用复杂度评估中的技术约束
+   - 避免重复分析相同技术问题
+7. 产出技术方案文档，写入 `.autospec/specs/{feature}/design.md`
+8. 如有API设计，写入 `.autospec/specs/{feature}/contracts/`
+
+### Step 4: 多系统模式设计
+
+1. **【效率优化】并行产出整体架构**：写入 `design/overview.md`
+   - 系统交互图
+   - 数据流向
+   - 跨系统接口契约
+   - 关键技术决策
+   - 依赖关系（开发顺序建议）
+   - *注：整体架构设计与子系统设计可并行启动*
+
+2. **【效率优化】并行产出各子系统设计**：
+   ```
+   # 无依赖的子系统可并行设计
+   parallel_for subsystem in config.subsystems（按依赖分组）:
+     1. 分析该子系统负责的功能范围
+     2. 设计该子系统的模块、数据模型、API
+     3. 写入 design/{subsystem.name}.md
+   ```
+
+3. **产出接口契约**：如有跨系统接口，写入 `contracts/api.yaml`
+
+### Step 5: 效果指标设计（AI/模型类功能）
+
+当项目包含 AI/模型 相关功能时，设计阶段需要额外产出：
+
+1. **效果指标定义**：
+   - 核心效果指标（如准确率、召回率、F1、BLEU等）
+   - 业务效果指标（如转化率、用户满意度、任务完成率）
+   - 效果基线（最低可接受效果）
+   - 效果目标（期望达到的效果）
+
+2. **评测方案设计**：
+   - 评测数据来源（公开数据集/业务数据/人工构造）
+   - 评测方法选择（自动评测/人工评测/A/B测试）
+   - 评测频率（离线评测/在线评测）
+
+3. 写入 `design.md` 的"效果指标"章节，或独立产出 `design/evaluation.md`
+
+## 验证
+
+### Layer 1: 确定性验证
+- Schema校验：方案文档包含所有必须字段（架构、数据模型、接口、技术选型、假设清单）
+- 一致性检查：方案中的数据模型与接口定义无矛盾
+- **多系统模式**：overview.md 包含系统交互图和开发顺序
+- **AI/模型功能**：有效果指标章节或 evaluation.md
+
+### Layer 2: AI审查（做审分离）
+使用 **independent-reviewer** Agent 执行独立审查：
+```
+**【强制】** 调用 Agent 工具：
+  prompt: 请审查以下技术方案。
+    1. 先读取审查标准: ${KNOWLEDGE}/guides/stages/design-reviewer.md
+    2. 被审查文档: .autospec/specs/{feature}/design.md（或 design/ 目录）
+    3. 上游需求文档: .autospec/specs/{feature}/requirement.md（用于校验一致性）
+    注意：你是独立审查者，只看产出物和标准
+```
+
+### Layer 3: Benchmarks 评测（新增）
+
+**【强制】** 执行 design benchmarks 评测：
+```
+1. 检测设计产出物完整性
+   - design.md（或 design/ 目录）
+   - contracts/api.yaml（如适用）
+   - data-model.md（如适用）
+2. 调用 benchmark-executor 执行评测：
+   - DES-001: 架构设计完整性（架构图、技术选型理由、非功能需求设计）
+   - DES-002: API 设计规范性（RESTful规范、错误码统一、版本管理）
+   - DES-003: 数据模型设计（ER图、字段类型、索引设计）
+   - DES-004: 设计-需求一致性（可追溯性检查）
+3. 生成评测报告到 .autospec/benchmarks/results/design-{run-id}.json
+4. 如评测未通过：
+   - 生成改进建议
+   - 返回 Step 2 完善设计
+   - 最多重试 3 次
+5. 如评测通过：
+   - 记录评测结果
+   - 允许进入 implementation stage
+```
+
+**评测触发方式**：
+- 自动触发：design.md 生成后自动执行
+- 手动触发：`/benchmark --run --stage=design`
+- 变更触发：设计文档修改后自动重新评测
+
+## 阶段门禁（所有自主级别）
+
+使用 **stage-gate-evaluator** Agent 评估产出物是否达到准出标准：
+```
+**【强制】** 调用 Agent 工具：
+  prompt: 请评估方案设计阶段的产出物是否达到准出标准。
+    当前阶段：Stage 02 方案设计
+    产出物：.autospec/specs/{feature}/design.md（或 design/ 目录）
+    准出标准：${KNOWLEDGE}/checklists/design.md
+    上游契约：.autospec/specs/{feature}/requirement.md
+    自主级别：{自主/交互}
+```
+
+**根据自主级别处理评估结果**：
+- **交互模式**：评估结果提交人工确认，AI 等待用户批准后继续
+- **自主模式**：评估通过后自动进入下一阶段，评估不通过进入精准回退
+
+## 完成
+
+- 两层验证通过 + 阶段门禁评估通过 → 输出精炼契约 → 更新 `.autospec/runtime/state.json` → 进入编码实现
+- 不通过 → 精准回退：
+  - Level 1: 内联重试（单次）
+  - Level 2: 修正循环（最多3次，只重处理失败项）
+  - Level 3: 3次后使用 **failure-diagnostician** Agent 执行根因分析，再升级用户

package/plugins/skills/evolution-process/SKILL.md

@@ -0,0 +1,291 @@
+---
+name: evolution-process
+description: "When framework improvement, skill distillation, methodology extraction, practice log review, or field-evolve execution is needed — loads AutoSpec self-evolution process."
+---
+
+# AutoSpec 自进化（自动感知）
+
+你检测到了与框架进化相关的任务（如：复盘、总结经验、提炼技能、更新方法论、执行 field-evolve）。
+
+## 前置
+
+1. 读取 `${KNOWLEDGE}/evolution.md` → 确认进化分区规则和安全护栏
+2. 读取 `${KNOWLEDGE}/principles/constitution.md` → 确认红线
+3. 读取 `${KNOWLEDGE}/principles/core-principles.md` → 本阶段重点 CP6(错误即信号)、CP7(模式识别)
+
+## 认知姿态（本阶段：反思 + 模式提炼）
+
+- **CP6 错误即信号**：每次回退/打回/纠正都是进化信号。重点关注：
+  - 同类错误第 2 次 → 生成防护规则（更新 checklist）
+  - 同类错误第 3 次 → 必须升级对应 skill
+- **CP7 模式识别**：从重复中发现规律。重点检测：
+  - 重复出现的任务模式 → 建议新 skill
+  - 重复出现的偏好/纠正 → 沉淀为 checklist
+  - 重复出现的架构决策 → 沉淀为 decision-tree
+
+## 三层进化体系
+
+```
+┌─────────────────────────────────────────────────────────────────┐
+│  L1: Self-Evolve (框架级)                                        │
+│  /self-evolve                                                    │
+│  目标: AutoSpec 框架自身的迭代升级                                  │
+│  位置: .claude/skills/self-evolve/                               │
+└─────────────────────────────────────────────────────────────────┘
+                              ↓ 提炼
+┌─────────────────────────────────────────────────────────────────┐
+│  L2: Field-Evolve (领域级)                                        │
+│  /autospec:field-evolve                                          │
+│  目标: 框架从实战项目中学习和提炼能力                               │
+│  位置: plugins/commands/field-evolve.md                            │
+└─────────────────────────────────────────────────────────────────┘
+                              ↓ 应用
+┌─────────────────────────────────────────────────────────────────┐
+│  L3: Project-Evolve (项目级)                                      │
+│  /autospec:project-evolve                                        │
+│  目标: 实战项目自身的代码、配置、文档优化                            │
+│  位置: plugins/commands/project-evolve.md                        │
+└─────────────────────────────────────────────────────────────────┘
+```
+
+## 进化类型识别
+
+根据触发来源，识别进化类型：
+
+| 触发来源 | 进化类型 | 层级 | 处理方式 |
+|---------|---------|------|---------|
+| `/self-evolve` | 框架自我进化 | L1 | 框架自身迭代 |
+| `/autospec:field-evolve --mode=quick` | 快速验证 | L2 | 执行确定性测试，生成报告 |
+| `/autospec:field-evolve --mode=deep` | 深度测试 | L2 | 执行 benchmarks + 评估分析 |
+| `/autospec:field-evolve --mode=full` | 完整循环 | L2 | deep + 改进 + 修复 + 蒸馏 |
+| `/autospec:field-evolve --mode=distill` | 技能蒸馏 | L2 | 从 practice-log 提炼技能 |
+| `/autospec:project-evolve --init-memory` | 初始化记忆 | L3 | 自动发现项目评测点 |
+| `/autospec:project-evolve --cruise` | 智能巡航 | L3 | 全自动持续进化 |
+| `/autospec:project-evolve --deep` | 深度进化 | L3 | 全维度分析+修复 |
+| `/autospec:project-evolve --focus=*` | 专项进化 | L3 | 针对特定维度优化 |
+| 自动触发（practice-log 积累） | 技能蒸馏 | L2 | 同 distill 模式 |
+
+## Field-Evolve 执行流程
+
+### Mode: quick（快速验证）
+
+**目标**: 快速验证项目基本健康度
+
+```
+Step 1: 确定技术栈
+  - 读取 .autospec/runtime/config.json
+  - 识别项目类型和构建工具
+
+Step 2: 运行确定性测试
+  - 编译检查
+  - 单元测试
+  - Lint 检查
+  - 类型检查（如适用）
+
+Step 3: AI 评测
+  - 失败分析
+  - 覆盖率分析
+  - 代码质量评估
+
+Step 4: 生成快速报告
+  - 测试结果汇总
+  - 改进建议
+  - 保存到 .autospec/logs/autospec:field-evolve/quick-{date}.md
+```
+
+### Mode: deep（深度测试）
+
+**目标**: 执行 benchmarks 并生成评估报告
+
+```
+Step 1: 扫描 Benchmarks
+  - 扫描 .autospec/benchmarks/*.yaml
+  - 加载 benchmark 配置
+
+Step 2: 执行 Benchmarks
+  - 创建隔离环境
+  - 执行每个 benchmark 的测试场景
+  - 捕获过程指标和产出物
+
+Step 3: 三维度评估
+  - 过程指标（30%）: Layer1/2 通过率、回退率等
+  - 结果指标（40%）: 产出物质量、一致性等
+  - 路径指标（30%）: 流程合规性、执行效率等
+
+Step 4: 生成深度报告
+  - 评分和等级
+  - 主要发现
+  - 改进建议
+  - 保存到 .autospec/logs/autospec:field-evolve/deep-{date}.md
+```
+
+### Mode: full（完整循环）
+
+**目标**: 完整进化循环（测试 → 评估 → 改进 → 修复 → 蒸馏）
+
+```
+Step 1-4: 同 deep 模式
+
+Step 5: 改进方案生成
+  - 问题分类（auto-fixable / manual-review）
+  - 优先级计算（P0/P1/P2）
+  - 影响预测
+  - 生成改进方案文档
+
+Step 6: 自动修复（如 --auto-fix）
+  - 执行 auto-fixable 的改进
+  - 验证修复效果
+  - 失败则回滚
+
+Step 7: 效果验证
+  - 重新执行 benchmarks
+  - 退化检测
+  - 生成验证报告
+
+Step 8: 技能蒸馏
+  - 同 distill 模式
+```
+
+### Mode: report（仅报告）
+
+**目标**: 分析并生成报告，不执行修复
+
+```
+Step 1-4: 同 deep 模式
+Step 5: 生成详细报告（包含改进建议，但不执行）
+```
+
+### Mode: distill（技能蒸馏）
+
+**目标**: 从 practice-log 提炼技能和方法论
+
+同「标准进化流程」（见下文）。
+
+### Mode: generate（生成 benchmarks）
+
+**目标**: 根据项目类型自动生成 benchmarks
+
+```
+Step 1: 检测项目类型
+  - package.json → Node.js
+  - pom.xml/build.gradle → Java
+  - go.mod → Go
+  - requirements.txt/pyproject.toml → Python
+
+Step 2: 选择模板
+  - 从 plugins/benchmarks/templates/ 加载对应模板
+
+Step 3: 生成配置
+  - 填充项目特定信息
+  - 调整构建/测试命令
+
+Step 4: 保存
+  - 保存到 .autospec/benchmarks/project-generated.yaml
+  - 提示用户可自定义修改
+```
+
+## 标准进化流程（Distill 模式）
+
+可使用 `/autospec:field-evolve --mode=distill` 或 `/evolve` 命令执行。
+
+### Step 1: 信号收集
+
+扫描 `.autospec/evolution/practice-log/` 中状态为 "Pending" 的条目。
+- 如果没有 Pending 条目 → 告知用户暂无可进化内容，结束
+- 如果有 → 列出所有 Pending 条目，继续
+
+### Step 2: 技能蒸馏（必须执行）
+
+**读取 `${KNOWLEDGE}/guides/support/skill-distiller.md`，按其中的"执行步骤"逐步执行：**
+1. 扫描 practice-log 中的操作轨迹和人工介入点
+2. 识别信号：反复出现的操作模式（3次以上）、频繁人工介入点、重复逻辑
+3. 如发现可蒸馏的新 skill → 按 `${KNOWLEDGE}/guides/_template.md` 格式生成
+4. 判断归属：stages/ 还是 domain/
+
+### Step 3: 方法论提取（必须执行）
+
+**读取 `${KNOWLEDGE}/guides/support/methodology-extractor.md`，按其中的"执行步骤"逐步执行：**
+1. 分析本次实践：哪些做法有效、哪些踩坑
+2. 与已有 `${KNOWLEDGE}/principles/core-principles.md` 和 `${KNOWLEDGE}/checklists/` 对比
+3. 如果是新发现 → 提取为方法论更新
+4. 如果与已有原则冲突 → 标记待讨论，**不自动覆盖**
+
+### Step 4: 已有技能升级检查
+
+**读取 `${KNOWLEDGE}/guides/support/skill-updater.md`，检查是否有需要升级的 skill：**
+- 同类问题出现 3 次以上 → 必须升级对应 skill
+- 收集该 skill 的所有反馈数据，分析问题模式
+- 生成修改建议
+
+### Step 5: 分区执行（读取 `${KNOWLEDGE}/evolution.md` 确认规则）
+
+对每个发现的进化项，确认所属分区后执行：
+
+**自由区**（domain skills, decision-trees）：
+1. 执行变更
+2. **必须调用 `${KNOWLEDGE}/guides/support/skill-validator.md` 验证** — 读取该文件的"评判标准"和"评审步骤"，逐项检查新/修改的 skill
+3. 验证通过 → 写入对应目录
+4. 验证不通过 → 修正后重新验证（最多2次）
+
+**受控区**（stage skills, checklists, principles）：
+1. 生成变更提案，写入 `.autospec/evolution/proposals/{NNN}-{title}.md`
+2. 提案格式：当前问题 + 建议修改 + 支撑证据(practice-log引用) + 预期效果
+3. **主动告知用户**：有新的受控区变更提案需要审批
+
+**冻结区**（constitution, evolution rules）：
+- **绝不触碰**，仅在报告中标记建议
+
+### Step 6: 三级回流决策（全局/组织能力沉淀）
+
+对每个自由区进化项，决定回流目标：
+
+**回流目标**：
+1. **项目级**（默认）：留在当前项目，仅当前项目可用
+2. **用户全局**（`~/.claude/autospec/skills/`）：所有项目可复用
+3. **组织级**（`~/.claude/autospec/orgs/{org-name}/skills/`）：组织内共享
+
+**决策规则**：
+- 优先回流到用户全局（除非用户偏好设置禁止）
+- 组织级回流需要明确指定组织名称
+- 读取 `team-preferences` 获取用户进化偏好（自动/手动）
+
+**回流操作**：
+- 用户全局回流：调用 `autospec global publish <skill-name>`
+- 组织级回流：调用 `autospec org publish <org-name> <skill-name>`
+- 自动回流时同时创建 Claude Code 符号链接（`~/.claude/skills/autospec`）
+
+**实战项目 → AutoSpec 回流**（field-evolve 特有）：
+```
+如配置回流到 AutoSpec：
+1. 将提炼的技能复制到 .autospec/evolution/distilled-skills/
+2. 生成回流提案（PR 模板）
+3. 提示用户提交到 AutoSpec 项目
+```
+
+### Step 7: 效果验证
+
+- 如有基准案例（`${KNOWLEDGE}/evaluation/benchmarks/`），对比变更前后
+- 退化 → 自动回滚并记录
+
+### Step 8: 记录审计
+
+- 所有变更记录到 `.autospec/evolution/evolution-log.json`
+- 更新 practice-log 对应条目状态为 "已处理"
+
+## 自动触发时机
+
+本 skill 会在以下时机被自动感知触发：
+- 全流程完成后（交付阶段结束时自动触发进化信号扫描）
+- practice-log 积累到 5 条以上
+- 同类问题出现第 3 次
+- 用户明确要求复盘或提炼经验
+- 收到人工反馈或纠正时
+- 执行 `/autospec:field-evolve` 命令时
+
+## 安全底线
+
+- 绝不修改 `constitution.md`、`evolution.md`、核心设计原则
+- 绝不降低审查标准
+- 每条变更必须引用至少1条 practice-log
+- 同一组件每轮最多进化一次
+- field-evolve 的自动修复不修改冻结区文件

package/plugins/skills/exploration-phase/SKILL.md

@@ -0,0 +1,133 @@
+---
+name: exploration-phase
+description: "探索阶段模块 - 团队对齐与需求澄清。可被 run/autospec:explore 命令复用。支持动态轮次和友好对话。"
+parameters:
+  maxRounds: 6
+  earlyExit: true
+  taskDescription: ""
+---
+
+# Exploration Phase - 探索阶段
+
+你正在执行探索阶段，负责与创业团队对齐并完成需求澄清。
+
+## 前置参数
+
+- **maxRounds**: 最大探索轮次（默认6，由复杂度决定）
+- **earlyExit**: 是否允许用户提前终止（默认true）
+- **taskDescription**: 任务描述（可选，用于上下文）
+
+## 执行流程
+
+### Step 1: 复杂度评估
+
+**【强制】** 读取 `${KNOWLEDGE}/guides/support/complexity-assessor.md`，执行复杂度评估：
+
+- 简单任务（score <= 5）：2-3轮
+- 中等任务（score 6-8）：3-4轮
+- 复杂任务（score >= 9）：5-6轮
+
+### Step 2: 检查已有澄清记录
+
+读取 `.autospec/specs/{feature}/clarifications.md`：
+
+- **【重要】** 即使有详细的需求文档，也不代表澄清完成！
+- 需求文档是重要输入材料，澄清时要基于文档内容深入探讨，不能忽略文档中的信息
+- 必须通过多Agent对抗分析和多轮澄清来验证和补充需求文档
+- 只有当 clarifications.md 中有完整的「对抗分析结果」+「多轮问答记录」时，才算完成
+- 如不存在或不完整 → **必须**继续执行 Step 3 和 Step 4
+
+### Step 3: 多Agent对抗分析
+
+**【强制】【不可跳过】** 必须启动 2-3 个独立 Agent 并行分析，即使需求文档很详细：
+
+1. **Agent A - 乐观视角**：支持这个需求的理由、预期价值
+2. **Agent B - 质疑视角**：潜在问题、风险、伪需求可能性
+3. **Agent C（可选）- 技术视角**：技术可行性、实现难点
+
+**【强制】** 使用 Agent 工具启动独立 Agent，不要自己模拟分析。
+
+汇总对抗结果，形成「待确认问题清单」，记录到 clarifications.md
+
+### Step 4: 多轮澄清（动态轮次）
+
+**【强制交互】【不可跳过】** 必须使用 AskUserQuestion 工具与用户进行交互澄清。
+
+**【重要】** 即使需求文档很详细，也必须执行至少一轮澄清！
+
+根据 Step 1 确定的轮次上限，执行以下循环：
+
+```
+循环直到用户确认「足够」或达到 maxRounds：
+
+  1. 基于对抗分析结果，从待确认问题清单中选择问题（每轮最多5个）
+
+  2. 【强制】使用 AskUserQuestion 工具提问：
+     - 每个问题必须有明确的 header（分类）和 question
+     - 每个问题必须提供 options（推荐答案选项）
+     - 每个问题可以附 preview（预览内容）
+
+  3. 等待用户回复，记录回答到 clarifications.md
+
+  4. 【友好询问】使用 AskUserQuestion 询问：
+     「这个问题已经清楚了。是否进入下一轮深入探讨？
+      或者我们已经有足够信息开始分析了？」
+     选项：继续深入 / 已经足够
+
+  5. 用户响应处理：
+     - 用户选择「已经足够」或说「足够」「清楚了」「可以了」→ 提前终止，返回完成
+     - 用户选择「继续深入」或说「继续」「下一轮」→ 继续下一轮
+```
+
+**【禁止跳过】** 以下情况必须暂停并向用户确认：
+- 需求有歧义
+- 技术方案有多种选择
+- 涉及安全/性能/成本等关键决策
+- **即使需求文档很详细，也必须执行至少一轮澄清**
+- 用户明确说「足够」前不得跳过澄清环节
+
+**典型轮次主题**（根据任务调整）：
+
+- 第1轮：背景确认（解决什么问题）
+- 第2轮：价值确认（为什么重要）
+- 第3轮：边界确认（什么不做）
+- 第4轮：技术约束（如需要）
+- 第5轮：风险识别（如需要）
+- 第6轮：验收标准（如需要）
+
+### Step 5: 需求分析
+
+**【强制】** 读取 `${KNOWLEDGE}/guides/stages/requirement-analyzer.md`，生成结构化需求文档：
+
+1. 将3轮澄清结果融入需求文档
+2. 每个决策标注来源：用户确认/自动决策/待审阅
+3. 写入 `.autospec/specs/{feature}/requirement.md`
+
+### Step 6: Layer 1 验证
+
+- Schema校验：需求文档包含所有必须字段
+- 格式检查：每条需求有优先级和验收标准
+- 验证失败 → 修复后重试
+
+### Step 7: Layer 2 审查
+
+**【强制】** 调用 Agent 工具，使用 independent-reviewer：
+
+```
+prompt: 请审查以下需求文档。
+  1. 先读取审查标准: ${KNOWLEDGE}/guides/stages/requirement-reviewer.md
+  2. 被审查文档: .autospec/specs/{feature}/requirement.md
+  注意：你是独立审查者，只看产出物和标准
+```
+
+审查通过 → 探索阶段完成
+
+## 输出
+
+- `.autospec/specs/{feature}/clarifications.md` - 完整澄清记录
+- `.autospec/specs/{feature}/requirement.md` - 结构化需求文档
+- 状态：COMPLETED / IN_PROGRESS / EARLY_EXIT
+
+## 完成
+
+探索阶段完成 → 返回调用者，继续后续流程