Vollmigration Claude Code → opencode

Overview

Claude Code wird als alleiniger Daily-Driver-Coding-Agent durch opencode 1.14.50+ ersetzt. Migration laeuft in 4 Phasen ueber ~5 Wochen mit Hybrid-Uebergangsphase (CC bleibt parallel laufbereit bis Phase 3 abgenommen ist). Cutover-Punkt: 2026-06-21 — danach wird CC aus dem PATH genommen und Plugins disabled.

Die 14 eigenen Skills im agentic-ventures-Plugin werden als opencode-Custom-Commands plus Plugin-Hooks reimplementiert. Die compound-engineering-Pipeline (ce:plan, ce:work, ce:review, ce:brainstorm, ce:compound, document-review, reproduce-bug, git-commit-push-pr) wird minimalistisch nachgebaut — nicht 1:1 portiert, sondern auf das reduziert was Marvin tatsaechlich nutzt. 11 MCPs werden in opencode-Config-Format ueberfuehrt mit Per-Agent-Gating via Glob-Patterns. Memory-System wandert vom CC-Auto-Loading-Mechanismus in den Vault (das ist es bereits, nur das Auto-Loading-Pattern aendert sich).

Problem Frame

Schmerzpunkt: Anthropic-only-Lock-in. Industriekunden-Spur (siehe hosting-industriekunden) braucht Provider-Wahl — Mistral via Hetzner fuer DSGVO-strenge Kunden, Bedrock EU fuer AWS-native Kunden, lokales Ollama fuer Privacy-kritische Beratungs-Sessions. Mit CC ist jeder dieser Pfade ein Workaround mit separater Tooling-Spur.

Sekundaer-Schmerz: Sub-Agent-Aktivitaet ist in CC eine Blackbox. Token-Verbrauch waehrend langer Plan-/Build-Laeufe nicht live sichtbar. Bei ADHS-Workflow problematisch — keine Rueckmeldung ob das System noch arbeitet oder haengt.

Was bleibt unveraendert nach Migration:

Das Vault selbst (alle Behavior Rules, Routing-Tabellen, Wissens-Files)
MCP-Server-Prozesse (laufen weiter, nur Config-Format aendert sich)
agents-platform-Lambdas (autark, brauchen separate Entscheidung in Phase 4)

Was sich aendert:

Skill-Auto-Routing (CLAUDE.md Regel 20) — opencode ruft Skills nicht automatisch auf, Marvin muss expliziter werden ODER Plugin-Hooks bauen die das Matching machen
Memory-Auto-Loading — opencode laedt nur AGENTS.md, kein separater Memory-Ordner. Loesung: Memory-Files ins Vault unter intern/firma/-Pattern (war eh CLAUDE.md Regel 18)
Plugin-Marketplace-System — opencode hat Plugins, aber nicht den CC-Marketplace-Mechanismus

Requirements Trace

R1. opencode laeuft als alleiniger Coding-Agent — claude wird aus dem PATH entfernt oder ~/.claude deaktiviert
R2. Alle 14 eigenen Skills (siehe intern/capabilities/skills/_index.md) sind in opencode aufrufbar — entweder als Custom Command, Plugin-Hook, oder Agent-Definition
R3. Compound-Engineering-Pipeline (ce:plan, ce:work, ce:review, ce:brainstorm, ce:compound, reproduce-bug, git-commit-push-pr) ist ersetzt durch funktional gleichwertige opencode-Commands — nicht 1:1, sondern reduziert auf tatsaechlich genutzten Workflow
R4. Alle 11 aktiven MCPs (gsuite, m365, papierkram, ticketpay, runway, replicate, calcom, whatsapp, elevenlabs, hetzner, aws-docs/api/iac/pricing, cloudflare) laufen in opencode mit Per-Agent-Gating wo sinnvoll
R5. Vault-Behavior-Rules (22 in CLAUDE.md) sind in AGENTS.md validiert und greifen in opencode genauso — Skill-Auto-Routing (Rule 20) ist explizit reflektiert wie es in opencode funktioniert
R6. Memory-Pattern (User-Profile, ADHS, Feedback, Project-State, Reference) ist im Vault unter intern/firma/ oder intern/wissen/prozesse/ konsolidiert — kein ~/.claude/projects/.../memory/-Ordner mehr noetig
R7. Provider-Setup laeuft: AWS Bedrock EU (eu-central-1) via av-production-Profile aktiv, Sonnet 4.6 + Haiku 4.5 + Opus 4.7 erreichbar. Optionaler Zweit-Provider (Ollama lokal) als Followup, nicht blockierend.
R8. Hybrid-Uebergang funktioniert — bis Cutover lebt opencode parallel zu CC, beide koennen auf das Vault zugreifen ohne Konflikte
R9. Provider-Kosten-Budget definiert und ueberwacht — opencode = pay-per-token, alter CC-Pro-Abo-Wert (~20 USD/Monat) ist Referenz
R10. Rollback-Plan dokumentiert — wenn Phase X scheitert, klarer Pfad zurueck auf CC

Scope Boundaries

Nicht in Scope: Migration der agents-platform-Cron-Lambdas von direktem Anthropic-API-Call auf opencode serve-Backend. Das ist eigener Workstream nach Cutover (Phase 4 als Pilot mit EINER Routine, nicht alle).
Nicht in Scope: Mobile/Web-Claude-Apps. Die nutzt Marvin separat fuer Chat, nicht fuer Coding.
Nicht in Scope: Komplette Rekonstruktion ALLER compound-engineering-Skills 1:1. Nur die tatsaechlich genutzten (siehe Phase 3 Approach). Skills wie dspy-ruby, dhh-rails-style, andrew-kane-gem-writer waren eh schon bewusst nicht eingebunden (siehe intern/capabilities/skills/_externe-skills.md).
Nicht in Scope: Neue Features die opencode kann aber CC nicht (z.B. opencode serve als Backend, lokale Modelle via Ollama). Diese werden ENABLED durch die Migration, aber sind separate Folge-Investitionen.
Nicht in Scope: Migration anderer Claude-Code-User auf Marvins Setup (Team-Skalierung). Single-User-Migration.

Context & Research

Relevante Vault-Files

CLAUDE.md — 22 Behavior Rules, Routing-Tabellen, MCP-Inventar (via @import). Greift bereits als AGENTS.md via Symlink.
intern/capabilities/skills/_index.md — 14 eigene Skills mit Trigger-Phrasen und Pointern. Source of Truth fuer Skill-Migration.
intern/capabilities/skills/_externe-skills.md — Coding-Pipeline-Map (welche compound-engineering-Skills welche Phase abdecken). Definiert Replacement-Scope.
intern/capabilities/mcps/_index.md — 11 aktive MCPs mit Endpoints, Auth-Pattern, Ports.
intern/firma/stack.md#claude-code-plugins-active — Plugin-Inventar (compound-engineering, frontend-design, obsidian, marketing-skills, document-skills, agentic-ventures).
~/.claude/settings.json — Hooks (permission_prompt + idle_prompt sound), statusLine, enabledPlugins, voiceEnabled, skipDangerousModePermissionPrompt.
~/.claude/projects/-Users-marvinkuehlmann-source-agentic-ventures/memory/ — 22 Memory-Files (1× MEMORY.md Index + 21 Inhalts-Files).

opencode-Architektur-Eckdaten

Aus den opencode-Docs (opencode.ai/docs/):

Provider-Konfiguration (providers): Multi-Provider via models.dev, Switch per /models. ENV-Vars pro Provider (ANTHROPIC_API_KEY, OPENAI_API_KEY, OPENROUTER_API_KEY, MISTRAL_API_KEY etc.). Anthropic Max OAuth gesperrt seit Jan 2026 — API-Key noetig.
Rules (rules): AGENTS.md primaer, CLAUDE.md Fallback. Hierarchisch — globale Rules in ~/.config/opencode/AGENTS.md, Projekt-Rules in ./AGENTS.md, Sub-Dir-Rules in ./<subdir>/AGENTS.md mergen.
MCPs (mcp-servers): Local (stdio) + Remote (HTTP/SSE) wie CC. OAuth Dynamic Client Registration (RFC 7591) automatisch. Per-Agent-Gating via Glob-Patterns in Agent-Config (tools: ["papierkram*", "sharepoint*"]).
Custom Commands (commands): Markdown-Files in ~/.config/opencode/commands/ oder ./.opencode/commands/. Frontmatter mit description, agent, model. Body wird als Prompt verwendet. Args via $ARGUMENTS. DAS ist das Skill-Replacement.
Agents (agents): Primary (Build, Plan) + Subagents (General, Explore, Scout, plus Custom). Definiert in ~/.config/opencode/agent/<name>.md mit Frontmatter (description, model, tools, prompt). Per-Agent-Tool-Scope. Plus Subagent-Aktivitaet live sichtbar in TUI.
Plugins (plugins): JS/TS-Module mit Event-Hooks (session.created, tool.execute.before/after, file.edited etc.). Custom-Tools via Zod-Schemas. Installiert via bun add @org/plugin oder lokal als Workspace-Package. Das ist das Replacement fuer komplexere Auto-Logik wie wiki-maintenance-Drift-Check.
Server-Mode (server): opencode serve startet Port 4096 mit OpenAPI 3.1 REST. Nicht in Phase 1-3 noetig, aber Vorbereitung fuer agents-platform-Workstream nach Cutover.
Modes vs Agents: opencode hat “Modes” — eingebaute Build, Plan (read-only). Tab switcht zwischen ihnen. Plus Custom Modes definierbar.
Share (share): Default manual setzen wegen NDA-Material (CLAUDE.md Regel 22 — Becker-NDA, AGB §16). NIE auto.

Institutional Learnings

Aus dem Vault relevant:

