Ein Skill bleibt ein Modul nach jarvis.skill.v1. In Docker wird Plugin-Code jetzt standardmäßig nicht im Master, sondern in einem Runtime-Worker ausgeführt.

Ordnerlayout

skills/
  python/<skill>/skill.json
  node/<skill>/skill.json
  go/<skill>/skill.json
  rust/<skill>/skill.json
  c/<skill>/skill.json
  cpp/<skill>/skill.json
  csharp/<skill>/skill.json

Jeder Worker mountet nur seinen Runtime-Ordner als /skills.

skill.json

Beispiel Python:

{
  "protocol": "jarvis.skill.v1",
  "id": "weather.local",
  "name": "Local Weather",
  "version": "1.0.0",
  "runtime": {
    "type": "process",
    "command": "python3",
    "args": ["main.py"],
    "timeout_ms": 5000
  },
  "permissions": {"system_exec": true},
  "actions": [{
    "name": "forecast",
    "description": "Liefert eine Vorhersage.",
    "mutates": false,
    "input_schema": {
      "type": "object",
      "properties": {"location": {"type": "string"}},
      "required": ["location"],
      "additionalProperties": false
    },
    "output_schema": {
      "type": "object",
      "properties": {"summary": {"type": "string"}},
      "required": ["summary"],
      "additionalProperties": false
    }
  }]
}

system_exec bezieht sich hier nur auf den Worker-Container. Er erlaubt z. B. python3, node, go, cargo, gcc, g++ oder dotnet aus dessen PATH. Der Worker hat keinen Docker-Socket.

Alternativ kann runtime.command auf ein lokales ./run zeigen. Das ist besonders für C/C++/Rust/Go praktisch: run kann kompilierte Artefakte cachen und anschließend das Binary starten.

Invoke Input

Der Skill-Prozess bekommt ein JSON-Objekt auf stdin:

{
  "protocol": "jarvis.skill.invoke.v1",
  "request_id": "remote_...",
  "skill_id": "weather.local",
  "action": "forecast",
  "input": {"location": "Berlin"},
  "context": {
    "trace_id": "http_...",
    "now": "2026-08-29T10:20:00+02:00",
    "timezone": "Europe/Berlin"
  }
}

Output

stdout muss genau eine JSON-Antwort enthalten. Logs gehören auf stderr.

{
  "protocol": "jarvis.skill.invoke.v1",
  "success": true,
  "data": {"summary": "Sonnig"},
  "message": "Vorhersage geladen.",
  "mutated": false
}

Input und Output werden im Worker und beim Master gegen die veröffentlichten Schemas geprüft.

Reload

Nach Änderungen am gemounteten Skill-Verzeichnis kann der Worker ohne Master-Neustart neu laden. Im UI unter Wissen & System -> Skill Worker & Container auf RELOAD SKILLS klicken.

Lokale Process-Skills

Der alte lokale Provider bleibt für Entwicklung erhalten. Ordner direkt unter skills/<name> können weiterhin vom Master geladen werden, wenn JARVIS_SKILL_PROCESS_ENABLED=true gesetzt ist. Im Docker-v9-Compose ist das absichtlich false; dort sollen Runtime-Skills über Worker laufen.

Ein Worker kann mehrere Skills hosten oder genau einen Skill-Container darstellen. Für 1 Container = 1 Skill darf direkt der Skill-Ordner auf /skills gemountet werden; der Worker erkennt auch /skills/skill.json als Root-Skill.

v9.1: `runtime.env_from`

Remote-Skills können einzelne Konfigurationswerte/Secrets explizit aus der Worker-Environment übernehmen, ohne sie in skill.json zu speichern:

"runtime": {
  "type": "process",
  "command": "python3",
  "args": ["main.py"],
  "env_from": ["SERVICE_URL", "SERVICE_API_TOKEN"]
}

Nur die aufgelisteten Variablen werden an den Skill-Prozess weitergereicht. Variablen mit JARVIS_-Präfix werden unabhängig vom Manifest nicht vererbt.

README.md Unescape Escape

JARVIS Skills – v9 Skill Mesh