@chongyan/autospec 1.0.2 → 1.0.4

package/plugins/skills/experiment-iteration/SKILL.md

@@ -1,154 +0,0 @@
----
-name: experiment-iteration
-description: "实验模式下的假设验证循环。提出假设→设计实验→收集数据→验证结论的迭代过程。"
-triggers:
-  - workflow: experiment
-parameters:
-  hypothesis: ""
-  experiments: []
-  currentPhase: design
----
-
-# Iteration Experiment - 实验迭代执行
-
-## 概述
-
-实验模式的核心是**假设驱动**的验证循环。与瀑布模式的完整流程和敏捷模式的故事驱动不同，实验模式通过提出假设→设计实验→收集数据→验证结论的迭代过程来探索最佳解决方案。
-
-## 输入
-
-- `hypothesis`: 待验证的假设
-- `experiments`: 实验列表
-- `currentPhase`: 当前实验阶段
-
-## 执行流程
-
-### Step 1: 假设定义
-
-```
-1. 明确问题：
-   - 背景描述
-   - 当前痛点
-   - 期望效果
-
-2. 提出假设：
-   - 假设内容（可验证）
-   - 假设前提
-   - 预期结果
-
-3. 定义成功标准：
-   - 量化指标
-   - 阈值定义
-   - 验证方法
-```
-
-### Step 2: 实验设计
-
-```
-1. 设计实验方案：
-   - 实验组 vs 对照组
-   - 变量控制
-   - 数据采集方法
-
-2. 确定实验规模：
-   - 样本数量
-   - 实验时长
-   - 资源需求
-
-3. 准备实验环境：
-   - 隔离环境
-   - 数据准备
-   - 监控配置
-```
-
-### Step 3: 实验执行
-
-```
-1. 运行实验：
-   - 记录实验过程
-   - 采集实验数据
-   - 监控关键指标
-
-2. 数据收集：
-   - 定量数据
-   - 定性反馈
-   - 异常记录
-
-3. 数据清洗：
-   - 去除异常值
-   - 数据标准化
-   - 初步分析
-```
-
-### Step 4: 结果验证
-
-```
-1. 统计分析：
-   - 显著性检验
-   - 置信区间
-   - 效果量计算
-
-2. 结论判断：
-   - 假设成立 → 沉淀为最佳实践
-   - 假设不成立 → 记录经验教训
-   - 需更多数据 → 设计新实验
-
-3. 产出实验报告：
-   - 实验过程
-   - 数据分析
-   - 结论建议
-```
-
-### Step 5: 迭代优化
-
-```
-基于实验结论：
-1. 假设优化：
-   - 调整假设前提
-   - 缩小验证范围
-
-2. 实验迭代：
-   - 设计新实验
-   - 继续验证
-
-3. 知识沉淀：
-   - 记录实验结论
-   - 更新最佳实践
-   - 分享经验
-```
-
-## 实验类型
-
-| 类型 | 说明 | 适用场景 |
-|------|------|---------|
-| A/B测试 | 对比两个版本的效果 | 功能优化、UI改进 |
-| 灰度发布 | 渐进式发布验证 | 新功能上线 |
-| 特性开关 | 动态控制功能开关 | 功能灰度 |
-| 埋点验证 | 通过数据分析验证假设 | 用户行为分析 |
-| 性能基准 | 性能指标对比 | 性能优化 |
-
-## 验证标准
-
-| 指标 | 说明 | 判断标准 |
-|------|------|---------|
-| 统计显著性 | p值 < 0.05 | 假设可信 |
-| 效果量 | 变化幅度 | 业务意义 |
-| 样本量 | 足够的数据量 | 结论可靠 |
-| 可重复性 | 多次实验结果一致 | 结论稳定 |
-
-## 与其他迭代模式的区别
-
-| 模式 | 驱动方式 | 适用场景 |
-|------|---------|---------|
-| waterfall-iteration | 阶段驱动 | 需求稳定、项目明确 |
-| agile-iteration | 故事驱动 | 需求变化、增量交付 |
-| hotfix-iteration | 问题驱动 | 紧急修复、快速响应 |
-| experiment-iteration | 假设驱动 | 探索性验证、A/B测试 |
-
-## 注意事项
-
-1. **假设可验证**：假设必须是可量化、可验证的
-2. **控制变量**：实验组和对照组需要控制变量
-3. **数据质量**：确保数据采集的准确性和完整性
-4. **统计严谨**：使用正确的统计方法，避免误导性结论
-5. **快速迭代**：小步快跑，快速验证假设

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

