limits-openclaw 0.0.12 → 0.0.13

package/dist/configure-wizard.js

@@ -113,7 +113,7 @@ export async function runConfigureWizard() {
     console.log("   Base URL is fixed. apiToken is used for /openclaw/enforce and policy-generator tools. Run after: openclaw plugins install -l <path>\n");
     const apiToken = await ask(rl, "Organization API key (apiToken) — required for enforce and policy-generator tools", process.env.LIMITS_ENFORCER_API_TOKEN ?? "");
     const sandboxAnswer = await ask(rl, "Do you run agents inside a sandbox?", "N");
-    const addSkillAnswer = await ask(rl, "Add limits-policy-generator skill to OpenClaw workspace?", "Y");
+    const addSkillAnswer = await ask(rl, "Add limits-policy-generator skill to OpenClaw workspace? (Recommended)", "Y");
     rl.close();
     if (apiToken)
         await runConfigSet("apiToken", JSON.stringify(apiToken));

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "limits-openclaw",
-  "version": "0.0.12",
+  "version": "0.0.13",
   "description": "Delegates policy enforcement to the Limits platform before and after every tool call.",
   "keywords": [
     "openclaw",
@@ -18,6 +18,7 @@
   },
   "files": [
     "dist",
+    "skills",
     "openclaw.plugin.json",
     "README.md",
     "LICENSE",

package/skills/limits-policy-generator/SKILL.md

@@ -0,0 +1,110 @@
+---
+name: limits-policy-generator
+description: "Generate and create or update policy rules on the Limits SaaS from natural language. Use when the user asks to add, change, or create policy rules enforced by the Limits backend."
+metadata: {"openclaw": {"emoji": "📜", "requires": {"config": ["plugins.entries[\"limits-openclaw\"].config.apiToken"]}}}
+---
+
+# Limits Policy Generator
+
+You have two tools for creating and updating policies on the Limits SaaS from natural language. They call the Limits backend so the user's enforcement rules are created or updated there (and apply to tool-call enforcement via the limits-openclaw plugin).
+
+## When to use this skill
+
+Use these tools when the user says things like:
+
+- "Create a policy that blocks all payment tools"
+- "Add a rule: never run bash with rm -rf"
+- "Generate a policy from this: block transactions over 500"
+- "Update my policy to also block stripe_* tools"
+- "I want to add a guardrail that redacts emails from tool output"
+- "Change the payment limit to 700"
+
+## Tools available
+
+### `limits_generate_create_policy`
+
+Generate a new policy from natural language and create it on the Limits backend. Use when the user wants to **add** a new policy.
+
+```
+limits_generate_create_policy(
+  input="Block any tool whose name starts with stripe_ or payment_. Allow all other tools.",
+  mode="INSTRUCTIONS",
+  tools=["stripe_.*", "payment_.*"]
+)
+```
+
+- **input** (required): Natural-language description of the policy (what to block, allow, or require).
+- **mode** (optional): `"INSTRUCTIONS"` | `"CONDITIONS"` | `"GUARDRAIL"`. Default is INSTRUCTIONS. Use GUARDRAIL for rules that scan tool **output** (e.g. redact PII).
+- **tools** (required): Which tool calls this policy applies to. See "Where to apply" section below.
+
+### `limits_generate_update_policy`
+
+Generate updates from natural language and apply them to an **existing** policy. Use when the user wants to **change** a policy they already have.
+
+```
+limits_generate_update_policy(
+  policyId="uuid-of-existing-policy",
+  input="Also block transfer_money. Keep the existing amount limit.",
+  mode="INSTRUCTIONS"
+)
+```
+
+- **policyId** (required): The ID of the existing policy to update (UUID).
+- **input** (required): Natural-language description of the changes or additions.
+- **mode** (optional): Same as above.
+- **Note:** Update does **not** change which tools the policy applies to — scope is fixed at creation time. If the user wants to change scope, they should create a new policy.
+
+## Where to apply (tools parameter)
+
+The `tools` parameter on `limits_generate_create_policy` is **required** and controls which tool calls the policy is enforced on.
+
+### Values
+
+| Value | Meaning |
+|-------|---------|
+| `["*"]` | Apply to **all** tool calls / all requests |
+| `["<tool_name>"]` | Apply to the exact tool (use only names from the agent's actual tool list) |
+| `["<prefix>.*"]` | Apply to all tools whose name starts with that prefix (e.g. `payment_.*`) |
+
+Use `prefix.*` (dot-star) for prefix matching. The backend also accepts `prefix_*` and normalizes it to `prefix_.*`. **Use only tool names or prefixes that exist in the user's / agent's available tools** — do not invent names.
+
+### Ask-once logic (required)
+
+**Do not call `limits_generate_create_policy` until you know scope.** If the user did not say scope, ask once.
+
+- User says **"everywhere"**, **"all requests"**, **"globally"**, or **"all tools"** → use `["*"]` without asking.
+- User **explicitly names specific tools** (e.g. "for read_file", "payment tools", "stripe_*") → use those tools without asking.
+- User **does not say** "all" / "everywhere" / "globally" and **does not name any tools** (e.g. "create a policy if currency is JOD allow request", "create a policy that blocks payments") → you **must ask once** before calling the tool: _"Which tools should this policy apply to: all tool calls, or only specific tools? If specific, which tool names from your available tools?"_ Then call the tool with the user's answer.
+
+Do not assume scope. Do not call the create-policy tool immediately when the user only describes the rule (e.g. "if currency is JOD allow") without stating where it applies. Ask once, then call.
+
+### Tool names: use source of truth only
+
+When setting the `tools` parameter, use **only tool names from the agent's actual available tools** (the list of tools you have access to). Do not invent or assume tool names. If the user wants "specific tools", list the relevant tools from your real tool list and use those exact names (or prefix patterns like `name_.*` that match them). If you do not have a list of available tools, ask the user which tools should be in scope and use only names they confirm.
+
+## Recommended flow
+
+1. If the user wants a **new** policy:
+   - **First determine scope.** If the user did not say "all tools" / "everywhere" / "globally" and did not name specific tools, ask once: "Which tools should this apply to: all tool calls or specific tools? If specific, which ones?"
+   - Only then call `limits_generate_create_policy` with `input`, `tools` (from user or from their actual tool list), and optionally `mode`.
+   - Confirm what was created and **where it applies** (e.g. "This policy applies to all tools" or "This policy applies to [tool names]").
+2. If the user wants to **change** an existing policy:
+   - Use `limits_generate_update_policy` with the policy id and the change description. (You may need to list or find the policy id first if the user says "update my payment policy".)
+   - Remind the user that **scope (which tools the policy applies to) cannot be changed via update** — it stays as set when the policy was created.
+3. Policies on the Limits backend apply to tool-call enforcement (via limits-openclaw) for that organization.
+
+## Sandbox vs host
+
+**If you are running inside a sandbox:** The `limits_generate_create_policy` and `limits_generate_update_policy` tools are only available if the gateway config allows them in the sandbox (e.g. `tools.sandbox.tools.allow` includes `"limits-openclaw"`). If those tools are not in your tool list, you cannot invoke them from this environment.
+
+- **To run the policy tools from the sandbox:** The admin must add `limits-openclaw` to the agent allowlist and to `tools.sandbox.tools.allow` (see the limits-openclaw README). After that, you can call the tools from here.
+- **If the tools are still not available:** Tell the user to run the policy command on the **host** or an agent instance that has the Limits backend wired up and the tools allowed.
+
+## Configuration
+
+The plugin must be configured with:
+
+- **baseUrl**: Base URL of the Limits API (e.g. `https://api.limits.dev`). Used for enforce and policy-generator tools.
+- **apiToken**: Organization API key (Bearer) for the Limits backend. Used for enforce and policy-generator tools.
+
+Without these, the tools will not be available or will return an error asking the user to configure them.