_context

Kontext: intern/capabilities/repos/

Zweck

Pro eigenem Code-Repo eine Pointer-Datei (Schema 5.19): wo liegt der Source, in welcher Sprache, wie installieren, was sind Inputs/Outputs, welche Skills nutzen es. Kein Code-Mirror — der Source bleibt in ~/source/<repo>/ oder ~/source/mcps/<repo>/.

Die meisten Eintraege hier sind unsere MCP-Forks und -Eigenbauten. Dazu gehoeren auch andere Tools (Remotion-Renderer etc.), wenn sie als Capability gebraucht werden.

Was gehoert hier rein / NICHT rein

Hier rein:

• Pointer auf eigene MCP-Forks (gsuite, lexware) und Eigenbauten (m365, papierkram, ticketpay, runway, replicate, sevdesk, vf-hosted)
• Pointer auf eigene Tools die ein Skill braucht (Renderer, Generatoren)
• Source-Pfad, Language, Entrypoint, Inputs/Outputs als Frontmatter

NICHT hier rein:

• Eigentlicher Source-Code → bleibt in ~/source/...
• MCP-Beschreibung (Tools, Auth, Quirks) → [[../mcps/]]
• Setup-Anleitung des Tools → in der [[../mcps/<name>]]-Datei

Fuer Agents

• Rule 18 (eigene Tools vor Workaround): Bevor du sagst „Tool X kann Y nicht”: diesen Index pruefen. Source-Edit + Claude-Code-Reload ist editable installiert — meist ein 2-Zeilen-Patch, kein Workaround.
• Source-Wurzel: ~/source/mcps/ (Top-Level-README.md ist redundant, dieses Vault ist die SoT).
• Bei Code-Aenderung: editable installs heisst nur Claude-Code-Reload, kein Reinstall — ausser bei pyproject.toml-Aenderungen.

Lokale Konventionen

• Frontmatter Schema 5.19: id, type=capability_repo, name, purpose, git_url (oder lokaler Pfad), language, entrypoint (Install-Command), inputs, outputs, used_by_skills, status
• Forks: Version mit eigenem Suffix (z.B. 0.4.1+marvin.1) damit klar ist dass es ein Fork ist
• Eigene MCPs: HTTP als Default-Transport (nicht stdio)