_context

Kontext: intern/capabilities/

Zweck

Hier liegt alles was der Zwilling tun kann. Trennung zu wissen/ (passives Nachschlagewerk) und runs/ (vergangenes Tun, append-only).

Drei Unterbereiche:

• skills/ — ausfuehrbare Workflows (Markdown + ggf. Code), pro Skill ein Ordner mit SKILL.md
• mcps/ — externe Werkzeuge ueber MCP-Protokoll, pro Server eine .md-Datei
• repos/ — eigene Code-Tools (eigene MCP-Forks, Renderer, Generatoren) als Pointer auf den echten Source

Was gehoert hier rein / NICHT rein

Hier rein:

• Skill-Ordner mit SKILL.md und Hilfsdateien
• MCP-Server-Beschreibungen (Status, Auth, Endpoint, used-by-skills)
• Code-Repo-Pointer (Pfad, Language, Entrypoint, Inputs/Outputs)
• _index.md als Dashboard pro Unterbereich
• [[mcps/_index]] wird via @import direkt in CLAUDE.md geladen

NICHT hier rein:

• Echter Source-Code (lebt in ~/source/mcps/<name>/ oder eigenen Repos) — hier nur Pointer
• API-Tokens, OAuth-Secrets — gehoeren in .env.local der jeweiligen Tool-Instanz, niemals ins Repo
• Setup-Anleitungen fuer Tools die wir nur passiv nutzen (kein MCP) → intern/firma/stack.md
• Recherche-Reports → intern/runs/

Fuer Agents

• Bevor du sagst „Tool X kann Y nicht”: pruefe repos/_index.md. Wir forken oft (gsuite, sevdesk, lexware, m365). Editable installs heisst ~/source/mcps/<name>/ editieren + Claude-Code-Reload — meist 2-Zeilen-Patch statt Workaround.
• HTTP ist Default-Transport bei eigenen MCPs (Konvention). Stdio nur wenn explizit so dokumentiert.
• Ports-Inventar steht in mcps/_index.md (8765 m365, 8766 ticketpay, 8767 papierkram, 8768 runway, 8769 replicate).
• Bei einem neuen MCP: erst Status configured (Token fehlt noch), dann active.

Verwandte Bereiche

• _context — passives Nachschlagewerk (Prozesse, Glossar, Decision Records)
• _context — was der Zwilling tatsaechlich getan hat
• stack — Tool-Stack ohne MCP (passive Doku)