Ein moderner KI-Agent wie Claude kann erstaunlich viel: Quellcode lesen, Datenbanken abfragen, Helm-Charts interpretieren, über kubectl in einen laufenden Cluster eingreifen. Die Fähigkeiten sind da. Was in der Praxis fast immer fehlt, ist etwas Banaleres — ein Einstiegspunkt. Der Agent kann alles lesen, aber er weiß nicht, wo es losgeht.

Genau diese Lücke schließt ein Bootstrap-Skill: eine einzige Markdown-Datei, die einen Agenten an alle Artefakte eines Projekts heranführt und ihm sagt, wie sie zusammenhängen. Im dritten Teil unserer Pipeline-Serie ist dieses Prinzip schon aufgetaucht — dort als „Skills-Knoten”, der den Pipeline-Betrieb bootstrappt. Dieser Artikel zoomt heraus: Pipeline-Operation ist nur ein Spezialfall. Das allgemeine Muster trägt jede App, jeden Service, jedes Projekt.

Was ein Bootstrap-Skill ist

Ein Bootstrap-Skill ist kein Code und keine Konfig-Magie. Es ist eine Wegweiser-Datei. Sie enthält selbst kaum Logik — sie verweist. Auf das Code-Repo. Auf die Daten-Orte. Auf das Deployment. Und vor allem: auf die Querverbindungen zwischen all dem.

Der Name ist wörtlich gemeint. So wie ein User-Prompt die Pipeline-Generierung bootstrappt und der Skills-Knoten den Betrieb, so bootstrappt diese eine Datei das gesamte Arbeiten des Agenten an einem Projekt: aus „kann lesen” wird „weiß, wo es losgeht”.

Die Kernidee: Ein Agent ohne Bootstrap-Skill ist wie ein neuer Kollege, dem man Zugang zu allen Systemen gibt — aber kein Onboarding. Der Zugang allein macht ihn nicht produktiv. Der Bootstrap-Skill ist das Onboarding-Dokument, das nie veraltet, weil es im Repo neben dem Code lebt.

Das Muster: die vier Fundamente + der Bootstrapper

Jedes nicht-triviale Software-Artefakt steht auf denselben vier Fundamenten. Ein guter Bootstrap-Skill benennt sie explizit und — entscheidend — verdrahtet sie miteinander:

1. Implementierung — wo liegt der echte Quellcode? Kein Wiki-Auszug, sondern das Repo, das der Agent direkt lesen kann.

2. Daten-Orte — wo kommen die Daten rein, wo gehen sie raus? Repos, Buckets, Datenbanken, PVCs, Filebrowser-Pfade.

3. Deployment — Helm-Chart, Image-Tags, Environment-Variablen, Namespace, ArgoCD-App, Ingress-Hostname.

4. Querverbindungen — die Kanten, nicht nur die Knoten. Wenn der Agent in Node A einen Fehler vermutet, muss er von dort zum Helm-Chart und von dort zum laufenden Pod navigieren können — ohne dass ein Mensch den nächsten Schritt einleitet.

Diese vier bilden das Quadrat am Boden. Was sie zusammenhält, ist der fünfte Knoten an der Spitze: der Bootstrap-Skill selbst. Er ist die einzige Stelle, an der alle vier Kanten zusammenlaufen — genau das, was die Krake im Bild oben tut: acht Arme, fünf Artefakte, ein Zentrum, das alles greift und festhält.

So sieht das konkret aus

Damit es nicht abstrakt bleibt — hier ein anonymisiertes Beispiel einer realen Bootstrap-Skill-Datei. Es geht um eine kleine selbstgebaute App (git-versionierter Datenstore statt Datenbank), reduziert aufs Wesentliche:

---
name: my-app
description: >
  Bootstrap-Skill für My-App — selbstgebaute Pipeline-App auf dem
  Standard-Helm-Chart. Erzeugt aus Eingangs-Sheets je Periode ein
  Artefakt, vergibt fortlaufende Nummern, rendert PDFs. Ergebnisse
  git-versioniert. Dashboard unter my-app.intern.
---

# My-App – Bootstrap-Skill

> Dieser Skill ist der Bootstrapper: Einstiegspunkt auf ALLE Artefakte.
> Source of Truth des Verhaltens ist .../MyAppDag/README.md.

## Die vier Fundamente

### 1. Implementierung
| Was             | Ort                                          |
|-----------------|----------------------------------------------|
| Pipeline-Code   | .../dags/MyAppDag (selbstbeschreibende Nodes)|
| Mapping-Logik   | SemanticMyApp.cs -> RecipientMap             |
| Image           | ghcr.io/org/my-app:latest                    |

### 2. Daten-Orte
| Was              | Ort                                         |
|------------------|---------------------------------------------|
| Daten-Repo       | git@github.com:org/data.git (Pfad my-app/)  |
| Filebrowser      | http://my-app.intern/filebrowser/           |
| Eingangs-Sheets  | Google Sheet <id>                           |

