Claude Skill

kata

KATA, the indentation-based configuration language Cerb uses for automations, toolbars, sheets, charts, workflows, policies, and more. Load it before writing any KATA -- the indentation and quoting rules are not YAML's.

LLM Mart · 0 points · 0 views 0 listing impressions 0 install-command copies
Virus-scanned Reviewed automatically before listing.

Full trust report

Download jstanden-cerb-features_cerberusweb.core_assets_agent_filesystems_cerb-agents_skills_kata-cf28b62.zip · 2 KB
Part of jstanden/cerb — 10 skills

Install

skills CLI npx skills add https://github.com/jstanden/cerb/tree/12.0.x/features/cerberusweb.core/assets/agent_filesystems/cerb-agents/skills/kata
Claude Code claude plugin marketplace add https://llmmart.ai/marketplace.json && claude plugin install jstanden-cerb@llmmart
Git git clone https://github.com/jstanden/cerb.git

The skills CLI installs just this skill, for any of its supported agents. Claude Code installs the whole jstanden/cerb collection as a plugin from our marketplace. Git is the plain clone.

Skill manifest

KATA

KATA is Cerb's configuration language: keys, values, and indentation. It looks like YAML and is not YAML. Everything below applies everywhere Cerb uses KATA -- automation scripts and policies, toolbars, sheets, charts, workflows, interaction elements, agent config, the schema file -- not just automations.

Full reference: /cerb-docs/references/docs/kata.md.

The indentation rule -- read this one twice

A bare key: with anything indented under it is an OBJECT. Always. There is no exception and no heuristic.

To put a multi-line VALUE under a key, the key must carry an annotation. @text: is the generic one, but any annotation works -- @int:, @bool:, @json: all accept a value indented on the following lines.

message@text:
  Subject: Order 123
  Status: open

→ the string "Subject: Order 123\nStatus: open".

Drop the annotation and the same lines mean something completely different:

message:
  Subject: Order 123
  Status: open

→ the object {"message": {"Subject": "Order 123", "Status": "open"}}.

That second one does not error. It parses cleanly into the wrong shape, and the failure surfaces much later as an empty placeholder or a command that received an object where it wanted a string. Prose is especially prone to it, because a colon anywhere in a sentence is enough -- Subject:, Note:, a time like 9:00.

You are only warned when the indented text can't be read as keys:

note:
  See https://cerb.ai/docs/ for more

→ Unexpected syntax (line 2). Same mistake, but this one is loud. Don't rely on it.

So: any value that spans lines, or that contains prose, needs an annotation on its key. When in doubt, @text:.

Strings are never quoted

Values are literal text from the colon to the end of the line. Quotes are not syntax -- they become part of the value.

name: Jeff          →  "Jeff"
name: "Jeff"        →  "\"Jeff\""      ← the quotes are IN the string
name: 'Jeff'        →  "'Jeff'"

Never wrap a value in quotes to "make it a string". It already is one. Quote only when the quotes are genuinely part of the text you want.

Comments must be on their own line

A # only starts a comment at the beginning of a line (after indentation). There are no trailing comments.

# This is a comment.
name: Jeff
name: Jeff # this is NOT a comment

→ the value is "Jeff # this is NOT a comment".

Note that this cuts the other way inside an annotated text block: there, a # line is content, because the whole block is a literal value.

Types come from annotations

All values are text by default. Convert explicitly:

@bool @int @float @csv @json @list @date @key @text @raw @optional

Annotations combine with a comma (@optional,text:). @optional is honored by whatever CONSUMES the KATA rather than by the parser, so what it does depends on the command -- check that command's documentation rather than assuming it drops empty values.

Never stack @raw inside an already-raw block. Inside script@raw: / event_kata@raw: / policy_kata@raw:, use the normal annotations (if@bool:, set:). Writing if@raw,bool: {{...}} makes the condition never match.

Keys must be unique among siblings

A repeated key silently clobbers the earlier one. Where you need the same command twice under one parent, give each an alias with /:

set/init:
set/increment:
await/step:

The part before the / is what Cerb dispatches on; the part after is yours, and it may contain only letters, numbers, and underscores -- no dots.

References

&name: defines a reusable block; @ref uses it. Useful for a long value you'd otherwise repeat, and for keeping a big text block out of the middle of a script.

House style

Two-space indentation, spaces not tabs. Annotate types rather than relying on a reader to infer them.

