repo runner

Bootstrap and run a GitHub project by following its docs (README/docs), with safeguards for untrusted install/run steps. Use when the user gives a GitHub rep...

Security Scan

The skill's code, instructions, and requirements align with its stated purpose (bootstrapping and running repos) and do not request unrelated credentials or install third‑party code automatically — but it still depends on user approval before running repo code, so standard caution when running untrusted projects applies.

Purpose & Capability

Name/description match the provided scripts and SKILL.md: the skill detects project type, suggests install/run commands, and guides safe setup. It does not request unrelated credentials or system paths.

Instruction Scope

SKILL.md keeps scope to repo discovery, prerequisite checks, dependency installation (only after explicit confirmation), .env handling (only after confirmation), and running documented commands. It does not instruct reading arbitrary host files or exfiltrating data. The workflow responsibly warns about treating repo code as untrusted.

Install Mechanism

There is no install spec and included shell scripts are small and local. No downloads from remote URLs or archive extraction are present. Risk from install-time actions is low from the skill itself (runtime actions depend on user consent).

Credentials

The skill declares no required env vars, credentials, or config paths. Scripts check for local runtimes (node, etc.) which is appropriate to detect project types; they do not read hidden credentials or request tokens.

Persistence & Privilege

always is false and there is no mechanism to persistently modify other skills or global agent settings. The skill does not request elevated or permanent privileges.

Assessment

This skill is internally consistent and behaves like a helper that inspects a repository and recommends safe commands. It does not itself exfiltrate secrets or require credentials. However, it is designed to run install/build/run commands you may approve — which can execute arbitrary code from the repository. Before approving destructive or networked operations (git pull, installs, curl | bash, docker compose, etc.), review the repo's README and the specific commands the skill proposes. Prefer running untrusted projects inside an isolated environment (container or VM), avoid auto-applying .env values (provide secrets out-of-band), and deny any installation or postinstall scripts you don't understand. If you want a higher assurance check, ask for the exact commands the skill will run and inspect them line-by-line before consenting.

Repo Runner (run a GitHub project)

Goal: given a GitHub URL or a downloaded folder, get the project running as its docs intend, without guessing dangerously.

Inputs to ask for

• Repo source: GitHub URL (preferred) or local path
• Target: dev (local dev server) / build / test
• Constraints: allow installing deps? allow running postinstall scripts? allow Docker?

Safety rules (must follow)

• Treat repo code as untrusted.
• Before running npm/pnpm/yarn install (or any curl | bash), ask for confirmation.
• Never paste or store secrets. If .env is needed, ask user to provide values out-of-band.

Workflow

1. Clone / prepare workspace

   • Clone to <openclaw-workspace>/projects/<repo> (create projects/ if missing)
   • Typical workspace path is $HOME/.openclaw/workspace, but don’t assume.
   • If already exists, ask before git pull or deleting anything.

2. Find the canonical docs

   • Prefer README.md + docs/ + CONTRIBUTING.md
   • Extract: prerequisites (Node/Python/Docker/Go/Rust), install steps, env vars, run command(s), ports.

3. Detect project type(s)

   • From the repo-runner skill directory (typically <openclaw-workspace>/skills/repo-runner), run: bash scripts/detect_project.sh <repoDir>
   • A repo can match multiple types (e.g. type=node + type=docker). Use docs to choose the canonical path.

4. Set up prerequisites

   • Verify required runtimes exist (Node/pnpm/yarn, Python, Docker, Go, Rust)
   • If missing, propose options (install locally, use Docker, or switch to a supported env)

5. Configure env

   • If .env.example exists, copy to .env only after confirmation
   • Ask user to fill required keys

6. Install dependencies (after confirmation, based on project type)

   • Node (when package.json exists)

     • Prefer lockfile-safe commands:
       • pnpm install --frozen-lockfile (if pnpm-lock.yaml)
       • yarn install --frozen-lockfile (if yarn.lock)
       • npm ci (if package-lock.json)
     • If unsure, run: bash scripts/suggest_node_commands.sh <repoDir>

   • Python (when pyproject.toml / requirements.txt exists)

     • Create and use a virtualenv (don’t install into system Python).
     • Typical patterns (follow docs first):
       • python -m venv .venv && source .venv/bin/activate
       • pip install -r requirements.txt
       • If pyproject.toml: use the tool specified by docs (commonly poetry install or pip install -e .).

   • Rust (when Cargo.toml exists)

     • cargo build / cargo test / cargo run (follow docs for features/flags)

   • Go (when go.mod exists)

     • go test ./...
     • go run . or go build ./... (follow docs for main package path)

   • Docker (when docker-compose.yml / Dockerfile exists)

     • Prefer the documented compose path when present:
       • docker compose up (or docker-compose up depending on docs)

7. Run

   • Use the docs’ recommended run target (dev server, CLI, compose stack, etc.)
   • Capture logs, detect common failures, iterate

Common outputs to report back

• Exact commands run (copy/paste friendly)
• URL/port to open
• Next steps (build/test) and known caveats