@chongyan/autospec 1.0.2 → 1.0.3

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

@@ -1,320 +0,0 @@
----
-name: implementation-stage
-description: "When code implementation, feature coding, or translating a technical design into working code is needed — loads AutoSpec implementation process and skill."
----
-
-# AutoSpec 编码实现（Stage 03）
-
-你正在执行编码实现阶段。此阶段将技术方案忠实落地为可运行代码。
-
-## ⚠️ 执行约束（强制）
-
-**【阻塞检查】** 在开始执行前，必须确认以下条件：
-
-```
-□ 上游方案设计阶段已完成（检查 state.json）
-□ design.md 文件存在且完整
-□ 已读取复杂度评估结果或重新评估
-□ 已确定参与角色列表
-□ 已识别涉及的子系统
-```
-
-**【跳过检测】** 以下行为将被检测并阻止：
-
-| 行为 | 检测方式 | 处理 |
-|------|----------|------|
-| 直接编码没有设计文档 | 检查 design.md 是否存在 | 阻止，返回执行方案设计 |
-| 跳过依赖包检查 | 检查 dependency-decision.md | 阻止，要求执行依赖检查 |
-| 跳过 Layer1 验证 | 检查编译/测试日志 | 阻止，要求执行验证 |
-| 跳过团队对抗审查 | 检查 Agent 调用记录 | 阻止，要求启动多 Agent 审查 |
-
-**【强制流程】** 必须按顺序完成以下步骤，不可跳过：
-
-```
-Step 1 → Step 2/3 → 阶段完成验证 → Layer1 → 团队对抗 → Layer2 → 阶段门禁
-         ↓
-    【强制】依赖包检查必须完成
-    【强制】Layer1 验证必须真实执行
-    【禁止】跳过验证直接提交代码
-```
-
-## 前置检查
-
-1. 确认方案设计阶段已完成（检查 `.autospec/runtime/state.json`）
-2. 读取 `knowledge/01-principles/09-constitution.md` → 确认红线
-3. 读取上游精炼契约（技术方案）
-4. **检查是否为多系统项目**：读取 `.autospec/runtime/config.json` 的 `subsystems` 字段
-5. 如有角色配置，加载 `.clause/agents/roles/{角色}.md` 中**编码阶段**关注点（如后端关注事务处理/并发安全/性能）
-6. 加载认知增强原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 本阶段重点应用 CP8(偏航检测)、CP9(刚好够用)、CP10(自我质检)
-
-## 执行
-
-### Step 1: 确定模式
-
-读取 `.autospec/runtime/config.json`，检查 `subsystems` 字段：
-- **无 subsystems 或长度为1** → 单系统模式
-- **有 subsystems 且长度>1** → 多系统模式
-
-### Step 2: 单系统模式
-
-1. **【强制】** 加载做类skill：读取 `${KNOWLEDGE}/03-guides/04-implement-code.md` → **按步骤执行**
-2. 加载检查清单：读取 `knowledge/04-checklists/02-code.md` → 逐项核对
-3. 加载方法论原则：读取 `${KNOWLEDGE}/principles/02-methodology-principles.md` → 注入 P9(高内聚低耦合)、P11(架构决策记录) 等编码原则
-4. **【强制】编码前依赖包检查**（DP15 Brownfield 适配 + 依赖包复用）：
-   - 调用 `plugins/skills/project-evolve-scanner/scripts/dependency-reuse-checker.js`
-   - 扫描项目依赖（package.json / pom.xml / build.gradle / go.mod 等）
-   - 检查团队组件使用手册（`${KNOWLEDGE}/environment/` 或 `team-wiki/`）
-   - 搜索项目现有代码，识别可复用实现
-   - 如决定自己实现，必须记录理由到 `.autospec/dependency-decision.md`：
-     - 现有包不满足需求（具体说明）
-     - 升级风险过大（具体说明）
-     - 其他合理理由
-5. **先搜索现有代码库**，识别可复用组件（DP15 Brownfield 适配）
-6. 如有角色特有检查项（如后端 profile.md 中的"事务处理"、"N+1查询"），额外关注
-7. **【强制】代码注释规范**：
-   - 每个公共函数/方法必须有文档注释（功能、参数、返回值、异常）
-   - 复杂逻辑必须添加行内注释说明"为什么"
-   - 关键算法必须注释说明实现思路
-   - 使用项目统一的注释风格（根据 `.autospec/config.json` 或常见约定）
-8. 按方案模块划分编码，产出代码+自测
-
-### Step 3: 多系统模式
-
-1. **读取整体架构**：读取 `design/overview.md`，理解：
-   - 系统交互关系
-   - 跨系统接口契约
-   - 开发顺序（通常：后端 → 前端 → 移动端；有ml时可能需要先验证效果）
-
-2. **按顺序处理每个子系统（带切换检查）**：
-   ```
-   for subsystem in config.subsystems（按依赖顺序）:
-     a. 读取 design/{subsystem.name}.md
-     b. 切换到 {subsystem.path} 目录
-     c. 搜索现有代码，识别可复用组件
-     d. 按方案编码
-     e. 执行子系统验证：
-        - {subsystem.build}（如有）
-        - {subsystem.test}（如有）
-        - {subsystem.lint}（如有）
-     f. 记录验证结果
-     g. **【强制】子系统切换检查**：
-        - 确认 Layer 1 验证通过（build/test/lint 全部 pass）
-        - 更新子系统状态为 completed
-        - 偏航自检：对照设计方案，确认无偏离
-        - 记录到 .autospec/monitoring-issues.json（如有问题）
-   ```
-
-3. **【强制】集成验证前检查**：
-   - 检查所有子系统状态是否为 completed
-   - 检查是否有未解决的 monitoring issues
-   - 确认依赖包复用检查通过
-   - 任一子系统未完成 → 阻塞集成验证
-
-4. **集成验证**（所有子系统完成后）：
-   - 验证跨系统接口联调
-   - 验证数据流正确性
-   - 记录集成问题
-
-### Step 4: 数据/AI子系统特殊处理
-
-当子系统类型为 `data` 或 `ai` 时：
-
-**数据系统（data）**：
-- 数据模型实现（表结构、字段定义）
-- ETL脚本开发
-- 数据质量检查脚本
-- 数据测试用例
-
-**AI/模型系统（ai）**：
-- 模型训练/推理代码
-- 特征工程代码
-- 评测数据集构建（如设计阶段定义）
-- 评测脚本开发（如设计阶段定义）
-- 效果验证脚本
-
-## 阶段检查点（本阶段必须完成）
-
-执行过程中请持续对照以下检查点，确保不遗漏：
-
-**说明**：
-- **检查点表**：快速验证产出是否存在/完成
-- **检查清单（checklists/）**：详细验证产出质量是否达标
-- 通过"检查清单核对完成"一项覆盖所有质量检查，避免重复
-
-| 类别 | 检查项 | 必须完成 | 验证方式 |
-|-----|-------|---------|---------|
-| 流程 | 复杂度评估/继承完成 | ✅ | 检查是否已有复杂度分数和角色列表 |
-| 流程 | 动态团队组建完成 | ✅ | 检查是否已根据复杂度确定参与角色 |
-| 做类 | 编码执行Agent加载完成 | ✅ | 已加载 implement-code skill |
-| 做类 | 编码执行Agent正确执行 | ✅ | 已执行编码任务（模块/接口/数据模型）并产出代码 |
-| 做类 | 代码汇总完成 | ✅ | 各Agent产出已合并到正确文件 |
-| 流程 | 团队对抗审查执行（审类） | ✅ | 检查是否已调用 team-orchestrator 并汇总审查报告 |
-| 流程 | consistency-checker Agent 调用 | ✅ | 代码-设计一致性检查 |
-| 流程 | independent-reviewer Agent 调用 | ✅ | Layer 2 审查必须调用 |
-| 产出 | 检查清单核对完成 | ✅ | 已按 02-code.md 逐项核对并记录（质量检查） |
-| 流程 | Layer 1 验证通过 | ✅ | 编译/测试/Lint 全部通过 |
-| 流程 | Benchmark 评测通过 | ✅ | IMP-001~003 全部通过 |
-
-**阶段完成前自检**：
-- [ ] 已完成复杂度评估或继承
-- [ ] 已组建动态团队（根据复杂度确定角色）
-- [ ] 已加载编码执行Agent（implement-code skill）
-- [ ] 已执行编码任务（模块/接口/数据模型）
-- [ ] 代码已汇总到正确文件
-- [ ] 已执行团队对抗审查（调用 team-orchestrator）
-- [ ] 已按检查清单（02-code.md）逐项核对（质量检查）
-- [ ] 已调用 consistency-checker（代码-设计一致性）
-- [ ] 已调用 independent-reviewer（Layer 2）
-- [ ] Layer 1 验证已通过（编译/测试/Lint）
-- [ ] Benchmark 评测已通过（Layer 3）
-- [ ] Layer 1 验证已通过（编译/测试/Lint）
-- [ ] Benchmark 评测已通过（Layer 3）
-
-## 认知纪律（本阶段：严格执行 + 偏航检测）
-
-- **CP8 偏航检测**：编码过程中持续对照技术方案。发现偏离时：
-  - 小偏离（命名/结构微调）→ 记录理由，继续
-  - 中偏离（新增方案未定义的模块）→ 暂停，回报用户
-  - 大偏离（需要改方案）→ **不自行修改**，标记问题提请回退到设计阶段
-- **CP9 刚好够用**：不添加需求之外的功能。三行相似代码优于一个过早抽象
-- **CP10 自我质检**：提交 Layer 1 验证前，自问：代码是否忠实实现了方案？有没有遗漏的功能点？有没有过度设计？
-
-## 验证
-
-### 阶段完成验证（阻塞检查）
-
-**【强制】【不可跳过】** 在执行 Layer1 验证之前，必须验证以下条件：
-
-```
-验证清单：
-□ 上游设计文档存在（design.md）
-□ 代码已按方案实现
-□ 依赖包复用检查已完成
-□ 代码注释规范已满足
-□ 多系统模式下各子系统已完成
-```
-
-**验证失败处理**：
-
-| 缺失项 | 处理方式 |
-|--------|----------|
-| 设计文档不存在 | 返回方案设计阶段 |
-| 依赖包检查未完成 | 执行依赖包检查 |
-| 代码注释不满足 | 补充注释 |
-| 子系统未完成 | 继续完成子系统 |
-
-**【禁止】** 验证未通过时，禁止进入 Layer1 验证。
-
-### Layer 1: 确定性验证（必须真实执行）
-
-**单系统模式**：
-- **编译检查**：项目能成功编译/构建
-- **测试执行**：运行所有测试，全部通过
-- **Lint检查**：代码风格无警告/错误
-- **类型检查**：类型系统无错误（如适用）
-- **注释检查**：关键函数有文档注释，复杂逻辑有说明
-- 每项必须附真实执行日志，无日志=BLOCKED
-
-**多系统模式**：
-- **每个子系统都必须通过验证**
-- 按顺序验证：先确保上游子系统通过，再验证下游
-- 汇总所有子系统的验证结果
-- 任一子系统失败 = 整体 BLOCKED
-
-**数据/AI子系统验证**：
-- **数据系统**：数据质量检查通过、ETL流程可执行
-- **AI/模型系统**：模型可加载、推理可执行、评测脚本可运行
-
-### 团队对抗审查（按复杂度）
-
-**【强制】** 根据复杂度评估结果，启动团队智能体并行审查：
-
-#### 简单任务（score <= 5）
-- 技术负责人：架构合理性、代码质量
-
-#### 中等任务（score 6-8）
-- 技术负责人 + 相关工程师（根据子系统类型）
-
-#### 复杂任务（score >= 9）
-- 技术负责人 + 后端工程师 + 前端工程师 + 相关工程师
-- 如触发强制规则，额外引入安全工程师/运维工程师
-
-**执行方式**：
-```
-**【强制】** 读取 `${KNOWLEDGE}/03-guides/01-team-orchestrator.md`
-并行启动团队智能体审查代码：
-  - 技术负责人 Agent：架构合理性、技术选型
-  - 后端工程师 Agent：API设计、数据库设计、性能
-  - 前端工程师 Agent：组件设计、状态管理
-  - 数据工程师 Agent：数据模型、ETL流程（如涉及数据系统）
-  - AI工程师 Agent：模型代码、评测代码（如涉及AI系统）
-  - 安全工程师 Agent：安全漏洞检查（如触发）
-  - 运维工程师 Agent：部署可行性（如触发）
-汇总审查意见，生成团队审查报告
-```
-
-### Layer 2: AI审查（做审分离）
-使用 **independent-reviewer** Agent 执行独立审查：
-```
-**【强制】** 调用 Agent 工具：
-  prompt: 请审查以下代码实现。
-    1. 先读取审查标准: ${KNOWLEDGE}/03-guides/11-review-code.md
-    2. 被审查的代码（提供变更文件列表和路径）
-    3. 上游技术方案: .autospec/specs/{feature}/design.md（或 design/ 目录）
-    4. 上游需求文档: .autospec/specs/{feature}/requirement.md
-    注意：你是独立审查者，检查代码是否忠实实现方案，不参考编码过程
-```
-
-### Layer 3: Benchmarks 评测（新增）
-
-**【强制】** 执行 implementation benchmarks 评测：
-```
-1. 执行 Layer 1 验证
-   - 编译检查
-   - Lint 检查
-   - 单元测试执行
-2. 调用 benchmark-executor 执行评测：
-   - IMP-001: 代码-设计一致性（实现符合设计、API符合契约）
-   - IMP-002: 代码质量基准（复杂度<10、无重复代码、覆盖率>80%、无Lint错误）
-   - IMP-003: 功能完整性（所有需求已实现、验收标准可验证）
-3. 生成评测报告到 .autospec/benchmarks/results/implementation-{run-id}.json
-4. 如评测未通过：
-   - 自动修复（如 auto_fixable：格式问题、简单重构）
-   - 生成改进建议
-   - 返回 Step 2 修正代码
-   - 最多重试 3 次
-8. 如评测通过：
-   - 记录评测结果
-   - 允许进入 testing stage
-```
-
-**评测触发方式**：
-- 自动触发：代码提交前（pre-commit钩子）自动执行
-- 手动触发：`/benchmark --run --stage=implementation`
-- 变更触发：src/ 目录代码修改后自动重新评测
-
-## 阶段门禁（所有自主级别）
-
-使用 **stage-gate-evaluator** Agent 评估产出物是否达到准出标准：
-```
-**【强制】** 调用 Agent 工具：
-  prompt: 请评估编码实现阶段的产出物是否达到准出标准。
-    当前阶段：Stage 03 编码实现
-    产出物：代码变更文件列表
-    准出标准：knowledge/04-checklists/02-code.md
-    上游契约：.autospec/specs/{feature}/design.md（或 design/ 目录）
-    自主级别：{自主/交互}
-```
-
-**根据自主级别处理评估结果**：
-- **交互模式**：评估结果提交人工确认，AI 等待用户批准后继续
-- **自主模式**：评估通过后自动进入下一阶段，评估不通过进入精准回退
-
-## 完成
-
-- 两层验证通过 + 阶段门禁评估通过 → 输出精炼契约 → 更新 `.autospec/runtime/state.json` → 进入代码审查
-- 不通过 → 精准回退：
-  - Level 1: 内联重试（单次）
-  - Level 2: 修正循环（最多3次，只重处理失败项）
-  - Level 3: 3次后使用 **failure-diagnostician** Agent 执行根因分析，再升级用户
-- 如发现方案有缺陷 → **不自行修改**，标记问题提请回退到设计阶段

