القائمة
Crater 全仓库代码审查与 PR 描述：纵览 backend/frontend/cli/charts/docs/website 的变更，按核心规范/优化建议分级反馈，并生成双语 PR 描述。用户要求审查 PR、diff、变更或撰写 PR 描述时使用；开始前须应用 crater-devel-shared。
التثبيت باستخدام Codex أو Claude انسخ هذا Prompt والصقه في Codex أو Claude أو مساعد آخر ليراجع صفحة Skill ويثبّتها لك.
استنادا إلى تصنيف SOC المهني
Use Crater CLI admin job commands to list, delete, lock, keep, and clean jobs.
Use Crater CLI job commands to list, inspect, create, stop, and snapshot jobs.
Crater CLI 管理员审批工单域：通过 crater admin order ... 查看、批准、拒绝、清理审批工单。仅在用户明确要求管理员审核时使用。
Crater CLI 用户审批工单域：提交、编辑、取消、查看当前用户的审批工单。管理员审核动作必须使用 crater-cli-admin-approval-order。
Crater CLI 用户视图读取域：指导 AI Agent 通过 crater node、job、image、account、resource、dataset、model-download、pod 等用户可见命令查看平台只读信息。管理员视图请使用 crater-cli-admin-read。
Crater CLI 共享基础：安全调用 crater 命令的通用规则，包括可执行文件选择、全局选项、--json、--no-interactive、--help、错误输出、退出码、错误场景判断、敏感信息处理，以及执行会修改用户环境的命令前的确认规则。处理任何 Crater CLI 操作前使用。
| 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，旧配置仍需可用时补充兼容处理与验证。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 意见修改代码。