# Klaus Assistant Config

> Given a plain-English description of the assistant a user wants, produce a complete JSON assistant configuration — persona, enabled channels, a tool allowlist with per-tool permission (auto/ask/deny), and safety guardrails — ready to hand to an OpenClaw-style runtime.

- Skill: `riteshkew/klaus-assistant-config` (Agent Skill, multi-file: 5 files)
- Install (CLI): `npx skillmds@latest add riteshkew/klaus-assistant-config`
- Raw SKILL.md: https://api.skillmd.com/api/skills/riteshkew/klaus-assistant-config/raw
- Safety review: pending
- Works with: Claude Code, Claude.ai, OpenAI Codex
- Category: Coding & Dev Tools
- Author: riteshkew (https://skillmd.com/u/riteshkew)
- Updated: 2026-09-17
- Page: https://skillmd.com/skills/riteshkew/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.