Menu
Build and install the steop companion binary to ~/.local/bin
Installer avec Codex ou Claude Copiez ce prompt, collez-le dans Codex, Claude ou un autre assistant, puis laissez-le vérifier la page du skill et l'installer pour vous.
Basé sur la classification professionnelle SOC
| name | install |
| description | Build and install the steop companion binary to ~/.local/bin |
| user-invocable | true |
End-to-end setup for the steop companion binary. Uses go install to pull the source module from the Go proxy and drop a statically-linked binary into ~/.local/bin.
The steop plugin ships skills, agents, and Claude Code hooks. The hooks call a steop binary which must be on your PATH. This skill installs that binary.
uname -s
Store the result — macOS (Darwin) or Linux (Linux). Windows users can install directly via go install github.com/tasanakorn/stele/apps/steop@main with GOBIN set to a directory on their PATH.
Verify the Go toolchain is available:
go version
If go is not found, tell the user:
steop's companion binary is built from Go source and requires the Go toolchain (1.22 or newer). Install it from https://go.dev/dl/ then re-run
/steop:install.
Stop here if Go is missing. Git is not required — go install fetches the source via the Go module proxy.
The binary installs to ~/.local/bin. Create it if missing:
mkdir -p "$HOME/.local/bin"
Tell the user:
Installing
steopviago installfrom themainbranch. The first run downloads the module to your Go module cache; subsequent reinstalls reuse the cache and finish in seconds.
GOBIN="$HOME/.local/bin" go install -trimpath -ldflags="-s -w" \
github.com/tasanakorn/stele/apps/steop@main
Why @main and not @latest? stele is a monorepo — apps/steop/ is a subdirectory module, so Go's proxy only recognises release tags prefixed with apps/steop/vX.Y.Z. Rather than maintaining a parallel tag stream just for steop, we install from the main branch HEAD. The resulting binary records a Go pseudo-version (e.g. v0.0.0-20260410133000-abc123def456) in its build metadata, but steop version continues to report the human-facing version from apps/steop/version.go — currently 0.4.1.
To pin a different point, replace @main:
@<commit-sha> — exact commit (the most reliable pin for reproducibility)@<branch-name> — tip of a feature branchTo see which commit a currently-installed binary was built from:
go version -m "$(which steop)" | grep vcs
steop now keeps session state, storage blobs, and hook logs in a local SQLite DB at $XDG_DATA_HOME/steop/steop.db (defaults to ~/.local/share/steop/steop.db). Pre-create it so the first hook fires without paying the schema-init cost:
steop db init
This prints the resolved DB path and exits 0. Re-running is a no-op — the schema is versioned and migrations are idempotent.
Check that steop is reachable on PATH:
which steop && steop version
If steop is not found, ~/.local/bin is probably not on PATH. Offer the snippet for their shell rc file (~/.zshrc or ~/.bashrc):
export PATH="$HOME/.local/bin:$PATH"
Then re-open their shell and retry steop version. If it still fails, stop and ask the user to troubleshoot their PATH.
Tell the user:
steop as a bare command, so ~/.local/bin must remain on your PATH whenever Claude Code runs. If it is not, the hooks will fail silently (Claude Code tolerates hook failures as advisory)./stele:install — steop reuses stele's ~/.config/stele/config.toml profile./steop:statusline-setup next.apps/steop/scripts/build.sh — it builds from your working tree instead of the Go proxy and installs to ~/.local/bin.Clarify phase of the workflow chain. Uses Opus to analyze the user's request, resolve ambiguities, define scope, and produce a clear task brief before research begins.
Execute phase of the workflow chain. Uses Haiku (simple), Sonnet (standard), or Opus (complex) to implement code changes according to a plan. Use when the user has an approved plan ready to execute.
Flow workflow chain that runs clarify → [research] → plan → execute → validate end-to-end without stopping. Pauses only on genuine ambiguity or circuit-breaker conditions.
Plan phase of the workflow chain. Uses Opus to design an implementation strategy. Use when the user wants to create a detailed plan before executing changes.
Research phase of the workflow chain. Uses Haiku (simple) or Sonnet (standard) to research the codebase and gather context for a task. Use when the user wants to investigate code before planning.
Validate phase of the workflow chain. Uses Sonnet to review and validate implementation changes. Use when the user wants to validate that code changes are correct and complete.