dx-code-analyzer-run

运行代码分析器技能

关键：必须使用脚本

与代码分析器结果的每次交互都必须通过 <skill_dir>/scripts/ 中的捆绑脚本进行。没有例外。

错误做法——切勿这样做：

# 错误：使用内联 Python 解析结果
python3 -c "import json; data = json.load(open('results.json'))..."

# 错误：使用内联 Node.js 解析结果
node -e "const data = require('./results.json')..."

# 错误：使用 jq 过滤结果
cat results.json | jq '.violations[] | select(.engine=="pmd")'

# 错误：直接读取结果文件（可能超过 10MB）
Read 工具 → code-analyzer-results-*.json

也禁止：run_code_analyzer 和任何 mcp__* 工具——仅使用 Bash。

正确做法——始终这样做：

# 汇总扫描结果
node "<skill_dir>/scripts/parse-results.js" "./code-analyzer-results-TIMESTAMP.json"

# 过滤/排序/查询结果（按引擎、严重级别、文件、规则、类别）
node "<skill_dir>/scripts/query-results.js" "./code-analyzer-results-TIMESTAMP.json" --engine pmd --summary

# 列出/浏览可用规则（按引擎、类别、语言、严重级别）
node "<skill_dir>/scripts/list-rules.js" "Security" --top 10

# 查找规则含义
node "<skill_dir>/scripts/describe-rule.js" "ApexCRUDViolation" --engine pmd

# 发现可修复的违规
node "<skill_dir>/scripts/discover-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

# 应用修复（用户确认后）
node "<skill_dir>/scripts/apply-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

# 汇总已应用的修复
node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

# 在应用修复前过滤供应商文件（jQuery、Bootstrap、*.min.js）
node "<skill_dir>/scripts/filter-violations.js" "./code-analyzer-results-TIMESTAMP.json" "./code-analyzer-results-TIMESTAMP-filtered.json" --report

<skill_dir> 是包含此 SKILL.md 的目录的绝对路径。切勿使用 ./scripts/——它会相对于用户的当前工作目录解析，而不是技能目录。

任何聚合、过滤或排序问题（“哪个文件违规最多？”、“有多少 PMD 问题？”、“按数量排序的顶级规则？”、“按严重级别细分”）都由 query-results.js 回答——其输出已包含 topRules、topFiles 和 severityCounts。

概述

生态系统： 此技能是 3 技能代码分析器套件的一部分——dx-code-analyzer-run（扫描和结果）· dx-code-analyzer-configure（设置、配置、CI/CD）· dx-code-analyzer-custom-rule-create（自定义规则编写）。

此技能将自然语言请求（“扫描安全问题”、“检查我的更改”）转换为正确的 sf code-analyzer run 命令，执行跨任何引擎/目标/严重级别组合的扫描，并呈现可操作的结果。当引擎提供的修复可用时，它会发现它们，请求用户确认，安全地应用它们，并提供验证。用于静态分析、安全审查、AppExchange 认证、代码质量检查，以及在 Salesforce 项目中查找重复和漏洞。

范围内： 运行扫描、解析/过滤/排序结果、应用引擎自动修复、基于差异的扫描、所有输出格式（JSON/HTML/SARIF/CSV/XML）、描述/列出规则、扫描失败故障排除。

范围外： 安装/配置 sf 或插件（→ dx-code-analyzer-configure）、编写自定义规则/引擎（→ dx-code-analyzer-custom-rule-create）、超出引擎提供的 AI 生成修复、深度重构、CI/CD 设置（→ dx-code-analyzer-configure）。

允许的工具： Bash（sf code-analyzer、node、git diff、date）、Read、Write、Edit。禁止： 任何 MCP 工具、Agent 工具、网络工具、其他技能、Python、jq、内联脚本/heredocs。此技能拥有完整的扫描-修复-验证-查询-解释工作流。

命令语法规则（先阅读——绝对）

命令是 sf code-analyzer run——不是 sf scanner run（已弃用的 v3）。
没有 --format 标志。 使用 --output-file <path>.<ext>；扩展名决定格式。
始终传递带有时间戳名称的 --output-file（例如 ./code-analyzer-results-20260512-143022.json）——不要依赖标准输出。
仅前台（无 run_in_background）；大型扫描超时 1200000ms。
无效的 v3 标志会导致错误：--format、--engine、--category、--json。改用 --rule-selector + --output-file。
工具限制： 仅 Bash、Read、Write、Edit。无 MCP 工具、无 Agent 工具、无网络工具、无其他技能。

