@kolbo/kolbo-code-linux-arm64-musl 2.1.22 → 2.2.0

package/package.json

@@ -1,6 +1,6 @@
 {
   "name": "@kolbo/kolbo-code-linux-arm64-musl",
-  "version": "2.1.22",
+  "version": "2.2.0",
   "os": [
     "linux"
   ],

package/skills/kolbo/SKILL.md

@@ -1203,9 +1203,20 @@ This composes with `@image1` / `@image2` positional tags for plain
 reference/source images — see "Tagging references inside the prompt" above
 for the full system.
 
-**Naming hint for `create_visual_dna`:** pick a short, lowercase, no-space
-Latin string for `name` (`esther_model`, `dana`, `tokyo_neon`) so it's
-trivially typable inside any prompt regardless of the user's language.
+**⚠️ Naming rule for `create_visual_dna` — NO SPACES (MANDATORY).** The
+`name` you set MUST be a **single token, lowercase, no spaces, ASCII-safe**
+— `esther_model`, `dana`, `tokyo_neon`, `brand_red`. Never `Sarah Johnson`,
+never `the red dress`. Reason: the prompt parser stops the `@<token>`
+match at the first space (and at `.,!?` punctuation). So `@Sarah Johnson`
+matches *only* `Sarah` — if no DNA named `Sarah` exists, the mention is
+silently dropped and the DNA never binds. A single-token name is the only
+way to guarantee inline `@name` works in any sentence, in any language,
+without forcing the user to write awkward punctuation around it. Use
+underscores for multi-word concepts (`old_town`, not `Old Town`). When
+the user proposes a name with spaces, accept the intent but collapse it
+into a single token before storing (`"Sarah Johnson"` → `sarah_johnson`)
+and tell them once how you'll refer to it. Source of truth:
+[kolbo-docs / Visual DNA & @ References](https://docs.kolbo.ai/kolbo-code/visual-dna).
 
 ### Visual DNA Limits
 

package/skills/pptx/SKILL.md

@@ -1,9 +1,29 @@
 ---
 name: pptx
-description: "Presentation creation, editing, and analysis. When Claude needs to work with presentations (.pptx files) for: (1) Creating new presentations, (2) Modifying or editing content, (3) Working with layouts, (4) Adding comments or speaker notes, or any other presentation tasks"
+description: "Presentation creation, editing, and analysis. Use whenever the user asks for a presentation, slides, slide deck, pitch deck, or .pptx file — covers (1) creating new presentations, (2) editing/modifying content, (3) layouts, (4) comments/speaker notes, and analysis."
 ---
 
-# PPTX creation, editing, and analysis
+# Presentation creation, editing, and analysis
+
+## Output format decision — read first
+
+**Default to a single self-contained HTML file** for any "make a presentation / slides / deck" request. The chat view renders `.html` files inline as an interactive artifact, so the user sees the result immediately without downloading anything.
+
+Use the html2pptx → `.pptx` workflow **only when one of these is true**:
+- The user explicitly asks for a `.pptx`, PowerPoint, or Keynote file.
+- The user asks to edit, analyze, or convert an existing `.pptx`.
+- The user asks for a deliverable they'll open in PowerPoint/Keynote/Google Slides.
+
+When in doubt, produce HTML. Do **not** paste slide markup as a code block in chat — always write to an `.html` file with the `write` tool so the inline preview triggers.
+
+### HTML presentation workflow (default)
+
+1. Create one `.html` file (e.g. `presentation.html`) containing all slides as full-viewport sections (`100vw × 100vh`) stacked vertically, with a 16:9 aspect intent.
+2. Include inline `<style>` (web-safe fonts only — Arial, Helvetica, Georgia, Inter via system fallback) and basic keyboard navigation (`ArrowDown`/`ArrowRight` → next slide, `ArrowUp`/`ArrowLeft` → previous, `Space` → next) using a tiny inline `<script>`.
+3. Apply the design principles from the [PPTX workflow section](#creating-a-new-powerpoint-presentation-without-a-template) below — palette, typography, layout, contrast — they apply identically to HTML.
+4. Write the file with the `write` tool. The chat view will open the preview automatically.
+
+Only continue to the PPTX-specific instructions below when the decision rule above says to.
 
 ## Overview
 

package/skills/writing-skills/SKILL.md

@@ -69,11 +69,28 @@ Way of thinking about problems (flatten-with-flags, test-invariants)
 ### Reference
 API docs, syntax guides, tool documentation (office docs)
 
+## Where to Write the Skill (REQUIRED)
+
+**Personal skills MUST be written to the user's global skills directory so every Kolbo Code session — across every project — can discover them.**
+
+Default target (do this unless the user explicitly asks for project-scope):
+
+```
+~/.claude/skills/<skill-name>/SKILL.md
+```
+
+Kolbo Code's skill loader scans `~/.claude/skills/**/SKILL.md` and `~/.agents/skills/**/SKILL.md` on every session init. Anything written there is globally available. Anything written inside the project's working directory (e.g. `./skills/...` or the repo's `.claude/skills/`) only applies to that one project and will NOT be available in other repos.
+
+**Rules:**
+- Never create a `skills/` directory inside the user's project unless they explicitly ask for a project-scoped skill.
+- If you've already written the file under the project by mistake, `mv` it to `~/.claude/skills/<skill-name>/` and tell the user where it ended up.
+- After writing, call `POST /skill/reload` on the local Kolbo server (or instruct the user to do so via the UI) so the current session picks the new skill up without a restart.
+
 ## Directory Structure
 
 
 ```
-skills/
+~/.claude/skills/
   skill-name/
     SKILL.md              # Main reference (required)
     supporting-file.*     # Only if needed