mcp-best-practices — Tool-Design-Konventionen fuer eigene MCPs, gilt weiter fuer opencode (MCP-Interface ist Standard).
hosting-industriekunden — Warum Mistral/Hetzner-Spur ueberhaupt der Trigger ist. Validiert R7 (Multi-Provider-Setup).
active-work — Marvins aktive Workstreams. Migration muss mit laufenden Kunden-Projekten (Becker, Friseur-im-Sueden, BSS, VF-Pilot) kompatibel bleiben — kann nicht alles auf einmal kippen.

Externe Quellen

opencode.ai/docs/ — Vollstaendige Doku, alle Unterseiten gelesen (providers, rules, mcp-servers, commands, agents, plugins, server, share, keybinds, themes, modes, config)
Thomas Wiegold Switcher-Blog — Real-World-Switcher-Erfahrung mit Fallstricken
XDA Article “I use opencode over Claude Code” — Feature-Parity-Vergleich
HN Thread Jul 2026 — Community-Bewertung, RAM-Footprint, Release-Kadenz-Warnungen

Key Technical Decisions

KTD-1: Skill-Implementierung via Custom Commands + Sub-Agents, nicht Plugins

Entscheidung: Die 14 eigenen Skills werden primaer als opencode Custom Commands (Markdown in ~/.config/opencode/commands/) implementiert. Komplexe Skills mit Multi-Step-Logik (z.B. wiki-maintenance, security-audit, routine-anlegen) bekommen zusaetzlich einen dedizierten Sub-Agent.

Rationale:

Custom Commands sind Markdown-Files — naeher am CC-SKILL.md-Pattern als JS/TS-Plugins. Migrations-Aufwand pro Skill: ~2-4h statt ~6-10h fuer Plugin.
Plugins (JS/TS mit Zod-Schemas) machen Sinn fuer Auto-Hooks (z.B. „bei jeder File-Edit pruefe Frontmatter”) — nicht fuer den 90%-Use-Case „Marvin tippt Trigger-Phrase, Skill laeuft”.
Sub-Agents sind sichtbar live aktiv — passt zu ADHS-Anforderung „System nicht unsichtbar”.
Plugin-Pfad bleibt offen fuer Phase 4+, wenn bestimmte Skills Hook-Verhalten brauchen.

Verworfen:

1:1-Port als opencode-Plugin pro Skill — zu hoher Anfangsaufwand, Plugin-Lifecycle (versionieren, deployen) ist Overkill fuer Single-User-Setup.
Native Skills bei opencode — gibt es so nicht. Custom Commands ist das opencode-Pattern fuer wiederverwendbare Prompts.

KTD-2: AGENTS.md bleibt im Vault, ergaenzt um opencode-spezifische Sektion

Entscheidung: Existierender Symlink AGENTS.md → CLAUDE.md bleibt. Eine neue Sektion „opencode-spezifisch” wird in CLAUDE.md ergaenzt, die Rule 20 (Skill-Auto-Routing) fuer opencode neu formuliert: Marvin triggert Skills via /<skill-name>-Slash-Command (opencode liest Custom-Commands aus ./.opencode/commands/), nicht via Trigger-Phrasen-Matching durch das Modell.

Rationale:

AGENTS.md ist opencode-Standard, das Vault hat es bereits.
Trennung Vault-Behavior-Rules vs opencode-spezifisch macht spaeter Tool-Wechsel (sollte er nochmal noetig werden) einfacher.
Skill-Auto-Routing funktioniert in opencode anders — das muss explizit dokumentiert werden, sonst sucht Marvin nach Phrase-Matching das nicht greift.

Verworfen:

Komplett neues AGENTS.md schreiben — vernichtet die 22 muehsam erarbeiteten Behavior Rules ohne Grund.
Symlink aufloesen und CLAUDE.md loeschen — opencode laesst CLAUDE.md als Fallback gelten, kein Schaden behalten.

KTD-3: Memory-Files ins Vault konsolidieren statt opencode-Memory-Pattern

Entscheidung: Die 22 Memory-Files in ~/.claude/projects/.../memory/ werden inhaltlich ins Vault uebersetzt:

user_profile.md, user_adhd.md → intern/firma/marvin-profile.md (neue Datei)
feedback_*.md → konsolidiert in intern/wissen/prozesse/marvin-arbeitsweise-patterns.md
project_*.md → existierende Projekt-Index-Files erweitern (intern/projekte/<slug>/_index.md) oder intern/firma/active-work.md
reference_*.md → existierende intern/firma/-Files (stack.md, AWS-Quick-Ref bleibt in intern/capabilities/aws/_index.md)

Diese Vault-Files werden in AGENTS.md via @import referenziert — opencode liest sie automatisch beim Session-Start.

Rationale:

CLAUDE.md Regel 18 sagt explizit: NIE in ~/.claude/projects/.../memory/ schreiben. Memory-Files waren historisches Versehen, die Migration ist Gelegenheit zur Konsolidierung.
opencode hat keinen Memory-Auto-Loader, aber @import in AGENTS.md ist das funktional aequivalente Pattern.
Vault ist git-tracked, Memory ist nicht — das ist sowieso die richtige Heimat.

Verworfen:

opencode-Memory-Pattern bauen (z.B. via Plugin-Hook bei session.created) — fuegt Komplexitaet ohne Vorteil hinzu.

KTD-4: Compound-Engineering-Pipeline reduziert nachbauen — nur tatsaechlich genutzte Skills

Entscheidung: Nicht alle ~25 compound-engineering-Skills werden ersetzt. Nur diese 6 als opencode Custom Commands + Sub-Agents:

/plan — ersetzt ce:plan (genutzt mehrfach pro Woche, kritisch)
/work — ersetzt ce:work (genutzt taeglich, Build-Phase)
/review — ersetzt ce:review (vor PR, mehrfach pro Woche)
/brainstorm — ersetzt ce:brainstorm (gelegentlich, ~1×/Woche)
/commit-push-pr — ersetzt git-commit-push-pr (taeglich)
/compound — ersetzt ce:compound (Lessons-Learned-Capture, ~1×/Woche)

