hoomanjs 1.40.1 → 1.41.0

package/dist/core/skills/built-in/hooman-config/providers.md

@@ -0,0 +1,171 @@
+# Hooman Providers And LLMs Reference
+
+Detailed provider-specific options for `~/.hooman/config.json` `providers` and `llms`.
+
+## LLMs array
+
+Each element of `llms` has:
+
+- `name`: non-empty label for this entry.
+- `provider`: provider reference name. It must match one of the entries in top-level `providers`.
+- `options.model`: model id passed to the resolved runtime provider.
+- `options.temperature`: optional normalized temperature override.
+- `options.maxTokens`: optional normalized output token limit.
+- `default`: boolean; mark one entry `"default": true` for the active model.
+- `billing`: optional billing metadata used for context-window utilization and session-cost display. When present, `billing.name` is required — the model identifier looked up on models.dev (defaults to `options.model` when `billing` is omitted). Optional overrides: `billing.context` (context window size in tokens) and `billing.costs` (USD per million tokens: required `"input/m"` and `"output/m"`, optional `"cache/m"` for cached-input reads). Anything not provided is resolved from the models.dev catalog; when neither source resolves, context usage and cost are simply not shown.
+
+Example `billing` block:
+
+```json
+{
+  "name": "Haiku 4.5",
+  "provider": "LiteLLM Anthropic",
+  "billing": {
+    "name": "claude-haiku-4.5",
+    "context": 200000,
+    "costs": { "input/m": 1, "cache/m": 0.1, "output/m": 5 }
+  },
+  "options": { "model": "claude-haiku-4.5" },
+  "default": true
+}
+```
+
+## Providers array
+
+Each element of `providers` has:
+
+- `name`: non-empty reference name used by `llms[].provider`.
+- `provider`: runtime provider id such as `"openai"`, `"bedrock"`, or `"ollama"`.
+- `options`: provider-specific shared settings such as API keys, base URL, headers, region, or AWS credentials.
+
+Supported `providers[].provider` values:
+
+```json
+[
+  "anthropic",
+  "azure",
+  "bedrock",
+  "google",
+  "groq",
+  "minimax",
+  "moonshot",
+  "ollama",
+  "openai",
+  "openrouter",
+  "xai"
+]
+```
+
+Common shape:
+
+```json
+{
+  "providers": [
+    {
+      "name": "Anthropic",
+      "provider": "anthropic",
+      "options": {
+        "apiKey": "..."
+      }
+    }
+  ],
+  "llms": [
+    {
+      "name": "Claude Sonnet",
+      "provider": "Anthropic",
+      "options": {
+        "model": "claude-sonnet-4-20250514",
+        "temperature": 0.2,
+        "maxTokens": 4096
+      },
+      "default": true
+    }
+  ]
+}
+```
+
+## Provider notes
+
+- `anthropic`: provider `options` support `apiKey`, optional `baseURL`, optional `headers`, and optional `reasoning` (an object with optional `effort` — `"minimal"`, `"low"`, `"medium"`, `"high"` — and optional `display` — `"summarized"` or `"omitted"`). Providing `reasoning` enables extended thinking (sent as `thinking: { type: "enabled", budget_tokens }`); `effort` defaults to `"medium"` and maps to an explicit budget (`minimal`→1024, `low`→2048, `medium`→4096, `high`→8192). When thinking is enabled Hooman drops any custom `temperature` (Anthropic requires it unset/`1`). `display` is for Bedrock Claude (via an Anthropic-compatible proxy) and MiniMax only: newer Bedrock Claude models (e.g. Opus 4.7+) hide reasoning by default and reject `type: "enabled"`, so set `display: "summarized"` to reveal reasoning — this switches the request to `thinking: { type: "adaptive", display }` with `output_config.effort` (`minimal`→`low`, else passthrough). Do NOT set `display` for the native Anthropic API (api.anthropic.com); it rejects `adaptive`/`display`/`output_config`. Omit `reasoning` to keep thinking off. LLM `options` support `model`, `temperature`, and `maxTokens`.
+- `azure`: provider `options` support optional `resourceName`, optional `baseURL`, optional `apiKey`, optional `headers`, optional `apiVersion`, optional `useDeploymentBasedUrls`, and optional `reasoning` (an object with optional `effort` — `"minimal"`, `"low"`, `"medium"`, `"high"` — and optional `summary` — `"auto"`, `"concise"`, `"detailed"`, `"none"`). `reasoning` uses the Azure OpenAI Responses API; only reasoning-capable deployments honor it. LLM `options` support `model`, `temperature`, and `maxTokens`. The `model` value should be your Azure deployment name.
+- `bedrock`: provider `options` support `region`, `accessKeyId`, `secretAccessKey`, `sessionToken`, optional `apiKey`, and optional `reasoning` (an object with optional `effort` and optional `display` — `"summarized"` or `"omitted"`). Providing `reasoning` enables extended thinking on supported models (e.g. Claude); because Bedrock's Converse API requires a budget, `effort` (default `"medium"`) maps to `budget_tokens` (`minimal`→1024, `low`→2048, `medium`→4096, `high`→8192). Ensure the LLM `maxTokens` exceeds the budget. Newer Bedrock Claude (e.g. Opus 4.7+) hide reasoning by default and reject `type: "enabled"`; set `display: "summarized"` to reveal it — this switches to `thinking: { type: "adaptive", display }` with `output_config.effort` (`minimal`→`low`, else passthrough) sent via `additionalRequestFields`. LLM `options` support `model`, `temperature`, and `maxTokens`.
+- `google`: provider `options` support `apiKey` and optional `reasoning` (an object with optional `effort`). Setting `reasoning.effort` enables Gemini thinking with a dynamic budget (`thinkingConfig: { includeThoughts: true, thinkingBudget: -1 }`). LLM `options` support `model`, `temperature`, and `maxTokens` (Hooman maps this to the Google SDK's `maxOutputTokens` internally).
+- `groq`: provider `options` support `apiKey`, optional `baseURL`, optional `headers`, and optional `reasoning` (an object with optional `effort`). `reasoning.effort` maps to Groq's `reasoning_effort` (`minimal`→`low`) and streams reasoning via `reasoning_format: "parsed"`. Only reasoning models honor it. LLM `options` support `model`, `temperature`, and `maxTokens`.
+- `minimax`: provider `options` support `apiKey`, optional `headers`, and optional `reasoning` (an object with optional `effort` — `"minimal"`, `"low"`, `"medium"`, `"high"` — and optional `display` — `"summarized"` or `"omitted"`). Providing `reasoning` enables thinking, normalized to MiniMax's `thinking: { type: "adaptive", budget_tokens }`; `effort` defaults to `"medium"` and maps to an explicit budget (`minimal`→1024, `low`→2048, `medium`→4096, `high`→8192). Setting `display` switches to `thinking: { type: "adaptive", display }` with `output_config.effort` instead of a budget. Omit `reasoning` to keep thinking off. Hooman routes this through the Anthropic-compatible MiniMax endpoint automatically.
+- `moonshot`: provider `options` support `apiKey`, optional `baseURL`, optional `headers`, and optional `reasoning` (an object with optional `effort`). Setting `reasoning.effort` enables Kimi thinking (`thinking: { type: "enabled" }`). Served through the reasoning-aware openai-compatible adapter, so Kimi's `reasoning_content` is surfaced as thinking. When `baseURL` is omitted, Hooman defaults it to `https://api.moonshot.ai/v1`. To reach Kimi through an OpenAI-compatible proxy (e.g. LiteLLM), use this provider with `baseURL` set to the proxy's `/v1` endpoint — the `openai` provider's Chat adapter would otherwise drop Kimi's reasoning.
+- `ollama`: provider `options` support optional `baseURL` and optional `reasoning` (an object with optional `effort`). Setting `reasoning.effort` enables thinking, mapped to Ollama's `think` level (`minimal`/`low`→`"low"`, `medium`→`"medium"`, `high`→`"high"`). LLM `options` support `model`, `temperature`, and `maxTokens`.
+- `openai`: provider `options` support `apiKey`, optional `baseURL`, optional `headers`, optional `api` (`"responses"` or `"chat"`, defaults to `"responses"`), and optional `reasoning` (an object with optional `effort` — `"minimal"`, `"low"`, `"medium"`, `"high"` — and optional `summary` — `"auto"` (default), `"concise"`, `"detailed"`, `"none"`). LLM `options` support `model`, `temperature`, and `maxTokens`. Use `"responses"` (the default) to surface model reasoning/thinking; set `"chat"` for OpenAI-compatible endpoints/proxies that do not implement the Responses API. Reasoning summaries stream only on the Responses API, and some models (e.g. GPT-5) require `reasoning.effort` of `"medium"` or higher to emit them; set `reasoning.summary` to `"none"` for non-reasoning models that reject the `reasoning` parameter. Note: `"chat"` mode does NOT surface reasoning (the Chat adapter drops `reasoning_content`); for a proxy that only exposes thinking via chat `reasoning_content` (e.g. Kimi/Moonshot), use the `moonshot` or `openrouter` provider instead. Also note the Responses API may return an empty reasoning item for non-OpenAI backends behind a proxy (they won't stream summary text).
+- `openrouter`: provider `options` support `apiKey`, optional `baseURL`, optional `headers`, and optional `reasoning` (an object with optional `effort`). Served through the reasoning-aware openai-compatible adapter, so `reasoning`/`reasoning_content` deltas are surfaced as thinking. `reasoning.effort` maps to `reasoning_effort`, which OpenRouter normalizes for reasoning models. LLM `options` support `model`, `temperature`, and `maxTokens`. The `model` value is usually a provider-qualified OpenRouter model id such as `anthropic/claude-3.5-sonnet`.
+- `xai`: provider `options` support `apiKey`, optional `baseURL`, optional `headers`, and optional `reasoning` (an object with optional `effort`). `reasoning.effort` maps to xAI's `reasoning_effort` (`low`/`high`; `minimal`/`low`→`low`, `medium`/`high`→`high`). Only reasoning models (e.g. grok-3-mini) honor it. LLM `options` support `model`, `temperature`, and `maxTokens`.
+
+## Examples
+
+```json
+{
+  "providers": [
+    {
+      "name": "MiniMax",
+      "provider": "minimax",
+      "options": {
+        "apiKey": "..."
+      }
+    },
+    {
+      "name": "Kimi",
+      "provider": "moonshot",
+      "options": {
+        "apiKey": "..."
+      }
+    }
+  ],
+  "llms": [
+    {
+      "name": "MiniMax M3",
+      "provider": "MiniMax",
+      "options": {
+        "model": "MiniMax-M3"
+      },
+      "default": true
+    },
+    {
+      "name": "Kimi K2.7 Code",
+      "provider": "Kimi",
+      "options": {
+        "model": "kimi-k2.7-code"
+      },
+      "default": false
+    }
+  ]
+}
+```
+
+```json
+{
+  "providers": [
+    {
+      "name": "Bedrock",
+      "provider": "bedrock",
+      "options": {
+        "region": "us-west-2",
+        "accessKeyId": "AKIA...",
+        "secretAccessKey": "...",
+        "sessionToken": "..."
+      }
+    }
+  ],
+  "llms": [
+    {
+      "name": "Claude Sonnet",
+      "provider": "Bedrock",
+      "options": {
+        "model": "anthropic.claude-sonnet-4-20250514-v1:0",
+        "temperature": 0.2,
+        "maxTokens": 4096
+      },
+      "default": true
+    }
+  ]
+}
+```
+
+When editing `providers` or `llms`, preserve unrelated entries and API keys unless the user asks to remove or replace them.

package/dist/core/skills/built-in/hooman-config/search.md

@@ -0,0 +1,39 @@
+# Hooman Search Config Reference
+
+`search.provider` must be `"brave"`, `"exa"`, `"firecrawl"`, `"litellm"`, `"serper"`, or `"tavily"`.
+
+```json
+{
+  "search": {
+    "enabled": true,
+    "provider": "brave",
+    "brave": {
+      "apiKey": "..."
+    },
+    "exa": {
+      "apiKey": "..."
+    },
+    "firecrawl": {
+      "apiKey": "..."
+    },
+    "litellm": {
+      "baseURL": "https://your-litellm-host",
+      "apiKey": "sk-...",
+      "tool": "perplexity-search"
+    },
+    "serper": {
+      "apiKey": "..."
+    },
+    "tavily": {
+      "apiKey": "..."
+    }
+  }
+}
+```
+
+Notes:
+
+- Hooman calls Exa through the official **`exa-js`** SDK ([Exa search API](https://exa.ai/docs/reference/search-api-guide-for-coding-agents)).
+- Hooman calls Firecrawl through **`@mendable/firecrawl-js`** ([Firecrawl search API](https://docs.firecrawl.dev/api-reference/endpoint/search)).
+- The `litellm` provider calls a [LiteLLM](https://docs.litellm.ai/docs/search/) proxy's Perplexity-compatible `POST {baseURL}/v1/search/{tool}` endpoint using the virtual key as `apiKey`. It requires `baseURL`, `apiKey`, and `tool` (the `search_tool_name` registered on the proxy). The actual upstream search provider (perplexity, tavily, exa, brave, etc.) is chosen by the proxy config, so no provider API key is stored in Hooman.
+- Defaults: `enabled: false`, `provider: "brave"`, all provider API keys unset.

package/dist/core/skills/built-in/hooman-mcp/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: hooman-mcp
-description: Read and update Hooman's mcp.json directly. Use when the user asks to list, add, update, remove, or configure MCP servers for Hooman, including stdio, streamable-http, and SSE transports.
+description: Read and update Hooman's ~/.hooman/mcp.json. Use when the user asks to list, add, update, remove, or configure MCP servers for Hooman — stdio commands, streamable-http or SSE URLs, env vars, and auth headers. For event-driven channel servers (cron, Slack, Telegram, WhatsApp, Jira) use hooman-channels instead; for config.json settings use hooman-config.
 ---
 
 # Hooman MCP
@@ -9,69 +9,25 @@ Use this skill when the user asks you to inspect or change Hooman's MCP server c
 
 ## Source Of Truth
 
-- Hooman MCP servers are stored in `~/.hooman/mcp.json`.
-- The file contains one top-level object: `mcpServers`.
-- Each key under `mcpServers` is the server name.
-- Each value is a transport object.
-
-Minimal valid file:
-
-```json
-{
-  "mcpServers": {}
-}
-```
+- Hooman MCP servers are stored in `~/.hooman/mcp.json`: one top-level `mcpServers` object where each key is a server name and each value is a transport object.
+- Minimal valid file: `{"mcpServers": {}}`.
 
 ## Read/Write Rules
 
 1. Read `~/.hooman/mcp.json` before changing it. If it does not exist, create it with `{"mcpServers": {}}`.
 2. Preserve existing servers unless the user explicitly asks to replace or delete them.
-3. Make the smallest JSON edit needed: add, update, or remove one server entry.
-4. Keep JSON valid. Comments are not supported.
-5. Treat `env` and `headers` as potentially secret-bearing maps. Do not expose or rewrite secrets unnecessarily.
-6. Use stable, descriptive server names such as `filesystem`, `slack`, `jira`, or `github`.
-7. Any change to `mcp.json` requires restarting the running Hooman agent/session before MCP server tools or instructions change.
-
-## File Shape
-
-```json
-{
-  "mcpServers": {
-    "server-name": {
-      "type": "stdio",
-      "command": "npx",
-      "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"],
-      "env": {
-        "TOKEN": "..."
-      },
-      "cwd": "/optional/working/directory"
-    }
-  }
-}
-```
-
-Supported transport `type` values:
+3. Make the smallest JSON edit needed: add, update, or remove one server entry. Keep JSON valid; comments are not supported.
+4. Treat `env` and `headers` as potentially secret-bearing maps. Do not expose or rewrite secrets unnecessarily.
+5. Use stable, descriptive server names such as `filesystem`, `slack`, `jira`, or `github`.
+6. Any change to `mcp.json` requires restarting the running Hooman agent/session before MCP server tools or instructions change.
 
-```json
-["stdio", "streamable-http", "sse"]
-```
-
-## Stdio Servers
-
-Use `stdio` for local subprocess-based MCP servers.
-
-Required:
-
-- `type`: `"stdio"`
-- `command`: executable command, for example `npx`, `node`, `python`, `uvx`, or an absolute binary path
+## Transports
 
-Optional:
+Supported `type` values: `"stdio"`, `"streamable-http"`, `"sse"`.
 
-- `args`: command arguments as an array of strings
-- `env`: environment variables as string key/value pairs
-- `cwd`: working directory for the server process
+### Stdio (local subprocess servers)
 
-Example:
+Required: `type: "stdio"` and `command` (e.g. `npx`, `node`, `python`, `uvx`, or an absolute binary path). Optional: `args` (string array), `env` (string map), `cwd` (working directory).
 
 ```json
 {
@@ -81,45 +37,17 @@ Example:
       "command": "npx",
       "args": ["-y", "@modelcontextprotocol/server-filesystem", "/tmp"],
       "env": {
-        "NODE_ENV": "production"
-      }
-    }
-  }
-}
-```
-
-Example with `cwd`:
-
-```json
-{
-  "mcpServers": {
-    "local-app": {
-      "type": "stdio",
-      "command": "node",
-      "args": ["dist/mcp-server.js"],
-      "cwd": "/Users/me/project",
-      "env": {
-        "API_KEY": "..."
-      }
+        "TOKEN": "..."
+      },
+      "cwd": "/optional/working/directory"
     }
   }
 }
 ```
 
-## Streamable HTTP Servers
-
-Use `streamable-http` for modern remote HTTP MCP servers.
+### Streamable HTTP (modern remote servers)
 
-Required:
-
-- `type`: `"streamable-http"`
-- `url`: full HTTP or HTTPS URL
-
-Optional:
-
-- `headers`: HTTP headers as string key/value pairs
-
-Example:
+Required: `type: "streamable-http"` and `url` (full HTTP/HTTPS URL). Optional: `headers` (string map).
 
 ```json
 {
@@ -135,77 +63,18 @@ Example:
 }
 ```
 
-## SSE Servers
-
-Use `sse` only for legacy remote MCP servers that still require SSE.
-
-Required:
+### SSE (legacy remote servers)
 
-- `type`: `"sse"`
-- `url`: full HTTP or HTTPS URL
-
-Optional:
-
-- `headers`: HTTP headers as string key/value pairs
-
-Example:
-
-```json
-{
-  "mcpServers": {
-    "legacy": {
-      "type": "sse",
-      "url": "https://example.com/sse",
-      "headers": {
-        "Authorization": "Bearer ..."
-      }
-    }
-  }
-}
-```
+Same shape as `streamable-http` but with `type: "sse"`. Use only for legacy remote MCP servers that still require SSE.
 
 ## Common Edits
 
-Add a server by inserting a new entry under `mcpServers`:
-
-```json
-{
-  "mcpServers": {
-    "github": {
-      "type": "stdio",
-      "command": "npx",
-      "args": ["-y", "@modelcontextprotocol/server-github"],
-      "env": {
-        "GITHUB_PERSONAL_ACCESS_TOKEN": "..."
-      }
-    }
-  }
-}
-```
-
-Update a server by replacing only that server's object:
-
-```json
-{
-  "mcpServers": {
-    "github": {
-      "type": "stdio",
-      "command": "npx",
-      "args": ["-y", "@modelcontextprotocol/server-github"],
-      "env": {
-        "GITHUB_PERSONAL_ACCESS_TOKEN": "...",
-        "GITHUB_TOOLSETS": "repos,issues,pull_requests"
-      }
-    }
-  }
-}
-```
-
-Delete a server by removing its key from `mcpServers`.
+- Add a server by inserting a new entry under `mcpServers`.
+- Update a server by replacing only that server's object (e.g. adding a key to its `env`).
+- Delete a server by removing its key from `mcpServers`.
 
 ## Notes
 
 - Prefer `streamable-http` over `sse` for remote servers unless the user specifically needs SSE.
-- For bearer tokens, use `headers.Authorization`.
-- For local subprocess secrets, use `env`.
+- For bearer tokens, use `headers.Authorization`; for local subprocess secrets, use `env`.
 - If a server package's README gives a specific JSON block, adapt it into the `mcpServers` object and preserve the required command, args, env, URL, and headers.

package/dist/core/skills/built-in/hooman-skills/SKILL.md

@@ -1,6 +1,6 @@
 ---
 name: hooman-skills
-description: Manage Hooman skills under ~/.hooman/skills. Use when the user asks to list, search, add, install, create, update, remove, inspect, or author Hooman skills and SKILL.md files.
+description: Manage Hooman skills under ~/.hooman/skills. Use when the user asks to list, search, install, add, create, author, update, inspect, or remove Hooman skills or SKILL.md files. Not for activating or using a skill in the current task, and not for Hooman config or MCP server changes (use hooman-config or hooman-mcp).
 ---
 
 # Hooman Skills
@@ -9,44 +9,26 @@ Use this skill when the user asks you to inspect, install, remove, create, or ch
 
 ## Source Of Truth
 
-- Hooman user-installed skills live under `~/.hooman/skills`.
-- Each installed skill is a directory directly under `~/.hooman/skills`.
-- Each skill directory must contain a `SKILL.md` file.
+- Hooman user-installed skills live under `~/.hooman/skills`; each installed skill is a directory directly under it containing a `SKILL.md` file (for example `~/.hooman/skills/code-review/SKILL.md`).
 - Built-in skills shipped with Hooman are separate from user-installed skills. Do not edit bundled skill files when the user means their installed skills.
 
-Example layout:
+## Reference File
 
-```text
-~/.hooman/skills/
-  code-review/
-    SKILL.md
-    reference.md
-  jira-workflow/
-    SKILL.md
-```
+Read `authoring.md` (next to this SKILL.md) before creating a new skill, editing a `SKILL.md`, or installing by manual copy. It covers frontmatter shape, naming rules, the creation checklist, update steps, and manual install steps.
 
 ## Operating Rules
 
 1. Use the `skills` CLI for catalog search, installs, listing, and removal when the user asks for those operations.
 2. Run every `skills` CLI command with working directory `~/.hooman` so the OpenClaw layout maps to `~/.hooman/skills`.
 3. Hooman discovers installed skills by scanning direct child directories under `~/.hooman/skills` for `SKILL.md`.
-4. Preserve unrelated skill folders and files.
-5. Treat files inside a skill directory as user data. Read before overwriting.
-6. Never delete a skill folder unless the user explicitly asks to remove that skill.
-7. For custom local authoring or edits, create/edit files directly under `~/.hooman/skills/<folder>`.
-8. Any skill install, removal, creation, or edit requires restarting the running Hooman agent/session before the runtime skill inventory changes.
+4. Preserve unrelated skill folders and files; treat files inside a skill directory as user data and read before overwriting.
+5. Never delete a skill folder unless the user explicitly asks to remove that skill.
+6. For custom local authoring or edits, create/edit files directly under `~/.hooman/skills/<folder>`.
+7. Any skill install, removal, creation, or edit requires restarting the running Hooman agent/session before the runtime skill inventory changes.
 
 ## Exact CLI Commands
 
-Use these commands for Hooman skill management:
-
-Working directory:
-
-```bash
-mkdir -p ~/.hooman && cd ~/.hooman
-```
-
-Run the following commands from that directory. If using a shell tool that supports a working-directory option, set it to `~/.hooman` instead of relying on a previous `cd`.
+Run from `~/.hooman` (`mkdir -p ~/.hooman && cd ~/.hooman`), or set the shell tool's working-directory option to `~/.hooman`.
 
 List installed skills:
 
@@ -76,130 +58,12 @@ Command notes:
 
 - `<source>` can be a package source accepted by the skills CLI, such as `owner/repo`, a GitHub URL, or a local path.
 - Use `--copy` for Hooman installs so skill files are copied into `~/.hooman/skills` instead of relying on symlinks.
-- If `list --json` fails or output is not useful, inspect `~/.hooman/skills` directly.
+- If `list --json` fails or output is not useful, list skills by inspecting `~/.hooman/skills` directly: read each direct child directory's `SKILL.md` frontmatter and report `name`, `description`, folder name, and path. Ignore directories without `SKILL.md`.
 - After installing or removing, verify the result by checking `~/.hooman/skills/<folder>/SKILL.md`.
 
-## SKILL.md Shape
-
-Every `SKILL.md` should start with YAML frontmatter:
-
-```markdown
----
-name: skill-name
-description: What this skill does and when Hooman should use it.
----
-
-# Skill Title
-
-Instructions for the agent.
-```
-
-Rules:
-
-- `name` should be lowercase words separated by hyphens when possible.
-- `description` should be specific and include trigger scenarios, because Hooman uses it to decide when the skill applies.
-- Keep the main `SKILL.md` focused. Put long references in nearby files such as `reference.md` and link to them.
-- Use relative links only inside the same skill directory.
-
-## Listing Skills
-
-To list installed skills without relying on CLI output:
-
-1. Open `~/.hooman/skills`.
-2. For each direct child directory, look for `SKILL.md`.
-3. Read each `SKILL.md` frontmatter.
-4. Report the frontmatter `name`, `description`, folder name, and `SKILL.md` path.
-
-Ignore files and directories that do not contain `SKILL.md`.
-
-## Creating A Skill Manually
-
-Create a new skill by making a directory under `~/.hooman/skills`:
-
-```text
-~/.hooman/skills/<folder>/SKILL.md
-```
-
-Use a safe folder name:
-
-- lowercase letters, numbers, and hyphens
-- no slashes
-- no `..`
-- no spaces
-
-Minimal example:
-
-```markdown
----
-name: pull-request-review
-description: Review pull requests for correctness, maintainability, tests, and project conventions. Use when the user asks to review a PR, diff, branch, or code changes.
----
-
-# Pull Request Review
-
-When reviewing code, lead with findings ordered by severity. Focus on bugs,
-regressions, missing tests, and maintainability risks.
-```
-
-Creation checklist:
-
-- Clarify the skill's purpose, trigger scenarios, and expected behavior.
-- Choose a folder name that is short, lowercase, and hyphenated.
-- Write a specific frontmatter `description` that includes when to use the skill.
-- Keep `SKILL.md` concise and actionable.
-- Put longer reference material in files next to `SKILL.md`, such as `reference.md` or `examples.md`.
-- Link supporting files with relative links.
-- Avoid time-sensitive claims unless the skill explicitly needs them.
-- Do not include secrets in skill files.
-
-## Updating A Skill
-
-To update an installed skill:
-
-1. Locate the folder under `~/.hooman/skills`.
-2. Read its current `SKILL.md` and any referenced files.
-3. Make the smallest edit that satisfies the request.
-4. Preserve frontmatter unless the user asked to rename or retarget the skill.
-5. Keep supporting files in the same skill directory.
-
-If changing the frontmatter `name`, consider whether the folder name should also change. Rename only when the user asks or the old folder name is clearly wrong.
-
-## Installing By Copying Or CLI
-
-Prefer the CLI for normal installs:
-
-```bash
-npx --yes skills@latest add "<source>" -y -a openclaw --copy
-```
-
-To install from a local skill directory manually:
-
-1. Verify the source directory contains `SKILL.md`.
-2. Choose a destination folder under `~/.hooman/skills`.
-3. Copy the skill directory into that destination.
-4. If the destination already exists, ask before replacing or merge carefully after reading both copies.
-
-For GitHub or web sources, prefer `skills add`. Fetch or clone manually only when the user asks or the CLI cannot handle the source. After retrieval, install by copying the actual skill directory into `~/.hooman/skills`.
-
-## Removing A Skill
-
-To remove a skill:
-
-1. Confirm the exact skill name or folder.
-2. Prefer the CLI removal command:
-
-```bash
-npx --yes skills@latest remove "<skill-or-folder>" -y
-```
-
-3. Verify the folder is gone from `~/.hooman/skills`.
-4. If manual deletion is required, verify the folder contains `SKILL.md` and delete only that folder.
-
-Do not remove built-in Hooman skills or unrelated folders.
-
 ## Common Mistakes
 
 - Do not create a single `~/.hooman/skills/SKILL.md`; each skill needs its own folder.
-- Do not put installed Hooman skills under Cursor's `~/.cursor/skills` directory.
+- Do not put installed Hooman skills under another application's skills directory; they belong under `~/.hooman/skills`.
 - Do not edit bundled Hooman skills when the user asked to install or update a personal skill.
 - Do not assume a catalog result is installed. A skill is installed only when its folder exists under `~/.hooman/skills` with `SKILL.md`.