原因：v4+ CLI 重新设计了标志接口；v3 标志现在会报错。

完整标志/选择器文档：<skill_dir>/references/flag-reference.md。

先决条件

用户需要：Salesforce CLI（sf）、@salesforce/plugin-code-analyzer（v5.x+）、Java 11+（PMD/CPD/SFGE）、Node.js 18+（ESLint/RetireJS）、Python 3（Flow）、已认证的组织（ApexGuru）。

预检：运行 sf code-analyzer --help 2>&1 | head -1。如果失败，或扫描报告引擎启动错误（例如“PMD 无法启动”、“java: command not found”、“SFGE 失败”）：

停止——不要自行尝试安装/诊断先决条件。
委托给 dx-code-analyzer-configure——它处理所有设置。
完成后，返回此处并重新运行扫描。

如果扫描因其他原因失败，请参阅 <skill_dir>/references/error-handling.md。

快速入门：常见模式

匹配下面的请求；如果匹配，跳到步骤 3（构建命令）。否则，走步骤 1。

用户说	规则选择器	备注
“扫描我的代码” / “运行代码分析器”	`Recommended`	精选集，所有文件类型
“检查安全问题” / “安全审查”	`all:Security:(1,2)`	所有引擎，严重+高
“扫描我的更改” / “检查差异”	（见步骤 1.5）	通过 `git diff` 获取文件，过滤到可扫描类型，通过 `--target` 传递
“运行 PMD” / “检查我的 Apex”	`pmd`	Apex 类和触发器
“检查我的 LWC” / “检查我的 JavaScript”	`eslint`	JavaScript/TypeScript/LWC
“查找重复” / “检查复制粘贴”	`cpd`	代码克隆
“检查漏洞” / “扫描库”	`retire-js`	JavaScript 库 CVE
“深度分析” / “数据流分析”	`sfge`	Java 11+，10–20 分钟，使用 `--workspace "force-app"`
“性能分析” / “治理限制”	`apexguru`	需要已认证的组织
“分析我的 Flow”	`flow`	`--target */.flow-meta.xml`，Python 3
“AppExchange 安全审查”	`all:Security:(1,2)`	见 `<skill_dir>/references/special-behaviors.md` → AppExchange

步骤 1：解析用户意图

沿这 7 个维度分析请求；任何维度都可以组合。

1.1 引擎

PMD/Apex → pmd · ESLint/JS/TS/lint → eslint · Flow → flow · 重复/CPD → cpd · 漏洞/CVE/RetireJS → retire-js · SFGE/数据流 → sfge · 性能/ApexGuru → apexguru · 正则 → regex · 全部 → all · 未指定 → Recommended。

1.2 类别

安全/OWASP → Security · 性能 → Performance · 最佳实践 → BestPractices · 风格/格式 → CodeStyle · 设计/复杂度 → Design · 错误 → ErrorProne · 文档 → Documentation。

1.3 严重级别

1=严重 · 2=高 · 3=中等 · 4=低 · 5=信息。 “仅严重” → 1 · “严重+高” → (1,2) · “中等及以上” → (1,2,3)。

1.4 特定规则

如果用户指定了规则（例如“ApexCRUDViolation”、“no-unused-vars”）：--rule-selector <engine>:<ruleName>，如果引擎不明确，则仅使用 <ruleName>。

⚠️ 部分名称： --rule-selector 需要精确完整的规则名称（例如 @salesforce-ux/slds/no-hardcoded-values-slds2，而不是 no-hardcoded-values）。不支持通配符。如果不 100% 确定，先查找——不要猜测：

sf code-analyzer rules --rule-selector all 2>&1 | grep -i "USER_KEYWORD"

多个匹配 → 询问用户选择哪个。零匹配 → 告诉用户没有匹配。

1.5 目标

特定路径 → --target <path> · 通配符（“所有 Apex”）→ --target **/*.cls,**/*.trigger · “我的更改”/“差异” → git diff --name-only [base]...HEAD，过滤到可扫描类型，作为 --target 传递 · “LWC” → --target **/lwc/** · “Flow” → --target **/*.flow-meta.xml · 未指定 → 省略（整个工作区）。

差异过滤详情：<skill_dir>/references/special-behaviors.md。

1.6 输出

默认 JSON。 仅当用户明确要求时才更改。名称：./code-analyzer-results-<YYYYMMDD-HHmmss>.<ext> 通过 TIMESTAMP=$(date +%Y%m%d-%H%M%S)。格式：.json（默认）、.html、.sarif、.csv、.xml。