Skills die NICHT nachgebaut werden (siehe intern/capabilities/skills/_externe-skills.md#skills-bewusst-nicht-eingebunden):

reproduce-bug, document-review, git-clean-gone-branches, git-worktree, todo-resolve, ce:ideate, onboarding, claude-permissions-optimizer
Diese werden bei Bedarf ad-hoc improvisiert oder spaeter ergaenzt — kein Block fuer Cutover.

Rationale:

compound-engineering ist ein massives Plugin (~25+ Skills) — kompletter 1:1-Port = ~150h Aufwand, davon nutzt Marvin <30% taeglich.
Pareto-Prinzip: 6 Skills decken ~85% der Pipeline-Nutzung ab.
Restliche Skills entstehen organisch nach Cutover, wenn der Schmerz konkret wird.

Verworfen:

Compound-Engineering komplett ueberspringen und „direkt arbeiten” — die Pipeline ist Marvins erprobtes Workflow-Geruest, einfach weglassen heisst Produktivitaets-Einbruch.

KTD-5: MCP-Per-Agent-Gating ausnutzen — getrennte Agents fuer Business-Tasks vs Coding

Entscheidung: Mindestens zwei Custom-Agents definieren:

coding (Default, Tools: alle Coding-MCPs wie hetzner, aws-*, cloudflare, github via local gh) — fuer Build/Plan/Review-Sessions
business (Tools: gsuite, m365, papierkram, ticketpay, calcom) — fuer Email-/Termin-/Buchhaltungs-Tasks ohne Code-Zugriff

Rationale:

Mandanten-Trennung sauberer als globaler Tool-Scope in CC.
Security: ein versehentlicher Aufruf von gsuite_send_mail aus einem Coding-Kontext wird strukturell unmoeglich, nicht nur durch Behavior Rule.
ADHS-Vorteil: Kontext-Switch ist sichtbar (Agent-Wechsel), nicht implizit.

Verworfen:

Pro-Kunde-Agents (z.B. becker-only) — Overkill fuer Single-User, Aufwand-Nutzen-Verhaeltnis schlecht.
Globaler Tool-Scope wie in CC — gibt einen Vorteil von opencode auf.

KTD-6: Cutover-Punkt = Datum + Abnahme-Kriterien, nicht „wenn ich Lust habe”

Entscheidung: Cutover-Tag 2026-06-21 (5 Wochen ab Start). Bis dahin laeuft Hybrid (CC bleibt verfuegbar). An dem Tag:

Phase 0-3 Abnahme-Kriterien gruen (siehe pro Phase unten)
2-Wochen-Parallel-Lauf ohne Show-Stopper-Bugs
claude aus PATH entfernt (Alias/Symlink umbiegen oder ~/.claude/settings.json deaktivieren)
Plugins disabled in CC (falls CC noch installiert bleibt fuer Notfall)
Rollback-Pfad dokumentiert in rollback (anlegen in Phase 0)

Rationale:

Ohne harten Punkt verschleppt sich die Migration in „beide parallel ewig” — das ist der Worst Case, weil Kontext-Switch teuer ist.
Datum gibt Forcing Function. ADHS-Tipp aus User-Profil: feste Deadlines wirken bei Marvin.

Verworfen:

„Cutover wenn alle Skills 100% migriert” — eskaliert ewig, weil bei jedem Skill noch was fehlt.
Cutover vor Phase-3-Abnahme — riskiert dass Build-Pipeline-Ersatz nicht stabil ist.

KTD-7: Provider-Setup — AWS Bedrock EU als Primary, Ollama als optionale Privacy-Spur

Entscheidung (revidiert 2026-05-17 nach Marvin-Clarify): Sonnet/Opus bleiben das primaere Modell — nur der Zugriffsweg aendert sich von Anthropic-direkt (CC Pro OAuth) auf AWS Bedrock EU (eu-central-1).

Aktiv konfiguriert in Phase 0:

amazon-bedrock via AWS-Profile av-production, Region eu-central-1 — Primary fuer alles
- Default-Modell: anthropic.claude-sonnet-4-6
- Small-Modell: anthropic.claude-haiku-4-5-20251001-v1:0 (fuer summary, name-gen etc.)
- Verfuegbar zusaetzlich: Sonnet 4.5, Opus 4.5/4.6/4.7, Haiku 4.5
Ollama lokal — optional, kommt spaeter wenn Disk-Cleanup gemacht + grosses Coder-Modell installiert ist (siehe issues.md). Nicht blockierend fuer Phase 0.

Rationale:

DSGVO-Story sauber: Bedrock EU haelt Daten in Frankfurt, kein US-Provider-Aufruf
Billing via existierenden AWS-Account (av-production, ID 425924867359) — kein neuer Billing-Stream, integriert in bestehende AWS-Kosten-Snapshot-Pipeline (intern/finanzen/cloud-snapshots/)
Kein neuer Account-Anlege-Aufwand (Anthropic-Console, OpenRouter)
Industriekunden-Story verkaufbar („wir nutzen Bedrock EU”) — passt zu hosting-industriekunden
Auth via SSO (existierend) statt API-Key-Verwaltung
Phase 0 Smoke-Test 2026-05-17 bestaetigt: opencode → Bedrock → Sonnet 4.6 funktioniert (PONG-Test gruen)

Verworfen (gegen urspruengliche Plan-Version):

Anthropic-Console-Direct-API — neuer Billing-Stream noetig, OAuth fuer opencode gesperrt seit Jan 2026, kein Mehrwert ggu Bedrock
OpenRouter — Multi-Provider-Gateway, aber bei „weiterhin Sonnet” unnoetig. Optional spaeter wenn echte Multi-Modell-Spur entsteht
Ollama als Phase-0-Pflicht — Disk-Druck (4.8 GiB frei) + 16GB-RAM-Limit machen es non-trivial. Wandert in Followup-Liste

Aufgehoben: Der urspruengliche Trigger „Provider-Lock-in schmerzt” loest sich anders auf als gedacht. Marvin will Sonnet, nicht weg davon — er will weg von Anthropic-direkt als alleinigem Pfad. Bedrock EU loest das vollstaendig.

Open Questions

Resolved During Planning

Wie viele Skills sind das wirklich? 14 eigene (nicht 22 wie im Brief stand — 22 ist die Anzahl Memory-Files). Siehe intern/capabilities/skills/_index.md.
AGENTS.md schon vorhanden? Ja, Symlink auf CLAUDE.md existiert (siehe Vault-Status git status 2026-05-17). Greift sofort.
Welcher opencode-Pattern fuer Skills? Custom Commands (KTD-1).
Compound-Engineering 1:1 oder reduziert? Reduziert auf 6 Core-Skills (KTD-4).
Memory-Files in opencode wie? Konsolidiert ins Vault, via @import in AGENTS.md geladen (KTD-3).

Deferred to Implementation

Welches lokale Modell genau via Ollama? Test in Phase 0 — qwen3-coder:30b vs mistral-large:latest vs deepseek-coder-v3. Haengt von verfuegbarem RAM/VRAM auf Marvins Mac ab.
Provider-Kosten-Budget konkret? Setze in Phase 0 ein Soft-Limit von 100 USD/Monat Anthropic-API + 30 USD OpenRouter und schaue nach 2 Wochen. Tatsaechliche Token-Last unbekannt bis live.
Sub-Agent-Definitionen fuer ce:plan/ce:work in opencode-Pattern? Final-Format entsteht beim Bau in Phase 3 — die compound-engineering-Sub-Agents (repo-research-analyst, learnings-researcher etc.) muessen alle nachgebaut oder ersetzt werden, das ist iterativ.
Auto-Skill-Routing in opencode moeglich? opencode hat kein Phrase-Matching wie CC Rule 20. Mit Plugin-Hook (session-message-Hook) waere ein Auto-Trigger denkbar. Entscheidung deferred: erstmal explizite /skill-name-Calls testen, Plugin-Hook nur wenn Marvin den Lift wirklich vermisst.
Was passiert mit Voice-Mode + Remote-Trigger? CC hatte voiceEnabled: true und Remote-Trigger fuer Email-TODO-Workflow. opencode-Equivalent unklar — Phase 4 evaluieren.
Hooks-Migration? CC hat zwei Notification-Hooks (Glass.aiff bei permission_prompt + idle_prompt). opencode-Plugin-Hooks haben anderes Modell. Phase 4 portieren, nicht kritisch fuer Cutover.

High-Level Technical Design

Diese Skizze zeigt die Zielarchitektur und Migrations-Phasen — Orientierung fuer Review, keine Implementierungs-Spezifikation. Konkrete Files entstehen in den Implementation Units unten.

Zielzustand nach Cutover

┌─────────────────────────────────────────────────────────────────┐
│  opencode 1.14.x  (alleiniger Coding-Agent)                     │
├─────────────────────────────────────────────────────────────────┤
│  Config:  ~/.config/opencode/opencode.json                      │
│           ~/.config/opencode/AGENTS.md  (globale Rules)         │
│           Vault: ./AGENTS.md → CLAUDE.md (Projekt-Rules)        │
├─────────────────────────────────────────────────────────────────┤
│  Provider:    [anthropic] [openrouter] [ollama-local]           │
│  Switch:      /models  (live, in-session)                       │
├─────────────────────────────────────────────────────────────────┤
│  Agents:      coding (default)        business                  │
│               ├─ Plan/Build modes      ├─ Plan/Build modes      │
│               └─ Tools: hetzner,       └─ Tools: gsuite,        │
│                  aws-*, cloudflare,        m365, papierkram,    │
│                  github, replicate         ticketpay, calcom    │
├─────────────────────────────────────────────────────────────────┤
│  Custom Commands (14 eigene + 6 compound-engineering-Ersatz):   │
│   ├─ /inbox-sync       /tagesplan      /wochenplan              │
│   ├─ /termin           /email          /email-review            │
│   ├─ /image-gen        /mcp-eigenbau   /mcp-cloud               │
│   ├─ /wiki-maintenance /transkript     /routine-anlegen         │
│   ├─ /security-audit   /qa-staging                              │
│   ├─ /plan             /work           /review                  │
│   └─ /brainstorm       /commit-pr      /compound                │
├─────────────────────────────────────────────────────────────────┤
│  Plugins (JS/TS, optional, nur wo Hooks noetig):                │
│   └─ ggf. auto-frontmatter-validator (Phase 4)                  │
└─────────────────────────────────────────────────────────────────┘

         │
         │  MCPs (unveraendert, nur Config-Format anders)
         ▼

┌──────────────┬──────────────┬──────────────┬──────────────┐
│ gsuite       │ m365         │ papierkram   │ ticketpay    │
│ (stdio)      │ (HTTP:8765)  │ (HTTP:8767)  │ (HTTP:8766)  │
├──────────────┼──────────────┼──────────────┼──────────────┤
│ runway       │ replicate    │ calcom       │ whatsapp     │
│ (HTTP:8768)  │ (HTTP:8769)  │ (HTTP:8770)  │ (HTTPS hosted)│
├──────────────┼──────────────┼──────────────┼──────────────┤
│ elevenlabs   │ hetzner      │ aws-* (4×)   │ cloudflare   │
│ (stdio)      │ (stdio)      │ (stdio)      │ (stdio)      │
└──────────────┴──────────────┴──────────────┴──────────────┘

Migrations-Phasen-Abhaengigkeiten

flowchart TB
    P0[Phase 0: opencode-Foundation<br/>Config + AGENTS + MCPs + Provider]
    P1[Phase 1: Tägliche Skills<br/>wiki-maintenance, inbox-sync, email-*]
    P2[Phase 2: Weekly Skills<br/>tages/wochen-planung, termin, image-gen,<br/>transkript, routine-anlegen]
    P3[Phase 3: Coding-Pipeline-Ersatz<br/>plan, work, review, brainstorm,<br/>commit-pr, compound + restl. Skills]
    P4[Phase 4: Cutover + Cleanup<br/>CC disable, Memory final,<br/>Hooks portieren, Rollback dokumentieren]
    AGP[Workstream agents-platform<br/>opencode serve als Backend für eine Routine]

    P0 --> P1
    P1 --> P2
    P2 --> P3
    P3 --> P4
    P4 -.optional Folge.-> AGP

Implementation Units

Phase 0 — opencode-Foundation (Woche 1, ~10h)

Unit 0.1: opencode-Config-File und Bedrock-Provider-Setup ✓ 2026-05-17

Goal: opencode startet mit Bedrock-EU-Provider via av-production-AWS-Profile. Sonnet 4.6 als Default, Smoke-Test gruen.

Requirements: R7

Dependencies: opencode 1.14.50 installiert (erledigt), AWS-SSO av-production eingeloggt.

Files:

Created: ~/.config/opencode/opencode.json

Approach (ausgefuehrt):

opencode.json mit amazon-bedrock-Provider, region: eu-central-1, profile: av-production
Model-Liste in Config: Sonnet 4.6 (default), Sonnet 4.5, Opus 4.7/4.6, Haiku 4.5 (small_model)
Auth via SSO — kein API-Key noetig, kein env-var noetig (profile in Config greift)
share: "manual" gesetzt — NDA-Schutz (CLAUDE.md Rule 22)

Verification (gruen):

opencode models amazon-bedrock listet alle Claude-Modelle + Nova-Modelle
opencode run --model amazon-bedrock/anthropic.claude-sonnet-4-6 "Say only PONG" → liefert „PONG”
Kein AWS_PROFILE-Prefix noetig — Config-Profile greift

Followups (nicht blockierend, in issues.md):

I-001: Disk-Cleanup fuer Ollama-Modell-Pull
I-002: OpenRouter — gestrichen (siehe KTD-7)
I-003: 16GB-RAM-Limit fuer lokale Modelle

Unit 0.2: AGENTS.md fuer opencode validieren und opencode-spezifische Sektion ergaenzen

Goal: Existierender AGENTS.md-Symlink wird von opencode korrekt geladen. CLAUDE.md bekommt eine neue Sektion „opencode-Specifics” die Rule 20 (Skill-Routing) fuer opencode neu fasst.

Requirements: R5

Dependencies: Unit 0.1

Files:

Modify: CLAUDE.md (neue Sektion „opencode-Specifics” am Ende, vor „Pflichtlektuere”)
Modify: intern/capabilities/skills/_index.md (Trigger-Tabelle ergaenzen um Slash-Command-Syntax)
Test: keine — manuelle Verifikation via opencode-Session

Approach:

In CLAUDE.md nach Sektion „Konventionen” einen Block „opencode-Specifics” einfuegen mit:
- Wie Skill-Routing in opencode funktioniert (/<skill-name>, keine Phrase-Matching)
- Wie @import in AGENTS.md MCPs und Skills lazy laedt
- Welche Custom Commands existieren (Tabelle mit /skill → Vault-Pfad)
Rule 20 explizit nochmal referenzieren mit Hinweis: „in opencode Slash-Commands statt Phrase-Matching”

Patterns to follow:

Existierende ## Konventionen-Sektion in CLAUDE.md
Vault-Wikilink-Pattern fuer Cross-References

Test scenarios:

Happy path: opencode-Session im Vault-Dir geoeffnet, Modell zitiert Behavior Rule 22 (Kunden-Namen-Regel) korrekt aus AGENTS.md
Edge case: opencode in Unter-Dir des Vaults (z.B. intern/projekte/) — hierarchische Rules werden korrekt gemerged
Integration: Test mit /wiki-maintenance (sobald in Phase 1 gebaut) — Skill liest AGENTS.md-Kontext

Verification:

opencode laedt AGENTS.md beim Start (sichtbar in TUI-Header oder via /help)
Behavior Rules wirken in Sessions (manueller Stichprobentest)

Unit 0.3: 11 MCPs in opencode-Config portieren ✓ 2026-05-17

Status nach Portierung + Pivot 2026-05-17 (12 MCPs konfiguriert, 8 connected):

Papierkram + TicketPAY + Sharepoint/M365 sind LOKAL ENTFERNT (Marvin nutzt sie nur via mcp-vf-hosted fuer VF-Kunden, nicht fuer sich selbst lokal in opencode).

MCP	Status	Hinweis
gsuite	✓ connected	Stdio OK
calcom	✓ connected	HTTP :8770
hetzner	✓ connected	op-Wrapper
aws-api	✓ connected	av-production
aws-docs	✓ connected
aws-iac	✓ connected
aws-pricing	✓ connected
cloudflare	✓ connected	npx mcp-remote
whatsapp	✗ Transport	SSE/Streamable-HTTP-Mismatch beim hosted endpoint — Followup
elevenlabs	✗ Key fehlt	siehe I-004
github	✗ Key fehlt	siehe I-004
banksapi	○ disabled	bewusst aus
~~papierkram~~	entfernt 2026-05-17	nur via mcp-vf-hosted fuer VF-Kunden
~~ticketpay~~	entfernt 2026-05-17	nur via mcp-vf-hosted fuer VF-Kunden

Real-Call verifiziert: opencode run "Liste 3 Hetzner-Server" → hetzner_list_servers wurde aufgerufen, echte API-Response: “av-tools-stirling-01 (running, cx23, Ubuntu 24.04)“. End-to-End-Pfad opencode → Bedrock → MCP → API funktioniert.

Files:

Modified: ~/.config/opencode/opencode.json (mcp block ergaenzt um 14 Eintraege)
Issues: siehe intern/projekte/opencode-migration/issues.md (I-004, I-005)

Goal: Alle aktiven MCPs (gsuite, m365, papierkram, ticketpay, runway, replicate, calcom, whatsapp, elevenlabs, hetzner, aws-docs/api/iac/pricing, cloudflare) sind in opencode konfiguriert und funktional getestet.

Requirements: R4

Dependencies: Unit 0.1

Files:

Modify: ~/.config/opencode/opencode.json (mcp-Sektion ergaenzen)
Modify: intern/capabilities/mcps/_index.md (Status-Spalte ergaenzen um „opencode active”)
Test: pro MCP einen Smoke-Test-Call dokumentiert

Approach:

Pro MCP Eintrag in opencode.json unter mcp Block. Format: {"type": "local" oder "remote", "command": "..." oder "url": "..."}.
Stdio-MCPs (gsuite, elevenlabs, hetzner, aws-*, cloudflare): type: local mit command Array.
HTTP-MCPs (m365, papierkram, ticketpay, runway, replicate, calcom): type: remote mit url.
whatsapp hosted: type: remote mit https://mcp-whatsapp.agenticventures.de/mcp + Auth-Header.
Migration von CC-Format .claude/mcp.json als Referenz lesen, in opencode-Format uebersetzen.

Patterns to follow:

Endpoint-Liste aus intern/capabilities/mcps/_index.md
Auth-Pattern pro MCP wie in jedem intern/capabilities/mcps/<mcp>.md dokumentiert

Test scenarios:

Happy path: papierkram_get_info liefert Account-Info, gsuite_query_gmail_emails mit from:me to:me liefert Inbox-Emails
Edge case: HTTP-MCP nicht erreichbar (m365 wenn lokaler Container down) — opencode markiert MCP als unavailable, andere laufen weiter
Error path: Auth-Token abgelaufen (z.B. gsuite OAuth-Refresh) — klare Fehlermeldung, kein Crash
Integration: aus opencode-Session mit coding-Agent: nur Coding-MCPs verfuegbar; mit business-Agent (Phase 0.4): nur Business-MCPs

Verification:

/mcp listet alle 11+ MCPs als „connected”
Smoke-Test pro MCP: ein *_get_* oder *_list_* Call erfolgreich

Unit 0.4: Custom Agents coding und business definieren ✓ 2026-05-17 (mit Caveat I-006)

Goal: Zwei Custom Agents in opencode mit unterschiedlichem Tool-Scope. coding ist Default, business wird via @business aufgerufen.

Requirements: R4, KTD-5

Dependencies: Unit 0.3

Files:

Create: ~/.config/opencode/agent/coding.md
Create: ~/.config/opencode/agent/business.md
Modify: ~/.config/opencode/opencode.json (default agent setzen)

Approach:

coding.md Frontmatter:
- description: Default coding agent — Build/Plan, alle Coding-MCPs
- model: anthropic/claude-sonnet-4-6
- tools: ["bash", "edit", "read", "write", "hetzner*", "aws-*", "cloudflare*", "replicate*", "elevenlabs*", "aws-docs*"]
- Body: Pointer auf AGENTS.md + Vault-Wiki, kein dupliziertes Wissen
business.md Frontmatter:
- description: Business/Admin agent — Email, Termine, Buchhaltung
- tools: ["read", "gsuite*", "sharepoint*", "papierkram*", "ticketpay*", "calcom*", "whatsapp*"]
- bash und edit BEWUSST raus — keine Code-Mutation aus Business-Context.
- Body: Pointer auf relevante Skills (email-schreiben, termin-koordinieren, inbox-sync)

Patterns to follow:

opencode-Agent-Doku https://opencode.ai/docs/agents/
Tool-Glob-Pattern aus opencode-MCP-Doku

Test scenarios:

Happy path: @coding plane einen neuen MCP — Agent hat hetzner/aws Tools, kein gsuite
Happy path: @business sende Mail an X — Agent hat gsuite, kein hetzner
Edge case: @business edit code — opencode blockiert (edit-Tool nicht im Scope)
Integration: Wechsel mitten in Session zwischen Agents via @<agent>

Verification:

/agents listet beide
Tool-Gating greift (verifizieren mit absichtlich falschem Aufruf)

Unit 0.5: Hybrid-Modus dokumentieren und Rollback-Plan anlegen ✓ 2026-05-17

Goal: Klare Doku wie CC und opencode parallel laufen ohne Konflikte. Rollback-Plan fuer den Fall dass Migration nicht klappt.

Requirements: R8, R10

Dependencies: Unit 0.1, 0.2

Files:

Create: intern/projekte/opencode-migration/hybrid-betrieb.md
Create: intern/projekte/opencode-migration/rollback.md
Modify: _index.md (Status auf „phase-0-active”)

Approach:

hybrid-betrieb.md: welches Tool wann nutzen waehrend Migration (CC fuer noch-nicht-migrierte Skills, opencode fuer alles andere), Konflikt-Punkte (beide schreiben in Vault — git als Source of Truth, kein Auto-Sync), Token-Budget-Trennung
rollback.md: Wenn Phase X scheitert: (1) opencode-Config aus PATH, (2) ~/.opencode/bin/-Backup wiederherstellen via brew uninstall opencode, (3) altes Pro-Abo reaktivieren falls gekuendigt, (4) was im Vault unveraendert bleibt
Backup des aktuellen ~/.claude/settings.json und ~/.claude/projects/.../memory/ als Tarball in ~/Backups/cc-pre-migration-2026-05-17.tar.gz

Test scenarios:

Test expectation: none — reine Doku/Operational-Unit

Verification:

Rollback-Plan-Doku reviewed (Stichprobe: koennte ein anderer Entwickler die Rolle uebernehmen mit diesen Files?)
Backup-Tarball existiert, ist > 0 Byte, ist git-ignored aber ~/Backups/-Eintrag in intern/firma/marvin-machine-state.md dokumentiert

Phase 0 Abnahme-Kriterien:

opencode startet im Vault-Dir, laedt AGENTS.md, hat 3 Provider und 11 MCPs verfuegbar
coding + business Agents funktional, Tool-Gating greift
Hybrid-Doku + Rollback-Plan existieren
CC laeuft parallel unveraendert weiter — kein „kill switch” gedrueckt

Phase 1 — Taegliche Skills (Woche 2, ~16h)

Migration der Skills mit hoechster Nutzungs-Frequenz. Nach Phase 1 koennte Marvin theoretisch schon ~70% des Alltags in opencode verbringen.

Unit 1.1: /wiki-maintenance Custom Command ✓ 2026-05-17

Files erstellt: ~/.config/opencode/commands/wiki-maintenance.md

Pattern: Duenner Wrapper der SKILL.md im Vault als Source of Truth laedt. Frontmatter mit agent: coding (braucht edit/write). Argument-Passthrough via $ARGUMENTS (z.B. „nur tbd”, „nur inbox”, „autonomous”).

Live-Test gruen: /wiki-maintenance nur tbd lief, fand TBD-Marker, gruppierte in 10 Cluster, schlug 2 direkt-fixbare Auto-Resolutions vor. Output-Qualitaet vergleichbar mit CC-Version.

Goal: wiki-maintenance-Skill als opencode Custom Command verfuegbar. Funktional aequivalent zur CC-Version (Inbox-Sortierung, Drift-Check, Frontmatter-Audit).

Requirements: R2

Dependencies: Phase 0 komplett

Files:

Create: ~/.config/opencode/commands/wiki-maintenance.md (Slash-Command-Definition)
Read for migration: intern/capabilities/skills/wiki-maintenance/SKILL.md
Modify: intern/capabilities/skills/wiki-maintenance/SKILL.md (Frontmatter status: opencode-migrated)
Test: manuelle Stichprobe — neuer Inbox-File einsortieren

Approach:

Custom-Command-File: Frontmatter mit description, agent: coding (wegen Edit-Tool noetig). Body = bestehender SKILL.md-Body, leicht umformuliert weg von „Du bist Claude” hin zu generischem „Du bist ein Skill der…“.
Drift-Check-Logik (Pass 2 — broken Wikilinks finden) ist Grep-basiert, laesst sich 1:1 uebernehmen.
Output: gleiches Format wie heute, damit Vault-Konsumenten (Marvin selbst, andere Skills) keinen Unterschied merken.

Patterns to follow:

Existierendes intern/capabilities/skills/wiki-maintenance/SKILL.md
opencode-Custom-Command-Doku

Test scenarios:

Happy path: /wiki-maintenance triggert, Inbox wird gescannt, klare Faelle batch-einsortiert (zeigt Diff-Vorschlag), unklare gehen ins Review
Edge case: Inbox leer — Skill meldet sauber „nichts zu tun”, kein Crash
Error path: Frontmatter eines Files kaputt — Skill meldet konkret welches File, schlaegt Fix vor statt zu crashen
Integration: /wiki-maintenance ruft intern Grep/Read/Edit-Tools korrekt auf, AGENTS.md-Rules werden respektiert (z.B. Rule 19 Pfad-Erwaehnungen)

Verification:

3 echte Inbox-Files erfolgreich einsortiert via opencode
Performance vergleichbar mit CC-Version (kein 10× langsamer)

Unit 1.2: /inbox-sync Custom Command ✓ 2026-05-17

Files erstellt: ~/.config/opencode/commands/inbox-sync.md

Pattern: Wrapper mit agent: business (gsuite-MCP-Scope). Lädt SKILL.md + Conventions, queryt beide Gmail-Accounts auf from:me to:me, schreibt inbox/<datum>-<slug>.md pro Mail, raeumt Gmail-Labels auf. Chain auf /wiki-maintenance nur inbox wenn Marvin „abarbeiten” sagt.

Pre-Test: 1 ungelesene Self-Mail im hello@-Account wartet — kann ad-hoc live getestet werden.

Goal: inbox-sync-Skill als opencode Custom Command. Zieht Emails von Marvin-an-Marvin via gsuite-MCP, schreibt nach inbox/.

Requirements: R2

Dependencies: Phase 0, gsuite-MCP funktional im business-Agent

Files:

Create: ~/.config/opencode/commands/inbox-sync.md
Read for migration: intern/capabilities/skills/inbox-sync/SKILL.md
Modify: intern/capabilities/skills/inbox-sync/SKILL.md (status-Update)

Approach:

Frontmatter agent: business (braucht gsuite-Tools, kein edit-Tool noetig — Files schreibt der Skill ueber write/bash).
HMMM — business-Agent hat aktuell kein write. Korrigieren: business-Agent bekommt write-Tool fuer Inbox-Files. Skills die schreiben muessen brauchen das. Sub-Decision: business-Agent erlaubt write nur in inbox/-Pattern via Per-Tool-Glob falls opencode das supportet, sonst muss Marvin akzeptieren dass business auch schreiben kann.
Logic 1:1 portieren — Gmail-Query, pro Email ein Markdown-File, Label setzen, archivieren.

Patterns to follow:

Existierendes intern/capabilities/skills/inbox-sync/SKILL.md
gsuite-Tool-Calls wie in CC genutzt

Test scenarios:

Happy path: 5 Test-Mails in Marvins Inbox, /inbox-sync zieht sie, schreibt 5 .md-Files, archiviert die Mails
Edge case: Mail mit Anhang — Anhang wird in inbox/<datum>-attachments/ gespeichert
Error path: gsuite-Token abgelaufen — sauberer Fehler, keine halb-importierten States
Integration: Skill ruft danach optional /wiki-maintenance zur Sortierung (wie heutiger Chain in CC)

Verification:

Smoke-Test mit echtem Konto erfolgreich
Output-Format identisch zu CC-Version (gleicher Frontmatter, gleiche Filename-Konvention)

Unit 1.3: /email und /email-review Custom Commands ✓ 2026-05-17

Files erstellt:

~/.config/opencode/commands/email.md (agent: business)
~/.config/opencode/commands/email-review.md (agent: business)

Pattern: Wrapper laedt SKILL.md + style-profile-marvin.md + email-footer.md + ggf. Kunden-/Lead-File. Frontmatter agent: business. Strikte Anti-Pattern explicit: NIE senden ohne OK, NIE Em-Dash/Doppelpunkt, Rule-22-Check fuer Kunden-Namen. Argument-Passthrough fuer Mail-Brief.

/email-review: 10-Punkt-Check als Tabelle vor Send-Verdict. Send-Ready nur wenn alle 10 gruen.

Goal: Email-Draft-Skill und Email-Review-Skill als Custom Commands. Beide nutzen gsuite-MCP + Stil-Profil aus Vault.

Requirements: R2

Dependencies: Phase 0, gsuite + business-Agent

Files:

Create: ~/.config/opencode/commands/email.md
Create: ~/.config/opencode/commands/email-review.md
Read for migration: intern/capabilities/skills/email-schreiben/SKILL.md, intern/capabilities/skills/email-review/SKILL.md
Read for migration: intern/capabilities/skills/email-schreiben/style-profile-marvin.md

Approach:

/email: Frontmatter agent: business, Body = SKILL.md-Body. Stil-Profil wird via @import in Custom-Command geladen oder per Read im Skill-Body.
/email-review: gleich, aber zusaetzlich Anhang-Check + 10-Punkt-Liste vor Send.
Beide Skills muessen die CLAUDE.md Rule 22 (Kunden-Namen-Regel) zwingend befolgen — explizit im Skill-Body referenzieren.

Patterns to follow:

Bestehende SKILL.md von email-schreiben + email-review
Stil-Profil-File

Test scenarios:

Happy path: /email schreib Mail an X dass Y — Draft im richtigen Gmail-Account, Stil korrekt, kein Em-Dash, korrekte Anrede
Edge case: Kunde existiert nicht im Vault — Skill fragt nach oder Schluss-Block bewusst leer
Error path: gsuite-Send-Permissions fehlt — sauberer Fehler statt halb-fertigem Draft
Integration: /email-review kann auf von /email erstellten Draft zugreifen via Draft-ID

Verification:

Drei echte Email-Drafts erstellt (verschiedene Empfaenger), Stil passt
Review-Skill flaggt absichtlich eingebauten Em-Dash + falsche Anrede

Phase 1 Abnahme-Kriterien:

/wiki-maintenance, /inbox-sync, /email, /email-review produktiv nutzbar
Marvin nutzt diese Skills 5 Werktage in Folge aus opencode statt CC
Keine Regressions (Output-Format, Vault-Hygiene gleich)

Phase 2 — Weekly Skills (Woche 3, ~14h)

Unit 2.1: /tagesplan und /wochenplan Custom Commands ✓ 2026-05-17

Goal: Beide Planungs-Skills als Custom Commands. Lesen Vault-Config + Kalender via gsuite, schlagen Plan vor, legen nach Bestaetigung Events an.

Requirements: R2

Dependencies: Phase 0, gsuite (calendar), business-Agent

Files:

Create: ~/.config/opencode/commands/tagesplan.md
Create: ~/.config/opencode/commands/wochenplan.md
Read for migration: intern/capabilities/skills/tages-planung/SKILL.md, intern/capabilities/skills/wochen-planung/plan.md
Read for migration: intern/_meta/config-planning.md (Arbeitszeit, Themen-Tage)

Approach:

Beide laufen primaer im business-Agent (Kalender-Zugriff). Brauchen write fuer Plan-Files in operations/day-plans/ bzw operations/week-plans/.
CLAUDE.md Rule 10 (morgens NICHT triggern) muss explizit im Skill-Body stehen — opencode hat keinen Auto-Time-Trigger.

Test scenarios:

Happy path: /tagesplan abends — Plan-Vorschlag erscheint, nach OK Events angelegt
Edge case: morgen ist Wochenende — Skill schlaegt Pause vor oder Hobby-Block
Error path: Kalender-API down — fragt nach manueller Eingabe
Integration: nach Plan-Erstellung wird operations/day-plans/2026-MM-DD.md geschrieben

Verification:

Eine echte Abend-Planung durchgefuehrt, Plan im Vault, Events angelegt

Unit 2.2: /termin Custom Command ✓ 2026-05-17

Goal: Termin-Koordinations-Skill — Slot-Finden, Reply-Drafts, Event-Anlage.

Requirements: R2

Dependencies: Phase 0, gsuite (calendar + mail), business-Agent

Files:

Create: ~/.config/opencode/commands/termin.md
Read for migration: intern/capabilities/skills/termin-koordinieren/SKILL.md

Approach: Standard-Custom-Command-Port. Wichtig: Rule 14 (nie Einladungen ohne Marvins OK senden) muss explizit drin sein.

Test scenarios:

Happy path: „Kunde X will Termin Dienstag” — Skill schlaegt 3 Slots vor, drafted Reply, fragt nach OK, traegt nach Bestaetigung ein
Edge case: keine freien Slots — Skill schlaegt Verschiebung anderer Termine vor
Error path: Konflikt waehrend Anlage — Rollback der Buchung
Integration: Reply-Draft im richtigen Gmail-Account

Verification: Echter Kundentermin koordiniert via opencode.

Unit 2.3: /image-gen Custom Command ✓ 2026-05-17 (Hinweis: replicate-MCP nicht in opencode konfiguriert — Fallback curl-Pfad im Wrapper dokumentiert)

Goal: Image-Gen-Skill via Replicate-MCP.

Requirements: R2

Dependencies: Phase 0, replicate-MCP im coding-Agent

Files:

Create: ~/.config/opencode/commands/image-gen.md
Read for migration: intern/capabilities/skills/image-gen/SKILL.md

Approach: Standard-Port. Brand-Lock-Logik (#F5F4ED + 2D4A3E) und Anti-AI-Slop-Filter bleiben.

Test scenarios:

Happy path: „/image-gen Hero-Background fuer Landing” — Modell-Auswahl korrekt, Bild + Metadaten-File generiert
Edge case: Replicate-Quota voll — sauberer Fehler
Error path: Prompt enthaelt verbotene Begriffe (slop-Trigger) — Skill filtert vor Send

Verification: Ein Bild generiert, Brand-Lock greift.

Unit 2.4: /transkript, /routine-anlegen Custom Commands ✓ 2026-05-17

Goal: Transkript-Erstellen und Routine-Anlegen als Custom Commands.

Requirements: R2

Dependencies: Phase 0, coding-Agent

Files:

Create: ~/.config/opencode/commands/transkript.md
Create: ~/.config/opencode/commands/routine-anlegen.md
Read for migration: existierende SKILL.md beider

Approach:

/transkript: ruft youtube/scripts/transcribe.py (existiert). Standard-Port.
/routine-anlegen: komplex — 6-Fragen-Brief, Code-Gen, CDK-Stack, Deploy. Hier evtl. Sub-Agent definieren (routine-anlegen-agent.md) fuer multi-step-Logik mit eigenem Modell-Choice (Opus fuer Plan-Step).

Test scenarios:

/transkript: ein Test-Video → 3 Output-Files
/routine-anlegen: neue Test-Routine in agents-platform, deployed in av-production Sub-Account, Smoke-Test gruen

Verification: Beide Skills produzieren funktional gleiches Ergebnis wie CC-Versionen.

Phase 2 Abnahme-Kriterien:

Alle Weekly-Skills migriert, mindestens 1× in Produktion genutzt
Keine offenen Migrations-Issues fuer diese Skills

Phase 3 — Coding-Pipeline-Ersatz (Woche 4, ~22h)

DAS ist der riskanteste Block — compound-engineering ersetzt durch Eigenbau.

Unit 3.1: /plan Custom Command + Sub-Agents fuer Research

Goal: Funktional aequivalent zu ce:plan. Custom Command der einen Plan-Workflow ausfuehrt mit Sub-Agents fuer Research.

Requirements: R3

Dependencies: Phase 0-2 (Pattern bekannt)

Files:

Create: ~/.config/opencode/commands/plan.md
Create: ~/.config/opencode/agent/research-repo.md (Sub-Agent fuer Repo-Research)
Create: ~/.config/opencode/agent/research-external.md (Sub-Agent fuer externe Doku via WebFetch)

Approach:

Hauptbody analog zu compound-engineering/ce-plan/SKILL.md — Phasen 0-5 — aber drastisch verkuerzt.
Statt 8+ Sub-Agents (repo-research-analyst, learnings-researcher, best-practices, framework-docs, spec-flow, architecture-strategist, pattern-recognition, performance-oracle etc.) nur ZWEI Sub-Agents: research-repo + research-external.
Plan-Output landet weiter in intern/projekte/<slug>/plan.md (Vault-Konvention) oder docs/plans/ falls Code-Repo, NICHT in beidem.
Plan-Template uebernehmen aus compound-engineering, leicht angepasst.

Test scenarios:

Happy path: /plan baue Feature X im Repo Y — Plan-File mit Implementation Units, Verification, Risks entsteht
Edge case: ueber Vault planen (kein Code-Repo) — File landet unter intern/projekte/
Error path: Sub-Agent crasht — Hauptcommand schlaegt Recovery-Pfad vor (Phase nochmal)
Integration: Plan kann von /work direkt geladen werden

Verification: Echter Plan fuer einen kleinen Feature-Build durchgefuehrt, Output qualitativ gleichwertig zu ce:plan-Output.

Unit 3.2: /work Custom Command

Goal: Ersetzt ce:work. Implementiert Plan-Units sequentiell mit Test-First-Default.

Requirements: R3

Dependencies: Unit 3.1

Files:

Create: ~/.config/opencode/commands/work.md

Approach:

Liest Plan-File, geht Units durch, fuer jeden: Read existing → make changes → run tests → mark checkbox.
Nutzt opencode-Build-Mode (default). Plan-Mode (Tab) fuer Read-only-Steps.
Wichtig: opencode /undo einsetzen wenn Step schief geht, statt manuelles git-revert.

Test scenarios:

Happy path: Plan mit 5 Units → alle abgehakt, Tests gruen
Edge case: Unit schlaegt fehl → klare Frage an Marvin, kein Auto-Skip
Error path: Tests fail → /undo und Re-Plan vorschlagen
Integration: Nutzt /review als optionalen letzten Schritt vor /commit-pr

Verification: Ein Plan komplett durchimplementiert.

Unit 3.3: /review Custom Command + Review-Sub-Agents

Goal: Ersetzt ce:review. Multi-Persona-Review wie compound-engineering — aber reduziert auf 3 Standard-Personas plus konditionale.

Requirements: R3

Dependencies: Unit 3.1, 3.2

Files:

Create: ~/.config/opencode/commands/review.md
Create: ~/.config/opencode/agent/reviewer-correctness.md
Create: ~/.config/opencode/agent/reviewer-maintainability.md
Create: ~/.config/opencode/agent/reviewer-security.md (konditional, nur bei security-relevanten Diffs)

Approach:

Always-on: correctness + maintainability
Konditional: security (bei Auth/Crypto/Secrets), performance (bei Queries/Loops), data-integrity (bei Migrations)
Reduziert auf 3-5 Personas total, nicht ce:review’s ~15
Output-Format wie compound-engineering: Findings, Confidence, Auto-Fix-Pfad

Test scenarios: Diff mit absichtlich eingebauten Bugs → Reviewer findet sie. Diff ohne Bugs → kein false positive.

Verification: Auf einen echten Branch angewendet, sinnvolle Findings produziert.

Unit 3.4: /brainstorm, /commit-pr, /compound Custom Commands

Goal: Restliche 3 Core-Skills der Pipeline.

Requirements: R3

Dependencies: Unit 3.1-3.3

Files:

Create: ~/.config/opencode/commands/brainstorm.md
Create: ~/.config/opencode/commands/commit-pr.md
Create: ~/.config/opencode/commands/compound.md

Approach:

/brainstorm: dialogisch, Requirements-Doc als Output unter intern/runs/<datum>-brainstorm-<topic>/
/commit-pr: git status + git diff + commit-message-gen + push + PR-create via gh. Hooks-Aware (Husky etc.). Nutzt CLAUDE.md/AGENTS.md Git-Safety-Rules.
/compound: nimmt eine recently-solved Problem-Beschreibung, schreibt nach intern/wissen/prozesse/<topic>.md mit Frontmatter — Anti-Drift-Pattern.

Test scenarios:

/brainstorm: ein vagues Feature → Requirements-Doc
/commit-pr: ein Branch mit Diff → Commit + Push + PR
/compound: ein Lesson-Learned → Vault-File mit Frontmatter

Verification: Alle 3 ein Real-Use durchgemacht.

Unit 3.5: Restliche eigene Skills migrieren — /mcp-eigenbau, /mcp-cloud, /security-audit, /qa-staging

Goal: Die 4 verbliebenen eigenen Skills aus _index.md migrieren.

Requirements: R2

Dependencies: Phase 0-2

Files:

Create: ~/.config/opencode/commands/mcp-eigenbau.md
Create: ~/.config/opencode/commands/mcp-cloud.md
Create: ~/.config/opencode/commands/security-audit.md
Create: ~/.config/opencode/commands/qa-staging.md

Approach:

Alle 4 sind komplexe Multi-Step-Skills. Bekommen jeweils einen dedizierten Sub-Agent fuer die Ausfuehrung (analog Unit 3.1 Pattern).
/security-audit braucht eigenen Sub-Agent security-auditor.md mit kompletter 13-Phasen-Logik.
/qa-staging nutzt webapp-testing (Playwright) — sicherstellen dass das Plugin in opencode verfuegbar ist (es ist Anthropic-Skill, sollte portabel sein) ODER chrome-devtools-mcp als Alternative.

Test scenarios: Pro Skill ein realer Use-Case.

Verification: Alle 14 eigenen Skills sind in ~/.config/opencode/commands/ und in echtem Use bestanden.

Phase 3 Abnahme-Kriterien:

Alle 14 eigenen Skills + 6 Compound-Engineering-Ersatz-Skills laufen in opencode
Eine komplette Feature-Pipeline (brainstorm → plan → work → review → commit-pr) erfolgreich durchgespielt
Marvin nutzt nur noch opencode fuer Coding-Tasks (CC nur noch als Fallback fuer Notfaelle)
2 Wochen Parallel-Lauf ohne Show-Stopper

Phase 4 — Cutover + Cleanup (Woche 5, ~8h)

Unit 4.1: Memory-Files ins Vault konsolidieren ✓ 2026-05-17

3 neue Vault-Files erstellt:

intern/firma/marvin-profile.md (Persona: Rolle, ADHS, Schreibstil, Aesthetik aus user_profile + user_adhd)
intern/wissen/prozesse/marvin-arbeitsweise-patterns.md (Konsolidierte 10 Feedback-Patterns: AWS-First, Nicht-selber-bauen, No-Auto-Close, Schreibstil, Workshop-statt-Formular, Kalender-Regeln × 3, Kanban, Daily-Planning)
intern/firma/marvin-projekt-context.md (Snapshot: Kernziel + Voit/HeyJulia + Foerder-Status + Geografie + MCP-Vision + AWS-Quick-Ref + Email-Setup + Kunden-Pipeline-Snapshot aus 6 project_.md + 2 reference_.md)

Loading-Strategie:

CC-Pfad: @import in CLAUDE.md (war so, bleibt so)
opencode-Pfad: instructions-Block in opencode.json mit 6 Vault-Pfaden (@import-Syntax wird von opencode nicht unterstuetzt)

Live-Test gruen: Stichprobe-Fragen ohne Tool-Call beantwortbar (Telefonnummer, AWS-Account-ID 425924867359, Hauptprodukt Voit). Persona + Projekt-Kontext werden vor jeder Session vorgeladen.

CC-Memory bleibt unangetastet bis Cutover:

22 Files im CC-Pfad ~/.claude/projects/.../memory/ bleiben fuer Hybrid-Phase
Backup-Tarball seit Phase 0 Unit 0.5: ~/Backups/cc-pre-migration-2026-05-17.tar.gz
Loeschung erst nach Cutover-Tag

Goal: Alle 22 Memory-Files in ~/.claude/projects/.../memory/ sind ins Vault uebersetzt. CC-Memory-Ordner kann geloescht werden.

Requirements: R6

Dependencies: Phase 0-3 abgenommen

Files:

Create: intern/firma/marvin-profile.md (aus user_profile.md + user_adhd.md)
Create: intern/wissen/prozesse/marvin-arbeitsweise-patterns.md (aus allen feedback_*.md konsolidiert)
Modify: existierende intern/projekte/<slug>/_index.md Files (Projekt-Memory einfliessen lassen)
Modify: CLAUDE.md (neue Sektion @import intern/firma/marvin-profile.md + @import intern/wissen/prozesse/marvin-arbeitsweise-patterns.md)
Archive: ~/.claude/projects/-Users-marvinkuehlmann-source-agentic-ventures/memory/ → ~/Backups/cc-memory-2026-06-XX.tar.gz

Approach:

Pro Memory-File: lesen, in Vault-Target uebersetzen, alte loeschen.
Pruefen dass @import-Mechanismus von opencode greift fuer alle neuen Files.

Test scenarios:

Happy path: opencode-Session — Modell zitiert „ADHS: kleine Schritte” korrekt aus Vault, nicht aus CC-Memory
Integration: alle Behavior-Rules + Memory-Patterns wirken in einer einzigen Session

Verification: CC-Memory-Ordner kann umbenannt werden ohne dass irgendwas in opencode bricht.

Unit 4.2: CC-Hooks portieren oder bewusst weglassen ✓ 2026-05-17 — Built-in statt Plugin

Entscheidung: opencode hat Built-in-TUI-Notifications + Sounds. Plugin-Hook (Ebene 4) explizit NICHT gemacht — auf Marvins Wunsch zurueckgestellt.

Files erstellt: ~/.config/opencode/tui.json mit attention.enabled: true, sound: true, volume: 0.4. Funktional aequivalent zu CC permission_prompt/idle_prompt Glass.aiff-Hooks.

Was bewusst NICHT portiert wird:

CC statusLine (handwerker-saas/tools/status_line.sh) — opencode hat eigene Status-Anzeige, kein 1:1-Mapping noetig
CC voiceEnabled — opencode-Equivalent unklar, ggf. spaeter wenn vermisst
CC skipDangerousModePermissionPrompt — opencode hat eigenes Permission-Modell (siehe permission-Block in opencode.json)

Goal: Entscheiden was mit Glass.aiff-Notification-Hooks passiert. Entweder als opencode-Plugin portieren oder bewusst aufgeben.

Requirements: R1

Dependencies: Phase 0-3

Files:

Optional Create: ~/.config/opencode/plugin/notification-sound/ (JS-Plugin)
Modify: intern/projekte/opencode-migration/_index.md (Entscheidungs-Doku)

Approach:

Wenn portieren: opencode-Plugin mit tool.execute.before-Hook fuer permission-Prompts → child_process.exec('afplay /System/.../Glass.aiff').
Wenn weglassen: Marvin akzeptiert dass opencode kein Sound bei Permission-Prompt macht — voiceEnabled: true ist in opencode separat.

Test scenarios: Mit/ohne Plugin testen, Marvin entscheidet welche Variante bleibt.

Verification: Entscheidung dokumentiert, Implementation matchend.

Unit 4.3: Cutover — claude aus PATH entfernen

Goal: CC ist nicht mehr der Daily Driver. PATH-Eintrag entfernt oder claude zu claude-legacy umbenannt.

Requirements: R1

Dependencies: Phase 0-3 abgenommen + 2 Wochen Hybrid-Parallel-Lauf erfolgreich

Files:

Modify: ~/.zshrc (PATH-Eintrag entfernen oder kommentieren)
Modify: ~/.claude/settings.json (Plugins disabled: "compound-engineering@every-marketplace": false etc.)
Modify: intern/firma/stack.md (Status auf „CC deprecated, opencode primary”)
Modify: CLAUDE.md (Hinweis am Anfang: „Vault wird primaer von opencode genutzt, CC ist Fallback”)

Approach:

claude-Binary nicht loeschen — als claude-legacy umbenennen via alias in zshrc, fuer Notfall verfuegbar.
Nach 4 Wochen ohne Bedarf: komplett deinstallieren.

Test scenarios:

Happy path: which claude zeigt nichts oder claude-legacy, opencode ist da
Integration: 1 Tag arbeiten OHNE CC-Fallback — gibt es Aufgaben die nicht gehen?

Verification: Marvin arbeitet 5 Werktage ausschliesslich in opencode, kein Notfall-Fallback noetig.

Unit 4.4: Final-Doku-Update

Goal: Vault-Doku reflektiert neue Realitaet. Alle CC-Referenzen entweder geupdated oder als „historisch” markiert.

Requirements: R5

Dependencies: Unit 4.3

Files:

Modify: intern/firma/stack.md (opencode als primary, CC als legacy)
Modify: intern/capabilities/skills/_externe-skills.md (compound-engineering-Sektion: „nicht mehr verfuegbar, ersetzt durch Eigenbau in Unit 3.x”)
Modify: CLAUDE.md Rule 20 + Rule 21 — Skill-Routing-Pattern fuer opencode formuliert
Modify: intern/capabilities/skills/_index.md (Trigger-Beispiele um /<skill>-Syntax ergaenzt)
Modify: intern/projekte/opencode-migration/_index.md (Status: completed, Migration-Datum)

Approach:

Grep durch das Vault nach Claude Code, claude code, CC — pro Hit entscheiden ob updaten oder stehen lassen (historische Refs OK).
Migration-Doku abschliessen mit „Lessons Learned”-Block (was lief gut, was nicht).

Test scenarios: Doku-Spot-Check — neue Marvin-Session in 4 Wochen versteht Setup ohne Rueckfragen.

Verification: Vault ist Tool-konsistent, kein Mix von „opencode” und „CC” in aktiven Files.

Phase 4 Abnahme-Kriterien:

claude nicht mehr im PATH
Vault-Doku konsistent auf opencode
Memory komplett im Vault
5+ Werktage ausschliesslich opencode-Betrieb ohne Notfall-Fallback

System-Wide Impact

Interaction graph:
- Vault liest jetzt von zwei Quellen (CLAUDE.md direkt + AGENTS.md-Symlink). Beide zeigen aufs gleiche, kein Drift-Risiko.
- MCP-Server-Prozesse (lokal laufende Stdio/HTTP-MCPs) sind unveraendert — opencode connected zu denselben Endpoints. Kein neuer Port-Bedarf.
- agents-platform-Lambdas sind ausserhalb. Ihre Anthropic-API-Calls sind unabhaengig — bleiben bestehen bis Phase 4-Workstream (separat).
Error propagation:
- Provider-Ausfall: opencode hat Multi-Provider-Fallback, Marvin kann manuell wechseln. CC haette einfach gestreikt.
- Memory-Verlust waehrend Migration (zwischen Unit 4.1 und Vault-Konsolidierung abgeschlossen): Backup-Tarball mit allen 22 Files existiert (Unit 0.5).
- Skill-Aufruf-Fehler: opencode Custom Commands fallen auf Standard-Prompt zurueck wenn File fehlt. Klar erkennbar via TUI.
State lifecycle risks:
- Vault-Konflikte bei Hybrid-Betrieb: beide Tools koennten dasselbe File aendern. Mitigation: git-Status vor jedem Lauf, ein Tool zur Zeit pro File.
- Custom-Command-Cache: opencode laedt Commands beim Start. Bei Aenderung restart noetig — dokumentieren.
API surface parity:
- MCP-Protokoll ist Standard — eigene MCPs (papierkram, ticketpay, calcom, whatsapp, runway, replicate) funktionieren unveraendert. Pattern-Validierung: wenn ein MCP-Tool in CC funktioniert hat, funktioniert es in opencode (kein API-Layer dazwischen).
- Slash-Command-Syntax /command ist opencode-spezifisch, war in CC Skill-Tool-Call. Aenderung sichtbar fuer Marvin, nicht fuer Skills selbst.
Integration coverage:
- Pro Phase ein Real-Use als Abnahme-Kriterium (nicht nur Unit-Test).
- 2-Wochen-Hybrid-Phase ist die Integration-Test-Periode fuer alle Skills zusammen.
Unchanged invariants:
- Vault-Struktur, Frontmatter-Schemas, Wikilink-Format, alle 22 Behavior Rules (Inhalt unveraendert, nur Skill-Routing-Implementierung wandert).
- MCP-Server-Code, agents-platform-Lambdas, Hugo-Sites, externe Dienste.
- Kunden-Workflows (Becker, Friseur, BSS, VF) — Migration laeuft im Hintergrund, Kunden merken nichts.

Risks & Dependencies

Risk	Likelihood	Impact	Mitigation
compound-engineering-Eigenbau-Ersatz ist qualitativ schwaecher als Original (z.B. weniger Personas in /review, weniger Research-Tiefe in /plan)	High	Medium	Reduzierter Scope (KTD-4 — nur 6 statt 25 Skills). Iterativ verbessern wenn echter Schmerz auftritt. Compound-engineering bei Marvin-CC liest auch nicht alle Sub-Agents — Pareto.
Skill-Auto-Routing-Verlust (CC Rule 20) macht Marvin frustriert weil er Slash-Commands tippen muss	High	Medium	Phase 4 evaluieren: wenn Schmerz real, opencode-Plugin mit session.user-message-Hook bauen das Trigger-Phrases matcht und Slash-Command vorschlaegt. Workaround: `/help` zeigt verfuegbare Commands.
Provider-Kosten explodieren — opencode hat keinen Pro-Abo-Cap	Medium	High	Budget-Soft-Limit 130 USD/Monat. Wochen-Check der Provider-Bills in Phase 0+1. Bei Eskalation: Default auf billigere Modelle (Sonnet statt Opus, lokales Ollama fuer einfache Tasks).
Show-Stopper-Bug in opencode (RAM-Hunger, Crashes, Provider-Disconnect)	Medium	High	Hybrid-Modus bis Cutover. CC-Backup-Setup intakt fuer 4 Wochen nach Cutover. Rollback-Plan (Unit 0.5) dokumentiert.
Memory-Konsolidierung verliert wichtigen Kontext	Low	High	Per-File-Migration mit explizitem Review pro Memory-File. Backup-Tarball als Fallback. Sub-Agent „doc-coauthoring” fuer praezise Uebersetzung.
Custom-Commands-Trigger-Konflikt (z.B. `/work` ueberlappt mit eingebautem opencode-Command)	Low	Low	Vor Phase 3 Naming-Check via `/help`. Bei Konflikt umbenennen (z.B. `/cework`).
Zeitliche Ueberschneidung mit aktiven Kunden-Projekten (Becker Phase 2, Friseur Live-Cutover, VF DNS-Cutover)	High	Medium	Phase 3 ist die intensivste — wenn Kunden-Druck zu hoch, Phase 3 in 2 Sub-Wochen splitten. Wochenplan beruecksichtigen.
Voice-Mode + Remote-Trigger gehen verloren	Medium	Low	Marvin nutzt diese selten. Phase 4 Evaluation: nur portieren wenn vermisst.
`~/.opencode/`-Verzeichnis-Konflikt mit altem Plugin-Setup	Resolved	—	Bei Update-Schritt heute schon entfernt (altes Binary gel.). `~/.opencode/package.json` enthaelt nur @opencode-ai/plugin-SDK, kein Konflikt.
Anthropic-API-Rate-Limits bei Heavy-Build-Session in /work	Medium	Medium	Multi-Provider-Setup von Tag 1 (KTD-7). Bei Rate-Limit auto-fallback auf OpenRouter→Gemini oder Ollama.

Documentation Plan

Phase 0:
- intern/projekte/opencode-migration/hybrid-betrieb.md — wie parallel
- intern/projekte/opencode-migration/rollback.md — wie zurueck
- intern/firma/secrets-inventar-opencode.md — welche Keys wo
Phase 1-3:
- Pro Skill: SKILL.md-Frontmatter ergaenzen um opencode_command_path
- intern/capabilities/skills/_index.md Trigger-Tabelle um Slash-Syntax erweitern
Phase 4:
- intern/firma/stack.md — opencode als primary, CC legacy
- intern/capabilities/skills/_externe-skills.md — compound-engineering-Sektion umschreiben
- CLAUDE.md — Rule 20+21 fuer opencode neu formuliert
- intern/projekte/opencode-migration/lessons-learned.md — Retrospektive

Operational / Rollout Notes

Wochen-Cadence: Pro Phase 1 Woche. Werktags. Wenn Kunden-Druck (Becker-Termin, VF-Cutover-Bug, etc.) hochfaehrt — Phase pausieren, nicht parallelisieren.
Daily-Checkin: Marvin nutzt opencode taeglich ab Phase 1. Frustpunkte sofort in intern/projekte/opencode-migration/issues.md (anlegen wenn noetig) festhalten — am Phasen-Ende loesen, nicht inline.
Hard-Stop bei Crisis: Wenn ein Kunde-Live-Issue waehrend Migration auftritt — Migration pausieren, mit CC fixen wenn schneller, opencode-Migration warten lassen.
Cutover-Datum: 2026-06-21 ist Ziel, aber flexibel ±1 Woche je nach Phase-3-Verlauf. Hartes Maximum: 2026-07-05 (danach wird die Migration selbst zum Stress-Faktor, nicht der Schmerz).
Kosten-Monitoring: Wochentlich Bills checken (Anthropic + OpenRouter Dashboard). In intern/finanzen/cloud-snapshots/2026-XX-opencode.md festhalten.
Voice-Mode + Hooks: Tier 2 — nur wenn vermisst, Phase 4 entscheiden.

Sources & References

Aktuelles Setup:
- CLAUDE.md — 22 Behavior Rules, Routing-Tabellen
- Skills-Index — 14 eigene Skills
- Externe-Skills-Map — compound-engineering-Pipeline
- MCP-Index — 11 aktive MCPs
- Firma-Stack — Plugin-Inventar
opencode Docs (alle eingelesen 2026-05-17):
- https://opencode.ai/docs/ — Overview
- https://opencode.ai/docs/providers/ — Multi-Provider-Setup
- https://opencode.ai/docs/rules/ — AGENTS.md
- https://opencode.ai/docs/mcp-servers/ — MCP-Config
- https://opencode.ai/docs/commands/ — Custom Commands
- https://opencode.ai/docs/agents/ — Custom Agents
- https://opencode.ai/docs/plugins/ — JS/TS-Plugins
- https://opencode.ai/docs/server/ — Headless-API
- https://opencode.ai/docs/share/ — Privacy/Share-Modi
Switcher-Erfahrungen:
Folge-Workstream (separat): agents-platform-Lambdas auf opencode serve-Backend — wird in separatem Plan adressiert nach Cutover.

Cutover-Checkliste (Decision Document)

Cutover-Tag (geplant 2026-06-21) wird gemacht wenn ALLE der folgenden gruen sind:

Phase 0 abgenommen (Foundation, MCPs, Provider, Agents)
Phase 1 abgenommen (Taegliche Skills produktiv)
Phase 2 abgenommen (Weekly Skills produktiv)
Phase 3 abgenommen (Coding-Pipeline-Ersatz produktiv, eine komplette Feature-Pipeline gelaufen)
2 Wochen Parallel-Lauf ohne Show-Stopper
Rollback-Plan dokumentiert und mental durchgespielt
Kosten-Baseline OK (≤130 USD/Monat Trend)
Kein laufendes Kunden-Crisis-Issue
Marvin emotional bereit (nicht „ich will jetzt aber” — sondern „macht Sinn auch wenn anstrengend war”)

Wenn nicht alle gruen sind: Cutover verschieben, blockierende Punkte adressieren, neuer Ziel-Tag.

Agentic Ventures Wiki

Explorer

Vollmigration Claude Code → opencode

Vollmigration Claude Code → opencode

Overview

Problem Frame

Requirements Trace

Scope Boundaries

Context & Research

Relevante Vault-Files

opencode-Architektur-Eckdaten

Institutional Learnings

Externe Quellen

Key Technical Decisions

KTD-1: Skill-Implementierung via Custom Commands + Sub-Agents, nicht Plugins

KTD-2: AGENTS.md bleibt im Vault, ergaenzt um opencode-spezifische Sektion

KTD-3: Memory-Files ins Vault konsolidieren statt opencode-Memory-Pattern

KTD-4: Compound-Engineering-Pipeline reduziert nachbauen — nur tatsaechlich genutzte Skills

KTD-5: MCP-Per-Agent-Gating ausnutzen — getrennte Agents fuer Business-Tasks vs Coding

KTD-6: Cutover-Punkt = Datum + Abnahme-Kriterien, nicht „wenn ich Lust habe”

KTD-7: Provider-Setup — AWS Bedrock EU als Primary, Ollama als optionale Privacy-Spur

Open Questions

Resolved During Planning

Deferred to Implementation

High-Level Technical Design

Zielzustand nach Cutover

Migrations-Phasen-Abhaengigkeiten

Implementation Units

Phase 0 — opencode-Foundation (Woche 1, ~10h)

Phase 1 — Taegliche Skills (Woche 2, ~16h)

Phase 2 — Weekly Skills (Woche 3, ~14h)

Phase 3 — Coding-Pipeline-Ersatz (Woche 4, ~22h)

Phase 4 — Cutover + Cleanup (Woche 5, ~8h)

System-Wide Impact

Risks & Dependencies

Documentation Plan

Operational / Rollout Notes

Sources & References

Cutover-Checkliste (Decision Document)

Graphansicht

Inhaltsverzeichnis