package/plugins/skills/layer1-validation/SKILL.md

@@ -1,79 +0,0 @@
----
-name: layer1-validation
-description: "After code changes are made (Write, Edit tool usage on source files) — reminds to run Layer 1 deterministic validation before claiming completion."
----
-
-# AutoSpec Layer 1 验证提醒（自动触发）
-
-你刚对源代码进行了修改。根据 AutoSpec 流程，**代码变更后必须运行 Layer 1 确定性验证**。
-
-## 检查模式
-
-### Step 1: 确定模式
-
-读取 `.autospec/runtime/config.json`，检查 `subsystems` 字段：
-- **无 subsystems 或长度为1** → 单系统模式
-- **有 subsystems 且长度>1** → 多系统模式
-
-### Step 2: 单系统模式
-
-在声明任何阶段完成之前，确保已执行：
-
-1. **编译检查** — 项目能否成功编译/构建
-2. **测试执行** — 运行所有已有测试
-3. **Lint检查** — 代码风格和静态分析
-4. **类型检查** — TypeScript/类型系统检查（如适用）
-
-### Step 3: 多系统模式
-
-对 config.json 中的每个 subsystem 执行验证：
-
-```
-for subsystem in config.subsystems:
-  1. {subsystem.build} — 构建检查（如有）
-  2. {subsystem.test} — 测试执行（如有）
-  3. {subsystem.lint} — Lint检查（如有）
-  4. {subsystem.typeCheck} — 类型检查（如有）
-```
-
-**验证顺序**：按依赖顺序执行，通常为 backend → frontend → mobile
-
-### Step 4: 数据/AI子系统验证
-
-当子系统类型为 `data` 或 `ai` 时：
-
-**数据系统（data）**：
-- 数据质量检查：`dbt test` 或 `pytest tests/data_quality`
-- ETL流程验证：确保可执行
-
-**AI/模型系统（ai）**：
-- 模型加载验证：确保模型可正常加载
-- 推理验证：确保推理流程可执行
-- 评测脚本验证：`pytest tests/evaluation`
-
-## 规则
-
-- 必须**真实执行**，看到真实输出
-- 不可用"静态分析"或"代码审查"替代实际执行
-- 跑不了 → 标记 BLOCKED，不是 PASSED
-- 每项结果附带执行日志
-- **多系统模式**：所有子系统都必须通过
-
-## 输出格式
-
-### 单系统模式
-| 检查项 | 状态 | 日志摘要 |
-|--------|------|----------|
-| 编译   | PASS/FAIL/BLOCKED | ... |
-| 测试   | PASS/FAIL/BLOCKED | ... |
-| Lint   | PASS/FAIL/BLOCKED | ... |
-| 类型   | PASS/FAIL/BLOCKED | ... |
-
-### 多系统模式
-| 子系统 | 类型 | 构建 | 测试 | Lint | 类型 |
-|--------|------|------|------|------|------|
-| backend | 后端 | ✅/❌/⚠️ | ✅/❌ | ✅/❌ | ✅/❌ |
-| frontend | 前端 | ✅/❌/⚠️ | ✅/❌ | ✅/❌ | ✅/❌ |
-| ai | AI/模型 | - | ✅/❌ | ✅/❌ | - |
-
-可使用 `/autospec:test` 命令执行完整验证。