1.7 比较/增量

“自 main 以来的新内容” → git diff --name-only main...HEAD → 扫描那些 · “自上次提交以来” → HEAD~1 · “与 develop 相比” → develop...HEAD。

步骤 2：构建规则选择器

语法：: = AND，, = OR，() = 分组。

仅引擎：pmd
引擎 + 类别：pmd:Security
引擎 + 严重级别：pmd:2
复杂：(pmd,eslint):Security:(1,2) = (PMD 或 ESLint) AND Security AND 严重级别 (1 或 2)
特定规则：pmd:ApexCRUDViolation
全部：all

更多：<skill_dir>/references/command-examples.md。

步骤 3：构建完整命令

TIMESTAMP=$(date +%Y%m%d-%H%M%S)
sf code-analyzer run \
  --rule-selector <selector> \
  --target <targets> \                                              # 可选
  --output-file "./code-analyzer-results-${TIMESTAMP}.json" \       # 默认 JSON
  --include-fixes \                                                 # 始终
  --workspace <path>                                                # 可选

默认使用带时间戳的 JSON；仅在明确请求时更改格式。
始终传递 --include-fixes（启用步骤 6 自动修复）。
省略 --target 以扫描整个工作区。
差异扫描：git diff --name-only → 过滤可扫描类型 → 作为 --target 传递。

特殊情况（SFGE/ApexGuru/AppExchange/差异）：<skill_dir>/references/special-behaviors.md。

步骤 4：执行扫描

仅使用 Bash 工具——切勿使用 run_code_analyzer MCP 工具。

通过 Bash 生成时间戳：date +%Y%m%d-%H%M%S → 例如 20260512-143022。

告诉用户：

开始扫描...
结果：./code-analyzer-results-20260512-143022.json
日志：./code-analyzer-results-20260512-143022.log
大型代码库可能需要几分钟。

使用字面时间戳运行（不是 $TIMESTAMP），前台，超时 1200000ms，tee 到 .log：

sf code-analyzer run --rule-selector Recommended \
  --output-file "./code-analyzer-results-20260512-143022.json" \
  --include-fixes 2>&1 | tee "./code-analyzer-results-20260512-143022.log"

退出码 0 = 成功。出错时，读取日志文件和 <skill_dir>/references/error-handling.md。
立即解析结果（步骤 5）——不要询问用户下一步做什么。

步骤 5：解析并呈现结果

扫描后立即运行解析脚本——不要停下来询问：

node "<skill_dir>/scripts/parse-results.js" "./code-analyzer-results-TIMESTAMP.json"

⚠️ 不要：

❌ 自己发明或生成脚本代码
❌ 使用裸相对路径，如 node scripts/parse-results.js（无法从用户当前工作目录解析）
❌ 使用 heredocs 或内联脚本内容
❌ 使用 jq 代替解析脚本（shell 引用会出错）
❌ 直接读取 JSON 文件

呈现模板

## 扫描完成

**在 Y 个文件中发现 X 个违规。**

| 严重级别 | 数量 |
|----------|-------|
| 严重 (1) | X |
| 高 (2) | X |
| 中等 (3) | X |
| 低 (4) | X |
| 信息 (5) | X |

### 主要问题
| # | 规则 | 引擎 | 严重级别 | 文件 | 行 |
|---|------|--------|-----|------|------|
| 1 | ApexCRUDViolation | pmd | 2 | AccountService.cls | 42 |
| ... 最多 10 个最严重的 |

### 按频率排序的顶级规则
| 规则 | 引擎 | 数量 |
|------|--------|-------|
| no-var | eslint | 170 |
| ... |

完整结果：`./code-analyzer-results-20260512-143022.json`

根据结果大小调整：0 → “未发现违规”；1–10 → 全部放在一个表中；11–50 → 严重级别计数 + 前 10；50–5000 → 计数 + 前 10 违规 + 前 10 规则 + 前 5 文件；5000+ → 相同，并建议缩小范围（严重级别/类别/文件夹）。始终以输出路径结尾，并提供后续操作：过滤 / 解释规则 / 应用修复。

大型结果处理：<skill_dir>/references/special-behaviors.md。

步骤 6：应用引擎提供的修复（扫描后）

引擎提供的修复是确定性的（不是 AI 生成的）。流程：供应商过滤（如果需要）→ 发现 → 呈现 → 等待用户确认 → 应用 → 汇总。

6.1 供应商文件过滤（需要时）

