{"id":"3a435bba-be45-439b-b52d-f93a5b995aa5","entityType":"agent","slug":"clawhub-taleintervenor-sjtu-slurm-skill","name":"SJTU SLURM Skill","canonicalUrl":"https://www.xpersona.co/agent/clawhub-taleintervenor-sjtu-slurm-skill","canonicalPath":"/agent/clawhub-taleintervenor-sjtu-slurm-skill","generatedAt":"2026-10-11T20:59:55.914Z","source":"CLAWHUB","claimStatus":"UNCLAIMED","verificationTier":"NONE","summary":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:18:34.488Z","emptyReason":null},"description":"Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill whe...","descriptionLabel":"Source description","evidenceSummary":"Capability contract not published. No trust telemetry is available yet. 1K downloads reported by the source. Last updated 10/11/2026.","installCommand":"clawhub skill install s17a7tzmmkbwha68wry3vfwq8h851s1r:sjtu-slurm-skill","sourceUrl":"https://clawhub.ai/taleintervenor/sjtu-slurm-skill","homepage":"https://clawhub.ai/taleintervenor/skills/sjtu-slurm-skill","primaryLinks":[{"label":"View on ClawHub","url":"https://clawhub.ai/taleintervenor/sjtu-slurm-skill","kind":"source"},{"label":"Homepage","url":"https://clawhub.ai/taleintervenor/skills/sjtu-slurm-skill","kind":"homepage"}],"safetyScore":84,"overallRank":62,"popularityScore":60,"trustScore":null,"claimedByName":null,"isOwner":false,"seoDescription":"SJTU SLURM Skill technical dossier on Xpersona with agent coverage, OPENCLEW support, and live trust metadata."},"coverage":{"evidence":{"source":"public-profile","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:18:34.488Z","emptyReason":null},"protocols":[{"protocol":"OPENCLEW","label":"OpenClaw","status":"self-declared","notes":"Declared in the public agent profile."}],"capabilities":[],"verifiedCount":0,"selfDeclaredCount":1,"capabilityMatrix":{"rows":[{"key":"OPENCLEW","type":"protocol","support":"unknown","confidenceSource":"profile","notes":"Listed on profile"}],"flattenedTokens":"protocol:OPENCLEW|unknown|profile"}},"adoption":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:18:34.488Z","emptyReason":null},"stars":null,"forks":null,"downloads":1020,"packageName":null,"latestVersion":"0.2.3","tractionLabel":"1K downloads"},"release":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:18:34.414Z","emptyReason":null},"lastUpdatedAt":"2026-10-11T17:18:34.488Z","lastCrawledAt":"2026-10-11T17:18:34.414Z","lastIndexedAt":null,"nextCrawlAt":"2026-10-12T17:18:34.414Z","lastVerifiedAt":null,"highlights":[{"version":"0.2.3","createdAt":"2026-04-28T07:32:18.183Z","changelog":"sjtu-slurm-skill 0.2.3 - Updated documentation in README.md for improved clarity and instructions. - No changes to code or functionality; documentation only.","fileCount":7,"zipByteSize":13569},{"version":"0.2.2","createdAt":"2026-04-22T02:22:54.958Z","changelog":"- Skill renamed from \"sjtu-hpc\" to \"sjtu-slurm-skill\" for better clarity and alignment with project naming. - Updated all instances of the skill name and relevant titles to match the new name. - No changes to functionality or behavior; usage instructions and operational logic remain the same.","fileCount":6,"zipByteSize":12143},{"version":"0.2.1","createdAt":"2026-04-21T02:17:40.437Z","changelog":"- Improved documentation and added detailed curl examples for relevant HPC APIs. - Expanded instructions for using the PATCH /user API, clarifying updatable fields and two-factor authentication requirements. - Clarified that GET /quota does not require authorization and provided explicit usage guidance. - Minor corrections and refinements to Quick Start and instruction sections for clarity. - No changes to code or interface; documentation only.","fileCount":6,"zipByteSize":12139},{"version":"0.2.0","createdAt":"2026-04-18T08:04:00.864Z","changelog":"sjtu-slurm-skill v0.2.0 - Improved password handling: Updated token request instructions to avoid storing or echoing plain text passwords in messages; added explicit instructions for handling uploaded password files. - Added steps to provide SSH private key and certificate to users on request, with security reminders. - Clarified correct usage and required parameters for the /quota API call based on home directory and account extraction. - Updated documentation to reinforce security best practices for credentials and user-provided files. - Minor updates to API path documentation and entry node selection guidance.","fileCount":6,"zipByteSize":11930},{"version":"0.1.4","createdAt":"2026-04-17T08:56:26.836Z","changelog":"sjtu-slurm-skill v0.1.4 - Changed the skill icon emoji in the skill's metadata from ♊️ to 🦞. - No other content edits were made to the user-facing documentation.","fileCount":6,"zipByteSize":11359},{"version":"0.1.3","createdAt":"2026-04-17T08:50:54.243Z","changelog":"sjtu-slurm-skills 0.1.3 - Added metadata section and homepage link to SKILL.md for improved discoverability. - Updated SKILL.md instructions to clarify password handling—now instructs to delete any user-uploaded password files after retrieving the token, and never mention passwords in chat. - Minor wording and structure improvements in SKILL.md for better clarity. - No user-facing changes to scripts/refresh_token.py.","fileCount":6,"zipByteSize":11365},{"version":"0.1.2","createdAt":"2026-04-17T06:55:06.283Z","changelog":"## sjtu-slurm-skills 0.1.2 Changelog - Updated documentation in README.md; no functional changes to code or features. - Improved clarity and instructions for using the sjtu-hpc skill.","fileCount":6,"zipByteSize":11286},{"version":"0.1.1","createdAt":"2026-04-17T06:46:30.540Z","changelog":"sjtu-slurm-skills v0.1.1 - Added version field (\"version: 0.1.1\") to SKILL.md metadata. - No functional or behavior changes; documentation and overview remain the same.","fileCount":6,"zipByteSize":11174}]},"execution":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No published capability contract is available yet."},"installCommand":"clawhub skill install s17a7tzmmkbwha68wry3vfwq8h851s1r:sjtu-slurm-skill","setupComplexity":"low","setupSteps":["Install using `clawhub skill install s17a7tzmmkbwha68wry3vfwq8h851s1r:sjtu-slurm-skill` in an isolated environment before connecting it to live workloads.","No published capability contract is available yet, so validate auth and request/response behavior manually.","Review the upstream CLAWHUB listing at https://clawhub.ai/taleintervenor/sjtu-slurm-skill before using production credentials."],"contract":{"contractStatus":"missing","authModes":[],"requires":[],"forbidden":[],"supportsMcp":false,"supportsA2a":false,"supportsStreaming":false,"inputSchemaRef":null,"outputSchemaRef":null,"dataRegion":null,"contractUpdatedAt":null,"sourceUpdatedAt":null,"freshnessSeconds":null},"invocationGuide":{"preferredApi":{"snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/trust"},"curlExamples":["curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/snapshot\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/contract\"","curl -s \"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/trust\""],"jsonRequestTemplate":{"query":"summarize this repo","constraints":{"maxLatencyMs":2000,"protocolPreference":["OPENCLEW"]}},"jsonResponseTemplate":{"ok":true,"result":{"summary":"...","confidence":0.9},"meta":{"source":"CLAWHUB","generatedAt":"2026-10-11T20:59:55.911Z"}},"retryPolicy":{"maxAttempts":3,"backoffMs":[500,1500,3500],"retryableConditions":["HTTP_429","HTTP_503","NETWORK_TIMEOUT"]}},"endpoints":{"dossierUrl":"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/dossier","snapshotUrl":"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/snapshot","contractUrl":"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/contract","trustUrl":"https://www.xpersona.co/api/v1/agents/clawhub-taleintervenor-sjtu-slurm-skill/trust"}},"reliability":{"evidence":{"source":"runtime-metrics","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No trust, reliability, or runtime telemetry is available."},"trust":{"status":"unavailable","handshakeStatus":"UNKNOWN","verificationFreshnessHours":null,"reputationScore":null,"p95LatencyMs":null,"successRate30d":null,"fallbackRate":null,"attempts30d":null,"trustUpdatedAt":null,"trustConfidence":"unknown","sourceUpdatedAt":null,"freshnessSeconds":null},"decisionGuardrails":{"doNotUseIf":["Contract metadata is missing or unavailable for deterministic execution."],"safeUseWhen":[],"riskFlags":["missing_or_unavailable_contract","trust_data_unavailable","schema_references_missing"],"operationalConfidence":"low"},"executionMetrics":{"observedLatencyMsP50":null,"observedLatencyMsP95":null,"estimatedCostUsd":null,"uptime30d":null,"rateLimitRpm":null,"rateLimitBurst":null,"lastVerifiedAt":null,"verificationSource":null},"runtimeMetrics":{"successRate":null,"avgLatencyMs":null,"avgCostUsd":null,"hallucinationRate":null,"retryRate":null,"disputeRate":null,"p50Latency":null,"p95Latency":null,"lastUpdated":null}},"benchmarks":{"evidence":{"source":"no-benchmark-data","verified":false,"confidence":"low","updatedAt":null,"emptyReason":"No benchmark suites or observed failure patterns are available."},"suites":[],"failurePatterns":[]},"artifacts":{"evidence":{"source":"CLAWHUB","verified":false,"confidence":"medium","updatedAt":"2026-10-11T17:18:34.488Z","emptyReason":null},"readme":"Skill: SJTU SLURM Skill\n\nOwner: taleintervenor\n\nSummary: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill whe...\n\nTags: latest:0.2.3\n\nVersion history:\n\nv0.2.3 | 2026-04-28T07:32:18.183Z | auto\n\nsjtu-slurm-skill 0.2.3\n\n- Updated documentation in README.md for improved clarity and instructions.\n- No changes to code or functionality; documentation only.\n\nv0.2.2 | 2026-04-22T02:22:54.958Z | auto\n\n- Skill renamed from \"sjtu-hpc\" to \"sjtu-slurm-skill\" for better clarity and alignment with project naming.\n- Updated all instances of the skill name and relevant titles to match the new name.\n- No changes to functionality or behavior; usage instructions and operational logic remain the same.\n\nv0.2.1 | 2026-04-21T02:17:40.437Z | auto\n\n- Improved documentation and added detailed curl examples for relevant HPC APIs.\n- Expanded instructions for using the PATCH /user API, clarifying updatable fields and two-factor authentication requirements.\n- Clarified that GET /quota does not require authorization and provided explicit usage guidance.\n- Minor corrections and refinements to Quick Start and instruction sections for clarity.\n- No changes to code or interface; documentation only.\n\nv0.2.0 | 2026-04-18T08:04:00.864Z | auto\n\nsjtu-slurm-skill v0.2.0\n\n- Improved password handling: Updated token request instructions to avoid storing or echoing plain text passwords in messages; added explicit instructions for handling uploaded password files.\n- Added steps to provide SSH private key and certificate to users on request, with security reminders.\n- Clarified correct usage and required parameters for the /quota API call based on home directory and account extraction.\n- Updated documentation to reinforce security best practices for credentials and user-provided files.\n- Minor updates to API path documentation and entry node selection guidance.\n\nv0.1.4 | 2026-04-17T08:56:26.836Z | auto\n\nsjtu-slurm-skill v0.1.4\n\n- Changed the skill icon emoji in the skill's metadata from ♊️ to 🦞.\n- No other content edits were made to the user-facing documentation.\n\nv0.1.3 | 2026-04-17T08:50:54.243Z | auto\n\nsjtu-slurm-skills 0.1.3\n\n- Added metadata section and homepage link to SKILL.md for improved discoverability.\n- Updated SKILL.md instructions to clarify password handling—now instructs to delete any user-uploaded password files after retrieving the token, and never mention passwords in chat.\n- Minor wording and structure improvements in SKILL.md for better clarity.\n- No user-facing changes to scripts/refresh_token.py.\n\nv0.1.2 | 2026-04-17T06:55:06.283Z | auto\n\n## sjtu-slurm-skills 0.1.2 Changelog\n\n- Updated documentation in README.md; no functional changes to code or features.\n- Improved clarity and instructions for using the sjtu-hpc skill.\n\nv0.1.1 | 2026-04-17T06:46:30.540Z | auto\n\nsjtu-slurm-skills v0.1.1\n\n- Added version field (\"version: 0.1.1\") to SKILL.md metadata.\n- No functional or behavior changes; documentation and overview remain the same.\n\nv0.1.0 | 2026-04-17T02:49:33.018Z | user\n\nsjtu-hpc v0.1.0 - Initial release\n\n- Enables users to perform job queries, submissions, cancellations, and data management on the SJTU HPC platform (交我算).\n- Handles credentials securely: stores API tokens, SSH keys, and certificates in a dedicated credentials directory; guides user to avoid password leaks.\n- Includes guided flows for obtaining and refreshing HPC API tokens and SSH certificates, with attention to two-factor authentication.\n- Provides clear rules for entry node selection based on user request, node group, and operation type.\n- Supports HPC API calls for quota and account management, with API usage restricted to documented endpoints.\n- Implements risk-aware measures for data deletion and job interruption, always confirming with the user before any risky actions.\n\nArchive index:\n\nArchive v0.2.3: 7 files, 13569 bytes\n\nFiles: README.md (1562b), scripts/refresh_token.py (4561b), scripts/req_certificate.py (7041b), scripts/req_token.py (4989b), skill-card.md (2311b), SKILL.md (13020b), _meta.json (135b)\n\nFile v0.2.3:SKILL.md\n\n---\nname: sjtu-slurm-skill\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\nmetadata:\n  {\n    \"openclaw\":\n      {\n        \"emoji\": \"🦞\",\n        \"homepage\": https://github.com/SJTU-HPC/SJTU-SLURM-Skill,\n      }\n  }\n---\n\n# sjtu-slurm-skill\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's plain text password or contain it in your talk messages**.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n   - if user want to get a passwordless certificate for SSH login, refer to [certificates section](#ssh-keys-and-certificates).\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token and ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Call script to request a new token with `req_token.py` :\n   - If user uploaded file to provide password, call script with the format like: `req_token.py \"username\" \"password\" --workspace \"path_to_workspace\" --textfile \"uploaded_file_path\"`. So script can help to remove the file to prevent password leak.\n   - Otherwise skip the `--textfile` option.\n\nThe token will be saved as `hpc_token` in the `credentials` directory under workspace. If any script failed, act according to the rules in [Error Handling section](#error-handling) .\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /user`: query user's information.\n  - Response will includ all the attributes defined by posixAccount and some addditional fields like jAccount, email, user type, etc.\n  - CURL example: `curl -L 'https://api.hpc.sjtu.edu.cn/user?name=userA&domain=pi' --header 'Authorization: Bearer ***'`\n- `PATCH /user`: update user's information.\n  - Only password, Email/jAccount, preferred contact method can be updated by user itself.\n  - Update request will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication before you send the request.\n  - Consult the [online documentation](https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of this API.\n- `GET /quota`: Query the storage quota data of user or its related group account.\n  - Call this API does not need authorization.\n  - Always call it with explict `name` parameter.\n  - If user's requirement didn't specify which `quota_type` them need, you should query with `quota_type=account` and `quota_type=user` seperately. The account name can be derived from user's home path, which can be query in `GET /user`. The parent dir of user‘s home is exactly its account name, for example:  `\"home\": \"%H/home/acct-hpc/hpcrobot\"` -> `account name: acct-hpc`.\n  - CURL example: `curl -L 'https://api.hpc.sjtu.edu.cn/quota?quota_type=account&name=acct-example'`\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nUse the token in `credentials` directory if authorization is required. Ask for user's HPC name if it is needed and has not been provided during the talk.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\nIf user directly asked for the key or certificate, follow the steps to send files to user:\n\n1. Check whether the valid time of the existing certificate meets the user's requirement. If not, request a new certificate with `--valid-time` argument.\n2. Check if there is any channel tools or skills can be used to send files directly to user. List all the candidate methods and ask user which one is preferred.\n3. Use the selected method to send private key and certificate file to user. Remind user of the security sensitivity of these files and advise user never use them in public environments.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. To aviod connection lost, wrap the remote transfer operation on data nodes with tmux. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.2.3:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Install skill\n\nThis skill has been published on [clawhub](https://clawhub.ai/taleintervenor/sjtu-slurm-skill) , so you can simplily ask your claw to install sjtu-slurm-skill skill itself.\n\nOr if you prefer to maintain skills manually:\n\n```\nopenclaw skills install sjtu-slurm-skill\nopenclaw skills update sjtu-slurm-skill\n```\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request.\n\nFile v0.2.3:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.2.3\",\n  \"publishedAt\": 1777361538183\n}\n\nFile v0.2.3:skill-card.md\n\n## Description:\n\nLog in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[taleintervenor](https://clawhub.ai/user/taleintervenor)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal SJTU HPC users use this skill to manage account information, query SLURM jobs and partitions, submit or cancel jobs, and move data between hot and cold storage through HPC APIs and SSH entry nodes.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill handles reusable HPC passwords, bearer tokens, SSH keys, and certificates stored in the workspace.\n\nMitigation: Use it only in a trusted local environment for an SJTU HPC account the user controls, avoid entering passwords directly in chat, and protect or remove credential files when no longer needed.\n\nRisk: The skill can perform user-level SSH, job, account, and data operations, including actions that may interrupt jobs or affect stored data.\n\nMitigation: Confirm destructive, account-changing, or job-interrupting actions with the user and verify target partitions, storage paths, and entry nodes before execution.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/taleintervenor/skills/sjtu-slurm-skill)\n- [Project homepage](https://github.com/SJTU-HPC/SJTU-SLURM-Skill)\n- [SJTU HPC API documentation](https://api.hpc.sjtu.edu.cn/doc/index.html#/)\n- [SJTU HPC account security documentation](https://docs.hpc.sjtu.edu.cn/accounts/security.html)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with inline shell commands and operational guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May initiate API calls, SSH sessions, credential setup, and long-running remote job or data operations when used by an agent.]\n\n## Skill Version(s):\n\n0.2.3 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment.\n\nArchive v0.2.2: 6 files, 12143 bytes\n\nFiles: README.md (1233b), scripts/refresh_token.py (4561b), scripts/req_certificate.py (7041b), scripts/req_token.py (4989b), SKILL.md (13020b), _meta.json (135b)\n\nFile v0.2.2:SKILL.md\n\n---\nname: sjtu-slurm-skill\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\nmetadata:\n  {\n    \"openclaw\":\n      {\n        \"emoji\": \"🦞\",\n        \"homepage\": https://github.com/SJTU-HPC/SJTU-SLURM-Skill,\n      }\n  }\n---\n\n# sjtu-slurm-skill\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's plain text password or contain it in your talk messages**.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n   - if user want to get a passwordless certificate for SSH login, refer to [certificates section](#ssh-keys-and-certificates).\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token and ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Call script to request a new token with `req_token.py` :\n   - If user uploaded file to provide password, call script with the format like: `req_token.py \"username\" \"password\" --workspace \"path_to_workspace\" --textfile \"uploaded_file_path\"`. So script can help to remove the file to prevent password leak.\n   - Otherwise skip the `--textfile` option.\n\nThe token will be saved as `hpc_token` in the `credentials` directory under workspace. If any script failed, act according to the rules in [Error Handling section](#error-handling) .\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /user`: query user's information.\n  - Response will includ all the attributes defined by posixAccount and some addditional fields like jAccount, email, user type, etc.\n  - CURL example: `curl -L 'https://api.hpc.sjtu.edu.cn/user?name=userA&domain=pi' --header 'Authorization: Bearer ***'`\n- `PATCH /user`: update user's information.\n  - Only password, Email/jAccount, preferred contact method can be updated by user itself.\n  - Update request will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication before you send the request.\n  - Consult the [online documentation](https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of this API.\n- `GET /quota`: Query the storage quota data of user or its related group account.\n  - Call this API does not need authorization.\n  - Always call it with explict `name` parameter.\n  - If user's requirement didn't specify which `quota_type` them need, you should query with `quota_type=account` and `quota_type=user` seperately. The account name can be derived from user's home path, which can be query in `GET /user`. The parent dir of user‘s home is exactly its account name, for example:  `\"home\": \"%H/home/acct-hpc/hpcrobot\"` -> `account name: acct-hpc`.\n  - CURL example: `curl -L 'https://api.hpc.sjtu.edu.cn/quota?quota_type=account&name=acct-example'`\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nUse the token in `credentials` directory if authorization is required. Ask for user's HPC name if it is needed and has not been provided during the talk.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\nIf user directly asked for the key or certificate, follow the steps to send files to user:\n\n1. Check whether the valid time of the existing certificate meets the user's requirement. If not, request a new certificate with `--valid-time` argument.\n2. Check if there is any channel tools or skills can be used to send files directly to user. List all the candidate methods and ask user which one is preferred.\n3. Use the selected method to send private key and certificate file to user. Remind user of the security sensitivity of these files and advise user never use them in public environments.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. To aviod connection lost, wrap the remote transfer operation on data nodes with tmux. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.2.2:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request.\n\nFile v0.2.2:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.2.2\",\n  \"publishedAt\": 1776824574958\n}\n\nArchive v0.2.1: 6 files, 12139 bytes\n\nFiles: README.md (1233b), scripts/refresh_token.py (4561b), scripts/req_certificate.py (7041b), scripts/req_token.py (4989b), SKILL.md (13004b), _meta.json (135b)\n\nFile v0.2.1:SKILL.md\n\n---\nname: sjtu-hpc\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\nmetadata:\n  {\n    \"openclaw\":\n      {\n        \"emoji\": \"🦞\",\n        \"homepage\": https://github.com/SJTU-HPC/SJTU-SLURM-Skill,\n      }\n  }\n---\n\n# sjtu-hpc\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's plain text password or contain it in your talk messages**.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n   - if user want to get a passwordless certificate for SSH login, refer to [certificates section](#ssh-keys-and-certificates).\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token and ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Call script to request a new token with `req_token.py` :\n   - If user uploaded file to provide password, call script with the format like: `req_token.py \"username\" \"password\" --workspace \"path_to_workspace\" --textfile \"uploaded_file_path\"`. So script can help to remove the file to prevent password leak.\n   - Otherwise skip the `--textfile` option.\n\nThe token will be saved as `hpc_token` in the `credentials` directory under workspace. If any script failed, act according to the rules in [Error Handling section](#error-handling) .\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /user`: query user's information.\n  - Response will includ all the attributes defined by posixAccount and some addditional fields like jAccount, email, user type, etc.\n  - CURL example: `curl -L 'https://api.hpc.sjtu.edu.cn/user?name=userA&domain=pi' --header 'Authorization: Bearer ***'`\n- `PATCH /user`: update user's information.\n  - Only password, Email/jAccount, preferred contact method can be updated by user itself.\n  - Update request will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication before you send the request.\n  - Consult the [online documentation](https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of this API.\n- `GET /quota`: Query the storage quota data of user or its related group account.\n  - Call this API does not need authorization.\n  - Always call it with explict `name` parameter.\n  - If user's requirement didn't specify which `quota_type` them need, you should query with `quota_type=account` and `quota_type=user` seperately. The account name can be derived from user's home path, which can be query in `GET /user`. The parent dir of user‘s home is exactly its account name, for example:  `\"home\": \"%H/home/acct-hpc/hpcrobot\"` -> `account name: acct-hpc`.\n  - CURL example: `curl -L 'https://api.hpc.sjtu.edu.cn/quota?quota_type=account&name=acct-example'`\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nUse the token in `credentials` directory if authorization is required. Ask for user's HPC name if it is needed and has not been provided during the talk.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\nIf user directly asked for the key or certificate, follow the steps to send files to user:\n\n1. Check whether the valid time of the existing certificate meets the user's requirement. If not, request a new certificate with `--valid-time` argument.\n2. Check if there is any channel tools or skills can be used to send files directly to user. List all the candidate methods and ask user which one is preferred.\n3. Use the selected method to send private key and certificate file to user. Remind user of the security sensitivity of these files and advise user never use them in public environments.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. To aviod connection lost, wrap the remote transfer operation on data nodes with tmux. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.2.1:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request.\n\nFile v0.2.1:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.2.1\",\n  \"publishedAt\": 1776737860437\n}\n\nArchive v0.2.0: 6 files, 11930 bytes\n\nFiles: README.md (1233b), scripts/refresh_token.py (4561b), scripts/req_certificate.py (7041b), scripts/req_token.py (4989b), SKILL.md (12213b), _meta.json (135b)\n\nFile v0.2.0:SKILL.md\n\n---\nname: sjtu-hpc\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\nmetadata:\n  {\n    \"openclaw\":\n      {\n        \"emoji\": \"🦞\",\n        \"homepage\": https://github.com/SJTU-HPC/SJTU-SLURM-Skill,\n      }\n  }\n---\n\n# sjtu-hpc\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's plain text password or contain it in your talk messages**.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n   - if user want to get a passwordless certificate for SSH login, refer to [certificates section](#ssh-keys-and-certificates). Provide the private key and certificate files together to user after you have ensured they are vaild. Remind user of the security sensitivity of these files and advise user never use them in public environments.\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token and ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Call script to request a new token with `req_token.py` :\n   - If user uploaded file to provide password, call script with the format like: `req_token.py \"username\" \"password\" --workspace \"path_to_workspace\" --textfile \"uploaded_file_path\"`. So script can help to remove the file to prevent password leak.\n   - Otherwise skip the `--textfile` option.\n\nThe token will be saved as `hpc_token` in the `credentials` directory under workspace. If any script failed, act according to the rules in [Error Handling section](#error-handling) .\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /user`: query user's information, including all the attributes defined by posixAccount and some addditional fields like jAccount, email, user type, etc.\n- `PATCH /user`: update some field of user's account, including password, binding Email/jAccount, preferred contact method.\n- `GET /quota`: Query the storage quota data of user or its related group account. Always call it with explict `name` parameter. If user's requirement didn't specify which `quota_type` them need, you should query with `quota_type=account` and `quota_type=user` seperately. The account name can be derived from user's home path, which can be query in `GET /user`. The parent dir of user‘s home is exactly its account name, for example:  `\"home\": \"%H/home/acct-hpc/hpcrobot\"` -> `account name: acct-hpc`.\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nBefore you call any API, you must consult the API's online documentation (https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of the target API. Use the token in `credentials` directory if authorization is required. Ask for user's HPC name if it is needed and has not been provided during the talk.\n\nThere may be more paths in the documentation than what we listed here. Don't care, you should not need to call other paths.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.2.0:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request.\n\nFile v0.2.0:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.2.0\",\n  \"publishedAt\": 1776499440864\n}\n\nArchive v0.1.4: 6 files, 11359 bytes\n\nFiles: README.md (1233b), scripts/refresh_token.py (4561b), scripts/req_certificate.py (7041b), scripts/req_token.py (4045b), SKILL.md (11337b), _meta.json (135b)\n\nFile v0.1.4:SKILL.md\n\n---\nname: sjtu-hpc\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\nmetadata:\n  {\n    \"openclaw\":\n      {\n        \"emoji\": \"🦞\",\n        \"homepage\": https://github.com/SJTU-HPC/SJTU-SLURM-Skill,\n      }\n  }\n---\n\n# sjtu-hpc\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's password** , if you received any attachment from user containing their password, delete it once you get a valid token.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `scripts/refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token, ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Request token with `python scripts/req_token.py \"username\" \"password\" --workspace \"path_to_workspace\"` . The token will be saved as `hpc_token` in the `credentials` directory under workspace. If script failed, act according to the rules in [Error Handling section](#error-handling) .\n5. **Remove password file**: If you got user's password from any files, delete them now to avoid password leak. Never include the plain password in talk messages.\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /quota`: query the storage quota data of user or its related group account.\n- `GET /user`: query user's account information.\n- `PATCH /user`: update some field of user's account, including password, binding Email/jAccount, preferred contact method.\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nBefore you call any API, you must consult the API's online documentation (https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of the target API. Use the token in `credentials` directory if authorization is required. Ask for user's HPC name or group account if they are needed and has not been provided during the talk.\nThere may be more paths in the documentation than what we listed here. Don't care, you should not need to call other paths.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.1.4:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request.\n\nFile v0.1.4:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.1.4\",\n  \"publishedAt\": 1776416186836\n}\n\nArchive v0.1.3: 6 files, 11365 bytes\n\nFiles: README.md (1233b), scripts/refresh_token.py (4561b), scripts/req_certificate.py (7041b), scripts/req_token.py (4045b), SKILL.md (11339b), _meta.json (135b)\n\nFile v0.1.3:SKILL.md\n\n---\nname: sjtu-hpc\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\nmetadata:\n  {\n    \"openclaw\":\n      {\n        \"emoji\": \"♊️\",\n        \"homepage\": https://github.com/SJTU-HPC/SJTU-SLURM-Skill,\n      }\n  }\n---\n\n# sjtu-hpc\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's password** , if you received any attachment from user containing their password, delete it once you get a valid token.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `scripts/refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token, ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Request token with `python scripts/req_token.py \"username\" \"password\" --workspace \"path_to_workspace\"` . The token will be saved as `hpc_token` in the `credentials` directory under workspace. If script failed, act according to the rules in [Error Handling section](#error-handling) .\n5. **Remove password file**: If you got user's password from any files, delete them now to avoid password leak. Never include the plain password in talk messages.\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /quota`: query the storage quota data of user or its related group account.\n- `GET /user`: query user's account information.\n- `PATCH /user`: update some field of user's account, including password, binding Email/jAccount, preferred contact method.\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nBefore you call any API, you must consult the API's online documentation (https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of the target API. Use the token in `credentials` directory if authorization is required. Ask for user's HPC name or group account if they are needed and has not been provided during the talk.\nThere may be more paths in the documentation than what we listed here. Don't care, you should not need to call other paths.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.1.3:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request.\n\nFile v0.1.3:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.1.3\",\n  \"publishedAt\": 1776415854243\n}\n\nArchive v0.1.2: 6 files, 11286 bytes\n\nFiles: README.md (1233b), scripts/refresh_token.py (4555b), scripts/req_certificate.py (7041b), scripts/req_token.py (4045b), SKILL.md (11207b), _meta.json (135b)\n\nFile v0.1.2:SKILL.md\n\n---\nname: sjtu-hpc\nversion: 0.1.1\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\n---\n\n# sjtu-hpc\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's password** , if you received any plain text attachment from user containing their password (usually stored in ` ~/.openclaw/media`) , delete it after you get a valid token.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `scripts/refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token, ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Request token with `python scripts/req_token.py \"username\" \"password\" --workspace \"path_to_workspace\"` . The token will be saved as `hpc_token` in the `credentials` directory under workspace. If script failed, act according to the rules in [Error Handling section](#error-handling) .\n5. If you got user's password from the text file uploaded by them, delete it now to avoid password leak.\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /quota`: query the storage quota data of user or its related group account.\n- `GET /user`: query user's account information.\n- `PATCH /user`: update some field of user's account, including password, binding Email/jAccount, preferred contact method.\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nBefore you call any API, you must consult the API's online documentation (https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of the target API. Use the token in `credentials` directory if authorization is required. Ask for user's HPC name or group account if they are needed and has not been provided during the talk.\nThere may be more paths in the documentation than what we listed here. Don't care, you should not need to call other paths.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.1.2:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request.\n\nFile v0.1.2:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.1.2\",\n  \"publishedAt\": 1776408906283\n}\n\nArchive v0.1.1: 6 files, 11174 bytes\n\nFiles: README.md (1037b), scripts/refresh_token.py (4555b), scripts/req_certificate.py (7041b), scripts/req_token.py (4045b), SKILL.md (11207b), _meta.json (135b)\n\nFile v0.1.1:SKILL.md\n\n---\nname: sjtu-hpc\nversion: 0.1.1\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\n---\n\n# sjtu-hpc\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's password** , if you received any plain text attachment from user containing their password (usually stored in ` ~/.openclaw/media`) , delete it after you get a valid token.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `scripts/refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token, ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Request token with `python scripts/req_token.py \"username\" \"password\" --workspace \"path_to_workspace\"` . The token will be saved as `hpc_token` in the `credentials` directory under workspace. If script failed, act according to the rules in [Error Handling section](#error-handling) .\n5. If you got user's password from the text file uploaded by them, delete it now to avoid password leak.\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /quota`: query the storage quota data of user or its related group account.\n- `GET /user`: query user's account information.\n- `PATCH /user`: update some field of user's account, including password, binding Email/jAccount, preferred contact method.\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nBefore you call any API, you must consult the API's online documentation (https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of the target API. Use the token in `credentials` directory if authorization is required. Ask for user's HPC name or group account if they are needed and has not been provided during the talk.\nThere may be more paths in the documentation than what we listed here. Don't care, you should not need to call other paths.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.1.1:README.md\n\n# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\nFile v0.1.1:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.1.1\",\n  \"publishedAt\": 1776408390540\n}\n\nArchive v0.1.0: 6 files, 11162 bytes\n\nFiles: README.md (1030b), scripts/refresh_token.py (4555b), scripts/req_certificate.py (7041b), scripts/req_token.py (4045b), SKILL.md (11192b), _meta.json (135b)\n\nFile v0.1.0:SKILL.md\n\n---\nname: sjtu-hpc\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\n---\n\n# sjtu-hpc\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's password** , if you received any plain text attachment from user containing their password (usually stored in ` ~/.openclaw/media`) , delete it after you get a valid token.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `scripts/refresh_token.py --workspace \"path_to_workspace\"`. If success, then you have ensured a valid token and can safely skip the following steps. If the request is refused (which means the token has expired), then continue to step 3. If the request reports internal error, act according to the rules in [Error Handling section](#error-handling) .\n3. Tell the user you are going to request a new token, ask for their HPC username and password. To avoid password leak, advise user to upload a text file instead of providing passwords directly in the chat window.\n4. Request token with `python scripts/req_token.py \"username\" \"password\" --workspace \"path_to_workspace\"` . The token will be saved as `hpc_token` in the `credentials` directory under workspace. If script failed, act according to the rules in [Error Handling section](#error-handling) .\n5. If you got user's password from the text file uploaded by them, delete it now to avoid password leak.\n\n## HPC API\n\nHere are some HPC API path you can call when users want to know their storage quota usage or update their account:\n\n- `GET /quota`: query the storage quota data of user or its related group account.\n- `GET /user`: query user's account information.\n- `PATCH /user`: update some field of user's account, including password, binding Email/jAccount, preferred contact method.\n\nOnly these tasks can be done through HPC API. **Do NOT try to use API for any other user requirements.**\n\nBefore you call any API, you must consult the API's online documentation (https://api.hpc.sjtu.edu.cn/doc/index.html#/) to understand the calling conventions of the target API. Use the token in `credentials` directory if authorization is required. Ask for user's HPC name or group account if they are needed and has not been provided during the talk.\nThere may be more paths in the documentation than what we listed here. Don't care, you should not need to call other paths.\n\n## Entry Node Selection Rules\n\nSelect the appropriate entry node based on the node group and operation type the user is interested in.\n\nHPC cluster has 3 node groups: pi, sy (思源) , kp (鲲鹏) . Partitions belong to node groups. If user does not explicitly specify a node group but only provides a target partition or a target storage, look up the corresponding node group from this table:\n\n| node group | partition                                                      | storage    |\n| ---------- | -------------------------------------------------------------- | ---------- |\n| pi         | cpu, debug, dgx2, huge, 192c6t                                 | lustre     |\n| kp         | debugarm, arm128c256g, scnet_arm                               |            |\n| sy         | small, 64c512g, el9, debug64c512g, win32, a100, a800, debug100 | dssg(gpfs) |\n\nThen select the entry node according to this table:\n\n| business | node group | entry node               |\n| -------- | ---------- | ------------------------ |\n| job      | pi         | pilogin.hpc.sjtu.edu.cn  |\n| job      | sy         | sylogin.hpc.sjtu.edu.cn  |\n| job      | kp         | armlogin.hpc.sjtu.edu.cn |\n| data     | pi, kp     | data.hpc.sjtu.edu.cn     |\n| data     | sy         | sydata.hpc.sjtu.edu.cn   |\n\n## SSH Keys and Certificates\n\nSSH login to entry nodes requires the user's passwordless certificate. The agent should store all credentials (tokens, SSH keys, certificates) in the workspace's `credentials` directory. If no certificate available, follow the steps to request a new SSH certificate:\n\n1. Ask for certificate owner: If you have asked username when requesting token, directly use that username and skip the ask. Otherwise ask for user's HPC username.\n2. Make sure user is prepared: Tell the user that requesting the certificate will trigger two-factor authentication via JWB APP (交我办) or Email. Ask user whether it have been prepared to do the authentication.\n3. Call synchronous script with long timeout: Give the user a prompt like \"Requesting certificate now, please check your JWB App (交我办) or Email...\", **Do NOT wait for the user's confirmation before proceeding**. Immediately call the script `req_certificate.py <username> --workspace \"path_to_workspace\"` with `timeout >= 600s` because the script will block waiting for the user to complete two-factor authentication on another channel.\n4. **Handle errors**: After script execution, check the exit code. If non-zero, act according to the rules in [Error Handling section](#error-handling) .\n\nThe SSH key and certificate will be saved to the `credentials` directory under workspace.\n\n## Error Handling\n\nIf any script execution or API call failed, parse the error message from stderr and inform the user with clear details:\n\n- If the error message indicates \"user have not set email or jAccount\", **Direct the user** to read the platform documentation: https://docs.hpc.sjtu.edu.cn/accounts/security.html . Ask them to follow the instructions in the documentation to bind their second identity channel (jAccount or email).\n- If the error message indicates internal error, tell user the session ID in error message, suggest them to ask help from `hpc@sjtu.edu.cn` with this ID.\n\n## Executing User-Requested Operations on Entry Nodes\n\nUse the SSH key and certificate from the workspace credentials directory to log in to the entry node and remotely execute the user's requested operations:\n\n```bash\nssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\"\n```\n\nNote that user data is distributed across multiple shared storage pools, and visible storage varies depending on the node group. The storage where the user's home directory resides also differs:\n\n| node group | mount point | storage information                                                                                              |\n| ---------- | ----------- | ---------------------------------------------------------------------------------------------------------------- |\n| pi, kp     | /lustre     | Hot storage, Lustre, user home directory is here                                                                 |\n| sy         | /dssg       | Hot storage, GPFS, user home directory is here                                                                   |\n| pi, sy, kp | /archive    | Cold storage A, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /vault      | Cold storage B, NFS, for archived data, writable only on data and sydata nodes, read-only on other nodes         |\n| pi, sy, kp | /union      | mergerfs virtual filesystem, combines /archive and /vault, same read/write restrictions as the two cold storages |\n\nUser personal directory paths are consistent across storage pools. Replace the top-level path of the user's home directory with the target storage to get the corresponding personal directory path. For example: `/lustre/home/acct-hpc/hpcrobot` -> `/archive/home/acct-hpc/hpcrobot`\n\nIf the user is interested in platform status or personal jobs, use SLURM commands to perform operations like: `sinfo, squeue, sacct, seff, sbatch, scancel, etc...`\n\nDue to different storage pool visibility across node groups, job data computed on a partition can only be viewed on entry nodes belonging to the corresponding node group. Each entry node only allows submitting job to partitions within its own node group.\n\nNever use cold storage data directly for job. If cold storage data is needed, transfer it to hot storage first before using it for job.\n\nLarge-scale data transfer operations should be performed on `data.hpc.sjtu.edu.cn` and `sydata.hpc.sjtu.edu.cn`. HPC has multiple cold storages, so before writing data to cold storage, check the free space of these candidates, and select the cold storage with most free space as the write target. If user asks about their data in cold storage and did not clearly specified which one, use the combined virtual filesystem `/union` .\n\n## Resources\n\n### scripts/\n\n- `req_token.py`: Request a new bearer token from HPC API. This is a one-time setup that enables other operations.\n- `refresh_token.py`: Refresh an existing bearer token to extend the session without re-authenticating.\n- `req_certificate.py`: Request SSH key and certificate files using an existing token, which can be used to log in to the entry nodes without a password.\n\nFile v0.1.0:README.md\n\n# SJTU HPC \n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\nFile v0.1.0:_meta.json\n\n{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.1.0\",\n  \"publishedAt\": 1776394173018\n}","readmeExcerpt":"Skill: SJTU SLURM Skill Owner: taleintervenor Summary: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill whe... Tags: latest:0.2.3 Version history: v0.2.3 | 2026-04-28T07:32:18.183Z | auto sjtu-slurm-skill 0.2.3 - Updated documentation in README.md for improved clarity and instructions. - No changes to code or func","codeSnippets":[],"executableExamples":[{"language":"bash","snippet":"ssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\""},{"language":"text","snippet":"openclaw skills install sjtu-slurm-skill\nopenclaw skills update sjtu-slurm-skill"},{"language":"bash","snippet":"ssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\""},{"language":"bash","snippet":"ssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\""},{"language":"bash","snippet":"ssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\""},{"language":"bash","snippet":"ssh -i \"/path_to_workspace/credentials/private_key\" -o \"CertificateFile=/path_to_workspace/credentials/certificate\" user@entry_node \"command\""}],"parameters":null,"dependencies":[],"permissions":[],"extractedFiles":[{"path":"SKILL.md","content":"---\nname: sjtu-slurm-skill\ndescription: Log in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management. Use this skill when the user requests operations related to HPC or \"交我算\".\nmetadata:\n  {\n    \"openclaw\":\n      {\n        \"emoji\": \"🦞\",\n        \"homepage\": https://github.com/SJTU-HPC/SJTU-SLURM-Skill,\n      }\n  }\n---\n\n# sjtu-slurm-skill\n\n## Overview\n\nUse this skill to log in to the SJTU HPC (交我算) platform as the user, acting on their behalf to perform personal job queries, submissions, cancellations, and data management operations.\n\nGeneral Principles:\n\n- **Risk-aware operations**: Deleting user's data and interrupting running jobs are risky operations. Before performing any risky operation, always confirm with the user that they clearly understand the impact of the operation and agree to its execution.\n- private credentials: All user's credential files (like SSH key, certificate, API token, etc...) should be stored in the `credentials` directory under workspace (e.g., `~/.openclaw/workspace/default/credentials`). **Do Not store user's plain text password or contain it in your talk messages**.\n\n## Quick Start\n\n1. Ensure HPC API token file is available in the workspace, which should be stored in `credentials` directory. If not, request a new token.\n2. For each user request, analyze whether you need to log in to an HPC entry node to perform the operation remotely. You can ask more questions to clarify any ambiguous parts of the request.\n   - If user wants to know its storage quota usage or update its account (like password, binding Email/jAccount, preferred contact method), then you can meet the requirement directly by calling HPC API with the token.\n   - if user is talking about job or its data, then you have to select an entry node to do remote operation. In this case, take the following steps.\n   - if user want to get a passwordless certificate for SSH login, refer to [certificates section](#ssh-keys-and-certificates).\n3. Ensure SSH keys and certificates are available in the workspace, which should be stored in `credentials` directory. If not, request a new SSH certificate for the user. Remind the user that requesting a certificate will trigger two-factor authentication.\n4. For each user request need remote operation, identify the node group/partition the user is interested in and the operation type to select the correct entry node.\n5. Use the SSH certificate to connect to the corresponding entry node based on the cluster and operation type, execute the user's requested operations on it.\n\n## Ensure Token Available\n\nBefore calling any HPC API, ensure there is a valid token in the credentials directory. Go through the following steps:\n\n1. Check whether `hpc_token` file exists in the `credentials` directory under workspace. If it exists, goto step 2, otherwise goto step 3.\n2. Try to refresh the token with `refresh_token.py --workspace \"path_to_workspace\"`. If success, then"},{"path":"README.md","content":"# SJTU slurm skill\n\nThis is the skill to interact with SJTU HPC platform on behalf of a user.\n\n## Skill ability\n\n- Manage your HPC account information like jAccount/Email binding, password update, prefer contact method setting, etc.\n- Query job status, partition queue, platform information, storage usage, etc.\n- Submit/manage job according to your instructions.\n- Help you to migrate data between hot/cold storages.\n\nIn a sense, it can help to do all the things you can through SSH login to platform's entry node.\n\n## Notes on using this skill\n\nThis skill will request API token and SSH key/certificate for you, and store them in workspace. **Make sure your claw is in safe environment. Never use this skill on a shared machine.**\n\nTo fullfill your instructions, claw agent may need to call lots of command, channel clients (like Feishu, weixin, QQ, etc.) cannot display the background command call process in real time. You may have to wait for a while to see the final reply, be patient if your LLM models service is not fast enough.\n\n## Install skill\n\nThis skill has been published on [clawhub](https://clawhub.ai/taleintervenor/sjtu-slurm-skill) , so you can simplily ask your claw to install sjtu-slurm-skill skill itself.\n\nOr if you prefer to maintain skills manually:\n\n```\nopenclaw skills install sjtu-slurm-skill\nopenclaw skills update sjtu-slurm-skill\n```\n\n## Repository\n\nThis project is hosted on GitHub at https://github.com/SJTU-HPC/SJTU-SLURM-Skill. If you have any suggestions for improvement, feel free to open an issue or submit a pull request."},{"path":"_meta.json","content":"{\n  \"ownerId\": \"kn7fzph2hetmda1vp99dwh114s850q1p\",\n  \"slug\": \"sjtu-slurm-skill\",\n  \"version\": \"0.2.3\",\n  \"publishedAt\": 1777361538183\n}"},{"path":"skill-card.md","content":"## Description:\n\nLog in to the SJTU HPC platform (also known as \"交我算\") as the user to perform job queries, submissions, cancellations, and data management.\n\nThis skill is ready for commercial/non-commercial use.\n\n## Publisher:\n\n[taleintervenor](https://clawhub.ai/user/taleintervenor)\n\n### License/Terms of Use:\n\nMIT-0\n\n## Use Case:\n\nExternal SJTU HPC users use this skill to manage account information, query SLURM jobs and partitions, submit or cancel jobs, and move data between hot and cold storage through HPC APIs and SSH entry nodes.\n\n### Deployment Geography for Use:\n\nGlobal\n\n## Known Risks and Mitigations:\n\nRisk: The skill handles reusable HPC passwords, bearer tokens, SSH keys, and certificates stored in the workspace.\n\nMitigation: Use it only in a trusted local environment for an SJTU HPC account the user controls, avoid entering passwords directly in chat, and protect or remove credential files when no longer needed.\n\nRisk: The skill can perform user-level SSH, job, account, and data operations, including actions that may interrupt jobs or affect stored data.\n\nMitigation: Confirm destructive, account-changing, or job-interrupting actions with the user and verify target partitions, storage paths, and entry nodes before execution.\n\n## Reference(s):\n\n- [ClawHub skill page](https://clawhub.ai/taleintervenor/skills/sjtu-slurm-skill)\n- [Project homepage](https://github.com/SJTU-HPC/SJTU-SLURM-Skill)\n- [SJTU HPC API documentation](https://api.hpc.sjtu.edu.cn/doc/index.html#/)\n- [SJTU HPC account security documentation](https://docs.hpc.sjtu.edu.cn/accounts/security.html)\n\n## Skill Output:\n\n**Output Type(s):** [text, markdown, shell commands, configuration, guidance]\n\n**Output Format:** [Markdown with inline shell commands and operational guidance]\n\n**Output Parameters:** [1D]\n\n**Other Properties Related to Output:** [May initiate API calls, SSH sessions, credential setup, and long-running remote job or data operations when used by an agent.]\n\n## Skill Version(s):\n\n0.2.3 (source: server release evidence)\n\n## Ethical Considerations:\n\nUsers should evaluate whether this skill is appropriate for their environment, review any generated or modified files before relying on them, and apply their organization's safety, security, and compliance requirements before deployment."}],"languages":[],"docsSourceLabel":"CLAWHUB","editorialOverview":null,"editorialQuality":{"score":100,"threshold":65,"status":"thin","wordCount":1736,"uniquenessScore":40,"reasons":["uniqueness-below-45"]}},"media":{"evidence":{"source":"no-media","verified":false,"confidence":"low","updatedAt":"2026-10-11T17:18:34.488Z","emptyReason":"No screenshots, media assets, or demo links are available."},"primaryImageUrl":null,"mediaAssetCount":0,"assets":[],"demoUrl":null},"ownerResources":{"evidence":{"source":"unclaimed","verified":false,"confidence":"low","updatedAt":"2026-10-11T17:18:34.488Z","emptyReason":"This page has not been claimed by the agent owner."},"hasCustomPage":false,"customPageUpdatedAt":null,"customLinks":[],"structuredLinks":{"docsUrl":null,"demoUrl":null,"supportUrl":null,"pricingUrl":null,"statusUrl":null},"customPage":null},"relatedAgents":{"evidence":{"source":"protocol-neighbors","verified":false,"confidence":"medium","updatedAt":"2026-10-11T20:59:55.914Z","emptyReason":null},"items":[{"id":"8ebccd8e-3863-4187-8355-c3f14e1f9edf","entityType":"agent","canonicalPath":"/agent/iofficeai-aionui","slug":"iofficeai-aionui","name":"AionUi","description":"Free, local, open-source 24/7 Cowork app and OpenClaw for Gemini CLI, Claude Code, Codex, OpenCode, Qwen Code, Goose CLI, Auggie, and more | 🌟 Star if you like it!","url":"https://github.com/iOfficeAI/AionUi","homepage":"https://www.aionui.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-10-09T19:11:12.944Z","createdAt":"2026-02-25T03:38:16.584Z","downloads":null},{"id":"b917f68a-ebff-438e-84f8-3f4b2494c0bc","entityType":"agent","canonicalPath":"/agent/activepieces-activepieces","slug":"activepieces-activepieces","name":"activepieces","description":"AI Agents & MCPs & AI Workflow Automation • (~400 MCP servers for AI agents) • AI Automation / AI Agent with MCPs • AI Workflows & AI Agents • MCPs for AI Agents","url":"https://github.com/activepieces/activepieces","homepage":"https://www.activepieces.com","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-15T02:22:12.426Z","createdAt":"2026-02-25T03:38:12.412Z","downloads":null},{"id":"5cb26759-3a39-483f-94cf-276a98c13bb8","entityType":"agent","canonicalPath":"/agent/cherryhq-cherry-studio","slug":"cherryhq-cherry-studio","name":"cherry-studio","description":"AI productivity studio with smart chat, autonomous agents, and 300+ assistants. Unified access to frontier LLMs","url":"https://github.com/CherryHQ/cherry-studio","homepage":"https://cherry-ai.com","source":"GITHUB_REPOS","protocols":["MCP","OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-04-11T14:38:40.986Z","createdAt":"2026-02-25T03:38:19.379Z","downloads":null},{"id":"6f6582d0-5d76-4f0f-b81d-86520247950b","entityType":"agent","canonicalPath":"/agent/copilotkit-copilotkit","slug":"copilotkit-copilotkit","name":"CopilotKit","description":"The Frontend for Agents & Generative UI. React + Angular","url":"https://github.com/CopilotKit/CopilotKit","homepage":"https://docs.copilotkit.ai","source":"GITHUB_REPOS","protocols":["OPENCLAW"],"capabilities":[],"safetyScore":100,"overallRank":70,"updatedAt":"2026-03-25T09:50:57.846Z","createdAt":"2026-02-25T03:39:14.617Z","downloads":null}],"links":{"hub":"/agent","source":"/agent/source/clawhub","protocols":[{"label":"OpenClaw","href":"/agent/protocol/openclew"}]}}}