@chongyan/autospec 1.0.2 → 1.0.4

package/plugins/skills/project-evolve-verifier/SKILL.md

@@ -1,105 +0,0 @@
----
-name: project-evolve-verifier
-description: "效果验证：验证修复效果，检测退化，计算质量分数变化"
-type: verifier
----
-
-# Project-Evolve Verifier
-
-## 定位
-
-效果验证技能，验证修复效果，检测退化，计算质量分数变化。
-
-## 输入
-
-- 修复记录（来自 fixer）
-- 修复前基线指标
-
-## 输出
-
-- 验证结果：通过/失败
-- 退化检测：是否发生退化
-- 质量分数：修复前后对比
-
-## 执行步骤
-
-### Step 1: 基线对比
-
-```
-记录修复前：
-1. 代码复杂度
-2. 测试覆盖率
-3. 构建时间
-4. 代码行数
-```
-
-### Step 2: 修复验证
-
-```
-验证每个修复：
-1. 运行测试
-2. 检查构建
-3. 验证功能
-4. 记录结果
-```
-
-### Step 3: 退化检测
-
-```
-检测退化：
-1. 对比修复前后指标
-2. 检查测试是否通过
-3. 验证性能影响
-4. 标记异常
-```
-
-### Step 4: 回滚处理
-
-```
-如检测到退化：
-1. 自动回滚修复
-2. 记录退化原因
-3. 生成警告报告
-4. 标记需人工处理
-```
-
-### Step 5: 质量评分
-
-```
-计算质量分数：
-1. 综合评分
-2. 各维度评分
-3. 分数变化
-4. 趋势分析
-```
-
-## 使用示例
-
-```
-# 执行效果验证
-读取 plugins/skills/project-evolve-verifier/SKILL.md 并执行
-
-# 输出
-- 验证项: 15
-- 通过: 14
-- 失败: 1
-- 退化: 无
-- 质量分数: +5 (70→75)
-```
-
-## 验证维度
-
-| 维度 | 验证内容 | 方法 |
-|------|----------|------|
-| 功能验证 | 代码功能正常 | 运行测试 |
-| 质量验证 | 复杂度降低 | 静态分析 |
-| 性能验证 | 运行无退化 | 性能测试 |
-| 集成验证 | 构建成功 | CI 检查 |
-
-## 与 self-evolve-verifier 的区别
-
-| 特性 | self-evolve-verifier | project-evolve-verifier |
-|------|----------------------|------------------------|
-| 目标 | 验证框架修复 | 验证项目修复 |
-| 验证对象 | 框架代码 | 用户项目 |
-| 回滚机制 | 自动回滚 | 自动回滚 |

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