package/plugins/skills/pending-dashboard/SKILL.md

@@ -1,110 +0,0 @@
----
-name: pending-dashboard
-description: "When a new Claude Code session starts in a project with .autospec/ directory — automatically scans for pending proposals, unprocessed practice-logs, stalled pipelines, and evolution items that need attention."
----
-
-# AutoSpec 待办事项仪表盘（会话启动自动触发）
-
-你在一个已初始化 AutoSpec 的项目中开始了新会话。**自动扫描以下待处理项并向用户汇报**。
-
-## 扫描项目（按优先级排序）
-
-### 1. 中断的流水线
-检查 `.autospec/runtime/state.json`：
-- 如果存在且 `completedAt` 为空 → 有未完成的流水线
-- 告知用户：**"有一个未完成的 {workflow} 流程（{task}），当前停在 Stage {currentStage}。"**
-- 建议：`/autospec:run` 恢复 或 确认放弃
-
-### 2. 待审批的进化提案
-扫描 `.autospec/evolution/proposals/` 目录：
-- 如果有 .md 文件 → 有待人工审批的受控区变更提案
-- 告知用户：**"有 {N} 个进化提案等待审批"**，列出每个提案的标题和一句话摘要
-- 建议：逐个审批（批准/拒绝/搁置）
-
-### 3. 未处理的实践日志
-扫描 `.autospec/evolution/practice-log/` 目录中的文件：
-- 检查每个文件内容，查找 `状态: Pending` 或 `Status: Pending`
-- 如果有 Pending 状态的 → 有未被进化扫描处理的实践记录
-- 告知用户：**"有 {N} 条实践记录未被进化扫描处理"**
-- 建议：运行 `/evolve` 触发进化扫描
-
-### 4. 进化信号积累
-如果 Pending 的 practice-log 数量 ≥ 5：
-- **强烈建议**立即运行 `/evolve`
-- 说明：每 5 条 practice-log 应触发一次方法论审查（进化周期规则）
-
-### 5. 自主级别晋升检查
-读取 `.autospec/runtime/config.json` 获取当前自主级别，扫描已完成的流程数量：
-- 交互模式成功完成 ≥ 2 次 → 提示可考虑切换到自主模式
-- 自主模式成功完成 ≥ 5 次 → 积累足够信任
-
-### 6. 记忆系统状态
-扫描记忆系统状态（使用 memory-manager.js API）：
-
-**全局记忆检查**：
-- 调用 `hasGlobalMemory()` 检查是否存在
-- 如果返回 false → 提示首次使用需要初始化全局记忆
-- 如果存在，调用 `getMemory(MEMORY_SCOPE.GLOBAL, 'team-preferences.json')`：
-  - 如果为空 → 提示配置团队偏好
-
-**项目记忆检查**：
-- 调用 `hasProjectMemory(projectRoot)` 检查是否存在
-- 如果返回 false → 提示初始化项目记忆
-- 如果存在，调用 `getNorthStar(projectRoot)`：
-  - 如果 `mission` 为空 → 提示填写北极星指标
-  - 如果 `northStarMetric.current` 与 `target` 差距 > 10% → 提示指标进度落后
-  - 如果 `lastUpdated` 超过 30 天 → 提示核心记忆可能过期
-
-**待确认记忆**：
-- 调用 `getMemory(MEMORY_SCOPE.PROJECT, 'memory-meta.json', projectRoot)` 检查是否有 `pendingExtractions`
-- 如果有待确认的记忆提取 → 提示用户确认
-
-## 输出格式
-
-```
-📋 AutoSpec 待办事项
-
-{如果有中断的流水线}
-⚠️  未完成流程：{task}（{workflow}，停在 Stage {N}）
-   → /autospec:run 恢复
-
-{如果有待审批提案}
-📝 待审批提案（{N} 个）：
-   - {提案1标题}：{一句话摘要}
-   - {提案2标题}：{一句话摘要}
-   → 逐个审批：批准 / 拒绝 / 搁置
-
-{如果有未处理practice-log}
-📊 未处理实践记录（{N} 条）
-   → /evolve 触发进化扫描
-
-{如果practice-log ≥ 5}
-🔄 进化信号已积累 {N} 条，建议立即运行进化扫描
-
-{如果可晋升}
-⬆️  已成功完成 {N} 次流程，可考虑晋升到 {下一级别}
-
-{如果记忆系统有状态}
-💡 记忆系统状态：
-   {如果全局记忆未初始化}
-   🌐 全局记忆未初始化 → /autospec:memory init --global
-   {如果项目记忆未初始化}
-   📁 项目记忆未初始化 → /autospec:memory init
-   {如果北极星指标为空}
-   🎯 北极星指标未设置 → /autospec:memory update-north-star
-   {如果指标进度落后}
-   📉 北极星指标进度落后：{name} {current} → {target}
-   {如果核心记忆过期}
-   ⏰ 核心记忆超过 30 天未更新，建议刷新
-   {如果有待确认记忆}
-   ❓ 有 {N} 条待确认的记忆提取 → /autospec:memory show pending
-
-{如果全部为空}
-✅ 无待处理事项
-```
-
-## 行为规则
-
-- 本 skill 只做**信息展示和建议**，不自动执行任何操作
-- 扫描失败（目录不存在等）静默跳过，不报错
-- 如果用户正在执行 / 命令，不重复提醒（避免干扰）

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

