@chongyan/autospec 1.0.2 → 1.0.4

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

@@ -1,307 +0,0 @@
----
-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）
-
-你正在执行方案设计阶段。此阶段将需求文档转化为可指导编码的技术方案。
-
-## ⚠️ 执行约束（强制）
-
-**【阻塞检查】** 在开始执行前，必须确认以下条件：
-
-```
-□ 上游需求分析阶段已完成（检查 state.json）
-□ requirement.md 文件存在且完整
-□ 已读取复杂度评估结果或重新评估
-□ 已确定参与角色列表
-```
-
-**【跳过检测】** 以下行为将被检测并阻止：
-
-| 行为 | 检测方式 | 处理 |
-|------|----------|------|
-| 直接生成 design.md | 检查上游阶段状态 | 阻止，返回执行需求分析 |
-| 跳过团队对抗审查 | 检查 Agent 调用记录 | 阻止，要求启动多 Agent 审查 |
-| 跳过一致性检查 | 检查 consistency-checker 调用 | 阻止，要求执行一致性检查 |
-| 跳过 Layer1/Layer2 验证 | 检查验证记录 | 阻止，要求执行验证 |
-
-**【强制流程】** 必须按顺序完成以下步骤，不可跳过：
-
-```
-Step 1 → Step 2 → Step 3/4 → 阶段完成验证 → Layer1 → Layer2 → 阶段门禁
-         ↓
-    【强制】Step 2 团队对抗审查必须完成
-    【禁止】直接跳到 Step 3 生成设计文档
-```
-
-## 前置检查
-
-1. 确认需求分析阶段已完成（检查 `.autospec/runtime/state.json`）
-2. 读取 `knowledge/01-principles/09-constitution.md` → 确认红线
-3. 读取上游精炼契约（需求文档）
-4. **检查是否为多系统项目**：读取 `.autospec/runtime/config.json` 的 `subsystems` 字段
-5. **检查是否需要效果指标设计**：检查是否有 ai 类型子系统或需求文档包含效果指标
-6. 加载创业团队角色画像：读取 `.claude/agents/roles/` 目录下的角色文件
-7. 加载方法论原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 注入 P7(class先于instance)、P8(抽象力度控制)、P3(系统六要素) 等设计原则
-8. 加载设计哲学：读取 `${KNOWLEDGE}/principles/01-first-principles.md` → 注入 DP15(Brownfield适配)、DP16(模板即约束) 原则
-9. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 本阶段重点应用 CP4(逻辑链完整)、CP9(刚好够用)、CP5(置信度标注)
-
-## 阶段检查点（本阶段必须完成）
-
-执行过程中请持续对照以下检查点，确保不遗漏：
-
-**说明**：
-- **检查点表**：快速验证产出是否存在/完成
-- **检查清单（checklists/）**：详细验证产出质量是否达标
-- 通过"检查清单核对完成"一项覆盖所有质量检查，避免重复
-
-| 类别 | 检查项 | 必须完成 | 验证方式 |
-|-----|-------|---------|---------|
-| 流程 | 复杂度评估/继承完成 | ✅ | 检查是否已有复杂度分数和角色列表 |
-| 流程 | 动态团队组建完成 | ✅ | 检查是否已根据复杂度确定参与角色 |
-| 做类 | 设计执行Agent加载完成 | ✅ | 已加载 design-planner skill 或并行设计Agent |
-| 做类 | 设计执行Agent正确执行 | ✅ | 已执行架构/API/数据模型设计任务并产出结果 |
-| 做类 | 设计结果汇总完成 | ✅ | 各Agent产出已汇总到 design.md |
-| 流程 | 团队对抗审查执行（审类） | ✅ | 检查是否已调用 team-orchestrator 并汇总审查报告 |
-| 流程 | consistency-checker Agent 调用 | ✅ | 设计-需求一致性检查 |
-| 流程 | independent-reviewer Agent 调用 | ✅ | Layer 2 审查必须调用 |
-| 产出 | 检查清单核对完成 | ✅ | 已按 01-design.md 逐项核对并记录（质量检查） |
-| 产出 | design.md 生成 | ✅ | 文件存在于 .autospec/specs/{feature}/ |
-| 流程 | Benchmark 评测通过 | ✅ | DES-001~004 全部通过 |
-
-**阶段完成前自检**：
-- [ ] 已完成复杂度评估或继承（Step 1）
-- [ ] 已组建动态团队（根据复杂度确定角色）
-- [ ] 已加载设计执行Agent（design-planner skill 或并行设计Agent）
-- [ ] 已执行设计任务（架构设计/API设计/数据模型设计）
-- [ ] 设计结果已汇总到 design.md
-- [ ] 已执行团队对抗审查（Step 2，调用 team-orchestrator）
-- [ ] 已按检查清单（01-design.md）逐项核对（质量检查）
-- [ ] 已调用 consistency-checker（设计-需求一致性）
-- [ ] 已调用 independent-reviewer（Layer 2）
-- [ ] design.md 已生成（Step 3/4）
-- [ ] Benchmark 评测已通过（Layer 3）
-
-## 认知姿态（本阶段：发散→收敛 + 防过度设计）
-
-- **CP4 逻辑链完整**：每个技术选型必须说明"选了什么 + 为什么 + 放弃了什么"。关键决策记录不可跳步
-- **CP9 刚好够用**：抵制过度设计。添加架构层次前自问：这是必须的吗？更简单的方案能不能满足需求？
-- **CP5 置信度**：对不确定的设计决策，标注置信度。技术选型的风险评估要诚实标注不确定性
-
-## 执行
-
-### Step 1: 确定模式与复杂度
-
-读取 `.autospec/runtime/config.json`，检查 `subsystems` 字段：
-- **无 subsystems 或长度为1** → 单系统模式
-- **有 subsystems 且长度>1** → 多系统模式
-
-**继承或重新评估复杂度**：
-- 如果需求阶段已有复杂度评估，继承结果
-- 如有新的技术复杂度因素，重新评估
-
-**【强制】** 读取 `${KNOWLEDGE}/05-config/01-team-stage.yaml`，检查强制触发规则（mandatoryTriggers）：
-- 涉及新架构/框架 → 强制引入 tech-lead
-- 跨系统变更 → 强制引入 tech-lead + devops-engineer
-- 新服务部署 → 强制引入 devops-engineer
-
-### Step 2: 创业团队对抗设计审查
-
-根据复杂度评估结果，启动团队对抗审查：
-
-#### 简单任务（score <= 5）
-快速通道，仅技术负责人审查：
-- 技术负责人：架构合理性、过度设计检查
-
-#### 中等任务（score 6-8）
-引入工程师视角：
-- 技术负责人 + 相关工程师（根据涉及的子系统类型）
-
-#### 复杂任务（score >= 9）
-引入完整团队：
-- 技术负责人 + 全部相关工程师
-- 如触发强制规则，额外引入安全工程师/运维工程师
-
-**对抗审查执行方式**：
-
-**自主模式 — 多Agent并行对抗**：
-```
-**【强制】** 读取 `${KNOWLEDGE}/03-guides/01-team-orchestrator.md`
-并行启动角色Agent（信息隔离，做审分离）：
-  - 技术负责人 Agent：架构合理性、技术选型、过度设计检查
-  - 后端工程师 Agent：API设计、数据库设计、性能（如涉及）
-  - 前端工程师 Agent：组件设计、状态管理、用户体验（如涉及）
-  - 数据工程师 Agent：数据模型、ETL设计（如涉及）
-  - AI工程师 Agent：模型选型、评估方案（如涉及）
-  - 安全工程师 Agent：安全设计（如触发）
-  - 运维工程师 Agent：部署方案、监控设计（如触发）
-汇总意见，生成团队对抗审查报告
-```
-
-**交互模式 — 与用户互动完成**：
-将团队各角色的关注点作为确认框架，与用户交互：
-1. **技术负责人视角**：架构方案、技术选型理由、关键决策
-2. **工程师视角**：实现可行性、技术风险
-3. **安全视角**（如触发）：安全方案、数据保护
-4. **运维视角**（如触发）：部署方案、监控告警
-
-### Step 2.5: 阶段完成验证（阻塞检查）
-
-**【强制】【不可跳过】** 在生成 design.md 之前，必须验证以下条件：
-
-```
-验证清单：
-□ 上游需求文档存在（requirement.md）
-□ 团队对抗审查已执行（有审查记录）
-□ 待确认问题已处理或记录
-□ 复杂度评估结果已记录
-```
-
-**验证失败处理**：
-
-| 缺失项 | 处理方式 |
-|--------|----------|
-| 需求文档不存在 | 返回需求分析阶段 |
-| 未执行团队对抗审查 | 返回 Step 2 执行审查 |
-| 待确认问题未处理 | 使用 AskUserQuestion 澄清 |
-
-**【禁止】** 验证未通过时，禁止进入 Step 3 生成设计文档。
-
-### Step 3: 单系统模式设计
-
-1. **【强制】** 加载做类skill：读取 `${KNOWLEDGE}/03-guides/03-design-solution.md` → **按步骤执行**
-   - 设计执行Agent正确加载和执行
-   - 检查Agent产出是否符合预期
-2. **【强制】** 加载检查清单并核对：读取 `${KNOWLEDGE}/04-checklists/01-design.md`
-   - 在设计过程中逐项核对
-   - 设计完成后记录检查结果到设计文档末尾或检查记录表
-3. 加载元学习方法：读取 `${KNOWLEDGE}/principles/02-methodology-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}/03-guides/10-review-design.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/04-checklists/01-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/experiment-evaluator/SKILL.md

@@ -1,271 +0,0 @@
----
-name: experiment-evaluator
-description: "实验模式的效果评测阶段。执行评测数据集，产出评测报告，判定假设是否成立。"
-triggers:
-  - workflow: experiment
-  - stage: EVAL
-parameters:
-  maxIterations: 10
-  currentIteration: 1
-  complexityLevel: medium
----
-
-# Experiment Evaluator - 实验评测
-
-## 概述
-
-实验模式的效果评测阶段是实验验证的关键环节。在原型实现完成后，自动触发效果评测，验证假设是否成立。
-
-## 输入
-
-- `specs/{feature}/evaluation-plan.md`: 评测方案
-- `specs/{feature}/assumptions.md`: 假设清单
-- `specs/{feature}/evaluation/dataset/`: 评测数据集
-- 原型代码
-
-## 执行流程
-
-### Step 1: 确定迭代次数上限
-
-根据实验复杂度确定最大迭代次数：
-
-| 复杂度 | 判断标准 | 最大迭代次数 |
-|--------|---------|-------------|
-| 简单 | 单模型单指标 | 3次 |
-| 中等 | 多模型或多指标 | 5次 |
-| 复杂 | 多模型多指标+数据管道 | 10次 |
-
-### Step 2: 加载评测方案
-
-读取 `specs/{feature}/evaluation-plan.md`：
-- 评测指标定义
-- 目标阈值
-- 评测方法
-- 数据集路径
-
-**评测方案格式**：
-```markdown
-# 评测方案
-
-## 评测指标
-
-| 指标名称 | 目标值 | 权重 |
-|---------|-------|------|
-| 准确率 | >= 85% | 0.4 |
-| 召回率 | >= 80% | 0.3 |
-| F1分数 | >= 82% | 0.3 |
-
-## 评测数据集
-
-- 训练集: `data/train.json`
-- 验证集: `data/valid.json`
-- 测试集: `data/test.json`
-
-## 评测方法
-
-1. 加载模型
-2. 执行推理
-3. 计算指标
-4. 生成报告
-```
-
-### Step 3: 执行评测
-
-调用评测脚本：
-
-```bash
-# 执行评测
-python evaluation/evaluator.py \
-  --model-path {model_path} \
-  --test-data {test_data} \
-  --output {output_path}
-```
-
-评测过程：
-1. 加载评测数据集
-2. 执行模型推理
-3. 计算评测指标
-4. 与目标阈值对比
-
-### Step 4: 产出评测报告
-
-写入 `specs/{feature}/evaluation-report.md`：
-
-```markdown
-# 评测报告
-
-## 评测结果
-
-| 指标名称 | 目标值 | 实际值 | 是否达标 |
-|---------|-------|-------|---------|
-| 准确率 | >= 85% | 87.2% | ✅ |
-| 召回率 | >= 80% | 78.5% | ❌ |
-| F1分数 | >= 82% | 82.8% | ✅ |
-
-## 综合评分
-
-- 达标指标: 2/3
-- 综合得分: 82.8%
-- 结论: 未完全达标
-
-## Badcase 分析
-
-### 失败案例1
-- 输入: ...
-- 预期输出: ...
-- 实际输出: ...
-- 分析: ...
-
-## 改进建议
-
-1. 增加训练数据
-2. 调整模型参数
-3. 优化特征工程
-```
-
-### Step 5: 假设判定
-
-```
-判定逻辑：
-
-if 所有指标达标:
-  return 'HYPOTHESIS_CONFIRMED'
-  → 假设成立，进入简化交付
-
-elif currentIteration < maxIterations:
-  # 分析未达标原因
-  analyze_failure_cases()
-
-  # 提出改进方向
-  suggest_improvements()
-
-  return 'HYPOTHESIS_NEEDS_ITERATION'
-  → 返回设计阶段迭代
-
-else:
-  return 'HYPOTHESIS_REJECTED'
-  → 输出失败报告，建议终止或调整方向
-```
-
-### Step 6: 迭代决策
-
-当需要迭代时：
-
-1. **分析失败原因**：
-   - 数据不足
-   - 模型选择不当
-   - 特征工程问题
-   - 超参数需要调整
-
-2. **提出改进方向**：
-   - 增加数据量
-   - 尝试其他模型
-   - 优化特征
-   - 调整超参数
-
-3. **更新假设置信度**：
-   - 降低置信度
-   - 记录迭代历史
-
-4. **返回设计阶段**：
-   - 更新设计文档
-   - 调整实现方案
-
-## 输出
-
-- `specs/{feature}/evaluation-report.md` - 评测报告
-- `specs/{feature}/assumptions.md` - 更新后的假设状态
-- 假设判定结论
-
-## 假设验证协议
-
-### 假设格式
-
-每个假设记录在 `assumptions.md`：
-
-```markdown
-## H-{id}: {假设描述}
-
-- **类型**: 技术可行性 / 用户价值 / 性能假设
-- **验证方式**: 效果评测 / A/B测试 / 用户访谈
-- **成功标准**: {可量化的指标}
-- **当前状态**: 待验证 / 验证中 / 已确认 / 已否定
-- **验证轮次**: {n}/{maxIterations}
-- **证据**: []
-```
-
-### 状态流转
-
-```
-待验证 → 验证中 → 已确认
-                  ↘ 已否定
-```
-
-### 验证循环
-
-```
-for iteration in 1..maxIterations:
-
-  # 执行评测
-  run_evaluation()
-
-  # 判定假设
-  result = judge_hypothesis()
-
-  match result:
-    case CONFIRMED:
-      假设成立，进入交付
-      break
-
-    case NEEDS_ITERATION:
-      分析失败原因
-      提出改进方案
-      更新假设置信度
-      continue
-
-    case REJECTED:
-      假设不成立
-      建议终止或调整方向
-      break
-```
-
-## 复杂度自适应机制
-
-### 复杂度评估
-
-```
-评估实验复杂度：
-
-简单：
-- 单一模型
-- 单一评测指标
-- 数据量 < 1000条
-
-中等：
-- 多个模型对比
-- 多个评测指标
-- 数据量 1000-10000条
-
-复杂：
-- 多模型多指标
-- 需要数据管道
-- 数据量 > 10000条
-- 涉及在线评测
-```
-
-### 迭代次数调整
-
-根据复杂度自动调整：
-- 简单：3次迭代上限
-- 中等：5次迭代上限
-- 复杂：10次迭代上限
-
-用户也可手动指定迭代次数上限。
-
-## 注意事项
-
-1. **评测数据集**：必须与训练数据分离，避免数据泄露
-2. **指标选择**：选择与业务目标相关的指标
-3. **阈值设定**：阈值应该有业务意义，而非随意设定
-4. **迭代成本**：每次迭代都有成本，避免无限迭代
-5. **失败处理**：实验失败是正常的，重要的是从中学习