Skip to main content

Documentation Index

Fetch the complete documentation index at: https://docs.loongclaw.ai/llms.txt

Use this file to discover all available pages before exploring further.

Skills

Use this page when the question is no longer “does Loong support skills?” and is now “how do I discover, install, expose, and troubleshoot them on purpose?” loong skills is the public operator surface for discovery, install, removal, and persisted policy updates around skills.

Start Here

If you need to…Start here
inspect the current persisted skills policyloong skills policy get
see what is already resolved in the runtimeloong skills list
search or recommend by operator goalloong skills search "browser automation" or loong skills recommend "summarize docs site"
inspect one installed or discoverable skillloong skills info <skill_id>
install a local directory or archiveloong skills install ./path/to/skill
fetch and install a remote packageloong skills fetch https://example.com/skill.zip --approve-download --install
install a bundled browser automation helperloong skills install-bundled agent-browser

Default Public Posture

Skills start from a fail-closed default:
[skills]
enabled = false
require_download_approval = true
allowed_domains = []
blocked_domains = []
auto_expose_installed = false
Rules that matter:
  • enabled = false keeps the skills runtime fail-closed rather than silently widening capability.
  • require_download_approval = true means remote skill downloads require an explicit operator approval step.
  • auto_expose_installed = false means installation and runtime visibility are kept separate until you turn that gate on.
  • install_root is optional and is the right place to pin a stable skill location when the default runtime-owned path is not enough.
If you want the broader config map before this page gets operational, start with Configuration Patterns.

Operator Mental Model

Skills have four separate states:
  1. discovery: loong skills list, search, recommend, and info tell you what the runtime can resolve; they do not install anything
  2. installation: loong skills install or fetch --install copies a skill into the install root
  3. exposure: skills.enabled and auto_expose_installed decide whether installed skills become part of the usable runtime surface
  4. runtime readiness: some skills, especially browser automation helpers such as agent-browser, still depend on shell policy or an external runtime binary on PATH
That separation is why “the skill installed correctly” and “the assistant can use it right now” are not always the same statement.

Core Operator Commands

Discovery and inspection:
loong skills list
loong skills search "browser automation"
loong skills recommend "summarize docs site"
loong skills info agent-browser
Install and remove:
loong skills install ./downloads/my-skill
loong skills install ./downloads/my-skill.zip --skill-id my-skill --replace
loong skills fetch https://example.com/my-skill.zip --approve-download --install
loong skills remove my-skill
Persisted policy:
loong skills policy get
loong skills policy set --enabled true --auto-expose-installed true --approve-policy-update
loong skills policy set --allow-domain skills.sh --block-domain internal.example --approve-policy-update
loong skills policy reset --approve-policy-update
Operational notes:
  • use skills search or skills recommend when you do not already know the skill id.
  • use skills info after install to inspect prerequisites and follow-up steps.
  • skills fetch is the remote-download path; if approval is required, include --approve-download.
  • skills policy persists runtime policy into config; it does not just change one in-memory session.
  • skills policy can toggle enablement, download approval, domain allow/block rules, and auto_expose_installed, but install_root still belongs in config.
  • skills install-bundled <skill_id> also exists for first-party packaged skills, including agent-browser.

Local Install vs Remote Fetch

Use local install when the package is already on disk:
loong skills install ./skills/browser-helper
Use remote fetch when the package lives behind a URL and you want the runtime to apply the same domain and approval policy that operators see in config:
loong skills fetch https://example.com/browser-helper.zip \
  --approve-download \
  --install
Choose deliberately:
  • install is best for local archives, unpacked directories, or reviewed build artifacts you already trust.
  • fetch --install is best when you want one operator command that both downloads and installs under the governed skills policy.
  • domain allow/block rules apply to fetch and belong in persisted policy rather than being hidden in ad-hoc shell aliases.

Agent Browser Setup

The shortest public route for richer browser automation is to install the bundled agent-browser skill and make sure the runtime binary is available. Typical operator loop:
loong skills install-bundled agent-browser --replace
npm install -g agent-browser && agent-browser install
agent-browser open example.com
loong doctor
Two boundaries still matter:
  • if [tools].shell_deny contains agent-browser, the runtime path will stay blocked until you remove that hard deny.
  • if the runtime binary is still missing on PATH, the skill may be installed but automation will not be ready yet.

Persisted Policy Shape

When you want the config to be explicit instead of relying only on CLI mutations, this is the public shape to keep in mind:
[skills]
enabled = true
require_download_approval = true
allowed_domains = ["skills.sh"]
blocked_domains = ["internal.example"]
install_root = "~/managed-skills"
auto_expose_installed = true
Use this when:
  • one team wants a reviewed install root instead of a runtime-owned default location
  • download sources should be pinned to an explicit domain set
  • installed skills should become runtime-visible automatically across operator restarts

Common Failure Cases

What happenedWhat it usually meansWhat to do next
skills fetch is rejected before download startsdownload approval or domain policy is blocking itrun loong skills policy get, then retry with --approve-download or update policy deliberately
a skill installed but does not show up as usableinstall succeeded, but the runtime exposure gate is still closedset auto_expose_installed = true through skills policy set
you do not know where skills should livethe runtime default is acceptable until you need a reviewed locationset skills.install_root in config when you need a stable explicit path
agent-browser still does not run after installshell policy or the runtime binary is still missingremove agent-browser from shell_deny, verify agent-browser open example.com, then rerun loong doctor

Continue Reading

  • Continue to Browser And Web Boundaries when the failure is really a private-host, allowed-domain, or browser runtime gate problem.
  • Continue to Tool Surface when you want the broader truthful-tool contract around enablement surfaces.
  • Continue to Doctor And Health when you want the health-first repair path after enabling skills or external browser automation.
  • Go back to Configuration Patterns when you want the wider operator config map.