关于 code-analyzer
code-analyzer 是用于静态代码分析与指标检查的技能，供代码审查和重构工作使用。它通过项目级分析、热点筛选及趋势跟踪，帮助确定改进重点。
主要功能
- 01分析单个文件或整个项目
- 02计算圈复杂度与可维护性指标
- 03统计代码行并查找重复块
- 04识别复杂度热点
- 05跟踪指标趋势
适用场景
- 01审查项目整体代码质量
- 02定位高复杂度文件
- 03为重构选择优先目标
- 04持续监测代码指标变化
安装
复制下面的命令，在终端中运行。
npx skills add https:/安装后在 Claude Code 中输入/code-analyzer确认已加载。
包含的文件
除 SKILL.md 外，安装时一起下载的参考资料和脚本。
commands/code-analyzer.mdhooks/post-execute.cjspre-execute.cjsreferences/research-requirements.mdrules/code-analyzer.mdschemas/input.schema.jsonoutput.schema.jsonscripts/main.cjstemplates/implementation-template.md详细介绍
代码分析器技能
安装
无需单独下载：此技能运行仓库内的工具 .claude/tools/analysis/project-analyzer/analyzer.mjs。
- 确保已安装 Node.js（v18+）：可从 nodejs.org 下载，或使用
winget install OpenJS.NodeJS.LTS（Windows）、brew install node（macOS）安装。 - 在项目根目录中，脚本会自动调用；无需额外安装步骤。
速查表与最佳实践
指标： 重点关注圈复杂度（决策路径）、LOC、可维护性指数和重复代码块。对 JS/TS 使用 ESLint complexity 规则（例如 "complexity": ["error", 15]）；可选链和默认参数会增加分支。
流程： 重构前先分析；先运行全项目分析，再深入查看热点。持续跟踪趋势，而不是只分析一次。除复杂度外，同时使用 max-depth、max-lines、max-nested-callbacks、max-params、max-statements。
技巧： 先查看 project-analyzer 的输出；按文件类型和阈值筛选。优先处理复杂度高且变更频繁的文件。只有在无法设定合理限制时才禁用复杂度规则；优先降低阈值，而非禁用规则。
认证与培训
**没有单一认证；**但与静态分析和 ESLint 复杂度规则相契合。ESLint： complexity 规则、max-depth、max-lines、max-params。技能数据： 圈复杂度、LOC、可维护性、重复代码；重构前进行分析；跟踪热点和趋势。
钩子与工作流
建议的钩子： 在提交前或 CI 中运行 project-analyzer/doctor 检查健康状况；可选设置复杂度门槛。与 developer（次要）、qa（次要）、code-reviewer（主要）搭配使用。
工作流： 与 code-reviewer（主要）、developer/ qa（次要）、c4-code（主要）搭配使用。流程：运行分析器 → 筛选热点 → 重构或添加测试。参见 code-review-workflow.md。
概述
静态代码分析与指标。节省 90% 以上的上下文。
工具（渐进式披露）
分析
| 工具 | 描述 |
|---|---|
| analyze-file | 分析单个文件 |
| analyze-project | 分析整个项目 |
| complexity | 计算复杂度指标 |
指标
| 工具 | 描述 |
|---|---|
| loc | 代码行数 |
| cyclomatic | 圈复杂度 |
| maintainability | 可维护性指数 |
| duplicates | 查找重复代码 |
报告
| 工具 | 描述 |
|---|---|
| summary | 获取分析摘要 |
| hotspots | 查找复杂度热点 |
| trends | 分析指标趋势 |
Agent 集成
- code-reviewer（主要）：代码审查
- refactoring-specialist（主要）：技术债务分析
- architect（次要）：架构评估
铁律
- 始终先运行全项目分析，再深入查看单个文件 — 缺少上下文的局部分析无法发现哪些文件才是真正优先级最高的热点；先全面分析，再聚焦重点。
- 始终聚焦复杂度高且变更频繁的文件 — 复杂但很少修改的文件，优先级低于中等复杂度但经常修改的文件；两者的交集最重要。
- 复杂度阈值绝不可设为高于 20 — 圈复杂度 >20 与缺陷存在明确相关性；允许复杂度 >20 的团队会在不知不觉中积累难以维护的代码。
- 始终持续跟踪指标，而非只分析一次 — 单次分析快照毫无意义；每周跟踪趋势，以便在逐渐恶化演变为危机前及时发现。
- 报告指标时绝不可不提供可执行的后续步骤 — 没有重构目标的复杂度数字毫无价值；每项高复杂度发现都必须包含具体的改进建议。
反模式
| 反模式 | 为什么会失败 | 正确做法 |
|---|---|---|
| 只分析已更改的文件 | 会遗漏跨文件复杂度的累积 | 先分析整个项目，再筛选已更改的热点 |
| 长期忽略高复杂度文件 | 渐进式退化在某个时间点的分析中难以察觉 | 每周跟踪趋势；任何增长都发出警报 |
| 复杂度阈值 >20 | 研究表明，缺陷率在复杂度超过 20 后会急剧上升 | 将 ESLint 复杂度规则设为 ≤15，以便强制执行 |
| 报告指标但不附带行动项 | 没有整改措施的指标无法降低复杂度 | 为每个热点附上具体的重构建议 |
| 只运行一次分析并忽略结果 | 技术债务会悄然累积 | 安排每周自动分析并生成趋势报告 |
记忆协议（强制）
开始之前：
阅读 .claude/context/memory/learnings.md
完成之后：
- 新模式 ->
.claude/context/memory/learnings.md - 发现问题 ->
.claude/context/memory/issues.md - 做出决策 ->
.claude/context/memory/decisions.md
假设会被打断：如果没有记录在记忆中，就等于没有发生。