---
name: project-convention-resolver
description: 项目规范问题自动修复 Skill。当用户指出项目内的规范偏差时，自动分类问题类型，路由到对应角色Skill执行修复，并通过verifier验证修复效果。类比产品侧「问题追踪+修复」的完整闭环，是项目内规范问题的「接收→分类→执行→验证」一体化机制。触发词：「这里有个规范问题」「这不符合规范」「规范偏差」「按规范修复这里」「这里违反了规范」「规范不对」「帮我修复规范问题」。注意：与 issue-tracker 的区别——后者只记录不执行；本 Skill 记录并自动路由执行。
---

# 项目规范问题自动修复（project-convention-resolver）

> 定位：项目内规范问题的「接收 → 分类 → 路由执行 → 验证 → 归档」一体化 Skill
>
> 类比关系：
> - issue-tracker → 记录问题（不执行）
> - **project-convention-resolver → 记录 + 自动路由执行 + 验证**
>
> 强绑定 Rule：R2 NO_FABRICATION / R3 READ_FIRST / R7 CLOSED_LOOP_REQUIRED

---

## 规范问题分类（五类）

```
A 类：产品规范偏差
  → 功能不符合产品定义中的闭环设计
  → 动线缺失入口/出口
  → 双层设计缺失（只有人层没有智能体层，或反之）
  → 产品文档描述与实际不符

B 类：技术架构规范偏差
  → 接口设计不符合技术架构.md 规范
  → 模块边界不清晰，违反关注点分离
  → 跨模块耦合过紧，扩展性风险
  → Schema/数据模型与规范不一致

C 类：代码规范/实现偏差
  → 命名规范违反（snake_case/camelCase 混用等）
  → 缺少必要的错误处理或测试
  → 安全漏洞（注入/越权/硬编码密钥）
  → 与产品文档描述不符的实现

D 类：文档规范偏差
  → 文档结构不符合项目规范（缺变更记录/版本号等）
  → 多个文档内容漂移（同一内容在不同文档中描述不一致）
  → README 与实际代码状态不符

E 类：Skill/Rule 规范偏差
  → Skill 描述不准确 / 触发词不对
  → Rule 有冲突 / alwaysApply 叠加矛盾
  → Skill 与实际行为不一致
```

---

## 激活后立即执行

```
Step 1  记录问题（R2：必须基于用户实际描述）
        调用 issue-tracker：
        - 如果是产品设计类 → 写入 产品经理/产品问题追踪台.md
        - 如果是技术实现类 → 写入 技术架构师/技术问题追踪台.md
        - 如果是 Skill/Rule 类 → 写入 .cursor/skills/skill-index/PENDING-EXPERIENCES.md

Step 2  Read 相关文档（R3 READ_FIRST）
        根据问题类型读取必要的上下文：
        A 类 → Read: 产品经理/产品定义.md
        B 类 → Read: 技术架构师/技术架构.md
        C 类 → Read: 被报告的代码文件（具体路径）
        D 类 → Read: 被报告的文档文件
        E 类 → Read: 被报告的 SKILL.md 或 .mdc 文件

Step 3  分类 + 确认修复方向
        向用户确认：
        「检测到 [X类] 规范问题：[问题描述]
          修复方向：[一句话说明]
          将调用：[对应角色 Skill / 工具]
          
          [确认，立即修复] [调整方向后修复] [只记录，暂不修复]」
        
        若用户选择「调整方向后修复」：
        → 等待用户说明调整内容
        → 重新展示调整后的修复方向
        → 再次确认后再执行
        
        不允许静默执行修复（规范修复可能有误判，必须用户知情）

Step 4  路由执行（按分类路由到对应角色 Skill）
        
        【A 类 → 按 role-产品经理 激活协议执行】
        将「规范问题描述 + 相关产品定义章节内容」作为本次 PM 任务的上下文
        按 role-产品经理 的步骤修复产品定义文档或设计逻辑
        
        【B 类 → 按 role-技术架构师 激活协议执行】
        将「规范问题描述 + 相关架构文档章节」作为上下文
        修复技术架构.md，若涉及产品意图，必须先回 PM 确认
        
        【C 类 → 按 role-后端开发 或 role-前端开发 激活协议执行】
        将「规范问题描述 + 具体代码文件路径 + 违反的规范条目」作为上下文
        修复代码后自动触发「Bug 修复后强制验证闭环」（调用 /verifier）
        
        【D 类 → 按 doc-consolidator 激活协议执行】
        将「规范问题描述 + 涉及的文档文件」作为上下文
        整合/修复文档，确保单一真源
        
        【E 类 → 加载 skill-rule-修改规范，强制三问+备份+修改+变更记录】
        E 类不允许直接修改，必须先回答三问，再备份，再修改

Step 5  验证修复效果（R7 CLOSED_LOOP_REQUIRED）
        
        C 类（代码修复）：
        → 自动调用 /verifier，传入原问题描述作为验证场景
        
        A/B/D/E 类（文档/规范修复）：
        → 人工确认：「已完成修复，请确认以下变更是否符合预期：[变更摘要]」
        → 等待用户确认
        → 若本次修复来源为 skill-system-health-check 报告 → 修复完成后，告知：「建议重新运行 skill-system-health-check 验证该问题已消解」

Step 6  归档关闭
        → 更新追踪台对应条目状态为「已修复（含修复说明）」
        → 告知用户：「规范问题已修复并验证，追踪台已更新。」
```