Files (cerb)
  • SKILL.md 4.1 KB
    ---
    name: kata
    description: KATA, the indentation-based configuration language Cerb uses for automations, toolbars, sheets, charts, workflows, policies, and more. Load it before writing any KATA -- the indentation and quoting rules are not YAML's.
    ---
    
    # KATA
    
    KATA is Cerb's configuration language: keys, values, and indentation. It looks like YAML and is not YAML. Everything below applies **everywhere Cerb uses KATA** -- automation scripts and policies, toolbars, sheets, charts, workflows, interaction elements, agent config, the schema file -- not just automations.
    
    Full reference: `/cerb-docs/references/docs/kata.md`.
    
    ## The indentation rule -- read this one twice
    
    **A bare `key:` with anything indented under it is an OBJECT. Always.** There is no exception and no heuristic.
    
    To put a multi-line VALUE under a key, the key must carry an annotation. `@text:` is the generic one, but any annotation works -- `@int:`, `@bool:`, `@json:` all accept a value indented on the following lines.
    
    ```
    message@text:
      Subject: Order 123
      Status: open
    ```
    → the string `"Subject: Order 123\nStatus: open"`.
    
    Drop the annotation and the same lines mean something completely different:
    
    ```
    message:
      Subject: Order 123
      Status: open
    ```
    → the object `{"message": {"Subject": "Order 123", "Status": "open"}}`.
    
    **That second one does not error.** It parses cleanly into the wrong shape, and the failure surfaces much later as an empty placeholder or a command that received an object where it wanted a string. Prose is especially prone to it, because a colon anywhere in a sentence is enough -- `Subject:`, `Note:`, a time like `9:00`.
    
    You are only warned when the indented text *can't* be read as keys:
    
    ```
    note:
      See https://cerb.ai/docs/ for more
    ```
    → `Unexpected syntax (line 2)`. Same mistake, but this one is loud. Don't rely on it.
    
    **So: any value that spans lines, or that contains prose, needs an annotation on its key.** When in doubt, `@text:`.
    
    ## Strings are never quoted
    
    Values are literal text from the colon to the end of the line. Quotes are not syntax -- they become part of the value.
    
    ```
    name: Jeff          →  "Jeff"
    name: "Jeff"        →  "\"Jeff\""      ← the quotes are IN the string
    name: 'Jeff'        →  "'Jeff'"
    ```
    
    Never wrap a value in quotes to "make it a string". It already is one. Quote only when the quotes are genuinely part of the text you want.
    
    ## Comments must be on their own line
    
    A `#` only starts a comment at the beginning of a line (after indentation). There are no trailing comments.
    
    ```
    # This is a comment.
    name: Jeff
    ```
    
    ```
    name: Jeff # this is NOT a comment
    ```
    → the value is `"Jeff # this is NOT a comment"`.
    
    Note that this cuts the other way inside an annotated text block: there, a `#` line *is* content, because the whole block is a literal value.
    
    ## Types come from annotations
    
    All values are text by default. Convert explicitly:
    
    `@bool` `@int` `@float` `@csv` `@json` `@list` `@date` `@key` `@text` `@raw` `@optional`
    
    Annotations combine with a comma (`@optional,text:`). `@optional` is honored by whatever CONSUMES the KATA rather than by the parser, so what it does depends on the command -- check that command's documentation rather than assuming it drops empty values.
    
    **Never stack `@raw` inside an already-raw block.** Inside `script@raw:` / `event_kata@raw:` / `policy_kata@raw:`, use the normal annotations (`if@bool:`, `set:`). Writing `if@raw,bool: {{...}}` makes the condition never match.
    
    ## Keys must be unique among siblings
    
    A repeated key silently clobbers the earlier one. Where you need the same command twice under one parent, give each an alias with `/`:
    
    ```
    set/init:
    set/increment:
    await/step:
    ```
    
    The part before the `/` is what Cerb dispatches on; the part after is yours, and it may contain only letters, numbers, and underscores -- no dots.
    
    ## References
    
    `&name:` defines a reusable block; `@ref` uses it. Useful for a long value you'd otherwise repeat, and for keeping a big text block out of the middle of a script.
    
    ## House style
    
    Two-space indentation, spaces not tabs. Annotate types rather than relying on a reader to infer them.
    

Comments (0)

Sign in to join the conversation.

No comments yet.

Reviews (0)

No reviews yet.

Related