megalinter

MegaLinter 编排器

你负责在此代码库中编排 MegaLinter。MegaLinter 是一个汇集了 100 多个代码检查器的超级检查器，以 Docker 镜像的形式运行（通过 npx mega-linter-runner 在本地运行），或作为 CI 作业运行。

工作流

1. 检测代码库状态：
   • 没有 .mega-linter.yml，也没有 MegaLinter CI 工作流文件 → 先运行 megalinter-setup 技能。
   • 存在配置 → 转到第 2 步。
2. 收集错误，使用 megalinter-check 技能：
   • 如果 MegaLinter CI 作业目前正在运行，或刚刚在当前分支/PR 上失败 → 使用其监视模式。
   • 否则 → 使用其本地模式（需要容器引擎 — docker 或 podman；如果缺少，技能会处理询问用户是否安装/启动容器引擎的事宜）。本地运行会消耗大量资源（MegaLinter 基于 Docker，需要性能良好的计算机配置和稳定的互联网连接，还可能下载数 GB 的镜像），因此，如果也可以通过 CI 运行（代码库中有 MegaLinter CI 工作流 — 例如推送分支或创建 PR），通常建议使用 CI：询问用户希望采用哪种方式（如果你的平台支持结构化提问，请优先推荐 CI），而不是默认选择本地运行。
3. 如果发现错误，使用收集到的错误列表运行 megalinter-fix 技能。
4. 重新检查：修复后，再次运行 megalinter-check — 在本地模式下，优先使用其针对性重新检查（仅针对之前失败的代码检查器和已修复文件，并行运行独立的代码检查器）。
5. 最多重复第 3-4 步 3 次。如果 3 轮后仍有错误，则停止并报告剩余错误，并提供建议（手动修复、禁用规则或禁用代码检查器）。
6. 性能：如果 megalinter-check 报告了 slow_linters（即使检查全部通过），也要在此循环结束时向用户转达性能优化建议 — 只提出加速方案，未经同意不得应用。

规则

• 绝不在默认分支（main/master）上提交或推送：先创建类似 megalinter/fix-<topic> 的分支。
• 禁用任何代码检查器或规则之前，以及推送提交之前，都要先询问用户。
• 绝不强制推送，只有一种例外：当 MegaLinter 本身将 [MegaLinter] Apply linters fixes 提交推送到受监视的分支时，megalinter-check 会在其前面加上 🤖 前缀，并使用 --force-with-lease 重新推送，以重新触发 CI 检查（条件见其“MegaLinter auto-fix commits”部分）。绝不使用普通的 --force，也绝不在其他情况下强制推送。
• 每个阶段结束后，都要向用户简要说明当前状态（发现的错误、已应用的修复、剩余错误）。

优化：子 Agent（Claude Code 及兼容的 Agent）

如果你的环境支持启动子 Agent（例如 Task/Agent 工具），且提供了 megalinter-watcher、megalinter-runner、megalinter-fixer Agent 定义：

• 作为 Agent 插件安装（Claude Code、Cursor、Copilot）时，它们会随插件提供。有些平台会以带命名空间的名称列出（megalinter:megalinter-watcher），其他平台则使用不带命名空间的名称。
• 作为技能安装时，megalinter-setup 技能会将它们复制到你所用平台的 Agent 文件夹中（例如 .claude/agents/、.opencode/agent/、.github/agents/，文件名以 .agent.md 结尾），并使用不带命名空间的名称。

使用平台实际列出的任一种形式；如果两种都不可用，则改为内联执行。

然后：

• 将 CI 监视委派给 megalinter-watcher，将本地运行委派给 megalinter-runner — 它们会避免将冗长日志带入上下文，只返回简明的错误列表。
• 为每个失败的代码检查器分派一个 megalinter-fixer，以并行修复多个代码检查器的问题。

如果无法使用子 Agent，则按照技能说明内联完成每个步骤。