---

## 路由决策树

```
用户报告规范问题
  ↓
判断问题类型
  ↓
├── 涉及产品功能/用户动线/闭环 → A类 → role-产品经理
├── 涉及接口/架构/模块边界 → B类 → role-技术架构师
├── 涉及代码文件 → C类 → role-后端/前端 → verifier
├── 涉及文档组织/版本/内容 → D类 → doc-consolidator
└── 涉及 Skill/Rule 文件 → E类 → skill-rule-修改规范
```

---

## 常见失败模式

**失败模式1**：用户描述的「规范问题」实际上是「功能需求」，而不是现有规范的偏差
→ 预防：Step 3 确认时，区分「当前已有规范要求X，实现做了Y」vs「希望新增规范要求Z」
→ 如果是新需求 → 路由到 role-产品经理 但不走修复路径，走功能设计路径

**失败模式2**：A/B 类规范修复后，未同步检查是否引起连锁影响
→ 预防：B 类技术架构修复后，提示「架构变更可能影响已有代码，建议运行 role-测试工程师 关卡C」

**失败模式3**：E 类 Skill/Rule 修复被静默执行，未通过三问+备份
→ 预防：E 类强制要求先加载 skill-rule-修改规范，不允许跳过

---

## 与现有组件的关系

| 组件 | 关系 |
|---|---|
| `issue-tracker` | 本 Skill 先调用 issue-tracker 记录，再继续执行（issue-tracker 是本 Skill 的 Step 1）|
| `role-产品经理` | A 类问题的执行 Skill |
| `role-技术架构师` | B 类问题的执行 Skill |
| `role-后端/前端开发` | C 类问题的执行 Skill |
| `doc-consolidator` | D 类问题的执行 Skill |
| `skill-rule-修改规范` | E 类问题的执行 Skill（不绕过，必须经过）|
| `verifier` | C 类代码修复后的验证 |
| `architecture-gap-mapper` | B 类问题分析时可选调用 |

### v1.0 → v1.1 — 2026-03-22 — Step 5 E类补修复后重验证建议（GAP-SK017-2 修复）

**根因**：scenario-sandbox-builder Phase 2 验证（SK-017沙盘）发现：Step 5 A/B/D/E类修复完成后只做人工确认，缺少「修复后重新运行 skill-system-health-check」的闭环验证步骤。导致Skill体系健康检查发现的P0问题修复后无法自动验证是否真正消解。

**修改内容**：
- 修改：Step 5 A/B/D/E类 → 在「等待用户确认」后追加：若修复来源为 skill-system-health-check 报告，建议修复完成后重新运行健康检查验证
- 备份路径：`history/SKILL_v1.0_20260322_before_sk017b.md`

**验证方法**：E类修复完成后，Skill 应提示「建议重新运行 skill-system-health-check 验证该问题已消解」
**验证状态**：🔵 待验证

---

## 注意事项

- **Step 3 必须等用户确认**：不允许静默执行修复，规范修复可能有错误判断
- **E 类不能绕过 skill-rule-修改规范**：Skill/Rule 修改的三问+备份是强制要求
- **B 类架构修复必须回 PM 确认**：技术架构变更可能影响产品定义，必须 PM 知情
- **C 类代码修复后强制 verifier**：遵循 role-后端/前端开发 的「Bug 修复后强制验证闭环」规则

---

## 变更记录

### v1.0 — 2026-03-19 — 初始创建

**根因**：项目内规范问题缺少「接收→分类→路由执行→验证」的完整链路。issue-tracker 只记录不执行，规范修复依赖用户记忆力手动触发对应角色 Skill。本 Skill 补完这个链路，使项目规范问题的处理与 Skill 体系自驱机制对等。

**强绑定 Rule**：R2 NO_FABRICATION / R3 READ_FIRST / R7 CLOSED_LOOP_REQUIRED

**验证状态**：🔵 待验证（关卡A/B/C 已通过设计阶段模拟）