@@ -1,217 +0,0 @@
----
-name: requirement-stage
-description: "When requirement analysis, user story writing, feature scoping, or PRD creation is needed — loads AutoSpec requirement analysis process and skill."
----
-
-# AutoSpec 需求分析（Stage 01）
-
-你正在执行需求分析阶段。此阶段将原始需求转化为结构化需求文档。
-
-## 前置检查
-
-1. 确认启动门禁已通过（`.autospec/runtime/state.json` 存在）
-2. 读取 `knowledge/01-principles/09-constitution.md` → 确认红线
-3. 加载创业团队角色画像：读取 `.claude/agents/roles/` 目录下的角色文件
-4. 加载方法论原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 注入 P1(问题定义先行)、P2(价值驱动)、P31(目标设定三原则) 等通用原则意识
-5. 加载设计哲学：读取 `${KNOWLEDGE}/principles/01-first-principles.md` → 注入 DP17(结构化澄清) 和 DP16(模板即约束) 原则
-6. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 本阶段重点应用 CP1(合伙人模式)、CP3(先问后做)、CP5(置信度标注)
-
-## 阶段检查点（本阶段必须完成）
-
-执行过程中请持续对照以下检查点，确保不遗漏：
-
-**说明**：
-- **检查点表**：快速验证产出是否存在/完成
-- **检查清单（checklists/）**：详细验证产出质量是否达标
-- 通过"检查清单核对完成"一项覆盖所有质量检查，避免重复
-
-| 类别 | 检查项 | 必须完成 | 验证方式 |
-|-----|-------|---------|---------|
-| 流程 | 复杂度评估完成 | ✅ | 检查是否已输出复杂度分数和角色列表 |
-| 流程 | 动态团队组建完成 | ✅ | 检查是否已根据复杂度确定参与角色 |
-| 做类 | 需求分析Agent加载完成 | ✅ | 已加载 analyze-requirement skill |
-| 做类 | 需求分析Agent正确执行 | ✅ | 已执行需求分析任务（背景/用例/功能点）并产出结果 |
-| 做类 | 需求文档生成完成 | ✅ | 各Agent产出已汇总到 requirement.md |
-| 流程 | 团队对抗审查执行（审类） | ✅ | 检查是否已调用 team-orchestrator 并汇总审查报告 |
-| 流程 | independent-reviewer Agent 调用 | ✅ | Layer 2 审查必须调用 |
-| 产出 | 检查清单核对完成 | ✅ | 已按 00-requirement.md 逐项核对并记录（质量检查） |
-| 产出 | requirement.md 生成 | ✅ | 文件存在于 .autospec/specs/{feature}/ |
-| 流程 | Benchmark 评测通过 | ✅ | REQ-001~003 全部通过 |
-
-**阶段完成前自检**：
-- [ ] 已完成复杂度评估（Step 1）
-- [ ] 已组建动态团队（根据复杂度确定角色）
-- [ ] 已加载需求分析Agent（analyze-requirement skill）
-- [ ] 已执行需求分析任务（背景/用例/功能点）
-- [ ] 需求文档已汇总到 requirement.md
-- [ ] 已执行团队对抗审查（Step 2，调用 team-orchestrator）
-- [ ] 已按检查清单（00-requirement.md）逐项核对（质量检查）
-- [ ] 已调用 independent-reviewer（Layer 2）
-- [ ] requirement.md 已生成（Step 4）
-- [ ] Benchmark 评测已通过（Layer 3）
-
-## 认知姿态（本阶段：发散 + 挑战）
-
-- **CP1 合伙人模式**：你有权挑战用户的需求假设。如果发现需求可能是伪需求或方向有误，必须指出
-- **CP3 先问后做**：需求天然存在不确定性。识别歧义后，先列出选项和推荐，再继续分析
-- **CP5 置信度**：对不确定的需求推断，标注"高/中/低置信度"，低置信度的标记为 NEEDS CLARIFICATION
-
-## 执行
-
-### Step 1: 复杂度评估与团队组建
-
-在进入具体需求分析前，先评估任务复杂度，确定参与角色：
-
-**【强制】** 读取 `${KNOWLEDGE}/03-guides/24-assess-complexity.md`，执行复杂度评估：
-- 评估维度：需求复杂度、技术复杂度、数据敏感度、业务复杂度
-- 输出：复杂度分数、级别（simple/medium/complex）、需要的角色列表
-
-**【强制】** 读取 `${KNOWLEDGE}/05-config/01-team-stage.yaml`，检查强制触发规则（mandatoryTriggers）：
-- 涉及用户数据 → 强制引入 security-engineer
-- 涉及支付/金融 → 强制引入 security-engineer
-- 跨系统变更 → 强制引入 tech-lead + devops-engineer
-
-### Step 2: 创业团队对抗探索
-
-根据复杂度评估结果，启动团队对抗审查：
-
-#### 简单任务（score <= 5）
-快速通道，仅核心角色参与：
-- CEO：战略对齐、商业价值确认
-- 产品负责人：用户价值、MVP范围
-
-#### 中等任务（score 6-8）
-引入技术视角：
-- CEO + 产品负责人 + 技术负责人
-
-#### 复杂任务（score >= 9）
-引入完整团队：
-- CEO + 产品负责人 + 技术负责人 + 相关工程师
-- 如触发强制规则，额外引入安全工程师/运维工程师
-
-**对抗审查执行方式**：
-
-**自主模式 — 多Agent并行对抗**：
-```
-**【强制】** 读取 `${KNOWLEDGE}/03-guides/01-team-orchestrator.md`
-并行启动角色Agent（信息隔离，做审分离）：
-  - CEO Agent：战略一致性、商业价值、风险把控
-  - 产品负责人 Agent：用户价值、产品方向、MVP范围
-  - 技术负责人 Agent：技术可行性、技术风险（如需要）
-  - 相关工程师 Agent：实现可行性（如需要）
-汇总意见，生成团队对抗审查报告
-```
-
-**交互模式 — 与用户互动完成**：
-将团队各角色的关注点作为提问框架，与用户交互：
-1. **CEO视角**：商业价值、战略对齐、成功指标
-2. **产品视角**：用户痛点、MVP范围、验收标准
-3. **技术视角**（如需要）：技术可行性、技术风险
-4. **安全视角**（如触发）：数据安全、合规要求
-
-### Step 3: 需求澄清（DP17 结构化澄清 + 双模式适配）
-
-在需求分析过程中发现的所有歧义，**收集后批量处理**，不逐个打断：
-
-1. 执行 11 维扫描（功能范围/数据模型/UX流程/非功能需求/集成接口/边界案例/约束条件/术语定义/优先级/风险项/验收标准）
-2. 按 Impact × Uncertainty 排序，取 Top 5
-3. 对每个歧义项分类：
-
-**AUTO-FIX**（直接修复）：术语不一致、格式缺失、引用错误 → 自动修正
-**AUTO-DECIDE**（自动决策）：
-  - 交互模式 → 加入批处理问题列表
-  - 自动模式 → 使用推荐值，记录到 `pendingConfirmations`，标注置信度
-**REQUIRE-REVIEW**（需人工审阅）：
-  - 交互模式 → 加入批处理问题列表，标记为 CRITICAL
-  - 自动模式 → 使用最保守选项，标记 `HIGH_PRIORITY_REVIEW`
-
-4. **交互模式：批处理提问**
-   收集所有 AUTO-DECIDE + REQUIRE-REVIEW 项，**一次性提问**（AskUserQuestion）：
-   - 每个问题附带 AI 推荐答案 + 推理过程
-   - 用户可接受推荐或给出不同答案
-   - 支持提前终止（"其余全用推荐值"）
-
-5. **自动模式：自动决策**
-   - 所有项使用推荐值
-   - 生成决策记录到 `.autospec/runtime/state.json` 的 `autoDecisions` 数组
-   - 输出摘要：已自动决策 N 项 + 待审阅 N 项
-
-### Step 4: 需求文档生成
-
-1. **【强制】** 加载做类skill：读取 `${KNOWLEDGE}/03-guides/02-analyze-requirement.md` → **按步骤执行**
-2. 加载检查清单：读取 `knowledge/04-checklists/00-requirement.md` → 逐项核对
-3. 加载元学习方法：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 应用"三层知识漏斗"（原料→认知→执行）确保需求从模糊想法转化为可执行结构
-4. 将团队对抗结论融入需求文档（战略背景、商业价值、成功指标）
-5. 将澄清结果融入需求文档（每个决策标注来源：用户确认/自动决策/待审阅）
-6. **【强制】** 补充边界条件分析：
-   - 对每个功能需求，识别边界条件（空值、极值、并发、异常输入等）
-   - 在验收标准中明确定义边界条件测试标准
-   - 记录边界条件到需求文档的「边界条件」章节
-7. 产出结构化需求文档，写入 `.autospec/specs/{feature}/requirement.md`
-
-## 验证
-
-### Layer 1: 确定性验证
-- Schema校验：需求文档包含所有必须字段（背景、功能需求、验收标准、假设清单、边界条件）
-- 格式检查：每条需求有优先级(P0/P1/P2)和验收标准
-- **边界条件检查**：验收标准必须包含边界条件测试标准（空值、极值、并发、异常输入等）
-
-### Layer 2: AI审查（做审分离）
-使用 **independent-reviewer** Agent 执行独立审查：
-```
-**【强制】** 调用 Agent 工具：
-  prompt: 请审查以下需求文档。
-    1. 先读取审查标准: ${KNOWLEDGE}/03-guides/09-review-requirement.md
-    2. 被审查文档: .autospec/specs/{feature}/requirement.md
-    3. 原始需求（用于对照）
-    注意：你是独立审查者，只看产出物和标准，不参考生产过程
-```
-
-### Layer 3: Benchmarks 评测（新增）
-
-**【强制】** 执行 requirement benchmarks 评测：
-```
-1. 检测 requirement.md 是否生成
-2. 调用 benchmark-executor 执行评测：
-   - REQ-001: 需求文档完整性（字段完整率 >= 90%）
-   - REQ-002: 非功能需求覆盖（性能/安全/扩展性）
-   - REQ-003: 多系统需求一致性（跨系统接口定义）
-3. 生成评测报告到 .autospec/benchmarks/results/requirement-{run-id}.json
-4. 如评测未通过：
-   - 生成改进建议
-   - 返回 Step 2 完善需求
-   - 最多重试 3 次
-5. 如评测通过：
-   - 记录评测结果
-   - 允许进入 design stage
-```
-
-**评测触发方式**：
-- 自动触发：requirement.md 生成后自动执行
-- 手动触发：`/benchmark --run --stage=requirement`
-- 变更触发：requirement.md 修改后自动重新评测
-
-## 阶段门禁（所有自主级别）
-
-使用 **stage-gate-evaluator** Agent 评估产出物是否达到准出标准：
-```
-**【强制】** 调用 Agent 工具：
-  prompt: 请评估需求分析阶段的产出物是否达到准出标准。
-    当前阶段：Stage 01 需求分析
-    产出物：.autospec/specs/{feature}/requirement.md
-    准出标准：knowledge/04-checklists/00-requirement.md
-    上游契约：原始需求
-    自主级别：{自主/交互}
-```
-
-**根据自主级别处理评估结果**：
-- **交互模式**：评估结果提交人工确认，AI 等待用户批准后继续
-- **自主模式**：评估通过后自动进入下一阶段，评估不通过进入精准回退
-
-## 完成
-
-- 两层验证通过 + 阶段门禁评估通过 → 输出精炼契约 → 更新 `.autospec/runtime/state.json` → 进入方案设计
-- 不通过 → 精准回退：
-  - Level 1: 内联重试（单次）
-  - Level 2: 修正循环（最多3次，只重处理失败项）
-  - Level 3: 3次后使用 **failure-diagnostician** Agent 执行根因分析，再升级用户