@@ -1,216 +0,0 @@
----
-name: exploration-phase
-description: "探索阶段模块 - 团队对齐与需求澄清。可被 run/autospec:explore 命令复用。支持动态轮次和友好对话。"
-parameters:
-  maxRounds: 6
-  earlyExit: true
-  taskDescription: ""
----
-
-# Exploration Phase - 探索阶段
-
-你正在执行探索阶段，负责与创业团队对齐并完成需求澄清。
-
-## ⚠️ 执行约束（强制）
-
-**【阻塞检查】** 在开始执行前，必须确认以下条件：
-
-```
-□ 已读取复杂度评估指南（24-assess-complexity.md）
-□ 已确定参与角色列表（根据复杂度）
-□ 已准备启动多 Agent 对抗分析
-□ 已准备使用 AskUserQuestion 进行澄清
-```
-
-**【跳过检测】** 以下行为将被检测并阻止：
-
-| 行为 | 检测方式 | 处理 |
-|------|----------|------|
-| 直接生成 requirement.md | 检查 clarifications.md 是否存在 | 阻止，返回执行 Step 3-4 |
-| 使用单个 Agent 模拟对抗 | 检查 Agent 调用记录 | 阻止，要求并行启动多 Agent |
-| 不使用 AskUserQuestion 澄清 | 检查问答记录 | 阻止，要求执行 Step 4 |
-| 跳过复杂度评估 | 检查评估记录 | 阻止，要求执行 Step 1 |
-
-**【强制流程】** 必须按顺序完成以下步骤，不可跳过：
-
-```
-Step 1 → Step 2 → Step 3 → Step 4 → Step 5 → Step 6 → Step 7
-         ↓
-    【强制】Step 3 和 Step 4 必须完成
-    【禁止】直接跳到 Step 5 生成需求文档
-```
-
-## 前置参数
-
-- **maxRounds**: 最大探索轮次（默认6，由复杂度决定）
-- **earlyExit**: 是否允许用户提前终止（默认true）
-- **taskDescription**: 任务描述（可选，用于上下文）
-
-## 执行流程
-
-### Step 1: 复杂度评估
-
-**【强制】** 读取 `${KNOWLEDGE}/03-guides/24-assess-complexity.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 模拟团队对抗
-- 自己模拟分析而不调用 Agent 工具
-- 跳过对抗分析直接进入需求分析
-
-#### 复杂度评估（继承 Step 1 结果）
-
-- **简单任务（score <= 5）**：CEO + 产品负责人
-- **中等任务（score 6-8）**：CEO + 产品负责人 + 技术负责人
-- **复杂任务（score >= 9）**：CEO + 产品负责人 + 技术负责人 + 相关工程师（如触发条件）
-
-#### 团队对抗执行
-
-**【强制】** 读取 `${KNOWLEDGE}/03-guides/01-team-orchestrator.md`，并行启动团队智能体：
-
-1. **CEO Agent**：战略一致性、商业价值、风险把控
-2. **产品负责人 Agent**：用户价值、产品方向、MVP范围
-3. **技术负责人 Agent**：技术可行性、技术风险（如中等及以上）
-4. **相关工程师 Agent**：实现可行性（如复杂任务且有特定子系统）
-
-**【强制】** 使用 Agent 工具启动独立 Agent（信息隔离，做审分离），不要自己模拟分析。
-
-**【执行验证】** 完成后必须记录：
-```
-对抗分析记录：
-- 参与角色：[CEO, 产品负责人, 技术负责人, ...]
-- 各角色意见汇总：...
-- 分歧点：...
-- 待确认问题清单：...
-```
-
-汇总团队对抗结果，形成「待确认问题清单」，记录到 clarifications.md
-
-### Step 4: 多轮澄清（动态轮次）
-
-**【强制交互】【不可跳过】** 必须使用 AskUserQuestion 工具与用户进行交互澄清。
-
-**【禁止】** 以下行为将被阻止：
-- 不使用 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 4.5: 阶段完成验证（阻塞检查）
-
-**【强制】【不可跳过】** 在生成 requirement.md 之前，必须验证以下条件：
-
-```
-验证清单：
-□ clarifications.md 文件存在
-□ clarifications.md 包含「对抗分析结果」章节
-□ clarifications.md 包含「多轮问答记录」章节
-□ 至少执行了一轮 AskUserQuestion 澄清
-□ 复杂度评估结果已记录
-```
-
-**验证失败处理**：
-
-| 缺失项 | 处理方式 |
-|--------|----------|
-| clarifications.md 不存在 | 返回 Step 3 执行对抗分析 |
-| 缺少对抗分析结果 | 返回 Step 3 补充对抗分析 |
-| 缺少问答记录 | 返回 Step 4 执行澄清 |
-| 未执行澄清 | 返回 Step 4 执行澄清 |
-
-**【禁止】** 验证未通过时，禁止进入 Step 5 生成需求文档。
-
-### Step 5: 需求分析
-
-**【强制】** 读取 `${KNOWLEDGE}/03-guides/02-analyze-requirement.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}/03-guides/09-review-requirement.md
-  2. 被审查文档: .autospec/specs/{feature}/requirement.md
-  注意：你是独立审查者，只看产出物和标准
-```
-
-审查通过 → 探索阶段完成
-
-## 输出
-
-- `.autospec/specs/{feature}/clarifications.md` - 完整澄清记录
-- `.autospec/specs/{feature}/requirement.md` - 结构化需求文档
-- 状态：COMPLETED / IN_PROGRESS / EARLY_EXIT
-
-## 完成
-
-探索阶段完成 → 返回调用者，继续后续流程

package/plugins/skills/field-evolve-analyzer/SKILL.md

@@ -1,65 +0,0 @@
----
-name: field-evolve-analyzer
-description: "分析实战项目问题，识别根因和模式"
-type: analyzer
----
-
-# Field-Evolve Analyzer
-
-## 定位
-
-分析实战项目问题，识别根因和共性模式，为技能蒸馏提供输入。
-
-## 输入
-
-- 扫描结果（来自 scanner）
-- 项目上下文
-
-## 输出
-
-- 问题分析报告
-- 根因分析
-- 模式识别
-
-## 执行步骤
-
-### Step 1: 问题分析
-
-```
-分析问题：
-1. 分类问题类型
-2. 评估影响范围
-3. 确定严重程度
-```
-
-### Step 2: 根因分析
-
-```
-分析根因：
-1. 定位问题位置
-2. 分析问题原因
-3. 评估影响范围
-```
-
-### Step 3: 模式识别
-
-```
-识别模式：
-1. 从多个项目中识别共性问题
-2. 提取可复用的解决方案
-3. 生成模式报告
-```
-
-## 使用示例
-
-```
-# 执行分析
-读取 plugins/skills/field-evolve-analyzer/SKILL.md 并执行
-```
-
-## 与其他技能的区别
-
-| 技能 | 侧重点 |
-|------|--------|
-| project-evolve-analyzer | 单个项目问题分析 |
-| **field-evolve-analyzer** | 多项目模式分析，提炼共性 |

package/plugins/skills/field-evolve-distiller/SKILL.md

@@ -1,66 +0,0 @@
----
-name: field-evolve-distiller
-description: "从实战项目中提炼技能，更新框架能力"
-type: distiller
----
-
-# Field-Evolve Distiller
-
-## 定位
-
-从实战项目中提炼技能，将项目级经验提升为框架级能力。
-
-## 输入
-
-- 项目执行记录
-- 问题分析结果
-- 修复方案
-
-## 输出
-
-- 新技能定义
-- 更新的技能模板
-- 框架改进建议
-
-## 执行步骤
-
-### Step 1: 经验提取
-
-```
-提取经验：
-1. 分析项目执行过程
-2. 识别可复用的解决方案
-3. 提取通用模式
-```
-
-### Step 2: 技能提炼
-
-```
-提炼技能：
-1. 将解决方案封装为技能
-2. 定义技能输入输出
-3. 编写技能文档
-```
-
-### Step 3: 框架更新
-
-```
-更新框架：
-1. 生成技能定义
-2. 更新技能模板
-3. 提出框架改进建议
-```
-
-## 使用示例
-
-```
-# 执行蒸馏
-读取 plugins/skills/field-evolve-distiller/SKILL.md 并执行
-```
-
-## 与其他技能的区别
-
-| 技能 | 侧重点 |
-|------|--------|
-| self-evolve-generalizer | 框架级经验泛化 |
-| **field-evolve-distiller** | 项目级经验提炼为框架级技能 |

package/plugins/skills/field-evolve-executor/SKILL.md

@@ -1,94 +0,0 @@
----
-name: field-evolve-executor
-description: "执行项目级 benchmark，评估实战项目的开发能力"
-type: executor
----
-
-# Field-Evolve Executor
-
-## 定位
-
-执行 `.autospec/benchmarks/` 中的项目级 benchmark，评估实战项目的开发能力。
-
-## 输入
-
-- `--benchmark <name>` - benchmark 名称（必需）
-- `--keep` - 保留临时目录用于调试
-- `--stage <name>` - 仅执行指定阶段
-
-## 输出
-
-- 执行报告：`.autospec/logs/field-evolve/execution-{benchmark}-{timestamp}.md`
-- 过程指标：`.autospec/logs/field-evolve/metrics-{benchmark}-{timestamp}.json`
-
-## 执行步骤
-
-### Step 1: 加载 Benchmark
-
-```
-1. 读取 .autospec/benchmarks/{name}.yaml
-2. 解析 benchmark 配置
-3. 验证配置完整性
-```
-
-### Step 2: 创建隔离环境
-
-```
-1. 创建 /tmp/autospec-field-benchmark-{id}/ 目录
-2. 初始化项目结构
-3. 复制 benchmark 配置
-```
-
-### Step 3: 执行 Pipeline
-
-```
-1. 按顺序执行各阶段：
-   - exploration
-   - requirement
-   - design
-   - implementation
-   - testing
-   - delivery
-
-2. 捕获每个阶段的指标：
-   - Layer1/Layer2 通过率
-   - 执行耗时
-   - 产出物完整性
-```
-
-### Step 4: 生成报告
-
-```
-1. 生成 Markdown 执行报告
-2. 生成 JSON 过程指标
-3. 保存到 .autospec/logs/field-evolve/
-```
-
-### Step 5: 清理
-
-```
-1. 如未指定 --keep，删除临时目录
-2. 如指定 --keep，保留目录用于调试
-```
-
-## 使用示例
-
-```bash
-# 执行 benchmark
-node plugins/skills/field-evolve-executor/executor.js --benchmark my-project
-
-# 保留临时目录
-node plugins/skills/field-evolve-executor/executor.js --benchmark my-project --keep
-
-# 仅执行 requirement 阶段
-node plugins/skills/field-evolve-executor/executor.js --benchmark my-project --stage requirement
-```
-
-## 与 self-evolve-executor 的区别
-
-| 特性 | self-evolve-executor | field-evolve-executor |
-|------|---------------------|----------------------|
-| 目标 | 框架自我测试 | 评估实战项目 |
-| Benchmark 位置 | `.claude/benchmarks/pipeline/` | `.autospec/benchmarks/` |
-| 输出目录 | `.autospec/logs/self-evolve/` | `.autospec/logs/field-evolve/` |
-| 临时目录前缀 | `autospec-benchmark-` | `autospec-field-benchmark-` |