@@ -1,95 +0,0 @@
----
-name: project-evolve-analyzer
-description: "问题分析：分析项目代码质量，识别问题，提供改进建议"
-type: analyzer
----
-
-# Project-Evolve Analyzer
-
-## 定位
-
-问题分析技能，分析项目代码质量，识别问题，提供改进建议。
-
-## 输入
-
-- 扫描结果（来自 scanner）
-- 修复历史（来自 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. 趋势分析
-```
-
-## 使用示例
-
-```
-# 执行问题分析
-读取 plugins/skills/project-evolve-analyzer/SKILL.md 并执行
-
-# 输出
-- 问题数: 25
-- 严重问题: 5
-- 改进建议: 12
-- 质量评分: 78/100
-```
-
-## 分析维度
-
-| 维度 | 分析内容 | 权重 |
-|------|----------|------|
-| 代码质量 | 复杂度、重复、死代码 | 25% |
-| 测试体系 | 覆盖率、边界、异常 | 25% |
-| 文档完整性 | README、API、CHANGELOG | 20% |
-| 配置工程 | 构建、依赖、CI/CD | 15% |
-| 架构设计 | 模块边界、依赖关系 | 15% |
-
-## 与 self-evolve-analyzer 的区别
-
-| 特性 | self-evolve-analyzer | project-evolve-analyzer |
-|------|---------------------|------------------------|
-| 目标 | 分析框架问题 | 分析项目问题 |
-| 分析对象 | 框架代码 | 用户项目代码 |
-| 评分标准 | 框架质量标准 | 项目质量标准 |

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

@@ -1,99 +0,0 @@
----
-name: project-evolve-fixer
-description: "自动修复：对项目代码进行自动化修复，包括代码规范、格式化、未使用导入等"
-type: fixer
----
-
-# Project-Evolve Fixer
-
-## 定位
-
-自动修复技能，对项目代码进行自动化修复，包括代码规范、格式化、未使用导入等。
-
-## 输入
-
-- 扫描结果（来自 scanner）
-- 修复类型：automatic（自动）/suggested（建议）
-
-## 输出
-
-- 修复记录：修复的文件、变更内容
-- 修复报告：修复数量、成功率
-- 退化检测：如有问题自动回滚
-
-## 执行步骤
-
-### Step 1: 修复类型判断
-
-```
-L1 自动修复（无需确认）：
-- 代码格式化
-- 未使用导入清理
-- 简单命名规范化
-- 依赖安全升级
-
-L2 建议修复（需确认）：
-- 复杂重构
-- 架构调整
-- 性能优化
-```
-
-### Step 2: 执行自动修复
-
-```
-对每个 L1 修复项：
-1. 备份原文件
-2. 执行修复
-3. 验证修复
-4. 记录变更
-```
-
-### Step 3: 生成建议
-
-```
-对每个 L2 修复项：
-1. 分析问题
-2. 生成修复方案
-3. 等待确认
-4. 执行或跳过
-```
-
-### Step 4: 验证与回滚
-
-```
-1. 运行测试验证
-2. 检查是否有退化
-3. 如有问题自动回滚
-4. 记录修复结果
-```
-
-## 使用示例
-
-```
-# 执行自动修复
-读取 plugins/skills/project-evolve-fixer/SKILL.md 并执行
-
-# 输出
-- 自动修复: 15项
-- 建议修复: 8项
-- 成功率: 100%
-```
-
-## 修复能力
-
-| 修复类型 | 自动/建议 | 说明 |
-|----------|----------|------|
-| 代码格式化 | 自动 | Prettier/ESLint |
-| 未使用导入 | 自动 | import 清理 |
-| 命名规范化 | 自动 | 驼峰/蛇形 |
-| 依赖升级 | 自动 | 安全补丁 |
-| 复杂重构 | 建议 | 需人工确认 |
-| 性能优化 | 建议 | 需人工确认 |
-
-## 与 self-evolve-iterator 的区别
-
-| 特性 | self-evolve-iterator | project-evolve-fixer |
-|------|----------------------|---------------------|
-| 目标 | 框架自我修复 | 项目代码修复 |
-| 修复范围 | 框架代码 | 用户项目代码 |
-| 修复类型 | 配置/模板 | 实际代码 |