package/plugins/skills/skill-forge/SKILL.md

@@ -1,223 +0,0 @@
----
-name: skill-forge
-description: "When creating a new skill from practice patterns, evolving an existing skill based on feedback, or optimizing skill description for better trigger accuracy — initiates the skill forging pipeline."
----
-
-# AutoSpec 技能锻造系统
-
-端到端的技能锻造系统，统一处理技能的新建、迭代和优化，是框架自进化能力的核心引擎。
-
-## 跳过条件
-
-如果用户明确表示不需要走锻造流程，尊重用户选择。
-
-## 三场景触发
-
-### 场景A：蒸馏新建
-
-**触发信号**：
-- practice-log 中某模式出现 **3 次以上**
-- 信号强度 = 证据数量 × 问题影响度
-
-**输入**：
-- practice-log 中状态为"待处理"的条目
-- 流程执行轨迹、人工介入记录
-
-**输出**：
-- 新的 skill 文件（符合模板标准）
-- 锻造报告（含证据清单）
-
-### 场景B：迭代进化
-
-**触发信号**：
-- 同类问题出现 **3 次以上**
-- 审类 skill 打回记录 ≥ 3 条
-- description 触发准确率 < 70%
-
-**输入**：
-- 待升级的 skill 文件
-- 反馈数据（审类打回记录 / practice-log / 人工反馈）
-
-**输出**：
-- 升级后的 skill 文件
-- 变更说明 + 证据清单
-- A/B 对比报告（如适用）
-
-### 场景C：Description 优化
-
-**触发信号**：
-- description 触发准确率 < 70%
-- 误触发或漏触发案例 ≥ 3 个
-
-**输入**：
-- skill 文件
-- 触发准确率数据
-- 误触发/漏触发案例
-
-**输出**：
-- 优化后的 description
-- A/B 测试报告
-
----
-
-## 锻造流水线
-
-### Phase 1: 信号诊断
-
-1. **信号分类**：
-   - 新建信号：模式出现 3 次以上 → 触发蒸馏
-   - 迭代信号：同类问题出现 3 次以上 → 触发进化
-   - 优化信号：description 触发准确率 < 70% → 触发优化
-
-2. **证据收集**：
-   - 收集至少 **3 条**支撑证据
-   - 标注证据类型（practice-log / 审查记录 / 人工反馈）
-   - 计算信号强度
-
-3. **分区判定**：
-   - 判断目标 skill 属于哪个进化分区（冻结区/受控区/自由区）
-   - 冻结区：停止，仅记录建议
-   - 受控区/自由区：继续
-
-### Phase 2: 草稿锻造
-
-**场景A：蒸馏新建**
-
-执行三场景蒸馏：
-1. **流程蒸馏（向内看）**：从执行轨迹识别可复用模式
-2. **业务蒸馏（向外看）**：从业务知识提取领域技能
-3. **测试知识蒸馏**：从测试执行中学习
-
-输出符合模板的 skill 草稿，重点：
-- CSO description（只写触发条件）
-- 反模式清单（≥ 5 条）
-
-**场景B：迭代进化**
-
-1. 收集该 skill 相关的所有反馈数据
-2. 分析问题模式：步骤不够具体？评判标准不准确？反模式不全面？
-3. 生成修改建议（明确改哪个 section、怎么改、预期效果）
-4. 保持向后兼容
-
-**场景C：Description 优化**
-
-1. 分析误触发案例（不该触发但触发了）
-2. 分析漏触发案例（该触发但没触发）
-3. 生成优化后的 description 候选版本
-4. 验证 CSO 格式（只含触发条件）
-
-### Phase 3: 双层验证
-
-**Layer 1: 确定性验证（skill-validator）**
-
-```
-检查项：
-- [ ] frontmatter 完整（name, description, type）
-- [ ] CSO description 符合格式
-- [ ] 输入/输出定义清晰
-- [ ] 执行步骤可操作
-- [ ] 反模式清单 >= 5 条
-- [ ] 包含完整示例
-```
-
-Layer 1 不过，不进 Layer 2。
-
-**Layer 2: AI 独立审查**
-
-使用 **skill-benchmarker** Agent 执行基准评测：
-- 用 skill 处理基准案例
-- 计算：完成率、首次通过率、平均回退次数
-- 输出结构化评测报告
-
-### Phase 4: 竞技场对比（仅迭代/优化场景）
-
-1. **盲评设置**：
-   - 旧版本 = Version A
-   - 新版本 = Version B
-   - 评测者不知道哪个是新版
-
-2. **多维度对比**：
-   | 维度 | 权重 | 评分方式 |
-   |------|------|----------|
-   | 输出质量 | 40% | AI 独立评分 |
-   | 执行效率 | 20% | 步骤数/时间 |
-   | 错误率 | 30% | 反模式触发次数 |
-   | 边界处理 | 10% | 边界案例通过率 |
-
-3. **胜者判定**：
-   - 综合得分高者胜出
-   - **平局时保留旧版本**（稳定性优先）
-   - 分差 < 5% 时建议人工评审
-
-### Phase 5: 发布审批
-
-**自由区 skills**（skills/domain/）：
-- Layer 1+2 通过 → 自动发布
-- 记录到 evolution-log.json
-
-**受控区 skills**（skills/requirement-stage/, skills/design-stage/等）：
-- 生成变更提案
-- 提交人工审批
-- 审批通过后发布
-
-**冻结区**：
-- 不自动执行
-- 仅记录建议
-
----
-
-## 反模式清单
-
-1. **证据不足锻造**：支撑证据 < 3 条就锻造。检测：必须有 3+ 实例支撑
-2. **跳过基准验证**：不跑基准案例就发布。检测：基准验证是必选步骤
-3. **盲目替换**：不对比新旧版本直接替换。检测：迭代场景必须走竞技场对比
-4. **Description 泄漏**：description 包含工作流内容。检测：CSO 格式检查
-5. **反模式缺失**：新 skill 没有反模式清单。检测：反模式清单是必填项
-6. **过度泛化**：基于单一项目特有模式泛化。检测：判断复用层级
-
----
-
-## 适用场景与边界
-
-- 适用：新建 skill、迭代 skill、优化 description
-- 不适用：方法论提取（用 methodology-extractor）、非 skill 类型文件
-
----
-
-## 示例
-
-### 新建示例
-
-```
-触发：practice-log 记录了 5 次"需求冲突检测"模式
-锻造：蒸馏为 skills/requirement-stage/req-conflict-detector.md
-验证：通过基准案例测试
-发布：受控区变更提案，人工审批后合入
-```
-
-### 迭代示例
-
-```
-触发：code-reviewer 连续 3 次漏判 SQL 注入
-锻造：补充安全检查步骤
-竞技场：新版 vs 旧版盲评，新版胜出
-发布：受控区变更提案，人工审批后合入
-```
-
-### Description 优化示例
-
-```
-触发：某 skill 触发准确率仅 55%
-分析：误触发案例 5 个，漏触发案例 3 个
-优化：重写 description，聚焦用户意图
-验证：触发准确率提升至 85%
-发布：自动发布，记录到 evolution-log
-```
-
----
-
-## 参考文档
-
-- `references/skill-template.md` — skill 标准模板
-- `references/description-guide.md` — CSO description 编写指南
-- `references/quality-rubric.md` — skill 质量评分标准