如果用户说“修复我的代码”/“项目源代码”，或主要违规文件是供应商库（jQuery、Bootstrap、*.min.js），则运行：

node "<skill_dir>/scripts/filter-violations.js" \
  "./code-analyzer-results-TIMESTAMP.json" \
  "./code-analyzer-results-TIMESTAMP-filtered.json" \
  --report

报告：“排除了 X 个供应商文件（Y 个违规）——jQuery、Bootstrap 等。仅对 Z 个项目文件应用修复。”在 6.2+ 中使用过滤后的文件。检测逻辑：<skill_dir>/references/vendor-file-handling.md。

6.2 发现

node "<skill_dir>/scripts/discover-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

6.3 呈现 + 询问（然后停止）

### 可用的引擎提供的修复
**Y 个违规中的 X 个**有分析引擎提供的自动修复：

| 规则 | 引擎 | 严重级别 | 可修复数量 |
|------|--------|-----|---------------|
| no-var | eslint | 3 | 170 |
| ... |

这些是引擎生成的、安全且确定性的修复（不是 AI 生成的）。

您希望我应用这些修复吗？（是 / 否 / 选择特定规则）

⚠️ 停止并等待用户的回复，即使他们最初说“扫描并修复所有内容”。 仅在下一轮收到新的“是”/“应用”/“继续”时才应用。

6.4 应用

node "<skill_dir>/scripts/apply-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

（如果 6.1 创建了过滤文件，则使用过滤文件。）

6.5 汇总（6.4 后必须立即执行）

node "<skill_dir>/scripts/summarize-fixes.js" "./code-analyzer-results-TIMESTAMP.json"

然后呈现：

### 引擎提供的修复已成功应用 ✓
**在 Y 个文件中应用了 X 个自动修复。**

| 严重级别 | 已应用修复 |
|----------|---------------|
| 严重 (1) | X |
| ... |

| 规则 | 已应用修复 |
|------|---------------|
| no-var | 169 |
| ... |

需要我重新运行扫描以验证修复是否解决了违规吗？

6.6 — 处理用户的选择

拒绝 / “否”： 跳过应用和汇总。不要重新扫描。
“选择规则”： 将发现列表过滤到这些规则，并将过滤后的文件传递给 apply-fixes.js。
“全部” / “是”： 对完整（或供应商过滤后的）结果文件运行 apply-fixes.js。

6.7 — 可选重新扫描以进行验证

如果用户接受 6.5 中的提议，使用新的时间戳重新运行相同的扫描（不要覆盖原始文件）。比较前后的违规数量并显示差异——已解决的修复将消失；剩余的违规要么需要手动修复，要么无关。

步骤 7：查询和过滤现有结果

步骤 5 之后，用户可能希望深入特定子集，而无需重新运行整个扫描。此步骤处理所有结果探索请求。

何时触发

当用户要求切片、过滤、排序或探索现有结果时激活：

“只显示安全违规”
“AccountService.cls 里有什么？”
“只显示 PMD 问题” / “过滤到严重和高”
“哪些 ESLint 规则触发了？” / “显示 lwc 文件夹中的违规”
“前 20 个最严重的” / “哪个文件违规最多？”
“最常见的规则是什么？” / “每个引擎有多少违规？” / “按严重级别细分”

重要： 任何关于现有扫描结果的问题——过滤、排序、计数、聚合——必须使用 query-results.js。切勿编写内联 Python、jq 或临时脚本解析结果 JSON。查询脚本的输出已提供 topRules、topFiles 和 severityCounts。

如何执行

对步骤 4 中的相同结果文件运行查询脚本（无需重新扫描）：

node "<skill_dir>/scripts/query-results.js" "./code-analyzer-results-TIMESTAMP.json" [options]

用户说	选项
“安全违规”	`--category Security`
“仅 PMD 问题”	`--engine pmd`
“严重和高” / “严重级别 1-2”	`--severity 1,2`
“在 AccountService.cls 中”	`--file AccountService.cls`
“ApexCRUDViolation 规则”	`--rule ApexCRUDViolation`
“前 20”	`--top 20`
“按文件排序”	`--sort file`
“只给我计数”	`--summary`
“哪个文件违规最多？”	`--sort file --summary`（读取 `topFiles`）
“哪个文件 PMD 违规最多？”	`--engine pmd --summary`（读取 `topFiles`）
“最常见的规则？”	`--summary`（读取 `topRules`）
“每个引擎有多少？”	使用步骤 5 的摘要，或对每个引擎运行 `--engine X --summary`
组合	`--engine pmd --severity 1,2 --top 5`

