| name | install-from-github |
| description | Clone a GitHub repository, detect its build system, and run the canonical install — pure shell, zero LLM calls. Crystallises the install-from-source dance so an agent doesn't surrender on "binary not found". |
| capabilities | ["shell"] |
Install From GitHub
Install a tool from its GitHub repository when the system package manager
doesn't have it. Procedure skill (run.sh, no LLM): clones the repo to a
workspace, detects the build system from the file layout, attempts the
canonical install for that ecosystem, and reports a structured outcome.
This skill exists because LLM agents routinely surrender on "I don't see
this binary" without ever trying to install from source. The dance —
git clone, read README, identify language, run the right install
command — is deterministic enough to crystallise into shell.
Run
tmuxllm-skill run install-from-github <repo>
<repo> accepts:
- full URL:
https://github.com/owner/repo or git@github.com:owner/repo.git
- shorthand:
owner/repo
- with host:
github.com/owner/repo
Env vars
| var | default | meaning |
|---|
URL | first positional arg | Repo to install (overridden by argv[1]) |
WS | /tmp/install-from-github-<pid> | Workspace for clone + logs + result.json |
METHOD | (auto-detect) | Force a specific install method: npm, cargo, go, pipx, pip, make, script |
Detection order
The skill tries methods in priority order, stopping at the first success:
package.json → npm install -g . (Node CLIs)Cargo.toml → cargo install --path . (Rust binaries)go.mod → go install ./... (Go binaries)pyproject.toml or setup.py → pipx install ., falling back to pip install --user .Makefile with an install: target → make install- Executable
./install.sh → ./install.sh
Force a specific method with METHOD=<name> when auto-detection picks
the wrong one (e.g., a polyglot repo with both package.json and
Cargo.toml).
Output
Writes $WS/result.json with the canonical envelope (status, summary,
decisions, tokens) and prints it to stdout. The clone, install log, and
README head are kept under $WS/ so the calling agent can read them
when triaging a failure.
status="success" means an install command completed with exit 0. The
skill does not verify the resulting binary is on PATH — the caller
should do that, since the install location depends on the method
(~/.cargo/bin, ~/go/bin, ~/.local/bin, etc.) and the user's shell
configuration.
Why a skill, not ad-hoc shell
The cost of getting this wrong is high (the agent gives up on the goal),
the steps are few, and the right sequence is always the same. Wrapping
it as an LLM loop would burn ~5–10 decisions reproducing the same
detection logic on every call. A 100-line shell script does the job
once, deterministically, and frees the agent to spend tokens on the
parts of the goal that actually need reasoning.
