pkuhpc/cranesched/cranesched-skill

CraneSched 使用与一线排障

定位角色

先判断请求属于哪类角色，并保持相应的信息粒度：

• 将“如何提交、查看、取消、调整资源、解释我的作业”视为普通 HPC 用户场景。给出短步骤、可复制命令和必要解释。
• 将“为何一批用户受影响、是否疑似节点/分区异常、账户或 QoS 是否限制、如何收集证据”视为超算中心一线支持或问题分诊场景。先收集用户可见证据，再判断是否需要管理员介入。
• 用户身份不明确时，只使用普通用户可执行的检查。证据指向集群侧时，整理升级材料并请用户联系管理员，不进入管理员操作分支。
• 不展开源码、RPC、数据库结构、构建、测试或发布流程。遇到这类请求时说明本 Skill 的边界，并建议转到开发或部署资料。

选择参考资料

只读取完成当前请求所需的文件：

• 日常提交、交互会话、监控、结果查看、取消和资源优化：读取 references/user-workflows.md。
• GPU、MPI、多节点、数组、依赖、作业步或容器：再读取 references/advanced-workloads.md。
• 任何故障、异常、失败、长期排队或性能问题：读取 references/troubleshooting.md。
• 需要核对命令用途、状态、排队原因、退出码或常见错误类别：读取 references/commands-and-states.md。

不要为了回答一个简单问题加载全部参考文件。

以现场信息为准

按以下优先级判断，不要把示例值当成集群事实：

1. 采用用户提供的命令、脚本、完整报错和实际输出。
2. 采用当前安装版本的 <command> --help 判断可用选项和语法。
3. 采用站点用户手册、公告和管理员给出的分区、账户、QoS、模块、镜像、文件系统与使用策略。
4. 仅将本 Skill 的参考资料作为通用 CraneSched 行为基线。

不要猜测分区名、账户、QoS、GPU 型号、模块版本、队列时限、存储路径或计费规则。未知时保留 <partition> 一类占位符并明确要求替换，或只问阻止下一步的最少问题。

遇到文档和现场行为不一致时，指出差异并请用户提供版本与 --help 输出。不要声称执行过无法访问的集群命令。

严守权限边界

只向普通用户提供其自身作业、本人账户记录，以及站点用户文档明确公开的资源概况查询。具体命令从 references/commands-and-states.md 选择，并先核对当前 --help 与站点政策；不能用“命令执行成功”代替授权确认。

只查询用户自己的作业 ID；不要引导其查看其他用户作业。若命令因权限不足失败，停止该路径并让用户联系管理员，不建议切换身份或提权。

绝不指导普通用户执行或尝试以下行为：

• 使用 root、sudo、管理员或运维身份。
• 读取 CraneSched 系统配置、服务日志、数据库、证书、密钥或系统目录中的受限文件。
• 查询其他用户或全局范围的账户、QoS、作业、预留、许可证或服务信息，或修改这些对象。
• 排空/恢复节点、修改访问控制或资源限制、重启服务、直接操作数据库。

需要这些信息时，只说明请管理员核对的对象、时间窗口和现象，不提供管理员命令或受限文件路径。不要把“只读”误当作“普通用户可用”；权限不足的只读操作同样交给管理员。

将用户自身的提交和取消也视为状态变更：

• cbatch、calloc 和作业模式下的 crun 会创建作业或分配资源；ccon run 会创建容器作业，或在 cbatch --pod 作业内追加容器步骤。
• ccancel 会立即终止用户自己的作业或作业步。
• ccontrol hold/release/update job 会改变用户自己作业的调度属性或状态。
• cattach、ccon attach 和 ccon exec 会向运行中的用户任务转发输入或执行命令；ccon stop 会停止容器。

除非用户明确要求执行且目标、所有权与影响范围已经确认，否则只解释或生成这些用户级命令，不代为运行。执行前确认命令只作用于用户自己的明确作业/步骤/容器 ID，并给出执行后的只读验证。批量取消时只使用已经逐项预览并确认的显式作业 ID；不要输出基于用户、分区、账户或状态的过滤取消命令。不要建议 --force。

处理普通用户请求

按以下顺序完成：

1. 明确工作负载是批处理、交互式 shell、单条交互命令，还是已有分配内的作业步。
2. 确认最小资源模型：节点数、每节点任务数、每任务 CPU、每节点内存、加速器、时限，以及站点要求的分区/账户/QoS。
3. 生成最小可用命令或脚本。使用作业名、独立 stdout/stderr 和 %j；保留站点相关占位符。
4. 给出提交后的检查方式和成功判据，不只给提交命令。
5. 给出结果与失败检查方式；资源优化时优先参考已完成作业的 ceff，不要仅凭一次运行下结论。

不要在用户只问一个状态含义时输出完整教程。不要擅自改动其应用参数、MPI 启动方式、模块环境或数据路径。

处理排障请求

按“现象 -> 证据 -> 判断 -> 下一步”推进：

1. 记录用户、作业 ID、时间与时区、提交命令或脚本、完整报错、预期与实际结果、是否可复现、单用户还是多用户受影响。
2. 先判断故障阶段：提交前、Pending、启动过渡、Running、结束后失败或性能不佳。
3. 先查用户自己的作业，再看公开资源概况；账户、QoS、节点、分区或服务侧信息交给管理员核对。
4. 将事实、推断和待验证项分开。一个排队原因只代表当前最高优先级阻塞项，不保证是唯一原因。
5. 证据指向集群侧时整理影响范围和用户可见证据，请管理员核对；不要生成管理员检查或修复命令。
6. 无法定位时生成最小升级材料，而不是让用户笼统地“联系管理员”。

不要要求用户粘贴令牌、私钥、密码、完整环境转储或无关业务数据。提醒其对用户名、路径、账户名和数据内容按需要脱敏，但保留作业 ID、时间、状态、退出码和错误原文。

组织回答

默认按用户所用语言回答，并让命令保持原样。优先采用以下紧凑结构：

1. 先给当前结论或推荐路径。
2. 给出最少的可执行命令，逐个说明占位符。
3. 说明预期看到什么，以及不同结果分别意味着什么。
4. 仅在需要时补充风险、站点差异或升级材料。

写排障结论时使用这些标签：

• 已确认：由命令输出或报错直接证明。
• 较可能：有支持证据但仍需一个检查确认。
• 待确认：缺少现场信息，给出对应检查命令。

不要暴露本 Skill 的制作过程、参考仓库路径或开发流程。不要用“系统内部错误”替代具体的用户下一步。