package/plugins/skills/skill-forge/references/description-guide.md

@@ -1,92 +0,0 @@
-# CSO Description 编写指南
-
-## 什么是 CSO？
-
-**C**ondition（条件）+ **S**ignal（信号）+ **O**nly（仅此）
-
-CSO 是 AutoSpec skill description 的编写原则，确保 description 只包含触发条件，不包含工作流摘要。
-
-## 为什么需要 CSO？
-
-1. **避免膨胀**：description 是注入到每次对话的，过长会浪费 token
-2. **精准触发**：只写触发条件，让 Claude 更容易判断是否应该使用这个 skill
-3. **避免混淆**：不写工作流摘要，防止 Claude 误以为 description 就是完整指令
-
-## CSO 格式
-
-```
-When [触发条件] — triggers [skill 名称/功能]
-```
-
-## 示例对比
-
-### ❌ 错误示例（包含工作流摘要）
-
-```
-这个 skill 帮助你分析用户需求，生成需求文档。它会执行11维扫描，
-包括功能完整性、边界条件、性能需求等，然后生成结构化的需求文档...
-```
-
-问题：
-- 包含工作流摘要
-- 过长（浪费 token）
-- 触发条件不明确
-
-### ✅ 正确示例（CSO 格式）
-
-```
-When analyzing user requirements to generate requirement specs — triggers requirement analysis pipeline.
-```
-
-优点：
-- 触发条件明确
-- 简洁（节省 token）
-- 不包含工作流内容
-
-## 编写技巧
-
-### 1. 从用户意图出发
-
-```
-❌ When the user wants to use the requirement-analyzer skill
-✅ When analyzing user requirements to generate requirement specs
-```
-
-### 2. 使用 When... — triggers... 句式
-
-```
-When [用户在做什么] — triggers [skill 提供什么能力]
-```
-
-### 3. 避免包含实现细节
-
-```
-❌ When the user needs to run 11-dimension scan on requirements
-✅ When analyzing user requirements for completeness and consistency
-```
-
-### 4. 长度控制在 200 字符以内
-
-```
-❌ When the user is working on a complex project that involves multiple subsystems including backend, frontend, and AI components, and needs to coordinate the development process across these subsystems — triggers multi-system development pipeline
-✅ When developing features spanning multiple subsystems (backend/frontend/AI) — triggers multi-system coordination pipeline
-```
-
-## 触发准确率优化
-
-如果 description 触发准确率 < 70%：
-
-1. **误触发**（不该触发但触发了）：
-   - 检查 description 是否过于宽泛
-   - 添加排除条件
-
-2. **漏触发**（该触发但没触发）：
-   - 检查 description 是否过于具体
-   - 添加更多触发场景
-
-## 反模式
-
-1. **工作流泄漏**：description 包含执行步骤
-2. **过度推销**：使用"强大的"、"完美的"等修饰词
-3. **模糊触发**：使用"当需要时"、"如果用户想要"等模糊表达
-4. **技术术语滥用**：使用只有开发者理解的术语