### 3. Deployment
| Was        | Ort / Status                                  |
|------------|-----------------------------------------------|
| Helm-Chart | charts/standard-pipeline (values_myapp.yaml)  |
| ArgoCD-App | my-app (ns my-app)                            |
| CronJobs   | 05:00 ingest · 05:15 assign · 05:30 render    |
| git-sync   | */15 Push-Back ins Daten-Repo                 |

### 4. Querverbindungen
- Sheet -> Pipeline -> Git: Output landet in data/my-app/, git-sync pusht.
- Code -> Empfänger: RecipientMap verknüpft Key -> Empfänger.
- Deploy <-> Cluster: values_myapp.yaml -> ArgoCD-App -> ns my-app.

## Konventionen & Gotchas
- Manuelles Freigabe-Gate: Artefakt wird erst nach Kopieren weiterverarbeitet.
- git-sync als uid 1000 ohne passwd-Eintrag bricht ab -> Fix per InitContainer.
- Frischer PVC: subPath einmalig auf uid 1000 chownen.

Kein Geheimwissen. Eine Markdown-Datei, die dem Agenten sagt, wo die vier Fundamente liegen, wie sie zusammenhängen und welche Fallstricke es gibt. Mit dieser einen Datei kann ein Agent die App ab Sekunde eins betreiben, debuggen und erweitern — ohne dass ein Mensch den Kontext mündlich nachreicht.

Warum Operation nur ein Spezialfall ist

Der Pipeline-Operation-Artikel zeigt Monitoring, Debug, Extend, Run — alles agentengetrieben. Diese vier Operationen sind genau das, was ein Bootstrap-Skill ermöglicht, sobald die Fundamente verdrahtet sind. Aber sie sind nicht auf Data Pipelines beschränkt:

Eine Web-App mit git-versioniertem Markdown-Store statt Datenbank? Vier Fundamente, ein Bootstrap-Skill.
Ein 3PL-Middleware-Service, der zwischen zwei Systemen vermittelt? Gleiches Muster.
Ein internes CRM, ein Theme-Repo, eine IoT-Backend-Komponente? Jedes Mal dasselbe: Code, Daten, Deployment, Querverbindungen — gebündelt in einer Datei.

Die Pipeline-Operation ist die Variante, bei der die „Implementierung” ein DAG ist und „Run” kubectl create job --from=cronjob/... heißt. Tausche den DAG gegen eine FastAPI-App und „Run” gegen „rollout restart” — das Muster bleibt identisch. Bootstrap-Skill ist das Allgemeine, Pipeline-Operation der Spezialfall.

Faustregel: Sobald ein zweiter Mensch — oder ein Agent — ein Artefakt betreiben, debuggen oder erweitern soll, ohne dass du danebensitzt, schreibst du einen Bootstrap-Skill. Spätestens ab der zweiten App zahlt sich das Muster aus: Du schreibst nicht mehr Onboarding, du schreibst Wegweiser.

Wann man einen schreibt — und was reingehört

Aus unserer Praxis hat sich eingebürgert: bei jeder neuen App entsteht zuerst der Bootstrap-Skill, noch bevor die erste Zeile Betriebs-Doku irgendwo anders landet. Er ist der Anker, auf den alles andere zeigt.

Was reingehört:

Eine description, die ein Agent als Routing-Signal lesen kann — Was ist die App? Welches Muster (Pipeline? Web-App? Middleware?)? Wo läuft sie?
Die vier Fundamente als Tabellen — kompakt, mit echten Pfaden und Hostnamen, nicht mit Prosa.
Die Querverbindungen explizit — das ist der Teil, den Menschen im Kopf haben und nie aufschreiben. Genau der fehlt dem Agenten.
Gotchas & Konventionen — die Fallstricke, über die du schon mal gestolpert bist. Jeder dokumentierte Gotcha ist ein Debug-Zyklus, den der Agent überspringt.
Verweise auf verwandte Skills — Rollen-Skills, Schwester-Apps, Eskalationspfade.

Was nicht reingehört: die Logik selbst. Der Bootstrap-Skill dupliziert keinen Code und kein README. Er verweist. Wenn sich die Logik ändert, ändert sich der Code — der Wegweiser bleibt gültig, weil er auf den Code zeigt, nicht ihn nacherzählt.

Der entscheidende Schritt ist nicht das LLM — das gibt es. Der entscheidende Schritt ist, deine Artefakte so zu erschließen, dass ein Agent überhaupt navigieren kann. Eine Krake mit acht Armen nützt nichts, wenn sie nicht weiß, wonach sie greifen soll. Der Bootstrap-Skill sagt es ihr — in einer einzigen Markdown-Datei.

Und falls ihr genau diese Erschließung nicht selbst aufsetzen wollt: Unser Agent Ops Team baut die Fundamente, verdrahtet die Querverbindungen und übergibt euch Projekte, die ein KI-Agent ab Tag eins betreiben kann.

Reveal & Agentic Ops kennenlernen →