X-CMD is a POSIX-shell toolkit that provides reusable shell modules and on-demand command-line packages for bash, zsh, ash, and dash. It is designed for people and AI agents that need shell utilities, integrations, and agent-related workflows, and the catalogue contains a large collection of skills for using it.
Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx skills add x-cmd/x-cmd --skill repogit clone --depth 1 https://github.com/x-cmd/x-cmdWrote this? Show the measurements
A badge with what this costs and how it scanned, read live from this page, so it follows the numbers instead of freezing them. Markdown for a README, HTML for a documentation site or a project page.
[](https://agentmods.dev/skills/x-cmd/x-cmd/repo)<a href="https://agentmods.dev/skills/x-cmd/x-cmd/repo"><img src="https://agentmods.dev/badge/skills/x-cmd/x-cmd/repo/github.svg" alt="Measured on agentmods" height="20"></a>Or the 80×15 button, for a site that already has a row of RSS and ATOM ones. Only the verdict fits; the numbers stay here.
<a href="https://agentmods.dev/skills/x-cmd/x-cmd/repo"><img src="https://agentmods.dev/badge/skills/x-cmd/x-cmd/repo.svg" alt="Reviewed on agentmods" width="80" height="20"></a>- NVIDIA SkillSpector pass
What it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5.1 | $0.00110 | $0.00702 |
| Opus 5.5 | $0.00044 | $0.00281 |
| Sonnet 5.5 | $0.00022 | $0.00140 |
| Haiku 4.5 | $0.00011 | $0.00070 |
Grade C, and why
repo scanned grade C with 1 finding against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 1mo ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Recursive force deletehighDestructive command
rm -rf with a variable or a broad path is one typo away from removing the wrong tree.
By default, repos are bare with linked worktrees — the bare in `.bare/`, a separate directory from the worktrees, so `rm -rf` of one wt can't reach it. Plain `git clone` is also accepted (`x repo ls/which/update` see it) How it starts
The opening of the file, as written. The whole thing — 45 lines — stays where its author put it; the contents beside it link to each section on GitHub.
repo
Why
All clones converge at ~/.x-repo/<provider>/<owner>/<name>. Same path for every agent, human, CI — mountable into containers or agent sandboxes so they share without re-cloning. One root to back up; discoverable via x repo ls. Layout mirrors github paths so ../<sibling> from any worktree resolves to that sibling's default worktree — configs and scripts that reference siblings work uniformly across wts and agents.
Path layout
- bare:
~/.x-repo/.bare/<provider>/<owner>/<name>.git - default wt:
~/.x-repo/<provider>/<owner>/<name> - designed wt:
~/.x-repo/<provider>/<owner>/<name>@<wtname>
@<wtname> — wtname is any identifier for this workspace: agent/worker name, branch name, tag, short SHA, issue id, free-form string. / in wtname encodes to ~.
By default, repos are bare with linked worktrees — the bare in .bare/, a separate directory from the worktrees, so rm -rf of one wt can't reach it. Plain git clone is also accepted (x repo ls/which/update see it) but without geometric protection. Please be careful in that case: don't rm -rf, prefer git worktree remove, and avoid cleanup heuristics that target .git/. Mid-task work lost this way can't be realigned with the original repo.
Commands
x repo <id> # cd to default wt (auto-clones if missing)
x repo wt <id> <wtname> # attach to existing branch, or create new from HEAD
x repo wt ls <id> # list wts
x repo wt rm <id> <wtname> # graceful remove (use this, not rm -rf)
x repo update <id> # refresh default wt after upstream changes
x repo ls [--raw|--tsv] # discover what's cloned
x repo which <id>[@<wtname>] # resolve id to absolute path
Don't
rm -rfa designed worktree. It leaves stale entries in the bare'sworktrees/registry. Usex repo wt rm. If you must, rungit -C <bare> worktree pruneafterwards.
Related
- doc/path-layout.md — full path grammar and worktree naming
- doc/workflow.md — operating procedure and cleanup-non-deletion principles
- doc/design.md — why the layout is shaped this way
What ships with it
3 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 1mo ago First seen · 45 lines · 110 tokens per session scan C 662770c7d024
repo is a skill published in the GitHub repository x-cmd/x-cmd (4,717 stars, last pushed 6d ago), licensed Apache-2.0. It adds 110 tokens to every session and 702 once invoked, about $0.0004 per session on Opus 5.5. A static security scan graded it C with 1 finding (recursive force delete). No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
dnanexus-integration
DNAnexus cloud genomics platform. Build apps/applets, manage data (upload/download), dxpy Python SDK, run workflows, FASTQ/BAM/VCF, for genomics pipeline development and execution.
latchbio-integration
Latch platform for bioinformatics workflows. Build pipelines with Latch SDK, @workflow/@task decorators, deploy serverless workflows, LatchFile/LatchDir, Nextflow/Snakemake integration.
lambda-gpu-cloud
Safely inspect and operate Lambda Cloud GPU instances through the documented Cloud API and SSH, with explicit approval before billable or destructive actions.
tensorpool-gpu-cloud
Safely inspect and operate TensorPool GPU clusters and jobs using the current tp CLI, with explicit approval before any billable or destructive action.
modal-serverless-gpu
Run approved CPU or GPU work through OpenScience computejob on the user's configured Modal account. Use for isolated scientific scripts, dependency provisioning, durable outputs, logs, status, cancellation, and recovery. Never invoke the Modal SDK or CLI directly.
runpod-gpu-cloud
Safely inspect and operate RunPod resources with runpodctl, live product data, and explicit approval before paid or destructive actions.