Commands
shllmeta-CLI for the shll toolkit
shll — meta-CLI for the shll toolkit. shll composes operations that span every per-tool CLI (hop, wt, fab-kit, run-kit, tu, idea) so you have one entry point for cross-toolkit concerns. Subcommands: shll doctor verify every shll tool is installed, runnable, and wired (read-only) shll install brew install every shll tool that isn't already installed shll update brew update + brew upgrade for shll and every installed shll tool shll check-updates check which shll tools have updates available (read-only) shll uninstall brew uninstall shll tools (a clean-slate repair path) shll changelog show release notes for shll tools (what an update would bring) shll shell-init <shell> emit a single eval-safe shell-init blob for all installed tools shll setup [shell|agent] wire this machine: rc-file shell integration + agent-harness skills (idempotent) shll version print versions of shll and every installed shll tool shll list list the managed shll tools with install status and repo links shll standards [name] read the toolkit's binding standards (list them, or print one) shll skill [tool] [topic] read a tool's agent skill bundle or one of its topic pages (or list installed tools) Per-tool CLIs continue to work standalone — shll wraps them, it does not replace them.
shll [command]
| flag | type | description | copy |
|---|---|---|---|
-v, --version | version for shll |
No flags match that filter.
show raw -h output
shll — meta-CLI for the shll toolkit. shll composes operations that span every per-tool CLI (hop, wt, fab-kit, run-kit, tu, idea) so you have one entry point for cross-toolkit concerns. Subcommands: shll doctor verify every shll tool is installed, runnable, and wired (read-only) shll install brew install every shll tool that isn't already installed shll update brew update + brew upgrade for shll and every installed shll tool shll check-updates check which shll tools have updates available (read-only) shll uninstall brew uninstall shll tools (a clean-slate repair path) shll changelog show release notes for shll tools (what an update would bring) shll shell-init <shell> emit a single eval-safe shell-init blob for all installed tools shll setup [shell|agent] wire this machine: rc-file shell integration + agent-harness skills (idempotent) shll version print versions of shll and every installed shll tool shll list list the managed shll tools with install status and repo links shll standards [name] read the toolkit's binding standards (list them, or print one) shll skill [tool] [topic] read a tool's agent skill bundle or one of its topic pages (or list installed tools) Per-tool CLIs continue to work standalone — shll wraps them, it does not replace them. Usage: shll [command] Available Commands: changelog show release notes for shll tools (what an update would bring) check-updates check which shll tools have updates available (read-only, never updates) doctor verify every shll tool is installed, runnable, and wired install brew install every shll tool that isn't already installed list list the shll tools shll manages, with install status and repo links setup wire this machine for the shll toolkit (shell + agent harnesses) shell-init emit composed shell-init for all installed shll tools skill read the agent skill bundle for a shll tool (or list installed tools) standards read the shll toolkit's binding standards (offline, embedded) uninstall brew uninstall shll tools (a clean-slate repair path) update brew update + per-tool update for shll and every installed shll tool version print versions of shll and every installed shll tool Flags: -h, --help help for shll -v, --version version for shll Use "shll [command] --help" for more information about a command.
shll changelogshow release notes for shll tools (what an update would bring)
Show GitHub release notes for shll tools. With no arguments, shll changelog shows the pending releases for every installed tool (its installed version → the latest release) — "what would an update bring?". Name one or more tools to scope it; add an explicit range with `tool@old..new` to show the releases in `(old, new]` regardless of what is installed. shll changelog all installed tools: installed → latest shll changelog tu one tool: installed → latest shll changelog tu@0.6.2..0.6.4 explicit range (releases in (0.6.2, 0.6.4]) shll changelog tu@0.6.2..0.6.4 hop@0.1.16..0.1.18 Valid tool names are the roster names plus shll itself. Versions are accepted with or without a leading v. Release data is fetched from GitHub, unauthenticated; if a fetch fails the entry degrades to a compare URL and the command still exits 0.
shll changelog [tool[@old..new]]... [flags]
show raw -h output
Show GitHub release notes for shll tools. With no arguments, shll changelog shows the pending releases for every installed tool (its installed version → the latest release) — "what would an update bring?". Name one or more tools to scope it; add an explicit range with `tool@old..new` to show the releases in `(old, new]` regardless of what is installed. shll changelog all installed tools: installed → latest shll changelog tu one tool: installed → latest shll changelog tu@0.6.2..0.6.4 explicit range (releases in (0.6.2, 0.6.4]) shll changelog tu@0.6.2..0.6.4 hop@0.1.16..0.1.18 Valid tool names are the roster names plus shll itself. Versions are accepted with or without a leading v. Release data is fetched from GitHub, unauthenticated; if a fetch fails the entry degrades to a compare URL and the command still exits 0. Usage: shll changelog [tool[@old..new]]... [flags] Flags: -h, --help help for changelog
shll check-updatescheck which shll tools have updates available (read-only, never updates)
Check for pending shll toolkit updates — installed version vs latest available — for shll itself plus every roster tool. Read-only: nothing is upgraded, installed, or written. To apply updates, run `shll update`. One backend, selected by --source: --source released latest versions + notify policy from https://shll.ai/versions.json (the default when the flag is omitted) --source github latest release tag per tool from the GitHub API (unauthenticated; no notify policy in this backend) shll check-updates human table: installed → latest per tool shll check-updates --json machine contract (what run-kit's daemon runs) shll check-updates --source github compare against GitHub release tags Installed versions are read from Homebrew, so brew must be present. Exit codes: 0 when the check ran (whether or not updates are pending — verdicts live in the output), 1 when the check itself failed (manifest unreachable, brew missing), 2 on a usage error. A github-backend per-tool fetch failure degrades that tool only (omitted from --json, noted in the table) and the run still exits 0.
shll check-updates [flags]
| flag | type | description | copy |
|---|---|---|---|
--json | emit the machine contract as JSON (for scripting; run-kit's consumer surface) | ||
--source | string | update-check backend: released (shll.ai versions manifest + notify policy; the default) or github (release tags, no notify policy) (default "released") |
No flags match that filter.
show raw -h output
Check for pending shll toolkit updates — installed version vs latest available —
for shll itself plus every roster tool. Read-only: nothing is upgraded, installed,
or written. To apply updates, run `shll update`.
One backend, selected by --source:
--source released latest versions + notify policy from https://shll.ai/versions.json
(the default when the flag is omitted)
--source github latest release tag per tool from the GitHub API (unauthenticated;
no notify policy in this backend)
shll check-updates human table: installed → latest per tool
shll check-updates --json machine contract (what run-kit's daemon runs)
shll check-updates --source github compare against GitHub release tags
Installed versions are read from Homebrew, so brew must be present. Exit codes:
0 when the check ran (whether or not updates are pending — verdicts live in the
output), 1 when the check itself failed (manifest unreachable, brew missing),
2 on a usage error. A github-backend per-tool fetch failure degrades that tool
only (omitted from --json, noted in the table) and the run still exits 0.
Usage:
shll check-updates [flags]
Flags:
-h, --help help for check-updates
--json emit the machine contract as JSON (for scripting; run-kit's consumer surface)
--source string update-check backend: released (shll.ai versions manifest + notify policy; the default) or github (release tags, no notify policy) (default "released")
shll doctorverify every shll tool is installed, runnable, and wired
Verify the shll toolkit is correctly installed and wired. For every roster tool, doctor checks that (1) the binary is on PATH, (2) it reports a version (so a half-installed/stale brew link is caught), (3) its Homebrew formula is trusted (so a future 'brew upgrade' won't be refused on Homebrew 6.0+), and (4) — for tools that ship shell integration (wt, tu, hop) — shll's composed shell-init eval block is present in your rc file. rk-desktop is not a brew formula: its checks (1)-(2) run through `rk desktop status` instead, and the trust check does not apply. Each tool gets one line with an OK / WARN / FAIL marker; non-OK lines carry an actionable suggestion. A missing or non-running binary is FAIL; an installed tool that simply isn't wired into your shell — or whose formula isn't trusted — is WARN (it still works when invoked directly). doctor exits non-zero if ANY tool is FAIL, so it is scriptable in CI. The leading shll row additionally checks any agent skill placed by 'shll setup agent': a placed skill whose content is stale (from an older shll) is WARN with a refresh pointer. No placement means no check — agent setup is opt-in. The trust sub-check queries 'brew trust --json=v1' read-only; if your Homebrew is too old to ship 'brew trust' (where trust isn't required anyway), it is skipped silently. doctor is strictly read-only — it never installs, upgrades, trusts, or edits your rc file. Use --json to emit a machine-readable array (one object per tool) instead of the aligned text table; the same checks and the same exit contract apply.
shll doctor [flags]
| flag | type | description | copy |
|---|---|---|---|
--json | emit a machine-readable JSON array instead of the aligned text table |
No flags match that filter.
show raw -h output
Verify the shll toolkit is correctly installed and wired. For every roster
tool, doctor checks that (1) the binary is on PATH, (2) it reports a version (so
a half-installed/stale brew link is caught), (3) its Homebrew formula is trusted
(so a future 'brew upgrade' won't be refused on Homebrew 6.0+), and (4) — for
tools that ship shell integration (wt, tu, hop) — shll's composed shell-init eval
block is present in your rc file. rk-desktop is not a brew formula: its checks
(1)-(2) run through `rk desktop status` instead, and the trust check
does not apply.
Each tool gets one line with an OK / WARN / FAIL marker; non-OK lines carry an
actionable suggestion. A missing or non-running binary is FAIL; an installed tool
that simply isn't wired into your shell — or whose formula isn't trusted — is
WARN (it still works when invoked directly). doctor exits non-zero if ANY tool is
FAIL, so it is scriptable in CI.
The leading shll row additionally checks any agent skill placed by
'shll setup agent': a placed skill whose content is stale (from an older shll) is
WARN with a refresh pointer. No placement means no check — agent setup is opt-in.
The trust sub-check queries 'brew trust --json=v1' read-only; if your Homebrew is
too old to ship 'brew trust' (where trust isn't required anyway), it is skipped
silently. doctor is strictly read-only — it never installs, upgrades, trusts, or
edits your rc file.
Use --json to emit a machine-readable array (one object per tool) instead of the
aligned text table; the same checks and the same exit contract apply.
Usage:
shll doctor [flags]
Flags:
-h, --help help for doctor
--json emit a machine-readable JSON array instead of the aligned text table
shll installbrew install every shll tool that isn't already installed
Install every roster tool that isn't already installed. shll install iterates the roster (`run-kit`, `rk-desktop`, `fab-kit`, `wt`, `idea`, `tu`, `hop`). Brew-managed tools install via `brew install sahil87/tap/<formula>`; rk-desktop is not a brew formula — it delegates to `rk desktop install` (managed by run-kit, so it is actionable only when `rk` is installed and the platform supports it; otherwise it is skipped with a note, never a failure — on a targeted `shll install rk-desktop` the refusal is printed explicitly). Tools that are already installed are skipped silently — the command is idempotent and safe to re-run. Brew's progress output streams directly to your terminal. With no arguments, shll install processes the whole roster as above. Pass one or more tool names to install only that subset (valid targets: run-kit, rk-desktop, fab-kit, wt, idea, tu, hop; the legacy alias `rk` still resolves to run-kit) — e.g. `shll install hop wt`. The subset is processed in roster order regardless of the order given; an unknown name is a hard error. Unlike `shll update`, `shll` itself is NOT a valid install target — you cannot brew-install the running orchestrator. By default, shll install records per-formula Homebrew trust before each install — it runs `brew trust --formula sahil87/tap/<formula>` for each tool in the install set first. Homebrew 6.0 makes tap-trust a hard install requirement, and a binary-download formula runs a sandboxed `def install` that requires a real trust record, so this is what lets the install actually proceed. `brew trust` is idempotent, so re-runs stay clean. Pass `--no-trust` to skip the trust step (for users who manage trust themselves). If your Homebrew is too old to ship `brew trust`, the trust step is skipped gracefully and the install proceeds. After the install outcome, shll install also wires the machine automatically. It runs the equivalent of `shll setup shell` (adds the `eval "$(shll shell-init <shell>)"` line to your rc file — sentinel-managed and idempotent, so re-runs are no-ops), then `shll setup agent --yes` (places the shll-toolkit skill for agent harnesses and delegates run-kit's dashboard hooks, forwarding --yes so nothing can prompt on an unattended run). Both steps are best-effort: a failure warns and prints the step's manual nudge instead, and never changes the install's exit code. Opt out with `--no-shell-setup` (e.g. dotfile-manager users) and/or `--no-agent-setup`. Neither step runs under `--dry-run`. After a fresh wire, restart your shell or run: exec $SHELL. shll install does NOT upgrade already-installed tools. Use `shll update` for that.
shll install [tool...] [flags]
| flag | type | description | copy |
|---|---|---|---|
--dry-run | preview what would run, without making any changes | ||
--no-agent-setup | skip the automatic agent-setup step at the end of install (wire agent harnesses yourself) | ||
--no-shell-setup | skip the automatic shell-setup step at the end of install (wire your rc file yourself) | ||
--no-trust | skip recording per-formula Homebrew trust before installing (manage trust yourself) |
No flags match that filter.
show raw -h output
Install every roster tool that isn't already installed.
shll install iterates the roster (`run-kit`, `rk-desktop`, `fab-kit`, `wt`, `idea`, `tu`, `hop`).
Brew-managed tools install via `brew install sahil87/tap/<formula>`;
rk-desktop is not a brew formula — it delegates to `rk desktop install`
(managed by run-kit, so it is actionable only when `rk` is installed
and the platform supports it; otherwise it is skipped with a note, never a
failure — on a targeted `shll install rk-desktop` the refusal is
printed explicitly). Tools that are already installed are skipped silently —
the command is idempotent and safe to re-run. Brew's progress output streams
directly to your terminal.
With no arguments, shll install processes the whole roster as above. Pass one or
more tool names to install only that subset (valid targets: run-kit, rk-desktop,
fab-kit, wt, idea, tu, hop; the legacy alias `rk` still resolves to run-kit) — e.g.
`shll install hop wt`. The subset is processed in roster order
regardless of the order given; an unknown name is a hard error. Unlike
`shll update`, `shll` itself is NOT a valid install target — you cannot
brew-install the running orchestrator.
By default, shll install records per-formula Homebrew trust before each install —
it runs `brew trust --formula sahil87/tap/<formula>` for each tool in the
install set first. Homebrew 6.0 makes tap-trust a hard install requirement, and a
binary-download formula runs a sandboxed `def install` that requires a real
trust record, so this is what lets the install actually proceed. `brew trust` is
idempotent, so re-runs stay clean. Pass `--no-trust` to skip the trust step
(for users who manage trust themselves). If your Homebrew is too old to ship
`brew trust`, the trust step is skipped gracefully and the install proceeds.
After the install outcome, shll install also wires the machine automatically. It
runs the equivalent of `shll setup shell` (adds the
`eval "$(shll shell-init <shell>)"` line to your rc file — sentinel-managed and
idempotent, so re-runs are no-ops), then `shll setup agent --yes` (places the
shll-toolkit skill for agent harnesses and delegates run-kit's dashboard hooks,
forwarding --yes so nothing can prompt on an unattended run). Both steps are
best-effort: a failure warns and prints the step's manual nudge instead, and
never changes the install's exit code. Opt out with `--no-shell-setup` (e.g.
dotfile-manager users) and/or `--no-agent-setup`. Neither step runs under
`--dry-run`. After a fresh wire, restart your shell or run: exec $SHELL.
shll install does NOT upgrade already-installed tools. Use `shll update`
for that.
Usage:
shll install [tool...] [flags]
Flags:
--dry-run preview what would run, without making any changes
-h, --help help for install
--no-agent-setup skip the automatic agent-setup step at the end of install (wire agent harnesses yourself)
--no-shell-setup skip the automatic shell-setup step at the end of install (wire your rc file yourself)
--no-trust skip recording per-formula Homebrew trust before installing (manage trust yourself)
shll listlist the shll tools shll manages, with install status and repo links
List the shll toolkit roster shll manages — one row per tool with an install-status indicator, a one-line description, and its GitHub repo URL. Install status reuses the same PATH probe as `shll version` (`<tool> --version`, any error means missing) — install-mechanism agnostic, not a Homebrew check. A missing tool is shown as missing, never an error: `shll list` always exits 0. Default output is a column-aligned table (with color when writing to a terminal). Pass --json for a plain JSON array suitable for scripting (`shll list --json | jq`).
shll list [flags]
| flag | type | description | copy |
|---|---|---|---|
--json | emit the roster as a JSON array (no color, for scripting) |
No flags match that filter.
show raw -h output
List the shll toolkit roster shll manages — one row per tool with an
install-status indicator, a one-line description, and its GitHub repo URL.
Install status reuses the same PATH probe as `shll version` (`<tool> --version`,
any error means missing) — install-mechanism agnostic, not a Homebrew check. A
missing tool is shown as missing, never an error: `shll list` always exits 0.
Default output is a column-aligned table (with color when writing to a terminal).
Pass --json for a plain JSON array suitable for scripting (`shll list --json | jq`).
Usage:
shll list [flags]
Flags:
-h, --help help for list
--json emit the roster as a JSON array (no color, for scripting)
shll setupwire this machine for the shll toolkit (shell + agent harnesses)
Wire this machine for the shll toolkit — both halves, in order: shell integration (the `eval "$(shll shell-init <shell>)"` line in your rc file), then agent-harness wiring (the shll-toolkit skill plus run-kit's dashboard hooks). Both halves are idempotent — re-running is safe, e.g. after installing a new shell or a new agent harness. This is the same wiring `shll install` runs automatically at the end of an install; `shll setup` is the standalone re-run entry point. Pass `--yes` (or `-y`) to forward `--yes` to the run-kit delegation so nothing can prompt on an unattended run. Both halves always run — the agent half runs even when the shell half failed — and the exit code is the worst of the two. Subcommands: shll setup shell [shell] the shell half only (rc-file block; --print/--uninstall/--rc-file) shll setup agent the agent half only (skill placement; --print/--uninstall/--yes)
shll setup [flags]shll setup [command]
| flag | type | description | copy |
|---|---|---|---|
-y, --yes | pass --yes to the run-kit agent setup delegation (assume yes — for unattended runs) |
No flags match that filter.
show raw -h output
Wire this machine for the shll toolkit — both halves, in order: shell integration (the `eval "$(shll shell-init <shell>)"` line in your rc file), then agent-harness wiring (the shll-toolkit skill plus run-kit's dashboard hooks). Both halves are idempotent — re-running is safe, e.g. after installing a new shell or a new agent harness. This is the same wiring `shll install` runs automatically at the end of an install; `shll setup` is the standalone re-run entry point. Pass `--yes` (or `-y`) to forward `--yes` to the run-kit delegation so nothing can prompt on an unattended run. Both halves always run — the agent half runs even when the shell half failed — and the exit code is the worst of the two. Subcommands: shll setup shell [shell] the shell half only (rc-file block; --print/--uninstall/--rc-file) shll setup agent the agent half only (skill placement; --print/--uninstall/--yes) Usage: shll setup [flags] shll setup [command] Available Commands: agent place the shll toolkit skill for agent harnesses shell append the shll shell-init eval line to your rc file Flags: -h, --help help for setup -y, --yes pass --yes to the run-kit agent setup delegation (assume yes — for unattended runs) Use "shll setup [command] --help" for more information about a command.
shll setup agentplace the shll toolkit skill for agent harnesses
Mechanically place one thin Agent Skill — the shll toolkit bootstrap — into the agent harnesses' global skills directories, then delegate run-kit's dashboard-hook wiring to `run-kit agent setup`. The skill teaches an agent to load `shll skill` before driving a toolkit tool. The skill is written to exactly two global locations (covering all four harnesses): ~/.agents/skills/shll-toolkit/SKILL.md Codex (USER scope), Cursor + OpenCode ~/.claude/skills/shll-toolkit/SKILL.md Claude Code The skill directories are shll-owned, so placement is idempotent by construction — install writes them, a re-run overwrites them, and there is no merge, prompt, or sentinel machinery. A per-path written/updated/unchanged summary is printed. Modes: shll setup agent place the skill at both locations (overwrites; idempotent) shll setup agent --print print the SKILL.md content and both target paths, write nothing shll setup agent --uninstall remove both placed skill directories Pass `--yes` (or `-y`) to forward `--yes` to the run-kit delegation so its own confirmation prompt is skipped — for unattended runs (shll's skill placement itself never prompts). With `--print` the flag is a no-op (print never delegates). The pre-consolidation spelling `shll agent-setup` still works for one release cycle — hidden and silent — and will be removed in a future release.
shll setup agent [flags]
| flag | type | description | copy |
|---|---|---|---|
--print | print the SKILL.md content and target paths, do not write any file | ||
--uninstall | remove both placed shll-toolkit skill directories | ||
-y, --yes | pass --yes to the run-kit agent setup delegation (assume yes — for unattended runs) |
No flags match that filter.
show raw -h output
Mechanically place one thin Agent Skill — the shll toolkit bootstrap — into the
agent harnesses' global skills directories, then delegate run-kit's dashboard-hook
wiring to `run-kit agent setup`. The skill teaches an agent to load `shll skill` before
driving a toolkit tool.
The skill is written to exactly two global locations (covering all four harnesses):
~/.agents/skills/shll-toolkit/SKILL.md Codex (USER scope), Cursor + OpenCode
~/.claude/skills/shll-toolkit/SKILL.md Claude Code
The skill directories are shll-owned, so placement is idempotent by construction —
install writes them, a re-run overwrites them, and there is no merge, prompt, or
sentinel machinery. A per-path written/updated/unchanged summary is printed.
Modes:
shll setup agent place the skill at both locations (overwrites; idempotent)
shll setup agent --print print the SKILL.md content and both target paths, write nothing
shll setup agent --uninstall remove both placed skill directories
Pass `--yes` (or `-y`) to forward `--yes` to the run-kit delegation so its own
confirmation prompt is skipped — for unattended runs (shll's skill placement itself
never prompts). With `--print` the flag is a no-op (print never delegates).
The pre-consolidation spelling `shll agent-setup` still works for one release
cycle — hidden and silent — and will be removed in a future release.
Usage:
shll setup agent [flags]
Flags:
-h, --help help for agent
--print print the SKILL.md content and target paths, do not write any file
--uninstall remove both placed shll-toolkit skill directories
-y, --yes pass --yes to the run-kit agent setup delegation (assume yes — for unattended runs)
shll setup shellappend the shll shell-init eval line to your rc file
Append a sentinel-wrapped eval block that wires shll shell-init into your shell rc file. Idempotent — re-running is a no-op when the block is already present. Plain O_APPEND so dotfile-manager symlinks are preserved. Modes: shll setup shell [shell] install the block (default mode) shll setup shell --print [shell] print the block to stdout, do not modify shll setup shell --uninstall [shell] remove the block from the rc file shll setup shell is pure rc-wiring — it maintains only the `eval "$(shll shell-init <shell>)"` line and touches no Homebrew state. (Tap trust is established by `shll install`, which trusts each formula it installs; see `shll install --help`.) When [shell] is omitted, shll infers it from $SHELL. Supported shells: zsh, bash. By default, the rc file path is derived per shell: zsh → ${ZDOTDIR:-$HOME}/.zshrc bash → $HOME/.bash_profile (macOS) or $HOME/.bashrc (Linux) Use --rc-file <path> to override derivation entirely. The pre-consolidation spelling `shll shell-setup` (alias `shll shell-install`) still works for one release cycle — hidden and silent — and will be removed in a future release.
shll setup shell [shell] [flags]
| flag | type | description | copy |
|---|---|---|---|
--print | print the block to stdout, do not modify any file | ||
--rc-file | string | override the rc file path (escape hatch for non-standard layouts) | |
--uninstall | remove the shll-managed block from the rc file |
No flags match that filter.
show raw -h output
Append a sentinel-wrapped eval block that wires shll shell-init into your
shell rc file. Idempotent — re-running is a no-op when the block is already
present. Plain O_APPEND so dotfile-manager symlinks are preserved.
Modes:
shll setup shell [shell] install the block (default mode)
shll setup shell --print [shell] print the block to stdout, do not modify
shll setup shell --uninstall [shell] remove the block from the rc file
shll setup shell is pure rc-wiring — it maintains only the
`eval "$(shll shell-init <shell>)"` line and touches no Homebrew state.
(Tap trust is established by `shll install`, which trusts each formula it
installs; see `shll install --help`.)
When [shell] is omitted, shll infers it from $SHELL. Supported shells: zsh, bash.
By default, the rc file path is derived per shell:
zsh → ${ZDOTDIR:-$HOME}/.zshrc
bash → $HOME/.bash_profile (macOS) or $HOME/.bashrc (Linux)
Use --rc-file <path> to override derivation entirely.
The pre-consolidation spelling `shll shell-setup` (alias `shll shell-install`)
still works for one release cycle — hidden and silent — and will be removed in a
future release.
Usage:
shll setup shell [shell] [flags]
Flags:
-h, --help help for shell
--print print the block to stdout, do not modify any file
--rc-file string override the rc file path (escape hatch for non-standard layouts)
--uninstall remove the shll-managed block from the rc file
shll shell-initemit composed shell-init for all installed shll tools
Emit a single concatenated shell-init blob for every installed shll tool that exposes shell integration. Today, tu, hop, and wt are the roster tools with shell integration. The output is eval-safe: missing tools produce no output, errors go to stderr, and stdout is shell code only. Use: eval "$(shll shell-init zsh)" # in your ~/.zshrc eval "$(shll shell-init bash)" # in your ~/.bashrc
shll shell-init <shell> [flags]
show raw -h output
Emit a single concatenated shell-init blob for every installed shll tool
that exposes shell integration.
Today, tu, hop, and wt are the roster tools with shell integration. The output
is eval-safe: missing tools produce no output, errors go to stderr, and stdout
is shell code only.
Use: eval "$(shll shell-init zsh)" # in your ~/.zshrc
eval "$(shll shell-init bash)" # in your ~/.bashrc
Usage:
shll shell-init <shell> [flags]
Flags:
-h, --help help for shell-init
shll skillread the agent skill bundle for a shll tool (or list installed tools)
Read the offline agent skill bundle for a shll tool — the one-page usage briefing an agent loads before driving the tool (per the toolkit's `skill` standard). Bare `shll skill` prints a one-line glossary of the installed tools (shll first, then the roster) — NOT a dump of every bundle. Pick one and ask for it by name: shll skill list installed tools, one line each shll skill <tool> print that tool's full agent skill bundle (raw markdown, stdout) shll skill <tool> <topic> print one of that tool's topic pages (large-scope tools) `shll skill <tool>` streams the tool's own `<tool> skill` output byte-for-byte (`shll skill shll` serves shll's own bundle from an embedded copy). A tool that is not installed, or whose version predates its `skill` subcommand, prints a one-line notice to stderr and exits 1; an unknown tool name is a usage error (exit 2). `shll skill <tool> <topic>` delegates to `<tool> skill <topic>` verbatim (a tool's core bundle lists its topics). On success it streams the topic page byte-for-byte. On a child failure it propagates the child's own stderr and exit code UNCHANGED — so an unknown topic surfaces the tool's own diagnostic (valid topics on stderr, non-zero exit), not a shll-rewritten one. shll ships no topics of its own, so `shll skill shll <topic>` is a usage error (exit 2).
shll skill [tool] [topic] [flags]
show raw -h output
Read the offline agent skill bundle for a shll tool — the one-page usage briefing an agent loads before driving the tool (per the toolkit's `skill` standard). Bare `shll skill` prints a one-line glossary of the installed tools (shll first, then the roster) — NOT a dump of every bundle. Pick one and ask for it by name: shll skill list installed tools, one line each shll skill <tool> print that tool's full agent skill bundle (raw markdown, stdout) shll skill <tool> <topic> print one of that tool's topic pages (large-scope tools) `shll skill <tool>` streams the tool's own `<tool> skill` output byte-for-byte (`shll skill shll` serves shll's own bundle from an embedded copy). A tool that is not installed, or whose version predates its `skill` subcommand, prints a one-line notice to stderr and exits 1; an unknown tool name is a usage error (exit 2). `shll skill <tool> <topic>` delegates to `<tool> skill <topic>` verbatim (a tool's core bundle lists its topics). On success it streams the topic page byte-for-byte. On a child failure it propagates the child's own stderr and exit code UNCHANGED — so an unknown topic surfaces the tool's own diagnostic (valid topics on stderr, non-zero exit), not a shll-rewritten one. shll ships no topics of its own, so `shll skill shll <topic>` is a usage error (exit 2). Usage: shll skill [tool] [topic] [flags] Flags: -h, --help help for skill
shll standardsread the shll toolkit's binding standards (offline, embedded)
Read the shll toolkit's binding, producer-facing standards. Bare `shll standards` lists every available standard with its scope and a one-line description of what it governs and when it applies (name, scope, description) — self-describing so an agent told only to "run shll standards" can pick the right document. Pass --json for a machine-readable array of {name, description, scope, source_path} objects (`shll standards --json | jq`). `shll standards <name>` prints the full markdown document to stdout, byte-identical to its canonical docs/site/standards source. Raw markdown, no rendering, no pager — agents consume it directly. An unknown name is an actionable error on stderr (exit non-zero). The content is embedded into the binary at build time, so it is offline and versioned with the release — when a canonical doc changes, the next shll release picks it up.
shll standards [name] [flags]
| flag | type | description | copy |
|---|---|---|---|
--json | emit the standards roster as a JSON array (no color, for scripting) |
No flags match that filter.
show raw -h output
Read the shll toolkit's binding, producer-facing standards.
Bare `shll standards` lists every available standard with its scope and a
one-line description of what it governs and when it applies (name, scope, description) —
self-describing so an agent told only to "run shll standards" can pick the right document.
Pass --json for a machine-readable array of {name, description, scope, source_path} objects
(`shll standards --json | jq`).
`shll standards <name>` prints the full markdown document to stdout, byte-identical
to its canonical docs/site/standards source. Raw markdown, no rendering, no pager — agents
consume it directly. An unknown name is an actionable error on stderr (exit non-zero).
The content is embedded into the binary at build time, so it is offline and versioned
with the release — when a canonical doc changes, the next shll release picks it up.
Usage:
shll standards [name] [flags]
Flags:
-h, --help help for standards
--json emit the standards roster as a JSON array (no color, for scripting)
shll uninstallbrew uninstall shll tools (a clean-slate repair path)
Uninstall shll toolkit tools via Homebrew — the clean-slate repair path that pairs with `shll install`. With no arguments, shll uninstall removes every INSTALLED brew-managed roster tool (`run-kit`, `fab-kit`, `wt`, `idea`, `tu`, `hop`) in reverse-roster order. rk-desktop is not a brew formula — it is skipped with a note (remove it via `rk desktop` itself), never `brew uninstall`ed. Tools that are not installed are skipped silently — uninstall is idempotent and its goal state ("gone") is a success even when a tool was already absent. shll itself is NOT part of the no-args sweep. Pass one or more tool names to uninstall only that subset (valid targets: shll, run-kit, rk-desktop, fab-kit, wt, idea, tu, hop; the legacy alias `rk` still resolves to run-kit). `shll uninstall shll` is legal and explicit-only — it removes shll itself (last, after the roster), and only when shll was installed via brew. The running process keeps working; a farewell note points at the reinstall command. By default shll uninstall prints the removal plan and asks for confirmation (`Proceed? [y/N]`). Pass `--yes` (or `-y`) to skip the prompt. On a non-interactive stdin (a pipe / CI) without `--yes`, shll uninstall refuses rather than removing without consent. Pass `--dry-run` to preview the exact brew commands without removing anything. shll uninstall does NOT untap sahil87/tap, revoke trust, purge tool state/config, or stop running processes (it prints hints for the daemon and rc-file cleanup instead).
shll uninstall [tool...] [flags]
| flag | type | description | copy |
|---|---|---|---|
--dry-run | preview what would run, without making any changes | ||
-y, --yes | skip the confirmation prompt (assume yes — for scripting) |
No flags match that filter.
show raw -h output
Uninstall shll toolkit tools via Homebrew — the clean-slate repair path
that pairs with `shll install`.
With no arguments, shll uninstall removes every INSTALLED brew-managed roster tool
(`run-kit`, `fab-kit`, `wt`, `idea`, `tu`, `hop`) in reverse-roster order.
rk-desktop is not a brew formula — it is skipped with a note (remove it via
`rk desktop` itself), never `brew uninstall`ed. Tools that are not installed
are skipped silently — uninstall is idempotent and its goal state ("gone") is a
success even when a tool was already absent. shll itself is NOT part of the
no-args sweep.
Pass one or more tool names to uninstall only that subset (valid targets: shll,
run-kit, rk-desktop, fab-kit, wt, idea, tu, hop; the legacy alias `rk` still resolves to
run-kit). `shll uninstall shll` is legal and explicit-only — it removes shll
itself (last, after the roster), and only when shll was installed via brew. The
running process keeps working; a farewell note points at the reinstall command.
By default shll uninstall prints the removal plan and asks for confirmation
(`Proceed? [y/N]`). Pass `--yes` (or `-y`) to skip the prompt.
On a non-interactive stdin (a pipe / CI) without `--yes`, shll uninstall
refuses rather than removing without consent. Pass `--dry-run` to preview the
exact brew commands without removing anything.
shll uninstall does NOT untap sahil87/tap, revoke trust, purge tool state/config, or
stop running processes (it prints hints for the daemon and rc-file cleanup instead).
Usage:
shll uninstall [tool...] [flags]
Flags:
--dry-run preview what would run, without making any changes
-h, --help help for uninstall
-y, --yes skip the confirmation prompt (assume yes — for scripting)
shll updatebrew update + per-tool update for shll and every installed shll tool
Update shll itself and every installed shll tool. shll update runs `brew update --quiet` once, then `brew upgrade sahil87/tap/shll` (when shll itself was installed via brew), then delegates to each installed roster tool's own `update` subcommand (with `--skip-brew-update` when the tool advertises it) so each tool's post-upgrade side effects (e.g. rk's daemon restart) are preserved. rk-desktop is not a brew formula — it delegates to `rk desktop update` (and is skipped when `rk` is absent or the platform is unsupported). A brew-managed roster tool that exposes no `update` is upgraded via `brew upgrade sahil87/tap/<formula>` instead. Uninstalled tools (including shll itself, e.g. on a `go install` dev build) are skipped silently. Brew and per-tool progress output streams directly to your terminal. When agent skills were previously placed via `shll setup agent`, the run ends by re-running `shll setup agent` so the placed skills track the freshly upgraded binaries (best-effort; skipped entirely when no placement exists). Pass `--yes` (or `-y`) to forward `--yes` through that refresh into the run-kit delegation, skipping its confirmation prompt — for unattended runs (an agent-driven pane, the run-kit dashboard's update button). Nothing else about the run prompts. With no arguments, shll update processes the whole roster as above. Pass one or more tool names to update only that subset (valid targets: shll, run-kit, rk-desktop, fab-kit, wt, idea, tu, hop; the legacy alias `rk` still resolves to run-kit) — e.g. `shll update shll` to bump only shll itself, or `shll update hop wt` for a pair. The subset is always processed in roster order regardless of the order given. An unknown name, or a named tool that is not installed, is a hard error (a named tool, unlike the whole-roster sweep, is not silently skipped).
shll update [tool...] [flags]
| flag | type | description | copy |
|---|---|---|---|
--dry-run | preview what would run, without making any changes | ||
-y, --yes | forward --yes to the end-of-run shll setup agent refresh (assume yes — for unattended runs) |
No flags match that filter.
show raw -h output
Update shll itself and every installed shll tool.
shll update runs `brew update --quiet` once, then `brew upgrade sahil87/tap/shll`
(when shll itself was installed via brew), then delegates to each installed roster
tool's own `update` subcommand (with `--skip-brew-update` when the tool
advertises it) so each tool's post-upgrade side effects (e.g. rk's daemon restart)
are preserved. rk-desktop is not a brew formula — it delegates to `rk desktop update`
(and is skipped when `rk` is absent or the platform is unsupported). A
brew-managed roster tool that exposes no `update` is upgraded via
`brew upgrade sahil87/tap/<formula>` instead. Uninstalled tools (including shll
itself, e.g. on a `go install` dev build) are skipped silently. Brew and per-tool
progress output streams directly to your terminal.
When agent skills were previously placed via `shll setup agent`, the run ends by
re-running `shll setup agent` so the placed skills track the freshly upgraded
binaries (best-effort; skipped entirely when no placement exists). Pass `--yes`
(or `-y`) to forward `--yes` through that refresh into the run-kit delegation,
skipping its confirmation prompt — for unattended runs (an agent-driven pane, the
run-kit dashboard's update button). Nothing else about the run prompts.
With no arguments, shll update processes the whole roster as above. Pass one or
more tool names to update only that subset (valid targets: shll, run-kit,
rk-desktop, fab-kit, wt, idea, tu, hop; the legacy alias `rk` still resolves to
run-kit) — e.g. `shll update shll` to bump only shll itself, or
`shll update hop wt` for a pair. The subset is always processed in roster order
regardless of the order given. An unknown name, or a named tool that is not
installed, is a hard error (a named tool, unlike the whole-roster sweep, is not
silently skipped).
Usage:
shll update [tool...] [flags]
Flags:
--dry-run preview what would run, without making any changes
-h, --help help for update
-y, --yes forward --yes to the end-of-run shll setup agent refresh (assume yes — for unattended runs)
shll versionprint versions of shll and every installed shll tool
Print a column-aligned plain-text table showing the version of shll itself plus every roster tool. Uninstalled tools show "not installed". Output is plain text — no colors, no JSON — so it pastes cleanly into bug reports.
shll version [flags]
show raw -h output
Print a column-aligned plain-text table showing the version of shll itself plus every roster tool. Uninstalled tools show "not installed". Output is plain text — no colors, no JSON — so it pastes cleanly into bug reports. Usage: shll version [flags] Flags: -h, --help help for version