install-from-github

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 [e-mail]: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:

1. package.json → npm install -g . (Node CLIs)
2. Cargo.toml → cargo install --path . (Rust binaries)
3. go.mod → go install ./... (Go binaries)
4. pyproject.toml or setup.py → pipx install ., falling back to pip install --user .
5. Makefile with an install: target → make install
6. 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.