mcpField
C
code-quality

code-quality

github.com/fusengine测试与质量3454 次安装今天更新
代码仓库

关于 code-quality

Code Quality 是一套用于代码修复后质量验证的七阶段技能，适用于跨语言代码库。它先探索架构、查阅文档并分析影响，再检查重复与错误，修正后重新验证；不负责确认原始问题是否解决。

主要功能

  1. 01按七阶段执行质量检查
  2. 02分析架构、文档与代码影响
  3. 03使用 jscpd 检测重复代码
  4. 04通过 Linters 检查错误
  5. 05修正后重跑 Linters、测试与重复检测
  6. 06覆盖 SOLID 与架构规则

适用场景

  1. 01功能问题解决后检查代码质量
  2. 02修复前评估修改影响范围
  3. 03查找重复代码并指导重构
  4. 04验证修正未引入新的检查错误

安装

复制下面的命令，在终端中运行。

$npx skills add https://github.com/fusengine/agents --skill code-quality

安装后在 Claude Code 中输入/code-quality确认已加载。

包含的文件

除 SKILL.md 外，安装时一起下载的参考资料和脚本。

references/
architecture-patterns.md
duplication-thresholds.md
examples.md
file-size-rules.md
linter-commands.md
solid-validation.md
validation-report.md

详细介绍

Code Quality 是与 `sniper` agent 共享的规范 7 阶段验证工作流（此技能与 `agents/sniper.md` 必须保持同步）：探索架构、研究文档、通过 Grep 用法分析影响、使用 jscpd 检测重复代码（DRY）、通过 linter 检测错误、根据文档／影响／DRY 分析结果进行精准修正，然后反复重新验证，直至 linter、测试和重复代码检查全部通过。该工作流涵盖所有语言的 SOLID 合规性、DRY 阈值、错误优先级（安全／逻辑／性能／风格）、文件大小限制和架构模式违规。

它会在事后验证代码质量——不会确认原始问题是否确实已解决。先运行 verification 技能确认功能问题已解决，再运行 code-quality 确认修复符合质量要求。

Code Quality 技能

规范工作流定义：agents/sniper.md（此技能与 sniper agent 共享同一套 7 阶段工作流——请同时更新两者）。

🚨 强制执行的 7 阶段工作流

PHASE 1: Exploration (explore-codebase) → BLOCKER
PHASE 2: Documentation (research-expert) → BLOCKER
PHASE 3: Impact Analysis (Grep usages) → BLOCKER
PHASE 3.5: DRY Detection (jscpd duplication) → NON-BLOCKING
PHASE 4: Error Detection (linters)
PHASE 5: Precision Correction (with docs + impact + DRY)
PHASE 6: Verification (re-run linters, tests, duplication)

重要：第 1–3 阶段是阻断性阶段。绝不可跳过。 DRY：第 3.5 阶段不具阻断性，但其发现结果会为第 5 阶段的修正提供依据。

阶段 1：架构探索

首先启动 explore-codebase agent：

> Agent(subagent_type="fuse-ai-pilot:explore-codebase", prompt="...")

收集：

  1. 检测到的编程语言
  2. 现有的 linter 配置（.eslintrc、.prettierrc、pyproject.toml）
  3. 包管理器和已安装的 linter
  4. 项目结构和约定
  5. 框架版本（package.json、go.mod、Cargo.toml）
  6. 架构模式（Clean、Hexagonal、MVC）
  7. 状态管理（Zustand、Redux、Context）
  8. 接口／类型目录的位置

阶段 2：文档研究

启动 research-expert agent：

> Agent(subagent_type="fuse-ai-pilot:research-expert", prompt="Verify [library/framework] documentation for [error type]. Find [language] best practices for [specific issue].")

针对每个错误，请求：

  • 官方 API 文档
  • 当前语法和弃用信息
  • 错误模式的最佳实践
  • 特定版本的破坏性变更
  • 安全公告
  • 特定语言的 SOLID 模式

阶段 3：影响分析

对于每个要修改的元素：通过 Grep 查找用法 → 评估风险 → 记录影响。

风险标准操作
🟢 低内部使用，0–1 处用法继续
🟡 中2–5 处用法，兼容谨慎继续
🔴 高5 处以上用法或存在破坏性变更先告知用户

阶段 3.5：代码重复检测（DRY）

工具：jscpd — 支持 150 多种语言 — npx jscpd ./src --threshold 5 --reporters console,json

级别阈值操作
🟢 优秀< 3%无需处理
🟡 良好3–5%记录，时间允许时修复
🟠 可接受5–10%提取共享逻辑
🔴 严重> 10%必须重构

每种语言的阈值、配置和提取模式，请参阅 references/duplication-thresholds.md。 各语言对应的 jscpd 命令，请参阅 references/linter-commands.md。

Linter 命令

各语言对应的命令，请参阅 references/linter-commands.md。

错误优先级矩阵

优先级类型示例操作
严重安全SQL 注入、XSS、CSRF、身份验证绕过立即修复
高逻辑SOLID 违规、内存泄漏、竞态条件在同一会话中修复
高DRY代码重复率 > 10%、复制粘贴的逻辑块必须重构
中DRY代码重复率 5–10%、重复模式提取共享逻辑
中性能N+1 查询、已弃用 API、低效算法时间允许时修复
低风格格式、命名、缺少文档时间允许时修复

SOLID 验证

S-O-L-I-D 检测模式和修复示例，请参阅 references/solid-validation.md。

文件大小规则

LoC 限制、计算方法和拆分策略，请参阅 references/file-size-rules.md。

架构规则

有关项目结构和模式，请参阅 references/architecture-patterns.md。

验证报告格式

完整的狙击报告模板请参阅 references/validation-report.md。

完整工作流示例

详细演练请参阅 references/examples.md。

禁止行为

工作流违规
  • ❌ 跳过阶段 1（探索代码库）
  • ❌ 跳过阶段 2（专家调研）
  • ❌ 跳过阶段 3（影响分析）
  • ❌ 跳过阶段 3.5（DRY 检测）
  • ❌ 未完成阶段 1–3 就开始修正
  • ❌ 阻塞项仍处于激活状态时继续
代码质量违规
  • ❌ 留下任何未修复的 linter 错误
  • ❌ 应用会引入新错误的修复
  • ❌ 忽略 SOLID 违规
  • ❌ 忽略超过 5% 的 DRY 违规
  • ❌ 复制粘贴代码，而不是提取共享逻辑
  • ❌ 在项目没有测试的情况下创建测试
架构违规
  • ❌ 在组件文件中定义接口（零容忍）
  • ❌ 在组件中编写业务逻辑（必须放在 hooks 中）
  • ❌ 创建单体组件（必须拆分）
  • ❌ 文件超过 100 行代码却不拆分
  • ❌ 使用局部状态存储全局数据（应使用 stores）
安全违规
  • ❌ 未经用户批准进行高风险更改
  • ❌ 悄然破坏向后兼容性
  • ❌ 在没有弃用机制的情况下修改公共 API

评论

支持 Markdown