Claude Skill

probe-compute-environment

Inspect a registered execution server before compute planning and interpret its persisted capability profile. Use when a server is added, when the user clicks Probe, before enabling an unfamiliar SSH/WSL resource, or when deciding whether GPU, sudo/root, a scheduler, Python, R, c

LLM Mart · 0 points · 15 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download xuzhougeng-wisp-science-skills_probe-compute-environment-2b7fd45.zip · 1 KB
Part of xuzhougeng/wisp-science — 25 skills

Install

skills CLI npx skills add https://github.com/xuzhougeng/wisp-science/tree/main/skills/probe-compute-environment
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install xuzhougeng-wisp-science@llmmart
Git git clone https://github.com/xuzhougeng/wisp-science.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole xuzhougeng/wisp-science collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

Probe compute environment

Use Wisp's environment Probe action. It performs bounded, read-only checks and stores the result on the ExecutionContext. An SSH probe batches every check into one authenticated session; do not replace it with an ad-hoc SSH discovery loop. Batch SSH uses IdentitiesOnly=yes; users relying on a non-default ssh-agent key must configure its IdentityFile in Wisp or SSH config.

After probing:

  1. Treat persisted capabilities as the server contract until it is probed again.
  2. Treat gpu_summary: null as no usable GPU. Plan CPU work and never add CUDA/GPU flags speculatively.
  3. Treat privilege: unprivileged as no root or passwordless sudo. Do not use sudo, system package managers, or system paths; prefer user-space environments, modules, containers already installed by the administrator, or ask the user for an administrator-installed dependency.
  4. Use a detected scheduler rather than running long work on a login node.
  5. Use the recorded interpreter paths and environment managers. Do not assume python, Rscript, conda, mamba, or modulecmd exists when absent.
  6. If the probe failed, inspect the saved error and ask the user to check the connection before manually probing again. Never loop or automatically retry an SSH probe. If it is merely stale relative to a server change, probe again before submitting work.
Files (wisp-science)
  • agents
    • openai.yaml 232 B
      interface:
        display_name: "Probe compute environment"
        short_description: "Inspect server hardware, runtimes, and privileges"
        default_prompt: "Use $probe-compute-environment to inspect this server before planning compute work."
      
  • SKILL.md 1.7 KB
    ---
    name: probe-compute-environment
    description: Inspect a registered execution server before compute planning and interpret its persisted capability profile. Use when a server is added, when the user clicks Probe, before enabling an unfamiliar SSH/WSL resource, or when deciding whether GPU, sudo/root, a scheduler, Python, R, conda, mamba, or environment modules are available.
    ---
    
    # Probe compute environment
    
    Use Wisp's environment Probe action. It performs bounded, read-only checks and
    stores the result on the `ExecutionContext`. An SSH probe batches every check
    into one authenticated session; do not replace it with an ad-hoc SSH discovery
    loop. Batch SSH uses `IdentitiesOnly=yes`; users relying on a non-default
    ssh-agent key must configure its `IdentityFile` in Wisp or SSH config.
    
    After probing:
    
    1. Treat persisted capabilities as the server contract until it is probed again.
    2. Treat `gpu_summary: null` as **no usable GPU**. Plan CPU work and never add
       CUDA/GPU flags speculatively.
    3. Treat `privilege: unprivileged` as **no root or passwordless sudo**. Do not
       use `sudo`, system package managers, or system paths; prefer user-space
       environments, modules, containers already installed by the administrator,
       or ask the user for an administrator-installed dependency.
    4. Use a detected scheduler rather than running long work on a login node.
    5. Use the recorded interpreter paths and environment managers. Do not assume
       `python`, `Rscript`, conda, mamba, or modulecmd exists when absent.
    6. If the probe failed, inspect the saved error and ask the user to check the
       connection before manually probing again. Never loop or automatically retry
       an SSH probe. If it is merely stale relative to a server change, probe again
       before submitting work.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related