# Was oh-my-opencode-slim wirklich kann – und was `omos` daraus machen sollte *Von Modell-IDs bis Sandboxing: Die OMOS-Konfiguration ist mächtiger, als man denkt.* Im ersten Teil haben wir beschrieben, wie ein APM-Package sein empfohlenes Team deklarieren kann. Dort haben wir `omos` als Übersetzer zwischen `team-profile.yaml` und OMOS-Presets vorgestellt – und dabei nur zwei Konfigurationsflächen genutzt: Modell-IDs und MCP/Skill-Allowlists. Das war bewusst minimal. Aber OMOS kann deutlich mehr. Und `omos` sollte das nutzen. ## Was OMOS alles kann Die vollständige Konfiguration von oh-my-opencode-slim geht weit über Presets hinaus. Hier die wichtigsten Features, die für Team-Pakete relevant sind: ### Custom Agents mit eigenen Prompts OMOS kann unter `agents` eigene Subagenten definieren. Jeder braucht ein `model`, einen `prompt` und optional einen `orchestratorPrompt`, der dem Orchestrator sagt, wann er delegieren soll: ```jsonc { "agents": { "writer": { "model": "ollama/qwen3.6:35b-a3b-q4_K_M", "prompt": "Erstelle faktenbasierte Bewerbungsunterlagen. " + "Nutze nur freigegebene Profilfakten. " + "Erfinde keine Erfahrung. " + "Lege Entwürfe in ShareLaTeX ab. " + "Reiche niemals eine Bewerbung ein.", "orchestratorPrompt": "@writer\n" + "- Rolle: Anschreiben und CV-Anpassungen erstellen\n" + "- Delegiere nach qualifiziertem Stellen-Match\n" + "- Liefere einen ShareLaTeX-Entwurf und offene Fragen" } } } ``` Der `orchestratorPrompt` ist der Schlüssel: Er wird direkt in den Orchestrator-Prompt injiziert und bestimmt, **wann** der Orchestrator diesen Agenten aufruft. Ohne ihn weiß der Orchestrator nicht, dass es den Agenten gibt. ### Tool-Permissions: Echte Sandboxing OMOS bietet pro Agent ein `permission`-Objekt, das auf Tool-Ebene durchgesetzt wird – nicht nur MCP-Allowlists, sondern auch OpenCode-Core-Tools: ```jsonc { "agents": { "researcher": { "model": "ollama/qwen3.5:9b", "permission": { "edit": "deny", "bash": "deny", "task": "deny", "webfetch": "allow", "websearch": "allow" } } } } ``` Das ist eine **echte Sandbox**. Der Researcher darf suchen und lesen, aber keine Dateien bearbeiten, keine Shell-Befehle ausführen und keine Subagenten spawnen. Das geht über `mcps` und `skills` hinaus und ist das, was wir im ersten Blogpost als „mehrere Schichten der Verteidigung" beschrieben haben. Verfügbare Permission-Keys: | Key | Was es kontrolliert | |-----|-------------------| | `read` | Dateien lesen | | `edit` | Dateien bearbeiten | | `bash` | Shell-Befehle ausführen | | `task` | Subagenten delegieren | | `webfetch` | Web-Inhalte abrufen | | `websearch` | Websuche | | `glob` | Dateisuche nach Pattern | | `grep` | Inhaltsuche | | `skill` | Skill-Ausführung | Jeder Key akzeptiert `"allow"`, `"deny"` oder `"ask"` (fragt den Nutzer). Für `bash` gibt es zusätzlich Pattern-basierte Regeln: ```jsonc "bash": { "*": "deny", "git status*": "allow", "git diff*": "allow" } ``` ### Fallback-Ketten OMOS unterstützt Modell-Failover bei 429-Errors (Rate Limiting). In der Mapping-Tabelle könnte man das so abbilden: ```yaml # ~/.config/apm-team/model-mapping.yaml model_classes: fast-research: primary: ollama/qwen3.5:9b fallback: - openai/gpt-4o-mini ``` `omos` würde daraus ein OMOS-Array generieren: ```jsonc "librarian": { "model": ["ollama/qwen3.5:9b", "openai/gpt-4o-mini"] } ``` OMOS versucht das erste Modell und wechselt bei Fehlern automatisch zum nächsten. ### Prompt-Dateien statt Inline-Prompts Statt lange Prompts inline in die Config zu schreiben, kann man sie als Markdown-Dateien ablegen: ``` .opencode/oh-my-opencode-slim/ ├── acme-job-applications/ │ ├── writer.md # Preset-spezifisch │ └── researcher.md └── writer.md # Fallback für alle Presets ``` Die Lookup-Reihenfolge ist: 1. `.opencode/oh-my-opencode-slim//.md` (projektspezifisch, preset-spezifisch) 2. `.opencode/oh-my-opencode-slim/.md` (projektspezifisch, preset-übergreifend) 3. `~/.config/opencode/oh-my-opencode-slim//.md` (global, preset-spezifisch) 4. `~/.config/opencode/oh-my-opencode-slim/.md` (global, preset-übergreifend) `omos` könnte die `purpose`-Felder aus dem Team-Profil in solche Dateien schreiben – versionierbar im Package, geteilt über Presets. ### Weitere relevante Features | Feature | OMOS-Feld | Nutzen für Teams | |---------|-----------|-----------------| | **Council** | `council.presets` | Mehrere Modelle parallel für kritische Entscheidungen (z.B. Checker) | | **ACP Agents** | `acpAgents.` | Externe Agent-CLIs (Claude Code, Gemini) als Subagent einbinden | | **Multiplexer** | `multiplexer.type` | tmux/zellij-Panes für Live-Beobachtung arbeitender Agenten | | **displayName** | `displayName` | Alias für den Orchestrator (bereits im ersten Blogpost genutzt) | | **description** | `description` | Beschreibung, die dem Orchestrator bei der Routing-Entscheidung hilft | | **disabled_agents** | `disabled_agents[]` | Agenten global deaktivieren (z.B. Observer) | | **Background Jobs** | `backgroundJobs.*` | Orchestrator-Wake, Wall-Timeout für Hintergrundaufgaben | ## Was `omos` daraus machen sollte Im ersten Blogpost haben wir `omos` als Übersetzer von Modellklassen und MCP-Allowlists beschrieben. Das war Phase 1. Hier ist, was Phase 2 und 3 aussehen: ### Phase 2: Custom Agents + Permissions `omos` liest das Team-Profil und generiert für jeden Custom Agent (also jeden, der nicht auf einen eingebauten OMOS-Agenten mapped) einen vollständigen Agent-Block: **Input** (team-profile.yaml): ```yaml - id: writer purpose: Erstellt auf Fakten basierende Anschreiben und Lebensläufe in ShareLaTeX. Nutze nur freigegebene Profilfakten. Erfinde keine Erfahrung. omos_agent: custom model_class: strong-writing capabilities: mcps: [openviking, sharelatex] skills: [] permissions: edit: deny bash: deny task: deny ``` **Output** (OMOS-Preset): ```jsonc "writer": { "model": "ollama/qwen3.6:35b-a3b-q4_K_M", "prompt": "Erstellt auf Fakten basierende Anschreiben und Lebensläufe in ShareLaTeX. Nutze nur freigegebene Profilfakten. Erfinde keine Erfahrung.", "orchestratorPrompt": "@writer\n- Rolle: Anschreiben und CV erstellen\n- Delegiere nach qualifiziertem Stellen-Match", "mcps": ["openviking", "sharelatex"], "skills": [], "permission": { "edit": "deny", "bash": "deny", "task": "deny" } } ``` ### Phase 3: Prompt-Dateien + Fallback + Council `omos` schreibt zusätzlich: - `.opencode/oh-my-opencode-slim/acme-job-applications/writer.md` mit dem vollständigen Prompt - Fallback-Ketten aus der Mapping-Tabelle - Optional: Council-Preset für den Checker (zwei Modelle parallel prüfen lassen) ## Die erweiterte Mapping-Tabelle Für Phase 2 und 3 wird die Mapping-Tabelle reichhaltiger: ```yaml # ~/.config/apm-team/model-mapping.yaml model_classes: strong-generalist: primary: ollama/qwen3.6:35b-a3b-q4_K_M fallback: - openai/gpt-4o-mini fast-research: primary: ollama/qwen3.5:9b fallback: - openai/gpt-4o-mini strong-writing: primary: ollama/qwen3.6:35b-a3b-q4_K_M high-reasoning: primary: ollama/qwen3.6:35b-a3b-q4_K_M variant: thinking options: thinking: type: enabled budgetTokens: 10000 cheap-reliable: primary: ollama/gemma4:12b ``` `omos` übersetzt das deterministisch: - `primary` → erstes Modell im Array - `fallback` → weitere Einträge im Array - `variant` → wird direkt übernommen - `options` → wird direkt übernommen ## Was das für den Blogpost-Workflow bedeutet Der erweiterte Flow sieht so aus: ```mermaid flowchart TD P[APM Package: team-profile.yaml] --> O[omos liest] M[~/.config/apm-team/model-mapping.yaml] --> O O -->|Modellklassen| G[Generiere OMOS-Preset] O -->|purpose-Felder| PR[Generiere Prompt-Dateien] O -->|permissions| PE[Generiere Permission-Objekte] O -->|fallback| FB[Generiere Fallback-Ketten] G --> C[Schreibe .opencode/oh-my-opencode-slim.json] PR --> C PE --> C FB --> C C --> D[Fertig] ``` ## Fazit OMOS ist nicht nur ein Preset-Switcher. Es ist ein vollständiges Agent-Konfigurationssystem mit Custom Prompts, Tool-Permissions, Fallback-Ketten und Multi-Model-Synthese. `omos` als Adapter sollte diese Möglichkeiten nutzen – nicht nur Modell-IDs übersetzen. Die drei Phasen: | Phase | Was omos generiert | OMOS-Features | |-------|-------------------|---------------| | **1** | Modell-IDs + MCP/Skill-Allowlists | `presets...model`, `mcps`, `skills` | | **2** | + Custom Prompts + Permissions | `agents..prompt`, `orchestratorPrompt`, `permission` | | **3** | + Fallback-Ketten + Prompt-Dateien + Council | `model[]`, `.md`-Dateien, `council.presets` | Phase 1 ist der Minimalprototyp. Phase 2 macht die Agenten wirklich arbeitsfähig. Phase 3 macht sie resilient.