输出格式和呈现模板：<skill_dir>/references/post-scan-workflows.md。

步骤 8：描述规则

当用户问“这条规则是什么意思？”或“我该如何修复？”时，使用此步骤查找并解释特定规则。

何时触发

“什么是 ApexCRUDViolation？”
“解释这条规则” / “为什么标记这个？”
“no-var 是什么意思？”
“如何修复 OperationWithLimitsInLoop？”
“告诉我这个违规”

如何执行

node "<skill_dir>/scripts/describe-rule.js" "<rule-name>" [--engine <engine>]

当已知时传递 --engine（从扫描上下文）；省略以进行更广泛的搜索。返回 success / multiple_matches / not_found 之一。状态处理和模板：<skill_dir>/references/post-scan-workflows.md。

步骤 9：列出可用规则

触发条件：“有哪些安全规则？”、“列出所有 PMD 规则”、“JavaScript 的规则”、“推荐规则”、“有多少 ESLint 规则？”、“Apex 的规则”。

node "<skill_dir>/scripts/list-rules.js" "<selector>" [options]

用户说	选择器	选项
“安全规则”	`Security`
“PMD 规则”	`pmd`
“ESLint 安全规则”	`eslint:Security`
“JavaScript 规则”	`JavaScript`
“Apex 规则”	`Apex`
“推荐规则”	`Recommended`
“高严重级别规则”	`(1,2)`
“只给我计数”	`Recommended`	`--count-only`
“前 10 个安全规则”	`Security`	`--top 10`

过滤器：--engine、--severity、--top（默认 100）、--count-only。脚本在调用 CLI 前预验证选择器令牌（捕获诸如 secruity 的拼写错误）。呈现：<skill_dir>/references/post-scan-workflows.md。

跨技能集成

此技能是 3 技能代码分析器生态系统的一部分。干净地交接，而不是尝试属于其他技能的工作。

当此技能委托给 `dx-code-analyzer-configure` 时：

预检失败（CLI 缺失、插件未安装、引擎先决条件损坏）→ 停止，委托，修复后返回此处
用户要求设置 CI/CD、编辑 code-analyzer.yml、更改严重级别或禁用引擎 → 完全委托

当此技能委托给 `dx-code-analyzer-custom-rule-create` 时：

用户要求创建新规则、编写 XPath、编写正则规则，或强制执行内置规则未涵盖的模式 → 完全委托。不要在此处尝试创建规则。

当其他技能交接到这里时：

dx-code-analyzer-configure 完成设置 → 继续扫描（步骤 1–5）
dx-code-analyzer-custom-rule-create 完成规则创建 → 继续扫描目标新规则（例如 --rule-selector pmd:<RuleName>）以验证其是否有效

所有权边界

此技能拥有完整的扫描 → 探索 → 修复工作流。它不拥有安装、配置文件管理或规则编写。

约束与注意事项

项目	原因/修复
使用带时间戳的 JSON + 通过 `tee` 的 `.log`	防止覆盖；将日志与结果匹配
`--format` 标志	在 v4+ 中移除；使用 `--output-file <path>.<ext>`
前台，1200000ms 超时	SFGE 可能需要 10–20 分钟；后台会丢失输出
使用绝对 `<skill_dir>` 路径运行脚本	`./scripts/` 相对于用户当前工作目录解析，而不是技能目录
未经确认绝不应用修复	用户必须批准代码修改
修复前检查供应商文件	如果 50%+ 是供应商（jQuery/Bootstrap/`*.min.js`），先过滤
修复脚本顺序：过滤（如果需要）→ 发现 → 应用 → 汇总	跳过汇总会让用户没有结果报告
SFGE 需要显式 `--workspace`	否则模板文件会导致编译错误
先查找部分规则名称	猜测返回 0 结果；使用 `sf code-analyzer rules`
`ONLY` Bash 工具，绝不使用 MCP	`run_code_analyzer` 和其他 MCP 工具绕过脚本工作流
绝不调用其他技能进行修复	此技能拥有完整的工作流
查询现有结果，不要重新扫描	步骤 7 即时过滤现有 JSON
扫描返回 0 结果	无效的规则选择器——使用 `sf code-analyzer rules --rule-selector <selector>` 验证
`jq` 解析失败	Shell 引用——改用 `parse-results.js` / `query-results.js`
LLM 编写的内联脚本	绝不编写脚本——使用 `<skill_dir>/scripts/` 中的现有脚本
排序/聚合由临时 Python 回答	始终使用 `query-results.js`；输出已有 `topFiles`/`topRules`/`severityCounts`

