Klaus Assistant Config

Workflow

When this skill is invoked, the user provides a plain-English description of the assistant they want to deploy. Your job is to parse that description and emit a complete, valid assistant configuration JSON that an OpenClaw-style runtime can consume directly.

This skill produces the configuration only. Deploying the assistant, provisioning channel credentials, and wiring tool integrations to live services are out of scope — that is the productionization gap the operator bridges after receiving this config.

Step 1 — Extract the assistant intent

Read the user's description carefully and extract every distinct component:

• Persona: What tone, name, and purpose should the assistant have? Extract a concise persona string — the assistant's "character" in one to two sentences.
• Channels: Which messaging surfaces should the assistant be active on? Identify each channel type (e.g., slack, email, sms, whatsapp, discord, web_chat, teams) and any scope constraints per channel (e.g., "read-only in #support", "only DMs from customers").
• Desired capabilities: What should the assistant be able to do? List every distinct action mentioned — read tickets, draft replies, look up orders, update CRM records, send messages, trigger webhooks, etc.
• Explicit restrictions: What should the assistant never do without confirmation, or never do at all? If the user says "must ask before sending", "never delete", "never make payments" — note these as explicit deny or ask constraints.
• Audience: Who interacts with this assistant? (Customers, internal team, developers.) This informs the persona tone and default safety posture.

If a constraint is not mentioned, default to the safe side: outbound messages and any write operations default to "ask", financial or destructive operations default to "deny".

Step 2 — Build the tool allowlist

Map each capability identified in Step 1 to a named tool. Assign a permission level to each tool:

• "auto" — the assistant may invoke this tool without asking the user, for clearly safe read operations (e.g., read_tickets, search_knowledge_base, get_order_status).
• "ask" — the assistant must present the proposed action to the user for confirmation before executing, for any outbound message, write to an external system, or moderately sensitive read (e.g., send_email, post_slack_message, update_crm_record, reply_to_ticket).
• "deny" — the assistant may never invoke this tool, for financial, destructive, or privileged operations (e.g., make_payment, delete_record, admin_impersonate).

Include a reason string on every tool explaining the permission decision. Always include a make_payment tool set to "deny" and a delete_record tool set to "deny" as baseline safety anchors — even if the user did not mention them — to demonstrate the default-deny posture.

Step 3 — Define guardrails

Produce a guardrails block with these fields:

• default_tool_permission — always "deny". Any tool not in the allowlist is denied by default.
• max_actions_per_run — a reasonable ceiling on consecutive autonomous actions (suggest 25 unless the user implies a higher-volume use case).
• require_confirmation_for — an array of operation categories that always require user confirmation regardless of individual tool permission. At minimum: ["outbound_message", "payment", "data_deletion"].
• redact_pii_in_logs — always true unless the user explicitly says logs may contain PII.

Step 4 — Define the escalation policy

Produce an escalation block specifying what happens when the assistant is uncertain or blocked:

• to — "human" by default.
• when — an array of trigger conditions. At minimum: ["ambiguous_request", "tool_denied", "low_confidence"]. Add "sensitive_topic" if the audience is customers. Add "escalation_keyword" if the user mentions words like "urgent", "legal", "compliance".

Step 5 — Assemble and self-check the JSON config

Emit a single JSON object with this shape:

{
  "assistant": {
    "name": "<assistant name>",
    "persona": "<one-to-two sentence persona description>",
    "description": "<one-sentence functional summary>"
  },
  "channels": [
    { "type": "<channel_type>", "enabled": true, "scope": "<scope constraint or 'all'>" }
  ],
  "tools": [
    {
      "name": "<tool_name_in_snake_case>",
      "permission": "auto | ask | deny",
      "reason": "<plain-English explanation of why this permission level>"
    }
  ],
  "guardrails": {
    "default_tool_permission": "deny",
    "max_actions_per_run": 25,
    "require_confirmation_for": ["outbound_message", "payment", "data_deletion"],
    "redact_pii_in_logs": true
  },
  "escalation": {
    "to": "human",
    "when": ["ambiguous_request", "tool_denied", "low_confidence"]
  }
}

Before emitting, verify:

• Every tool in the tools array has a non-empty name, a permission value from the allowed set (auto, ask, deny), and a non-empty reason.
• make_payment and delete_record are present with permission: "deny".
• Every channel in channels has a type and an enabled boolean.
• guardrails.default_tool_permission is "deny".
• require_confirmation_for includes at minimum "outbound_message", "payment", and "data_deletion".
• The document is syntactically valid JSON — no trailing commas, no comments, no single-quoted strings.

If any check fails, fix it before emitting.

Safety-first design principle

The configuration follows a default-deny posture: any tool not explicitly listed in tools[] is automatically denied. Outbound actions (messages, emails, posts) and any write to an external system require explicit user confirmation ("ask") unless the user explicitly grants auto-approval. Financial and destructive operations are always "deny". This mirrors the "safe" pillar in Klaus AI's hosted assistant design and the OpenClaw runtime's permission model.

Example

See examples/input.md for a plain-English assistant request (a customer support assistant on Slack and email that reads tickets and drafts replies but must ask before sending anything external).

See examples/output.md for the complete, valid JSON assistant configuration this skill produces from that input.