agentleFS
Daisybastioned440Daisybastioned440/lite-research-agents/skills/system-info/SKILL.md

system-info

Skill2 starsChanged 8 months agoMITView on GitHub

Probe system resources — CPU, RAM, disk, GPU/CUDA/MPS — and translate findings into experiment design recommendations. Run this at the start of any compute-intensive project.

2 other projects use a version of this.

Adopted by

Most recently taken up by

  • Other versions2 projects use a version of this.

    Word for word · 0

    None found.

    Edited · 0

    None found.

    Wrote their own version · 2

    1. Xxiii8322766509/NagaAgent★ 1.5ksame name
    2. RTGS2017/NagaAgent★ 1.5ksame name

    How matches are found. Word for word: the exact same text. Edited: shares passages with this file (“99% same” means 99% of its five-word phrases also appear here; 10% or more counts). Their own version: similar meaning, or, weakest, the same name. We can’t tell which project had it first. Projects are counted among the 200 most-starred candidates, and mentions are links to the repository we found, up to 50 per site, so both counts are a floor.

  • In this repository8 other files it gives its agents.

The file

We split this skill into the rules it gives an agent

10 rules. About 0 are common, 5 are distinctive, and 5 are very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈5

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 5

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Distinctive:

    When a training run is unexpectedly slow or crashes (re-run to check resource pressure)

    line 15
  2. Distinctive:

    Before deciding batch size, number of workers, mixed precision settings, or dataset size

    line 16
  3. Very specific:

    Run from within the project sandbox_root to see available space on the relevant partition.

    line 74
  4. Very specific:

    If nvidia-smi is not found, no NVIDIA GPU is available.

    line 88
  5. Very specific:

    If neither CUDA nor MPS is available, record compute: cpu-only.

    line 109
  6. Distinctive:

    If torch is not installed, note it — the project setup step will need to install it.

    line 121
  7. Very specific:

    Write findings to memory/system-profile.md inside the project sandbox.

    line 127
  8. Very specific:

    After collecting the profile, reason about what it means for the project goal.

    line 168
  9. Distinctive:

    If available disk < 10 GB, warn — checkpoints and datasets may fill it

    line 184
  10. Distinctive:

    If CPU only and project involves a non-trivial model, flag that training may take hours and recommend checkpointing aggressively (every N …

    line 188

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

System Info

Gather a complete picture of available compute before designing or launching experiments. After collecting the data, produce a structured profile and write it to memory/system-profile.md in the project sandbox.


When to Use

  • At the start of any project involving training, fine-tuning, or large-scale data processing
  • When a training run is unexpectedly slow or crashes (re-run to check resource pressure)
  • Before deciding batch size, number of workers, mixed precision settings, or dataset size

Step 1 — Detect OS

uname -s
  • Linux → use Linux commands below
  • Darwin → use macOS commands below
  • Windows → use PowerShell commands below (limited support)

Step 2 — CPU

Linux:

lscpu | grep -E "Model name|Socket|Core|Thread|MHz"
nproc

macOS:

sysctl -n machdep.cpu.brand_string
sysctl -n hw.physicalcpu hw.logicalcpu

Record: model name, physical cores, logical cores (threads).


Step 3 — RAM

Linux:

free -h

macOS:

sysctl -n hw.memsize | awk '{print $1/1024/1024/1024 " GB"}'
vm_stat | grep -E "Pages free|Pages active|Pages inactive|Pages wired"

Record: total RAM, available RAM. On macOS, note that vm_stat pages are 16KB each.


Step 4 — Disk

Linux / macOS:

df -h .

Run from within the project sandbox_root to see available space on the relevant partition.

Record: total disk, used, available on the partition where the project lives.


Step 5 — GPU Detection

Check for NVIDIA GPU (Linux / Windows WSL)

nvidia-smi --query-gpu=name,memory.total,memory.free,utilization.gpu,driver_version --format=csv,noheader

If nvidia-smi is not found, no NVIDIA GPU is available.

Also check CUDA availability via Python:

python3 -c "import torch; print('CUDA:', torch.cuda.is_available()); print('Device count:', torch.cuda.device_count()); [print(f'  GPU {i}:', torch.cuda.get_device_name(i)) for i in range(torch.cuda.device_count())]"

Check for Apple Silicon MPS (macOS)

python3 -c "import torch; print('MPS available:', torch.backends.mps.is_available()); print('MPS built:', torch.backends.mps.is_built())"

Also check chip type:

sysctl -n machdep.cpu.brand_string   # shows "Apple M1/M2/M3/M4"
system_profiler SPHardwareDataType | grep "Chip"

Fallback — CPU only

If neither CUDA nor MPS is available, record compute: cpu-only.


Step 6 — Python and Deep Learning Environment

python3 --version
python3 -c "import torch; print('PyTorch:', torch.__version__)"
python3 -c "import torch; print('cuDNN:', torch.backends.cudnn.version())" 2>/dev/null || echo "cuDNN: not available"

If torch is not installed, note it — the project setup step will need to install it.


Step 7 — Write System Profile

Write findings to memory/system-profile.md inside the project sandbox. Use this template:

# System Profile

- **Collected**: <YYYYMMDD_HHMMSS>
- **OS**: <Linux x86_64 | macOS Darwin arm64 | ...>

## CPU
- **Model**: <e.g. Apple M3 Pro | Intel Core i9-13900K>
- **Physical cores**: <N>
- **Logical cores**: <N>

## RAM
- **Total**: <e.g. 36 GB>
- **Available**: <e.g. 28 GB>

## Disk (project partition)
- **Total**: <e.g. 1 TB>
- **Available**: <e.g. 420 GB>

## Compute
- **Type**: <NVIDIA GPU | Apple MPS | CPU only>
- **Device**: <e.g. NVIDIA A100 80GB | Apple M3 Pro (integrated) | N/A>
- **VRAM / Unified memory**: <e.g. 80 GB | 36 GB shared | N/A>
- **CUDA version**: <e.g. 12.2 | N/A>
- **MPS available**: <yes | no>

## Python Environment
- **Python**: <version>
- **PyTorch**: <version | not installed>
- **cuDNN**: <version | not available>

## Experiment Implications
<filled in during Step 8>

Step 8 — Derive Experiment Implications

After collecting the profile, reason about what it means for the project goal. Add an ## Experiment Implications section to memory/system-profile.md. Consider:

Batch size:

  • NVIDIA GPU with ≥40GB VRAM → large batches (512+) viable
  • NVIDIA GPU with <16GB VRAM or MPS → moderate batches (64–256), watch for OOM
  • CPU only → small batches (8–32), training will be slow; flag this clearly

Mixed precision:

  • NVIDIA Ampere (A100, RTX 30xx/40xx) or newer → torch.float16 or bfloat16 safe
  • Apple MPS → torch.float16 supported; bfloat16 not supported on all models
  • CPU → keep float32

Number of dataloader workers:

  • Set to min(physical_cores - 1, 8) as a safe default

Disk:

  • If available disk < 10 GB, warn — checkpoints and datasets may fill it
  • Note available space explicitly so the user can plan

Estimated training time:

  • If CPU only and project involves a non-trivial model, flag that training may take hours and recommend checkpointing aggressively (every N steps, not just per epoch)

Example output:

## Experiment Implications
- **Compute**: MPS (Apple M3 Pro). Use `device = "mps"`. Mixed precision not recommended.
- **Batch size**: Start with 64. Increase if memory allows; watch `mps` backend for silent OOM.
- **Workers**: 4 (physical cores: 6, leaving 2 for system)
- **Disk**: 420 GB available — sufficient for checkpoints and shakespeare_char dataset.
- **Estimated time**: shakespeare_char on MPS ~15–30 min. CPU fallback ~2–4h.
- **Recommendation**: Checkpoint every 500 iterations given MPS instability on long runs.

Output

FileDescription
memory/system-profile.mdFull system profile + experiment implications

This file is read by other agents (executor, orchestrator) when configuring training runs. It does not need to be included in every checkpoint — write it once at project start and update it only if hardware changes.


Credit: originally sourced from clawhub.ai

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.