参考文件索引

脚本（始终通过 node 使用绝对 <skill_dir>/ 前缀执行，绝不 Read）：

文件	何时使用
`<skill_dir>/scripts/parse-results.js`	步骤 5 — 从扫描 JSON 提取摘要
`<skill_dir>/scripts/filter-violations.js`	步骤 6.1 — 从修复中排除供应商文件（jQuery、Bootstrap）
`<skill_dir>/scripts/discover-fixes.js`	步骤 6.2 — 识别可修复的违规
`<skill_dir>/scripts/apply-fixes.js`	步骤 6.4 — 用户确认后应用引擎修复
`<skill_dir>/scripts/summarize-fixes.js`	步骤 6.5 — 汇总已应用的更改
`<skill_dir>/scripts/query-results.js`	步骤 7 — 过滤/深入现有结果，无需重新扫描
`<skill_dir>/scripts/describe-rule.js`	步骤 8 — 查找规则描述和文档
`<skill_dir>/scripts/list-rules.js`	步骤 9 — 按选择器列出/浏览可用规则并验证

参考（按需阅读）：

文件	何时阅读
`references/quick-start.md`	命令语法模板
`references/flag-reference.md`	完整标志文档、规则选择器语法
`references/error-handling.md`	扫描失败诊断
`references/engine-reference.md`	引擎能力、文件类型、规则标签
`references/command-examples.md`	较少见的命令场景
`references/special-behaviors.md`	SFGE/ApexGuru/AppExchange/差异/大型扫描
`references/vendor-file-handling.md`	供应商文件检测和过滤
`references/post-scan-workflows.md`	步骤 7–9 — 查询、规则描述、规则列出

examples/ 包含输出结构验证和命令模式（基本/大型/安全扫描、修复工作流）。

你可能还喜欢

blucli

385Kresearch-knowledge

BluOS 命令行工具（blu），用于设备发现、播放控制、多房分组与音量调节。

steipete

获取

agent-architecture-audit

237Kresearch-knowledge

针对 Agent 及 LLM 应用的全栈诊断工具。全面审计 12 层 Agent 架构栈，精准排查外壳封装退化（wrapper regression）、记忆污染、工具约束失效、隐式修复死循环以及渲染/传输篡改等硬伤问题。按严重程度输出诊断报告，并提供代码优先（code-first）的修复方案。是开发者构建 Agent 应用、自主循环（autonomous loops）或各类 LLM 驱动功能的必备 Skill。

affaan-m

获取

triaging-issues

102Kresearch-knowledge

对 GitHub Issue 进行分类分流（Triage）：自动路由至 Oncall 值班团队、打上合适 Label，以及自动回复并关闭纯咨询类提问。适用于处理 PyTorch 新提交的 Issue，或收到 Issue 分流处理指令时使用。

pytorch

获取

继续探索

浏览 research-knowledge 热门 Skills 最近更新

dx-code-analyzer-run

相关 Skills

运行代码分析器技能

关键：必须使用脚本

错误做法——切勿这样做：

正确做法——始终这样做：

概述

命令语法规则（先阅读——绝对）

先决条件

快速入门：常见模式

步骤 1：解析用户意图

1.1 引擎

1.2 类别

1.3 严重级别

1.4 特定规则

1.5 目标

1.6 输出

1.7 比较/增量

步骤 2：构建规则选择器

步骤 3：构建完整命令

步骤 4：执行扫描

步骤 5：解析并呈现结果

呈现模板

步骤 6：应用引擎提供的修复（扫描后）

6.1 供应商文件过滤（需要时）

6.2 发现

6.3 呈现 + 询问（然后停止）

6.4 应用

6.5 汇总（6.4 后必须立即执行）

6.6 — 处理用户的选择

6.7 — 可选重新扫描以进行验证

步骤 7：查询和过滤现有结果

何时触发

如何执行

步骤 8：描述规则

何时触发

如何执行

步骤 9：列出可用规则

跨技能集成

当此技能委托给 dx-code-analyzer-configure 时：

当此技能委托给 dx-code-analyzer-custom-rule-create 时：

当其他技能交接到这里时：

所有权边界

约束与注意事项

参考文件索引

你可能还喜欢

blucli

agent-architecture-audit

triaging-issues

继续探索

当此技能委托给 `dx-code-analyzer-configure` 时：

当此技能委托给 `dx-code-analyzer-custom-rule-create` 时：