菜单
Crater 全仓库代码审查与 PR 描述：纵览 backend/frontend/cli/charts/docs/website 的变更，按核心规范/优化建议分级反馈，并生成双语 PR 描述。用户要求审查 PR、diff、变更或撰写 PR 描述时使用；开始前须应用 crater-devel-shared。
默认使用会先检查来源的 Prompt；你也可以切换为直接命令，或下载本地副本。
决定是否安装前，请先阅读 SKILL.md，以及 SkillsMP 当前展示的配套文件。
用 Codex 或 Claude 帮你安装 复制这段 Prompt，粘贴到 Codex、Claude 或其他助手里，让它检查 Skill 页面并帮你完成安装。
直接命令不会经过审查 Prompt；运行前请先检查来源。
npx skills add https://github.com/raids-lab/crater --skill crater-devel-review命令会保持在同一行。复制前请横向滚动并检查完整内容。
想先保存到本地？可下载 SkillsMP 当前能够提供的文件。
Use Crater CLI job commands to list, inspect, view logs, create, stop, and snapshot jobs.
Crater CLI 共享基础：安全调用 crater 命令的通用规则，包括可执行文件选择、全局选项、列表分页、--json、--no-interactive、--help、错误输出、退出码、错误场景判断、API 兼容性诊断、敏感信息处理，以及执行会修改用户环境的命令前的确认规则。处理任何 Crater CLI 操作前使用。
Crater CLI 管理员审批工单域：通过 crater admin order ... 查看、批准、拒绝、清理审批工单。仅在用户明确要求管理员审核时使用。
基于 SOC 职业分类
正在显示 SKILL.md
| name | crater-devel-review |
| version | 0.1.0 |
| description | Crater 全仓库代码审查与 PR 描述：纵览 backend/frontend/cli/charts/docs/website 的变更，按核心规范/优化建议分级反馈，并生成双语 PR 描述。用户要求审查 PR、diff、变更或撰写 PR 描述时使用；开始前须应用 crater-devel-shared。 |
开始前先应用 crater-devel-shared。 本 Skill 用于帮助开发者在提交或 PR 前纵览 monorepo 变更、发现问题并撰写 PR 描述。开发规范的完整权威来源是各级 CONTRIBUTING；.github/instructions/* 是引用 CONTRIBUTING 的审查 MUST/SHOULD 清单。GitHub Copilot code review 阶段的行内 / 总览评论格式由 .github/copilot-instructions.md 负责，本 Skill 不强制遵循那套输出形态。
审查命中的目录时，读取对应权威文档并据此判断，不要在评论里另立一套约定：
| 变更目录 | 审查依据（规范权威 + 审查清单） |
|---|---|
backend/** | backend/CONTRIBUTING.md + .github/instructions/codebase.instructions.md |
frontend/** | frontend/CONTRIBUTING.md + .github/instructions/codebase.instructions.md |
cli/** | cli/CONTRIBUTING.md；先读 cli/docs/REVIEW.md（CLI 审查入口），契约见 COMMANDS/SPEC/ARCHITECTURE.md |
charts/** | charts/CONTRIBUTING.md + .github/instructions/charts.instructions.md |
docs/**、website/** | website/CONTRIBUTING.md + .github/instructions/docs.instructions.md |
Admin 路由、用户接口入 Protected 路由；外部 API 变更同步 swag；HTTP 状态码符合 RESTful；错误信息为清晰英文。MetadataForm* version；提升版本时必须有“上一版本 -> 当前版本”的迁移函数并接入模板迁移注册表，旧版本通过链式迁移升级，不支持的更早版本要明确报错。新增或修改作业模板加载 / 解析入口时，必须复用统一模板迁移逻辑，不要手写局部兼容，也不要把任意 JSON 导入误接入作业模板迁移。translation.json，保证翻译准确和专有名词一致；身份判断用 useIsAdmin()；非幂等操作执行前须有确认弹出框，说明对象和后果；改动 ui-custom/ 等高复用组件须评估影响范围与兼容性（审查时列为核心规范，要求开发者确认）；不易理解的输入 / 配置项须提供帮助图标与 hover tooltip；前端 / UI 改动的 PR 描述须包含相应界面截图。values.yaml / 模板 / 依赖 / 配置项行为或默认值变更须提升 charts/crater/Chart.yaml 的 version 与 appVersion，二者必须保持完全相同的值，并同步 charts/crater/README.md；values-only 可 patch，前后端 API 变化影响应用契约须 minor，不主动 major；版本发布变化须提醒创建 GitHub tag；新增项含英文注释。website/ 应面向平台用户（集群用户与集群管理员）承载部署、使用、管理、排障等产品文档；docs/ 和仓库各级 .md 默认面向开发者 / 贡献者。归档须正确；术语准确（Account=调度队列）；website/ 部署命令无硬编码 Chart 版本，命令附近用 <CraterChartVersionNotice />，代码块内用 <chart-version>，Chart 配置页用 <ChartBadge />。go version 符合对应 go.mod / CONTRIBUTING；后端 make run 依赖真实配置和网络环境，缺少配置、凭据或集群访问时应要求开发者检查，不要求 Agent 反复尝试。website/ 文档；配置结构变更同步 charts/。website/ 空格、基础校对等琐碎问题交由 Workflow，不必评论。审查结束时，结合 diff 告诉开发者还需要亲自检查什么，而不是只说“请测试”：
ui-custom/，指出可能被牵连的其它页面或流程，要求开发者抽查代表性页面。git status / diff，确认没有把用于记录任务、测试、issue 编号、临时方案或开发过程的 task note / 临时文件纳入提交；除非维护者明确要求，这类文件不应提交。根 CONTRIBUTING.md「Open And Iterate On A Pull Request / 创建并迭代 Pull Request」定义 PR 描述必须包含的信息；具体生成流程、模板、AI / 开发者测试分组与拒绝条件以 crater-devel-shared 的「PR 描述」为准。
生成 PR 描述前，必须询问开发者亲自做过哪些人工检查，并要求其提供具体页面操作、命令场景或文档阅读检查。若用户尚未说明关联 issue，必须询问是否有关联 issue；有则按 GitHub 可识别格式写入（如 Resolve #123），没有则省略。文档改动必须要求开发者说明已阅读检查的文档、语言版本、链接、术语、示例命令、版本占位或关键步骤，并确认是否需要调整。Agent 可以加入自己实际执行过的验证，但必须标注为 AI 执行；如果开发者不提供亲自检查结果，或文档改动没有开发者阅读检查结果，拒绝创建 PR 描述。
若需要创建或更新 PR，必须先把最终 PR 描述展示给开发者并取得确认；不能把开发者没看过的 AI 生成文本直接用于 PR。
创建 PR 后提醒开发者检查 workflow 状态；如工具可用，可帮助读取 workflow 状态和 PR 链接。若 workflow 失败，先读取失败 job / log，判断根因与是否和本 PR 相关，再给开发者修复方案。处理 Copilot review 或人工 review 时，先读取意见并判断其是否正确、是否值得修改，再给开发者修改方案。未经开发者讨论和确认，不要直接按 workflow / review 意见修改代码。